| 01:52 |
jonsykkel |
cool, i can drill my nats with random hamering |
| |
↖ |
| 01:53 |
jonsykkel |
in about 100sec on avg |
| 01:54 |
jonsykkel |
http://zzz.st/up/zu6XhbEb/ |
| |
~ 4 hours 55 minutes ~ |
| 06:50 |
PeterL |
I was just thinking, would it be helpful to have a message that you send to a peer that is essentially "what have you got for my AT?", and then you could use the response in your address cast to the cold peer? |
| |
↖ |
| |
~ 58 minutes ~ |
| 07:48 |
PeterL |
I'm updated to 9971 now |
| |
~ 2 hours 5 minutes ~ |
| 09:53 |
PeterL |
http://logs.bitdash.io/asciilifeform/2022-09-19#1113917 vex: nto sure if this is clear from context, but isn't deadname what the kids these days call their birth name after they decide to do a gender transition and start going by Katherine instead of Kenny? |
| 09:53 |
bitbot |
(asciilifeform) 2022-09-19 vex: copypate/ unaure if you're joking re deaname |
| 10:04 |
phf |
PeterL, i think vex thought that copypaste decided to go full troon, but i think cp is just using the term ironically to refer to an old handle |
| |
~ 49 minutes ~ |
| 10:54 |
asciilifeform |
http://logs.bitdash.io/pest/2022-09-19#1013203 << we've been doing this by hand on occasion but imho aint a good idea to mechanize it : in general, only a station's peer has any biz knowing its addr |
| 10:54 |
bitbot |
Logged on 2022-09-19 06:50:01 PeterL: I was just thinking, would it be helpful to have a message that you send to a peer that is essentially "what have you got for my AT?", and then you could use the response in your address cast to the cold peer? |
| 10:54 |
dulapbot |
(asciilifeform) 2022-09-18 asciilifeform: asciilifeform's curr. at for phf |
| 10:56 |
asciilifeform |
fwiw phf proposed related scheme not long ago |
| 10:56 |
bitbot |
Logged on 2022-09-07 14:02:14 phf[awt]: immediately that'll only solve 2x decode, but then peers can have some kind of coordination thing going |
| 10:57 |
PeterL |
asciilifeform: it would only be your peer that would get the addr, your warm peer is the one who already has it, and you would be giving it to your cold peer to update their AT, so what would be wrong with automating it? |
| 10:57 |
PeterL |
btw, asciilifeform, could I get your addr too, we seem to have lost our connection? |
| 10:58 |
asciilifeform |
PeterL: is same as before |
| 10:58 |
bitbot |
Logged on 2022-09-14 11:42:14 asciilifeform[6]: PeterL: 100.15.116.69:1337 |
| 11:00 |
asciilifeform |
PeterL: possibly asciilifeform misread, and what you're asking for is simply the existing prod |
| 11:01 |
asciilifeform |
( the response to your prod will contain your addr ) |
| 11:02 |
PeterL |
aha, I somehow missed that the prod contained the destination address in it |
| 11:04 |
asciilifeform |
PeterL: it does, that is in fact half the point of it, to send a meaningful addrcast you need to know yer own reachable addr, and when yer behind a nat, you learn it via prod responses |
| 11:04 |
PeterL |
awt: does the blatta need to keep repeating that it can't use mccrypt, couldn't that just be one error message at the beginning when it starts? |
| 11:05 |
PeterL |
asciilifeform: I updated the at, but it looks like we are still not connected? |
| 11:06 |
asciilifeform |
PeterL: likely culprit; i'ma have to look when hands free |
| 11:06 |
bitbot |
Logged on 2022-09-18 13:04:32 asciilifeform[5]: on local rack recently installed a new pfsense box and oughta take anuther look at the config, strongly suspects the fwd rule aint actually wurking |
| 11:06 |
PeterL |
maybe try updating my at to 162.247.151.243:55565 if not currently same? |
| 11:07 |
asciilifeform |
PeterL: in fact already same |
| 11:08 |
PeterL |
heh, strange that I am not getting anything from you? |
| 11:09 |
asciilifeform |
once we have the hammer, this headache oughta evaporate (along with the need to manually set fwd rules on nat) |
| 11:09 |
bitbot |
Logged on 2022-09-18 20:03:44 asciilifeform[5]: orthogonally: thinking re when is the correct time, hypothetically, for station to hammer ports. imho oughta be when received addrcast, and knows that atm peer is live, but attempt to connect to the ephemeral port in the addrcast not resulted in war |
| 11:09 |
dulapbot |
(asciilifeform) 2022-09-18 asciilifeform: we'll need this, eventually, asciilifeform suspects, for 'final solution to nat' |
| 11:12 |
asciilifeform |
ftr asciilifeform currently on 9973 (rolled back coupla d ago) so not has even addrcast |
| |
~ 16 minutes ~ |
| 11:28 |
awt |
PeterL: yes a once off warning would be better. |
| |
~ 1 hours 28 minutes ~ |
| 12:56 |
asciilifeform |
http://logs.bitdash.io/pest/2022-09-19#1013200 << nifty! approx what asciilifeform expected. |
| 12:56 |
bitbot |
Logged on 2022-09-19 01:52:50 jonsykkel: cool, i can drill my nats with random hamering |
| 12:59 |
asciilifeform |
awt: apropos: prolly oughta have control cmd '%ip' for a station behind nat to initially declare own external ip (found by operator outta band.) that way can actually revv up even if all peers in at behind nat |
| 12:59 |
asciilifeform |
(so addrcast has sumthing to throw even on boot, before receives any prod) |
| 13:01 |
asciilifeform |
... moar cleanly, '%addr' . if w/out args, displays current ip:port , such as is getting fed to addrcast. if with arg, can manually set ip:port. |
| 13:01 |
asciilifeform |
( naturally, overridden by prod if/when actually received a prod ) |
| 13:01 |
awt |
asciilifeform: makes sense |
| 13:01 |
* |
asciilifeform will stuff in next spec rev |
| 13:05 |
asciilifeform |
moar on subj of nats -- for hypothetical fyootor pestron, may want upnp port opener. ( problem being , asciilifeform cannot test such, does not have any konsoomer nat boxen where it worx ) |
| 13:05 |
asciilifeform |
some of the folx tuned in might tho |
| 13:06 |
asciilifeform |
( upnp is a kludge sometimes found in konsoomer 'cable box' nats where a magick json string thrown at certain internal port on gateway results in a fwd rule ) |
| 13:06 |
asciilifeform |
notoriously unreliable tho, nfi whether makes sense to spend cycles on subj. |
| 13:08 |
asciilifeform |
^ on further thought, prolly 100% waste of time given port hammerer, which oughta solve the problem conclusively |
| |
~ 5 hours 15 minutes ~ |
| 18:24 |
asciilifeform |
awt, phf, jonsykkel , et al: proposed 'hammer algo' : |
| |
↖ |
| 18:24 |
asciilifeform |
1. Station X and Y are peers; X is "cold" from Y's POV, and vice-versa, but each knows the other is live via connection to a common pestnet. |
| 18:25 |
asciilifeform |
2. T_c elapsed on X and Y, and the stations begin sending addrcasts to one another. |
| 18:25 |
asciilifeform |
3. X received an addrcast from Y, with ip_y:port_y. But port_y is blocked on Y's end by a 'symmetric' NAT. X will send prods to Y, but there is no answer. An interval T_p(X) elapses from the first attempt of X to provoke a response from Y without any such respo |
| 18:25 |
asciilifeform |
... response. |
| 18:25 |
asciilifeform |
4. Y similarly received an addrcast from X, with ip_x:port_x, but similarly to above, T_p(Y) elapses without a response. |
| 18:26 |
asciilifeform |
5. X begins to send prods to Y, choosing port_y (both in the transmitting socket and in the prod) randomly, in standard ephem. port range 1024–-65535. Hammering continues for an interval H(X), with delay between emitted packets H_d(X). |
| 18:27 |
asciilifeform |
6. Meanwhile, Y similarly sends randomized prods to X, for an interval H(Y) with delays between packets H_d(Y). |
| 18:27 |
asciilifeform |
7. Each shot by either side has a 1 in 64511 chance of 'getting lucky' if there is only one symmetric NAT standing between the peers; or a 1 / (64511^2) chance if ~both~ stations are trapped behind symmetric NATs. |
| 18:27 |
asciilifeform |
8. If either side receives a 'lucky' prod from the other, it immediately answers, and a connection is established. |
| 18:27 |
asciilifeform |
~fin~ |
| 18:28 |
* |
asciilifeform invites q's/comments |
| 18:30 |
* |
asciilifeform aint wholly certain re odds in (7) |
| 18:34 |
* |
asciilifeform suspects that the hammer time can be shortened considerably by preferentially exploring the space around the ephemeral ports seen in successfully-received prods from currently-warm peers -- many NATs issue ephemeral ports sequentially |
| |
↖ |
| 18:36 |
asciilifeform |
... in the simplest variant, start with highest_known_ephemeral--65535. |
| 18:37 |
asciilifeform |
^ worth empirical test imho |
| 18:38 |
asciilifeform |
see also: this likbez re subj. |
| |
↖ |
| |
~ 1 hours 15 minutes ~ |
| 19:54 |
* |
asciilifeform realized obv. lulgaffe in hammer algo -- highest_known_ephemeral needed is of the ~counterparty~, not yer own. i.e. would have to be slipped into addrcast, to be of use. |