cgra: asciilifeform, re potentially permanently broken pest chains mixed with temporarily broken ones: would an exponential backoff getdata retry schedule make sense?
lobbes[cgra|asciilifeform]: odd, I'm not seeing mod6 broadcasts in my station logs yet. Possibly due to my running an older v9971 blatta but idk
asciilifeform: wb lobbes
asciilifeform: cgra: prolly good idea
lobbes[asciilifeform]: ty asciilifeform. I've been engaged on other fronts, so I'm a bit behind the logs. I apologize in advance to any peers if my station is emitting any strange. I gotta spend some time tonight re-reading the spec and whatnot
asciilifeform: lobbes: 0xfa pre-draft spec here, if you haven't seen yet.
asciilifeform: lobbes: ftr there's a # of threads where asciilifeform concluded '... and oughta amend spec' but not did this yet.
phf: test
phf: hmm, network was claiming it was down...
phf: i had a moment of clarity last night, and in between realizing that i've probably already lived longer, than i have left to live, i had a sudden flash of recollection and remembered my gpg password
phf: monsegnor asciilifeform, signpost, cgra and any other willing parties please send me peering information for your respective stations
phf: i also have crtdaydreams in my station list, but that one also never connected, which probably means it's 3 month old key
cgra: phf, peering info for you. ip address is outdated
phf[cgra]: ok, cool, so you're theoretically broadcasting addresscast for me?
phf: (("signpost" 1) ("jonsykkel" 96) ("unpx" 144))
phf: (("signpost" 1) ("jonsykkel" 96) ("unpx" 144))
phf: whoops
phf: well, that's the addresscasts i'm getting
phf: unpx and jonsykkel can i also get peering info
jonsykkel[cgra|asciilifeform]: sure, sec
phf: multline test, first line
phf: billymg, asciilifeform can you guys update your respective loggers with awt's recent multiline patch?
phf: jonsykkel, you're running your own, c based client, right?
cgra: http://logs.bitdash.io/pest/2023-02-23#1024080 << yeah. do we have common peers? awt,billymg,dulapbot,jonsykkel,lobbes,signpst
bitbot[asciilifeform|cgra]: Logged on 2023-02-23 13:39:24 phf[awt]: ok, cool, so you're theoretically broadcasting addresscast for me?
jonsykkel[cgra|asciilifeform]: corect
phf: jonsykkel, cool, i'm getting prod requests from you, that nobody else asked for yet, so i'm going to implement that next
jonsykkel[cgra|asciilifeform]: yep, currently spams those once/min
phf: cgra, yeah, we got a bunch, but come to think of it nobody but theoretically only awt (and jonsykkel?) will support addresscast rebroadcast
jonsykkel[cgra|asciilifeform]: mine pestron rebroadcasts those yes
signpost[cgra]: in which we learn verisimilitude was a high endurance jonsykkel troll
lobbes[cgra|asciilifeform]: phf: my peering info, if you want it
asciilifeform pressed 9969 (trying on desk station 1st)
phf: asciilifeform, is prod the only op that tells you your address?
asciilifeform: phf: peering info
asciilifeform: phf: correct
phf: also ty
asciilifeform: np
phf: so prods are otherwise functionally equivalent. whether ack is set or no is mostly note to self
signpost[cgra] reading phf, cool
asciilifeform: phf: notion was, a prod oughta be answered with a prod. theoretically could omit 'this is an answr' mark, but imho not hurts
asciilifeform still seeing phf as hearsay, btw
phf: i still think that your station is misconfigured :>
phf: as far as packet forwarding
asciilifeform: quite likely
asciilifeform gears up for n-th attempt at unfucking subj
signpost[cgra]: yeah, I've got ascii as hearsay still also.
asciilifeform: apropos -- is anyone from the set of folx who have working direct peerings w/ asciilifeform , in a nat while doing so ?
asciilifeform suspects -- not
phf: i would guess that one can sort of rely on prods to know what ones ip is
lobbes[cgra|asciilifeform]: fwiw I am not behind nat and am directly peering with ascii (as far as I can tell)
asciilifeform btw seeing multi-second lags in weechat lagmeter ; and kilometres of 'couldn't use mcrypt...'
phf: lobbes, what does your at say? specifically what's the port
lobbes[cgra|asciilifeform]: phf: as in, what does my AT entry for asciilifeform read?
awt[cgra]: asciilifeform: if you haven't built mcrypt, see: http://logs.bitdash.io/pest/2023-02-20#1023890
bitbot[cgra]: Logged on 2023-02-20 11:11:59 awt: PeterL: Looks like I didn't. To aleviate for now you can comment out line 80 in lib/message.py.
asciilifeform: ty awt
phf: lobbes, yes
asciilifeform: awt: also loox like it's sending addrcasts erry coupla min
asciilifeform thought that per new patch, will only addrcast if notices ip changed
asciilifeform: + on boot
signpost[cgra]: would be funny if ascii's station is crash-looping each send, and only making it partway through peers
lobbes[cgra]: phf: port 51465
phf: asciilifeform ^
asciilifeform: signpost: not detectably (seems to send n^2 addrcasts, n being # of coldpeers)
asciilifeform: loox like these fire erry ~minute
asciilifeform: actually nope. here's ~15s apart, lol
asciilifeform: awt: is there some flag that needs to be set to turn off the old spammy addrcast behaviour on 9969 ?
awt[cgra|asciilifeform]: asciilifeform: no. 9969 only broadcasts ac when send_address_cast is set to 1 in the knobs table. Aftward is set to 0.
awt[cgra]: It sends address cast on startup, when a key is added, and when prod reports changed address.
jonsykkel[cgra|phf]: phf one of ur messsages selfchain points to a asciilifeform message and another one self+netchain is 00000. in case u are un aware
asciilifeform: awt: this is defo not what asciilifeform is seeing currently on 9969
signpost[phf|cgra] just received a replay
asciilifeform goes to actually read the patch...
signpost[phf|cgra]: would be nice to log whose packet caused this
asciilifeform: ftr the thing is sending addrcasts ~nonstop
signpost[asciilifeform]: rather, send as part of IRC notice
asciilifeform: (and no, ip not changed)
phf: jonsykkel, i haven't been keeping any state across reboots, so normally it'll be either 0 0 or 0 netchain
phf: i normally do a prod on launch, but this one was a result of a buggy situation
phf: but the one where it points to asciilifeforms is a bug, ty, i'll investigate. does your client complains when the chain is broken per spec?
jonsykkel[cgra]: it does yes, for immediate messages
phf: ok, i'll fix it then
jonsykkel[cgra]: (which i learned later is incorrect behavior, orginally misunderstood spec. fork lamp supposed to light up for hearsay only as i understand it)
jonsykkel[cgra]: cool
awt[cgra|asciilifeform]: asciilifeform: not seeing any PROD messages from you - was hoping to be able to check your version.
phf: jonsykkel, ty on the asciilifeform thing. it was a silly bug in a lookup function
awt[cgra|asciilifeform]: asciilifeform: try %knob send_address_cast 0
jonsykkel[cgra]: sure
phf: ok, i'm getting decodable addresscasts from asciilifeform and cgra, so i'll implement that part next..
asciilifeform: awt: set the knob to 0, but somehow still sending addrcasts nonstop
awt[cgra]: asciilifeform: comment out server.py:200 to stop.
awt[asciilifeform|cgra]: ok there I got your init prod asciilifeform
asciilifeform: awt: commented; ~still~ sends addrcasts
phf[asciilifeform|cgra]: is that stop entirely? possibly to just reduce the frequency? i'd still like to addresscast w/ ascii
asciilifeform: phf: lol it still spams
awt[cgra]: asciilifeform: sorry that line was for the initial ac. Also need to comment out 204
asciilifeform will leave it spamming so phf can test his eater
asciilifeform: ty awt
awt[asciilifeform|cgra]: Curious to know why spamming for asciilifeform
asciilifeform: awt: strongly suspect that 'did addr change' detector aint nat-friendly; but not read the sores yet
phf: imho did addr change should work directly from prod, and no other way
asciilifeform: there's the question of wat-do re port tho
asciilifeform: under nat, it'll be ephemeral port, i.e. rubbish
asciilifeform: should trigger cast or not ? if yes, it'll fire nonstop. which is what asciilifeform suspects is happening on his desk
phf: i thought under nat port is reused
phf: so e.g. if i'm sending to ascii from port 12345 then i'm also sending to anybody else from same port
asciilifeform: sometimes yes, sometimes not
phf: actually i'm wrong aren't i..
awt[cgra|asciilifeform]: asciilifeform: works directly from prod. See station.py:198
asciilifeform: seems to depend on the nattron
awt[cgra|asciilifeform]: compares entire address, not just IP
asciilifeform: awt: this might explain the nonstop addrcast thing
awt[cgra|asciilifeform]: asciilifeform: in that case you can disable it there instead of commenting out in server.py. Then you'll still get the ac on startup and addition of key.
phf: asciilifeform, actually i'd like to see a nat that doesn't do it that way
awt[cgra|asciilifeform]: For the time being.
phf: because if all packets come from same port on machine, why would nat randomize ports on exodus?
awt[cgra]: asciilifeform: from my outgoing prod message to your station, port/ip remain constant: port: 21580
asciilifeform: awt: nfi which peering is triggering it. evidently not that one
asciilifeform: it's not a timer trigger tho, quite clearly
asciilifeform: seems to be going more or less nonstop.
awt[cgra|asciilifeform]: Yes could trigger as often as you receive a prod with a different address. You should be able to see all your incoming prod messages in the log.
phf: the whole prod based ip then is not particulraly trivial
asciilifeform: phf: given idjicy of commonplace nat -- defo not trivial
phf: imho one needs to keep seen-as-address per each station, and then have smart code to figure out if one can even make claims about "external address". so e.g. if everyone tells you different addresses, then you're sol. if only one station, then that station is broken. if everyone ag
phf: grees on your address, then can go to stage two of hole punching
asciilifeform: phf: if yer using N ips simult. (as explicitly design goal, per spec, to allow this) you may well see 'diff external addr per peer' always
asciilifeform aint, presently, doing this, fwiw
phf: in which case you're in a completely different territory, from the addresscast problem
asciilifeform: rright, simply 1 moar point in re 'addrcast aint trivial'
awt[cgra] curious to see asciilifeform's other inbound PROD messages
phf: or you have operational modes or whatever
asciilifeform: may have to at least have modes 'in nat' 'not in nat'
asciilifeform: (oughta be simple to detect'
asciilifeform restarted pestron, and it's nao phucked:
asciilifeform: ' Peer with duplicate address or handle id detected ...' for all peers, kilometres of this
asciilifeform: seems to operate tho, otherwise
asciilifeform: but over9000 annoying, debug log nao ~useless when scrolled in realtime
mod6[asciilifeform]: hey all, thanks for your feedback! i've had hands full last couple of days with snow.
asciilifeform: hmm this not received by either logger ?
mod6[asciilifeform]: for sure, high-val ascii chars from playback has snafu'd irssi here. when I get a chance, day or so, will get a new client and reconn/re-sync and continue working on whatever probs i've got.
mod6[asciilifeform]: windows are totally hosed in this thing now, including privmsg. no worries tho. cheers :]
asciilifeform unrelatedly, notices that his AT entries for 3 peers ( bitbot, TomServo, PeterL ) are equal to asciilifeform's ~own~ addr . this oughta be categorically impossible, lol
asciilifeform: actually, 3 others, too -- shinohai, phf, crtdaydreams, ditto
asciilifeform: lol !
asciilifeform: addrcast apparently catastrophically broken in current blatta
asciilifeform: all the entries in question are timestamped today
asciilifeform: awt ^
asciilifeform: seems to explain this lul.
bitbot[asciilifeform]: Logged on 2023-02-23 17:41:53 asciilifeform[5]: ' Peer with duplicate address or handle id detected ...' for all peers, kilometres of this
asciilifeform: incidentally, 2 or moar peers sitting behind 1 ip aint necessarily an error condition. (supposing that they ~actually~ are; rather than whateverthefuck is going on currently re addrcast)
asciilifeform: nuffin in the spec requires addrs to be unique.
asciilifeform: ( hypothetically e.g. asciilifeform may have his flagship station + a test station with separate key, in one lan )
awt[asciilifeform]: asciilifeform: %at
awt[asciilifeform]: lol
awt[asciilifeform]: asciilifeform: I believe I saw this once. if you are running two stations on the same net, or start a new one in time to get your own previous address cast. Don't remember exactly how it happened.
awt[asciilifeform]: Or if you just restart quickly, having sent out a flood of address casts, you can somehow end up receiving and processing your own ac.
awt[asciilifeform]: asciilifeform: I think your at will repair itself if you stop, wait a bit for your acs to clear, then start back up. Something to try anyway.
awt[asciilifeform]: might have to "manually" fix at entries for peers who aren't online.
phf: lulzy
asciilifeform: awt: nah, survived coupla hrs and coupla restarts
asciilifeform: http://logs.bitdash.io/pest/2023-02-23#1024230 << to asciilifeform , seems like oughta be simple to perma-kill this ( yer station always knows 'msg with $hash is sumthing i sent' )
bitbot[asciilifeform]: Logged on 2023-02-23 20:11:41 awt: Or if you just restart quickly, having sent out a flood of address casts, you can somehow end up receiving and processing your own ac.
asciilifeform: http://logs.bitdash.io/pest/2023-02-23#1024229 << fwiw asciilifeform was not running >1 station from 1 lan at any point to date
bitbot[asciilifeform]: Logged on 2023-02-23 20:09:07 awt: asciilifeform: I believe I saw this once. if you are running two stations on the same net, or start a new one in time to get your own previous address cast. Don't remember exactly how it happened.
asciilifeform: fwiw all 6 of the listed peers still showing asciilifeform's own addr.
asciilifeform: meanwhile, apropos of nuffin : gptchat lulz. ( 'shooting fish in barrel', arguably, but will leave the lolgaffes to alert reader )
asciilifeform: eh, watever, will spoil: both algos the thign gives are straight wiki cribs, and neither actually answers the reqs of the prompt, lol