IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2022/03/12
dr|z3d a few ssu2 routers enabled, zzz, since yesterday. is there anything to look for in the netdb to identify an ssu2 enabled router?
zzz so you jumped the gun, ok
dr|z3d well, I figured you were about to advertise the config :)
zzz SSU addresses have v=2 and also "s" and "i" in the address
dr|z3d is the v=2 a suffix on the end of the address?
zzz no it's another option next to s and i
zzz it's like we did with NTCP. First we're supporting both 1 and 2 on a single port published as S
zzz * as SSU
zzz later when we turn off 1, it will be published as SSU2.
zzz and as before, i2pd is doing it the other way, publishing both SSU and SSU2 from the start
dr|z3d ah, ok, I see it now, some css mods required here to unhide it.
dr|z3d never did get around to ordering the keys displayed in the netdb. host: .. port: .. etc.
dr|z3d is there anything specific in logging that can be enabled to see ssu2 transactions?
zzz InboundEstablishState2 and OutboundEstablishState2 are for the handshake as Bob and Alice respectively. PeerState2 for the data phase
dr|z3d I've got net.i2p.router.transport.udp=DEBUG there, but that's probably not helping much given the likely frequency of ssu2 entries.
zzz PacketBuilder2 for the low-level sent pkts
dr|z3d ah, yeah, thanks. obvious now you mention it, with the 2 suffix on those classes :)
dr|z3d missing OutboundEstablishState2 here, maybe a merge error on my part.
zzz yup. the 2 suffixes are built on top of their 1 counterparts; the SSU2* classes are low-level stuff with little logging
zzz look again, there's no way it would compile w/o it
dr|z3d under net.i2p.router.transport.udp? definitely not there.. have InboundEst..State, just no Outbound
zzz seems impossible you could botch it that badly and still have it compile
dr|z3d only net.i2p.router.transport.udp.OutboundEstablishState there.
dr|z3d yeah, I'm pretty sure I've been fairly good at grabbing all the relevant commits lately, after missing that one previously.
zzz added Feb. 24, modified in ~17 subsequent checkins
dr|z3d should be identical to your copy.
zzz so you do have it
dr|z3d yeah, have the file, just no entry for the class in logging.
zzz if it's in the box above already, it's not in the dropdown
dr|z3d ok, so it's not there then. you referenced it when I asked about logging, which is why the confusion :)
zzz lol
dr|z3d glad we cleared that up. *chuckle*
dr|z3d or did we?
dr|z3d "if it's in the box already" ..
dr|z3d no, it's not in the textarea, and it's also not on the dropdown.
zzz then the class hasn't been initialized yet, probably because you haven't made an outbound connection
dr|z3d ah, there we go. that makes sense now. thanks.
zzz you can add it manually in the box above
dr|z3d net.i2p.router.transport.udp.OutboundEstablishState2=DEBUG added
dr|z3d on a totally different note, now seeing around 6-8 failed scrape requests (from bigly) on zzzot, and of course jetty doesn't respect the logging configs so just spews it's warns regardless.
dr|z3d *per min