#pest | 2023-02-23

odd, I'm not seeing mod6 broadcasts in my station logs yet. Possibly due to my running an older v9971 blatta but idk

~ 1 hours 22 minutes ~

10:15

wb lobbes

10:16

cgra: prolly good idea

~ 2 hours 25 minutes ~

12:41

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

12:52

lobbes: 0xfa pre-draft spec here, if you haven't seen yet.

12:53

lobbes: ftr there's a # of threads where asciilifeform concluded '... and oughta amend spec' but not did this yet.

~ 23 minutes ~

13:16

test

13:16

hmm, network was claiming it was down...

13:18

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

13:19

monsegnor asciilifeform, signpost, cgra and any other willing parties please send me peering information for your respective stations

13:22

i also have crtdaydreams in my station list, but that one also never connected, which probably means it's 3 month old key

13:26

cgra

phf, peering info for you. ip address is outdated

13:39

ok, cool, so you're theoretically broadcasting addresscast for me?

↖ ↖ ↖ ↖

13:40

(("signpost" 1) ("jonsykkel" 96) ("unpx" 144))

13:40

(("signpost" 1) ("jonsykkel" 96) ("unpx" 144))

13:40

whoops

13:40

well, that's the addresscasts i'm getting

13:40

unpx and jonsykkel can i also get peering info

13:42

sure, sec

13:42

multline test, first line

13:43

http://zzz.st/up/WJ4eqVlc/phf.asc

13:44

billymg, asciilifeform can you guys update your respective loggers with awt's recent multiline patch?

13:47

jonsykkel, you're running your own, c based client, right?

13:47

cgra

http://logs.bitdash.io/pest/2023-02-23#1024080 << yeah. do we have common peers? awt,billymg,dulapbot,jonsykkel,lobbes,signpst

13:47

Logged on 2023-02-23 13:39:24 phf[awt]: ok, cool, so you're theoretically broadcasting addresscast for me?

13:47

corect

13:48

jonsykkel, cool, i'm getting prod requests from you, that nobody else asked for yet, so i'm going to implement that next

13:49

yep, currently spams those once/min

13:51

cgra, yeah, we got a bunch, but come to think of it nobody but theoretically only awt (and jonsykkel?) will support addresscast rebroadcast

13:52

phf http://paste.deedbot.org/?id=Gup3

13:52

mine pestron rebroadcasts those yes

13:53

in which we learn verisimilitude was a high endurance jonsykkel troll

13:55

lol

14:04

phf: my peering info, if you want it

14:08

*

asciilifeform pressed 9969 (trying on desk station 1st)

14:11

asciilifeform, is prod the only op that tells you your address?

14:11

phf: peering info

14:11

phf: correct

14:11

also ty

14:12

np

14:18

so prods are otherwise functionally equivalent. whether ack is set or no is mostly note to self

~ 38 minutes ~

14:56

*

signpost reading phf, cool

14:58

phf: notion was, a prod oughta be answered with a prod. theoretically could omit 'this is an answr' mark, but imho not hurts

14:58

*

asciilifeform still seeing phf as hearsay, btw

14:59

i still think that your station is misconfigured :>

14:59

as far as packet forwarding

14:59

quite likely

14:59

*

asciilifeform gears up for n-th attempt at unfucking subj

14:59

yeah, I've got ascii as hearsay still also.

15:00

apropos -- is anyone from the set of folx who have working direct peerings w/ asciilifeform , in a nat while doing so ?

15:01

*

asciilifeform suspects -- not

15:01

i would guess that one can sort of rely on prods to know what ones ip is

15:02

fwiw I am not behind nat and am directly peering with ascii (as far as I can tell)

15:02

*

asciilifeform btw seeing multi-second lags in weechat lagmeter ; and kilometres of 'couldn't use mcrypt...'

15:02

lobbes, what does your at say? specifically what's the port

15:03

phf: as in, what does my AT entry for asciilifeform read?

15:03

asciilifeform: if you haven't built mcrypt, see: http://logs.bitdash.io/pest/2023-02-20#1023890

15:03

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.

15:04

ty awt

15:04

lobbes, yes

15:04

awt: also loox like it's sending addrcasts erry coupla min

15:04

*

asciilifeform thought that per new patch, will only addrcast if notices ip changed

15:04

+ on boot

15:04

would be funny if ascii's station is crash-looping each send, and only making it partway through peers

15:05

phf: port 51465

15:05

asciilifeform ^

15:06

signpost: not detectably (seems to send n^2 addrcasts, n being # of coldpeers)

15:08

loox like these fire erry ~minute

15:09

actually nope. here's ~15s apart, lol

15:09

awt: is there some flag that needs to be set to turn off the old spammy addrcast behaviour on 9969 ?

15:11

asciilifeform: no. 9969 only broadcasts ac when send_address_cast is set to 1 in the knobs table. Aftward is set to 0.

15:12

It sends address cast on startup, when a key is added, and when prod reports changed address.

15:12

phf one of ur messsages selfchain points to a asciilifeform message and another one self+netchain is 00000. in case u are un aware

15:12

http://zzz.st/up/zHgVMXOd/

15:13

awt: this is defo not what asciilifeform is seeing currently on 9969

15:13

*

signpost just received a replay

15:13

would be nice to log whose packet caused this

15:13

*

asciilifeform goes to actually read the patch...

15:13

rather, send as part of IRC notice

15:14

ftr the thing is sending addrcasts ~nonstop

15:14

(and no, ip not changed)

15:16

jonsykkel, i haven't been keeping any state across reboots, so normally it'll be either 0 0 or 0 netchain

15:16

i normally do a prod on launch, but this one was a result of a buggy situation

15:16

a

15:17

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?

15:19

it does yes, for immediate messages

15:19

ok, i'll fix it then

15:20

(which i learned later is incorrect behavior, orginally misunderstood spec. fork lamp supposed to light up for hearsay only as i understand it)

15:20

cool

15:21

asciilifeform: not seeing any PROD messages from you - was hoping to be able to check your version.

15:22

jonsykkel, ty on the asciilifeform thing. it was a silly bug in a lookup function

15:22

asciilifeform: try %knob send_address_cast 0

15:22

sure

15:24

ok, i'm getting decodable addresscasts from asciilifeform and cgra, so i'll implement that part next..

15:38

awt: set the knob to 0, but somehow still sending addrcasts nonstop

15:40

asciilifeform: comment out server.py:200 to stop.

15:42

ok there I got your init prod asciilifeform

15:44

awt: commented; ~still~ sends addrcasts

15:44

is that stop entirely? possibly to just reduce the frequency? i'd still like to addresscast w/ ascii

15:44

phf: lol it still spams

15:44

asciilifeform: sorry that line was for the initial ac. Also need to comment out 204

15:45

*

asciilifeform will leave it spamming so phf can test his eater

15:45

ty awt

15:45

Curious to know why spamming for asciilifeform

15:46

awt: strongly suspect that 'did addr change' detector aint nat-friendly; but not read the sores yet

15:46

imho did addr change should work directly from prod, and no other way

15:47

^

15:47

there's the question of wat-do re port tho

15:47

under nat, it'll be ephemeral port, i.e. rubbish

15:47

should trigger cast or not ? if yes, it'll fire nonstop. which is what asciilifeform suspects is happening on his desk

15:48

i thought under nat port is reused

15:48

so e.g. if i'm sending to ascii from port 12345 then i'm also sending to anybody else from same port

15:49

sometimes yes, sometimes not

15:49

actually i'm wrong aren't i..

15:49

asciilifeform: works directly from prod. See station.py:198

15:49

seems to depend on the nattron

15:49

compares entire address, not just IP

15:49

awt: this might explain the nonstop addrcast thing

15:50

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.

15:50

asciilifeform, actually i'd like to see a nat that doesn't do it that way

15:51

For the time being.

15:51

because if all packets come from same port on machine, why would nat randomize ports on exodus?

15:54

asciilifeform: from my outgoing prod message to your station, port/ip remain constant: port: 21580

15:55

awt: nfi which peering is triggering it. evidently not that one

15:56

it's not a timer trigger tho, quite clearly

15:56

seems to be going more or less nonstop.

15:58

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.

16:00

the whole prod based ip then is not particulraly trivial

16:01

phf: given idjicy of commonplace nat -- defo not trivial

16:02

􏿽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

16:02

􏿽grees on your address, then can go to stage two of hole punching

16:02

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

16:03

*

asciilifeform aint, presently, doing this, fwiw

16:04

in which case you're in a completely different territory, from the addresscast problem

16:04

rright, simply 1 moar point in re 'addrcast aint trivial'

16:05

*

awt curious to see asciilifeform's other inbound PROD messages

16:05

or you have operational modes or whatever

16:05

may have to at least have modes 'in nat' 'not in nat'

16:06

(oughta be simple to detect'

16:06

)

~ 1 hours 35 minutes ~

17:41

*

asciilifeform restarted pestron, and it's nao phucked:

17:41

' Peer with duplicate address or handle id detected ...' for all peers, kilometres of this

17:42

seems to operate tho, otherwise

17:42

but over9000 annoying, debug log nao ~useless when scrolled in realtime

~ 1 hours 54 minutes ~

19:37

mod6

hey all, thanks for your feedback! i've had hands full last couple of days with snow.

19:37

hmm this not received by either logger ?

19:37

mod6

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.

19:37

mod6

windows are totally hosed in this thing now, including privmsg. no worries tho. cheers :]

~ 22 minutes ~

19:59

*

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

19:59

actually, 3 others, too -- shinohai, phf, crtdaydreams, ditto

19:59

lol !

20:00

addrcast apparently catastrophically broken in current blatta

20:00

all the entries in question are timestamped today

20:00

awt ^

20:03

seems to explain this lul.

20:03

Logged on 2023-02-23 17:41:53 asciilifeform[5]: ' Peer with duplicate address or handle id detected ...' for all peers, kilometres of this

20:04

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)

20:05

nuffin in the spec requires addrs to be unique.

20:06

( hypothetically e.g. asciilifeform may have his flagship station + a test station with separate key, in one lan )

20:07

asciilifeform: %at

20:07

lol

20:09

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.

20:11

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.

20:17

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.

20:18

might have to "manually" fix at entries for peers who aren't online.

~ 2 hours 11 minutes ~

22:30

lulzy

~ 41 minutes ~

23:12

awt: nah, survived coupla hrs and coupla restarts

23:15

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' )

23:15

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.

23:16

http://logs.bitdash.io/pest/2023-02-23#1024229 << fwiw asciilifeform was not running >1 station from 1 lan at any point to date

23:16

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.

23:17

fwiw all 6 of the listed peers still showing asciilifeform's own addr.

~ 34 minutes ~

23:51

meanwhile, apropos of nuffin : gptchat lulz. ( 'shooting fish in barrel', arguably, but will leave the lolgaffes to alert reader )

23:53