IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/12/15
@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+acetone
+orignal
+weko
FreeRider
Irc2PGuest12106
Irc2PGuest77585
Onn4l7h
Onn4|7h
T3s|4_
aargh2
anon3
eyedeekay_bnc
not_bob_afk
profetikla
shiver_
u5657_1
x74a6
orignal so I send SessionRequest with wrong token
orignal and I get
orignal 21:25:40@230/debug - SSU2: Retry from -Akx1l9v~mGBse6zILOsmPtcwrTWxS2a8NXiKgy6kG
orignal and then
orignal 21:25:40@230/debug - SSU2: SessionCreated from -Akx1l9v~mGBse6zILOsmPtcwrTWxS2a8NXiKgy6kGs=
orignal can you check you side please?
orignal my router was x-EV
dr|z3d seeing some buggy behavior with blocklist.txt
dr|z3d router a, added, no problem, appears in the console ban list as soon as it's seen after session start.
dr|z3d router b, added, verified it's in the blocklist, doesn't appear in ban list, router's requesting part tunnels unfettered.
dr|z3d router b in the netdb listed as unreachable, no introducers listed.
zzz orignal, I didn't see much in the logs, but if you got session created, then everything was fine
zzz the problem is 87 byte session request, see yesterday morning logs above ^^^
zzz dr|z3d, yeah it's all very sloppy, I'll work on it
dr|z3d roger that, zzz.
dr|z3d I've got some updates to the blocklist if you want to pull them into cannon. some basic ipv6 bogons.
dr|z3d *canon
dr|z3d only 38 entries.
zzz I believe it's all handled in TransportUtil.isPubliclyRoutable()
dr|z3d all the bogons you mean? so the entries in the blocklist are redundant?
zzz would have to think about it, not exactly the same
dr|z3d yeah, blocklist kills them outright, transport util just ignores them, no?
zzz ah, here's the issue. blocklist.txt doesn't support ipv6 /x masks or ranges
dr|z3d fixable?
zzz the blocklist code doesn't support ipv6 ranges at all
zzz singles only
dr|z3d yeah, re-reading the blocklist.txt comments seems to suggest that.
dr|z3d that router that wasn't appearing in the blocklist, after a router restart now it is. and yet it was previously in the blocklist.txt, so I don't know what's happening.
dr|z3d *appearing on the banned routers page
dr|z3d only thing I can think of is that the last entry (not the router in question) was missing a trailing newline.
zzz - ssu 1/2 don't check banlist for inbound, only blocklist
zzz - it's a little murky on when we also block IPs for a banned peer
zzz - even trickier if banned peer is firewalled
dr|z3d yeah, right, you don't want to ban the introducers. :|
dr|z3d I guess you're banning by hash then, anyways. But I'm still scratching my head about how a firewalled router gets into the netdb without publishing introducers if not a bug.
orignal maybe I was disconnected
orignal because previously you mentioned 88+ bytes
zzz orignal, 11:12 AM yesterday, do you have it or need it reposted?
orignal sessioncreated that's what I mean you respond right
orignal <zzz> oooh orignal have more information
zzz ok good
orignal I thought following lnes were addresses to dr|z3d
orignal so, what's the problem now?
orignal zero X?
zzz when you send an 87 byte session request, everything is zeros I think
zzz and after that is when it all goes bad
zzz yes, all for you :)
orignal so, I guuess it's 87 bytes issue
zzz that's my theory, yes
dr|z3d got a stracktrace for "sending to ourselves", zzz, will paste in -dev.
zzz w00t
orignal then can we try again today
orignal and you check wheat I send
orignal dest connid will definitly be bad in case of 87 bytes
zzz yeah everything is bad
orignal so let me know when you are ready
zzz I have everything fixed up now to identify and drop 87 byte requests. I'm getting 100+ 87 byte requests per hour on a low-bandwidth router
zzz what do you want me to look for? if it's 88 or more bytes everything works fine
orignal probability is 1/16
orignal I want you to check how you handle situation with Retry and second SessionRequest
orignal "if it's "
orignal then I still don't understand how you bypassed 88 bytes check and reach the point with wrong connid
orignal that's my question
zzz because I had bugs :)
zzz I'm ready
orignal so your previous statement was wrong
zzz probably. took me a couple days to really figure out what was happening
orignal I got a connection from you instead ))
orignal bad luck
orignal will try again later
orignal have to go now
zzz ok, thanks
orignal 11:45:00@450/debug - SSU2: Retry from -Akx1l9v~mGBse6zILOsmPtcwrTWxS2a8NXiKgy6kGs=
orignal 11:45:01@450/debug - SSU2: SessionCreated from -Akx1l9v~mGBse6zILOsmPtcwrTWxS2a8NXiKgy6kGs=
orignal please check
zzz I didn't have logging low enough to see that it was OK, but I didn't see anything wrong either
zzz omg I'm an idiot
zzz I'm sending 1 or 2 byte packets when retransmitting session confirmed
zzz @@ -1024,7 +1030,7 @@ public class PeerState2 extends PeerState implements SSU2Payload.PayloadCallback
zzz byte data[] = pkt.getData();
zzz int off = pkt.getOffset();
zzz System.arraycopy(_sessConfForReTX[i], 0, data, off, _sessConfForReTX[i].length);
zzz - pkt.setLength(_sessConfForReTX.length);
zzz + pkt.setLength(_sessConfForReTX[i].length);
zzz I set the packet length to the number of packets (((((((((((((((((((((((
zzz I was seeing a lot of 1 or 2 byte packets, finally tracked it down
orignal yes, I was wodneting where such incomplete packets come from
zzz this is getting bad. so. many. bugs.
orignal yes, maybe you should also make an intermediate release?
orignal let's conclude it was 87 bytes problem
zzz maybe. we discussed it at our meeting yesterday
orignal since I was not there, what was the conclusion?
orignal I also have many bug fixes
zzz we didn't decide yet
zzz if you do it, when do you think you would?
orignal somewhen in January
zzz let us know when you decide
orignal when we clear all issue
orignal as you see we have two guys who run and test aggressively
dr|z3d I'd suggest pushing out a point release update before Xmas, if that's something that's universally considered a good idea.
dr|z3d network's likely to get busy around then, public holiday and all.
dr|z3d but maybe that's too soon to get something out, so maybe there's not enough time.
zzz regardless of urgency, the timing must depend on the stability of the code base, not on when a holiday is