jonsykkel[asciilifeform]: cool, i can drill my nats with random hamering
jonsykkel[asciilifeform]: in about 100sec on avg
PeterL[asciilifeform]: 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?
PeterL[asciilifeform]: I'm updated to 9971 now
PeterL[asciilifeform]: 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?
bitbot[asciilifeform]: (asciilifeform) 2022-09-19 vex: copypate/ unaure if you're joking re deaname
phf[asciilifeform]: 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
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
dulapbot: (asciilifeform) 2022-09-18 asciilifeform: asciilifeform's curr. at for phf
bitbot[asciilifeform]: 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?
asciilifeform: fwiw phf proposed related scheme not long ago
bitbot[asciilifeform]: 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
PeterL[asciilifeform]: 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?
PeterL[asciilifeform]: btw, asciilifeform, could I get your addr too, we seem to have lost our connection?
asciilifeform: PeterL: is same as before
bitbot[asciilifeform]: Logged on 2022-09-14 11:42:14 asciilifeform[6]: PeterL: 100.15.116.69:1337
asciilifeform: PeterL: possibly asciilifeform misread, and what you're asking for is simply the existing prod
asciilifeform: ( the response to your prod will contain your addr )
PeterL[asciilifeform]: aha, I somehow missed that the prod contained the destination address in it
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
PeterL[asciilifeform]: 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?
PeterL[asciilifeform]: asciilifeform: I updated the at, but it looks like we are still not connected?
asciilifeform: PeterL: likely culprit; i'ma have to look when hands free
bitbot[asciilifeform]: 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
PeterL[asciilifeform]: maybe try updating my at to 162.247.151.243:55565 if not currently same?
asciilifeform: PeterL: in fact already same
PeterL[asciilifeform]: heh, strange that I am not getting anything from you?
asciilifeform: once we have the hammer, this headache oughta evaporate (along with the need to manually set fwd rules on nat)
bitbot[asciilifeform]: 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
dulapbot: (asciilifeform) 2022-09-18 asciilifeform: we'll need this, eventually, asciilifeform suspects, for 'final solution to nat'
asciilifeform: ftr asciilifeform currently on 9973 (rolled back coupla d ago) so not has even addrcast
awt[asciilifeform]: PeterL: yes a once off warning would be better.
asciilifeform: http://logs.bitdash.io/pest/2022-09-19#1013200 << nifty! approx what asciilifeform expected.
bitbot[asciilifeform]: Logged on 2022-09-19 01:52:50 jonsykkel: cool, i can drill my nats with random hamering
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
asciilifeform: (so addrcast has sumthing to throw even on boot, before receives any prod)
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.
asciilifeform: ( naturally, overridden by prod if/when actually received a prod )
awt[asciilifeform]: asciilifeform: makes sense
asciilifeform will stuff in next spec rev
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 )
asciilifeform: some of the folx tuned in might tho
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 )
asciilifeform: notoriously unreliable tho, nfi whether makes sense to spend cycles on subj.
asciilifeform: ^ on further thought, prolly 100% waste of time given port hammerer, which oughta solve the problem conclusively
asciilifeform: awt, phf, jonsykkel , et al: proposed 'hammer algo' :
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.
asciilifeform: 2. T_c elapsed on X and Y, and the stations begin sending addrcasts to one another.
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
asciilifeform: ... response.
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.
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).
asciilifeform: 6. Meanwhile, Y similarly sends randomized prods to X, for an interval H(Y) with delays between packets H_d(Y).
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.
asciilifeform: 8. If either side receives a 'lucky' prod from the other, it immediately answers, and a connection is established.
asciilifeform: ~fin~
asciilifeform invites q's/comments
asciilifeform aint wholly certain re odds in (7)
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
asciilifeform: ... in the simplest variant, start with highest_known_ephemeral--65535.
asciilifeform: ^ worth empirical test imho
asciilifeform: see also: this likbez re subj.
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.