#pest | 2021-11-15

asciilifeform still suspects it aint packet loss (in GBs of udp wankage carried out by asciilifeform , incl. trans-oceanic, saw 0 packet loss in the classical sense) but possibly buggy deduper.

awt: billymg: you should be able to verify that "seems to work" was forwarded from your main station by searching for it in the log

awt: if you care to, that is.

billymg: yeah, my bot's station didn't get that first messag

awt: clearly your main station received it

awt: possibly a routing issue?

billymg: ah, hrm, my last message, "yeah", didn't get logged

awt: perhaps message when from ascii to me, then billymg, then maybe bounce count exceeded somehow? Then was a dupe when it came directly from ascii with a lower bounce count?

awt: Could invalidate this theory by locating log of the message being sent to bot from billymg's station

billymg: if that's the case we should see more randomly dropped lines

billymg: not a bad theory, since previously my bot was connected to the same station as my irc client

awt: yeah also my box is way closer to you, if you are running it in CR

billymg: awt: i'm not, it's in asciilifeform's rack

awt: so that *could* explain the delay in asciilifeform's message reaching you

awt: oh

awt: lol but then where is asciilifeform running his?

asciilifeform: lol ping time to cr aint anywhere near 3sec

awt: possibly china

asciilifeform: awt: my test station is on desk, ~5ms ping from rack

awt: ok

awt: bounces is at 3 so shouldn't be a factor anyway unless it took an even more circuitous route

asciilifeform: awt: am i correct in supposing that the mechanism for superceding of hearsay by a direct packet aint in the coad yet ?

awt: asciilifeform: what does superceding mean here?

billymg: awt: minor request, you should add a page on your blog with all of the patches in one place, like http://billymg.com/bitdash-crawler-vtree/

asciilifeform: awt: http://www.loper-os.org/pub/pest/pest_draft.html#42322-in-wot-hearsay

billymg: all of the blatta patches

awt: what about this? http://share.alethepedia.com/blatta/

billymg: lol that works

billymg: didn't know it existed

awt: asciilifeform: yes there is not yet a hearsay buffer

asciilifeform: a

asciilifeform: this still doesn't 100% explain what billymg saw, tho..

awt: no. need to know if the packet left billymg's station, basically

asciilifeform: at some pt in near future i'ma set up a test station on dulap, but sadly prolly not until wk+ from nao

awt wodners if pest can get through the great firewall

billymg: http://paste.deedbot.org/?id=JTKF

billymg: awt: lemme know if those lines are helpful

awt: this your logger? 2021-11-15 17:27:53.790539 [127.0.0.1:7779] <- d4768c92c2c25e21

awt: if so, that line indicates 'yeah' was sent to your logger

billymg: awt: yep

billymg: but never showed up in logger station's logs

awt: now in your logger, if the bounce count was too high, there would be an message about rejecting a stale packet

awt: if that hex code doesn't show up anywhere in the bot logs then there's a connectivity issue

awt: which would be odd on the same machine

awt: billymg: the message could have been rejected for some other reason

awt: but there should be a record of that

awt: you just need to find d4768c92c2c25e21

asciilifeform: awt: asciilifeform aint an expert on chinese firewall, but iirc it doesn't throw out udp per se (unless endpoint on banlist)

awt: actually stale would be if the timestamp was too old sorry

billymg: awt: http://paste.deedbot.org/?id=fusJ

awt: billymg: there is actually NO output if the bounce count is too high to forward

billymg: so those lines invalidate the > maxbounces theory?

awt: no actually

billymg: oh

awt: I take that back, yes they do

billymg: lol that's what i thought you meant by "NO output"

awt: according to the code I'm looking at that message should have been forwarded to the irc client

awt: bounce count check is only for rebroadcast, and packet is sent to the irc client before that check

billymg: weird

awt: so if your last paste is your bot logs, it received the packet

awt: and marked it as duplicate

billymg: yeah, those are the bot's station's logs

billymg: but according to your code it should've still sent them to the connected bot?

awt: how could it be marked as duplicate if it came directly from you and there are no other instances in the log?

awt: billymg: is that the only line with that message id?

awt: seems unlikely

billymg: awt: it is, the only other instances of that id are in the payload of your messages telling me to search for it

awt: Then that means some previous message had the exact same timestamp

awt: Now, with all the rubbish messages going out very frequently, this is theoretically possible

awt: especially if on SAME box

awt: if ts is in secs and not miliseconds, highly possible

awt: so we need some mechanism of avoiding sending out broadcasts simultaneously with rubbish

awt: or the timestamp shouldn't be used to uniquely identify messages

billymg: awt: ah, looks like that might've been it, see timestamps on surrounding lines: http://paste.deedbot.org/?id=eoGq

awt: yep

awt: asciilifeform ^

awt: OR don't track rubbish messages in dupe queue?

awt: seems like the best approach

PeterL: what is to say that you won't get two valid maessages from different peers at the same time? probably better to track them by a hash or something than by timestamp

awt: PeterL true

awt: I mean there's no reason to track IGNORE messages in the queue still, too

PeterL: billymg: I am still not seeing a timestamp in my AT from you, I wonder if we are still not peered correctly?

asciilifeform: awt: why are timestamps 'being used to validate messages' ????

asciilifeform: deduping is done with hash of entire msg per spec

asciilifeform: it is entirely permissible for over9000 msg to come in w/ equal timestamps.

awt: asciilifeform: implemented dedup before the spec came out, haven't reviewed

asciilifeform: aa

asciilifeform: ok

asciilifeform: btw another missed msg in pestlog

asciilifeform: ('but yeah.... getdata...')

billymg: PeterL: i still don't have timestamps for most others either, only awt and now bitbot

asciilifeform: welcome to pesttestnet, jonsykkel !

asciilifeform: seems to work

asciilifeform: 'u still see my msgs? changed something in firewal' most recent i'm seeing prior to 'cool'

asciilifeform: jonsykkel: it's still 'alpha' proggy, occasionally msgs go to devnull lol

asciilifeform: but 'spreading -- works!'

PeterL: so, not sure if this is a dumb question, to send someone a key should it be gpg encrypted to their key or should I sign it first and then encrypt it?

asciilifeform: PeterL: sign then encrypt

asciilifeform: this is more or less sop for any serious wot work

asciilifeform: (else how does peer know it was PeterL's key)

PeterL: good point, that's what I though, just checking

asciilifeform also recs to have such thrd in #a, where lines not randomly vanished lol

PeterL: lol! But it is so fun to be using the pestnet already

asciilifeform: indeed

PeterL: http://paste.deedbot.org/?id=teav << asciilifeform

asciilifeform: PeterL: how come 2 keys in there ?

PeterL: it's the same key, that is the format that awt's little script spits it out

asciilifeform: oh yea lol

asciilifeform: ok added PeterL

awt: PeterL: I recommend to use /genkey

asciilifeform: still seeing 'None' for his timestamp in AT tho

asciilifeform: PeterL: are you behind nat ?

PeterL: hmm, I think so?

asciilifeform: PeterL: try adding http://logs.bitdash.io/pest/2021-11-13#1000321 for asciilifeform's AT entry

bitbot: Logged on 2021-11-13 18:20:59 asciilifeform: billymg: try adding /AT asciilifeform 71.191.220.241 50725

asciilifeform: on your end

asciilifeform: (this'll work for so long as asciilifeform's station not reset)

asciilifeform: presently this is the only way 2 natted stations can peer

asciilifeform: btw billymg i see my lines in the logs but no echos from bot here

awt: not seeing echoes either

PeterL: ok, I added that as the address, but it still lists None as your timestamp

asciilifeform: anybody have a successful peering w/ PeterL ?

asciilifeform: (somebody gotta, or i couldn't see him , lol)

awt raises hand

asciilifeform: awt: what's his ephemeral port ?

awt: asciilifeform: 55565

asciilifeform: very odd, because i have him in AT w/ 55565

asciilifeform: and 0contact

PeterL: should I give you my udp port instead of thee ephemeral one?

asciilifeform: PeterL: if yer behind nat, the ephemeral (which came into being when your session started) is the 1 that yer reachable on

asciilifeform: and seems like other folx able to ?

asciilifeform: but not asciilifeform

asciilifeform: 'PeterL 162.247.151.243:55565 None'

asciilifeform: ^ from AT

PeterL: I seem to have connected fully with shinohai, awt, and jonsykkel

awt: asciilifeform, PeterL, you can check logs to verify the message is being sent out to each other and at what ip:port.

asciilifeform: 2021-11-15 15:13:01.618130 [162.247.151.243:55565] <- 67caa7127e93207f

asciilifeform: my station is defo sending to his

awt: PeterL: you can search your log for that message id

awt: and see what's happening to it

awt: asciilifeform: that is correct

PeterL: hmm, seem to be getting a TypeError: an integer is required

PeterL: just a sec

awt: hm - perhaps somehow port is being passed in as a string somewhere...

PeterL: Traceback (most recent call last):

asciilifeform: i saw 1 or 2 when starting station

PeterL: maybe because there is no port, which expects an integer?

asciilifeform: no port where ?

awt: that too. stack trace would be very helpful

PeterL: I mean if you have a peer and key but no associated address and port?

billymg: asciilifeform: i see bitbot's echos on my terminal here (and they're showing up in the logs)

asciilifeform: i don't

billymg: asciilifeform: might the bot need to peer with some other users?

billymg: currently only peered with billymg

asciilifeform: billymg: if it can see my broadcasts, i oughta be able to see its

asciilifeform: so very evidently bug

awt: ty jonsykkel

billymg: yeah, for example i see this echo in the logs

bitbot: Logged on 2021-11-15 20:14:21 bitbot: Logged on 2021-11-13 18:20:59 asciilifeform: billymg: try adding /AT asciilifeform 71.191.220.241 50725

billymg: and in my terminal here see the echo of the echo ^

awt: I saw that echo

asciilifeform: i see its echo in its log (where of course it will appear) but not in my console

awt: could be the timestamp problem

asciilifeform: yea if timestamp is being used as a dupe indicator, would readily explain the random msg loss

asciilifeform: doesn't explain why i haven't received even 1 packet from PeterL tho

awt: /AT asciilifeform 71.191.220.241 50725 -- this command could end up setting port to ""

awt: should be 71.191.220.241:50725

billymg: PeterL: i updated your at entry

PeterL: hmm, still not seeing anything from billymg or asciilifeform

billymg: PeterL: likewise, those two and shinohai still showing up as None for last timestamp

asciilifeform: so far my only working peerings are with awt and shinohai

billymg: my only working peerings are with awt and bitbot (according to output of /at)

awt: PeterL can you paste your at from sqlite? select * from at;

awt: want to see if I can tell what is wrong with your port field

PeterL: how do I get it out of sqlite?

billymg: .quit

awt: perhaps also paste the command you used to add asciilifeform to at

billymg: oops, sorry, i thought you said how do i get out of sqlite lol

awt: sqlite3 blatta.db

asciilifeform: all of this was the stimulus behind http://logs.nosuchlabs.com/log/asciilifeform/2021-11-14#1065718 thrd

PeterL: I just did /at asciilifeform 71.191.220.241:50725

asciilifeform still not received a single packet from PeterL's station

PeterL: 1|200.122.181.26|55000|2021-11-15 20:29:00|2021-11-15 20:29:00

PeterL: 3||7778||

PeterL: did that show up ok?

asciilifeform: that aint mine

awt: you could paste in the pastebin

PeterL: http://paste.deedbot.org/?id=HXbm

PeterL: yeah, probably works better that way

asciilifeform: hmm weird, PeterL's is sending to mine ?

PeterL: what did it do, only show the first line?

asciilifeform: or rather, mine to his

asciilifeform: (if AT display is correct, that is)

awt: peterl that first line 3 as the handle id looks pretty bad!

PeterL: I think that was because in my config I had a key for billymg but no address?

awt: PeterL that could be causing the exception, which could be causing the message not to be sent to subsequent recipients

awt: must bbl

PeterL: right, is there a way to get rid of that?

awt: you could stop blatta and delete it with an sql query

awt: delete from at where .... etc

awt: must bbl

PeterL: ok, I will return shortly

PeterL: ok, back now, maybe it will work?

PeterL: OK, so the logging bot sees me, that is good

PeterL: looks like jonsykkel is one bounce too far from the logging bot to get recorded in the log?

PeterL: ^ peer (join as equals), not pear (fruit)

PeterL: I will peer into the depths of logic to figure this out

PeterL: lol, to the bot it just looks like I am talking to myself

PeterL: maybe we should consider increasing the max jumps by one?

asciilifeform still not seen 1 packet from PeterL ftr

asciilifeform: or from bitbot

asciilifeform: (the latter sees mine via hearsay, but i see nuffin outta it)

awt: PeterL 162.247.151.243:55565 2021-11-15 23:24:52

asciilifeform: still nuffin from his station here btw

asciilifeform: PeterL 162.247.151.243:55565 None

asciilifeform: summary of asciilifeform's current puzzlers : 1) wai no packets from PeterL's station 2) wai no hearsay msgs ~from~ bitbot (despite the latter seeing asciilifeform's msgs, as it evidently does)

asciilifeform: btw bitbot ignored last ln from asciilifeform

awt: Yeah no real point in testing much more until I can get out a patch that fixes the dup detection problem

awt: As for PeterL's and billymg's issues, they nothing for ascii to do until they can show some logs of outgoing messages targeted at ascii's station

asciilifeform: awt: make sense, ty

← 2021-11-14 | 2021-11-16 → ↑