IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2023/08/02
@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
Danny
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest19353
Irc2PGuest48042
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cancername
cumlord
dr4wd3_
eyedeekay_bnc
hagen_
khb
mittwerk
not_bob_afk
plap
poriori_
profetikla
rapidash
shiver_
solidx66
u5657
uop23ip
w8rabbit
weko_
x74a6
RN here is me, walnuts and hydraulic presses
RN hehehe
dr|z3d and stilettos. don't forget those :)
RN only on days that end in "y"
RN who let a monkey into the code!
dr|z3d you might need to screenshot that for context, well, in this channel :)
RN yeah, there's a chimp in a hoodie blended into the interface of the i2p+ web console
RN just one of doubtless many more easter eggs when you look around that i2p+ has to offer
robin eyedeekay Router gets an exception if I close the primary session TCP socket. Will sending a "QUIT" request first avoid this? Spec says QUIT is optional
eyedeekay Quit is usually optional but it might not be in your case, I seem to recall us running into an issue when the SAM API is on a separate host in the past
robin It does not seem to be fatal, but I am trying to eliminate anything 'unusual'
robin Clinet is no sending a UDP message to the router's UDP port, but no mention of that appears in the log. Do datagrams get logged there?
robin is NOW sending
eyedeekay Yeah they should be logged, but I haven't looked too much into the specifics of the logging yet
robin Wireshark soes the message leaving the client mahcine with no error coming back. I have not tried running WS on the router yet
robin I will do that tomorrow
eyedeekay I have an appointment in the morning but I'll be back at noon, my bouncer will be here to get the scrollback
eyedeekay Well noon my time, I guess that's what like 5UTC?
eyedeekay Everybody knows my time zone anyway
robin eyedeekay wireshark on my I2P router node shoes my UDP datagram (938 bytes long) arriving to port 7655. But no mention is made in the router's log with net.i2p.sam.SAMv3Handler=DEBUG
robin And netstat shows that port 7655 is open, udp6, by java
robin Interesting, the newer 'ss' program shows it open as [::ffff:(my router IP)]:7655
robin It occurs to me that the router will silently drop any UDP message it receives that it thinks is not in the correct format.
obscuratus robin: It might be worth your while to play around alittle with some of the other SAM libs that support UDP, and see if you can figure out what they're doing differently.
obscuratus I've been using UDP Datagrams connections on the libsam3 C library a lot lately on my testing network, to simulate traffic.
obscuratus I'm not trying to convince you to switch to C, but it might help you sort out the differences.
obscuratus I'm pretty sure polistern's pboted is also using UDP. It's on the C++ i2psam library.
robin Part of this project is to develop my own library that handles SAM. The chat program is just the application I use to test it.
robin libsam3. I could look at how they do it.
robin Yes, libsam3 formats its messages the same way I do.
robin "3.0 SESSIONID DESTINATION\ndata"
robin eyedeekay It seems that sending an explicit QUIT *does* avoid the Exception on readline in the router.
eyedeekay Thanks for the update
eyedeekay I'm just going over the logging in the SAMv3 app
robin Still not seing my messages logged though. I am not sure if there is even code to do that - the SAM code is a bit obscure
eyedeekay You might be ahead to build the branch from source when it's pushed
eyedeekay Yeah I'm working on some of that this afternoon
robin One though is that I think SAM will drop a message in the wrong format. But I am sending a message exactly as documented.
robin I can put one in pastebin.
robin (If I could figure out how to make pastebin work)
robin It is a UTF-8 encoded byte string
obscuratus eyedeekay: I've ran into a few early issues/concerns with the nested-netdb changes. Let me know when you've got a minute.
eyedeekay Now's fine if you've got time
obscuratus Oops, sorry, you got back just as I switched away and was waiting for a fresh message. :)
obscuratus Sorry for the crappy etiquette on my part, let me know if you're still around eyedeekay.
eyedeekay I'm still here and I always see the scrollback :)
obscuratus I've got two things, one quite a bit bigger. Let me start with the smaller one I actually have a suggested fix for.
obscuratus On my testing network, I'm the subDb's don't look like they're keeping themselves updated for their RI.
obscuratus One problem I noticed is that the subDb's are using the floodfill peerSelector, and this causes them to drop the RI.
obscuratus When I look here at the createPeerSelector, I'm confused...
obscuratus It looks like you're iterating through the subdbs, but returning the on the first iteration, which will almost always be the floodbill subdb, since it's created first.
eyedeekay Oops yup you're absolutely right, that's a problem
obscuratus My suggested fix is over in StoreJob.java.
obscuratus But, like most problems, there's lots of ways to fix this.
obscuratus I guess you could skip the iterator, and just return this.createPeerSelector() in FloodfillNetworkDatabaseSegmentor.
obscuratus The bigger issues stems from my observation that the RI in the subDbs aren't getting updated. I have the same RI I start with, and never add new ones or update the ones I started with.
obscuratus This is bad in itself, but I should be seeing more errors from this behavior (unless the errors are there, but my logging isn't set right).
obscuratus How can a client be doing the things it needs to do if it never gets the RI for the OBEP and IBGW of its tunnels?
eyedeekay Logical explanation is that it's still getting those peers from the floodfill context
obscuratus Presumably, it's going to send DBSM for it's lease set down it's tunnel, and ask for a reply on the IBGW. But it either doesn't know it's inbound gateway, or it's crossing the segmentation barrier.
obscuratus Do we want it to get RI from the local floodfill context?
eyedeekay I *think* that it's OK, but I don't know for sure
obscuratus At any rate, I was wondering what the current desired behavior is here. Maybe I just misunderstand what I'm expecting it to do here.
obscuratus I'll try to confirm how it's building its Database Store Messages. Maybe that'll give me insight.
eyedeekay My intention was to target similarity with the i2pd implementation at first, and unless I'm wrong they're getting the RI's out of the big pool
obscuratus OK, that'll raise another issue with how Database Search Reply Messages are handled. I've got a suggestion on that, so expect something from me on that topic.
eyedeekay Awesome, keep looking, I need all the help I can get on this
eyedeekay Thanks very much
obscuratus Have you had a chance to run the current nested-netdb code much yet? I'm wondering if you're seeing the same thing where the subdb just sits there and never grows or shrinks.
obscuratus This is specific for RI. LeaseSets seem to work better.
eyedeekay Yeah that's exactly what I'm seeing too
obscuratus If we're going to target i2pd's imlementation, maybe we don't need RI at all in the segmented db.
eyedeekay TBH an ulterior motive of this was to help see if we ever had an RI down a client tunnel unsolicited
eyedeekay In theory, if we saw that then the RI count would grow
eyedeekay I think you're right
obscuratus How solidly do we know if an RI received down a tunnel was solicited or not. I've been trying to find the matching code, but I'm not sure what I expect is there.
eyedeekay The long and short of it is that I don't think it happens, if they were coming down client tunnels at all they would be getting tagged with the dbid
obscuratus At any rate, thanks for the clarifications. I have a better idea what's expected now, and have a better idea of what is unexpected.
eyedeekay Thanks for keeping an eye on it
obscuratus I *think* I am seeing those, but for some reason they're getting ploinked. Unintentionally I think.
obscuratus But I need to update the logging messages, added the context for the subDb that the loggin message is associated with.
eyedeekay Could be the very difficult-to-follow old netDb defenses doing it
obscuratus Otherwise, I'm never sure if I'm seeing a message for the floodfill subDb or the client subDb
eyedeekay Good point, I'll make some changes to the logging to fix that
obscuratus So the good news is, when I run a client (I'm using a simple SAM client for testing), the nested-netdb stuff does seem to be working.
obscuratus So it must be correctly sending and receiving LS, or it wouldn't work at all.
eyedeekay Yeah I'm running the current i2p.i2p.2.4.0-test1 branch right now and everything seems to be mostly fine minus one or two wrinkles
obscuratus Let me re-phrase that.... It must be sending and receiving LS. Need to make sure it's doing it correctly. :)
eyedeekay Yup. I think it's getting close though