IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2024/11/02
dr|z3d here you go, zzz, roadmap mods.. you only need to copy the <style> block and overwrite your current <style> block with it: cake.i2p/file/TDjsCosSkP_GurxlUNjOuUPX8XC3ozIHY8q5iCGMe_hFTqJHXFVX/zzz-plan.html
zzz thx for the pnuts
RN *** hands zzz an epi-pen ***
zzz orignal, re: multiple relay responses sent from bob to alice
zzz done some logging and looking
zzz what I see is i2pd 0.9.64 alice repeatedly sending me a relay request with same nonce, AFTER I've sent the relay response
zzz and forgotten about that nonce. so the next time I do it all again
zzz sample:
zzz 11/02 17:32:43.213 Receive relay request from 85.228.46.115:17214 j~EeS2
zzz 11/02 17:32:43.251 Got relay response 0 as bob, forward nonce 2863524794
zzz 11/02 17:32:43.328 Receive relay request from 85.228.46.115:17214 j~EeS2
zzz 11/02 17:32:43.373 Got relay response 0 as bob, forward nonce 2863524794
zzz 11/02 17:32:43.565 Receive relay request from 85.228.46.115:17214 j~EeS2
zzz 11/02 17:32:43.605 Got relay response 0 as bob, forward nonce 2863524794
zzz 11/02 17:32:43.885 Receive relay request from 85.228.46.115:17214 j~EeS2
zzz 11/02 17:32:43.924 Got relay response 0 as bob, forward nonce 2863524794
zzz 11/02 17:32:44.293 Receive relay request from 85.228.46.115:17214 j~EeS2
zzz 11/02 17:32:44.333 Got relay response 0 as bob, forward nonce 2863524794
zzz 11/02 17:32:44.830 Receive relay request from 85.228.46.115:17214 j~EeS2
zzz 11/02 17:32:44.869 Got relay response 0 as bob, forward nonce 2863524794
zzz 11/02 17:32:45.456 Receive relay request from 85.228.46.115:17214 j~EeS2
zzz 11/02 17:32:45.497 Got relay response 0 as bob, forward nonce 2863524794
zzz so I think I'm doing everything right, except maybe I should remember and ignore old nonces?
zzz but look at your 0.9.64 alice code
zzz I don't see any logs or code where I 'spontaneously' send a bunch of them
orignal so you respond to relay requests?
orignal thanks. will check
orignal do you send Ack to that relay request packet?
orignal for me it seems that retrans
orignal e.g. packet is not acked but you
orignal shoudl I set set "ack requested" in flags?
zzz no need to set flag
zzz yes we ack relay requests; even if we didn't send a separate ack, there would be in ack block in the relay response
orignal even if Data msg contains only relay request?
orignal I think that's the problem
zzz of course, we include ack blocks in every message
orignal the question is if even send it
orignal got it. it must be with relay response message
orignal let me investigate deeper
zzz this is a little confusing for sure
orignal but if it's Alice it's easy to reproduce
orignal the question is why I keep resending despite ack
orignal and strange that it doesn't happen with peer test
orignal althrough the same logic
zzz I'm not logging the timestamp in the request, I'll do that, that should tell us if it's a retransmission or a new one with the same nonce
orignal no doubts it's a restransimmission
orignal because I generate nonce randomly
orignal RAND_bytes ((uint8_t *)&nonce, 4);
orignal for every relay request
orignal when you receive replay request do you send ack right a way or with relay response received from Charlie?
zzz almost right away, delayed ~ RTT/6 which is way before the relay response usually
orignal so you don't wait for RelayResponse from Charlie
zzz correct
orignal let me investigate put some logging and see
zzz in the end I'll probably have to keep a recent relay request nonce list, because after I send the relay response I "forget" the nonce and can't recognize dups
zzz even if there's no bugs on either side, it can happen
orignal what is packet num is zero?
orignal most likely I send relay request as first message
orignal although it souldn't be
zzz checked a few dups, first one is #5 on one, #8 on another, #24 on another
orignal yes you are right I aslways recdeive Ack
dr|z3d zzz: got a question for you. can't find the search code for leasesets, want to do a partial search instead of searching for the entire b32. any ideas where the code is? :)
zzz same as for partial router hash. get them all, and iterate thru them
dr|z3d yeah, I just can't find where we're doing the ls/b32/hostname search. must be blind.
zzz sec
dr|z3d thanks
dr|z3d I figured it'd be useful to be able to input a partial b32 and get a result.
dr|z3d or a partial hostname for that matter.
zzz renderer.renderLeaseSet(Writer out, String hostname, boolean debug)
dr|z3d ok, thanks, I recognise that, it's in NetDbRenderer.
orignal what I see all these relay reponses come in the same second
zzz you can see my timestamps in what I pasted above
orignal yes, you also send in the same second
orignal it seems my resend algoruthm
zzz only because the dup requests come in pretty quickly
orignal that's why it's definitly bug in my resend algorithm
zzz my min retransmission timeout is 1 second
zzz ok, you found something? good news
zzz I'm adding some logging and dup checks, will have results tomorrow
orignal not yet but it's clear that you send acks
orignal my retrans time is based on RTT
zzz don't forget you've also made a lot of changes since the release? easy to lose track of whats what
orignal see in case of I2NP you drop dupplicates
orignal I'm trying trunk
orignal and see bunch of RelayResponses
zzz yeah, for relay and peer test the dup checks have to be in the state machine because they don't have i2np message numbers
orignal will inverstiage why
orignal anyway we know the reason now
zzz normally I track dups but once I'm done with a test as Bob (when I send the relay response to alice), I delete all the state so I 'forget'
zzz so that's what I need to improve
zzz whether you have a bug or not...
zzz adding a LRU cache of nonces
orignal yes I delete nonce once I get reponse from Charlie too
orignal const int SSU2_RESEND_ATTEMPT_MIN_INTERVAL = 3; // in milliseconds
orignal ha ha
orignal that's why
dr|z3d you probably meant 3*1000?
zzz yikes
dr|z3d we've found a network spammer..
orignal no. 3 ms
zzz long delta = Math.max(10, Math.min(_rtt/6, ACK_FREQUENCY));
dr|z3d no, I mean you *intended* 3*1000 when you wrote the code, but got it wrong.
orignal do you have a problem with SSU2 spam?
zzz rotected static final int ACK_FREQUENCY = 150;
orignal 3 ms was intende3d
orignal it's just about initial resend interval
zzz oh wait that's the delayed ack calc... stand by...
orignal in reality it's based on RTO
RN *** does Pee Wee Herman impression "I meant to do that" ***
orignal americans who are you going to vote for Tuesday?
zzz private static final int MIN_RTO = 1000;
orignal I'm still checking
orignal definitly the problem come for very first message when no RTO yet
zzz private static final int INIT_RTO = 1000;
orignal const size_t SSU2_INITIAL_RTO = 540; // in milliseconds
orignal const size_t SSU2_MIN_RTO = 100; // in milliseconds
zzz I know you guys have been playing around a lot with rtt/rto/retx in streaming. I continue to recommend sticking exactly with RFC 6298 both for streaming and SSU2
orignal we diddn't changemuch in SSU2
zzz and that is referenced in the ssu2 spec
zzz 6298 specifies 1 sec min RTO (as a SHOULD)
dr|z3d what about for streaming?
dr|z3d private static final int INITIAL_RTO = 9000;
zzz same here
dr|z3d no, I know that's what you've got, I'm asking if it's due a revision. I've got 5000 right now.
dr|z3d just because 9000 seemed a bit high, but maybe it can go lower than 5?
orignal according to zzz's log my RTO is around 100 ms
orignal 100 after first, 200 after second, 300 after third etc.
orignal zzz, what's your ack interval? rtt/6?
orignal look like your ack is always late
orignal that's what happens
zzz long delta = Math.max(10, Math.min(_rtt/6, ACK_FREQUENCY));
zzz yeah. rtt/6, min 10, max 150
orignal what it will be if rtt is 100 ms?
zzz 100/6
zzz my median RTT is about 100
orignal but how do you know rtt at that moment?
orignal if it's first message came from me?
orignal you send Ack to my SessionConfirmed
zzz initial RTT is set during the handshake
orignal that I understand
orignal it's RTT + x25519 time
zzz by timing how long to get the handshake message back
orignal between wich messages if you are Bob?
orignal you send SessionCreated and wait SessionConfirmed?
zzz that sounds right, but I'd have to check
orignal the problem is x25519 round
zzz InboundEstablishState2.java: _rtt = (int) ( _context.clock().now() - _lastSend );
orignal on Alice side
zzz sure, it's not perfect, but it's a good place to start
orignal do you know how long x25519 is?
orignal I believe few millseconds at least
zzz no, but we have a queue of eph. keys precalculated, so that saves a little
zzz still better than just a constant. if the peer is slow doing DH, it's probably slow for other stuff
orignal ofc I mean x5519 shared key calculation
orignal my point is
zzz rtt is just an estimate anyway, not trying to be perfect
orignal what if your RTT is much higher than on my side
orignal say my RTT is based on RelayRequst->Ack
orignal so what was your ack delay time?
orignal 10 ms?
zzz yes
orignal should not be an issue than
orignal let me investigate deeper
zzz ok, afk, back tomorrow