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