#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

orignal so I send SessionRequest with wrong token

orignal and I get

orignal 21:25:40@230/debug - SSU2: Retry from -Akx1l9v~mGBse6zILOsmPtcwrTWxS2a8NXiKgy6kG

orignal s=

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 sourced from: freenetworktutorials.com/ipv4-and-ipv6-bogon-address-list

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 oh

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.

dr|z3d this is what I've got for ipv6: cake.i2p/view/8sUyBAWf7J_Dzm6CmUfs1xpB2vkAviXh5PTo321CI_QomQj2mPpI/ipv6

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 shit

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

orignal huh?

zzz I'm sending 1 or 2 byte packets when retransmitting session confirmed

orignal why?

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 s

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