IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2023/10/16
@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+acetone
+dr|z3d
+hk
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest21357
Irc2PGuest21881
Irc2PGuest89954
Leopold_
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
Soni
T3s|4_
aargh2
anon2
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb
not_bob_afk
plap
poriori
profetikla
r3med1tz
rapidash
shiver_
solidx66
tr
u5657
uop23ip
w8rabbit
x74a6
dr|z3d zzz: streaming -> ConnectionManager probably wants it's Proxy-Connection line removed. LIMIT_HTTP_RESPONSE..
dr|z3d have we still got an issue with old DSA keys on a dual dest setup or has that been fixed?
zzz no ticket afaik
dr|z3d the details are nebulous, no dual dest services here, so I couldn't file one even if I wanted to.
dr|z3d more "Warning! LeaseSet not found in persistent data store for key [xxxx]" entries in the logs than I'd like to see, dunno if that's related.
zzz one reason we got within a week of release with numerous catastrophic problems is that nobody was filing tickets
zzz that code section to re-lookup and warn was added by idk and appears to be solely for debugging; I recommend removal
zzz and I'll do you the favor and enter a ticket
zzz #455
robin On a PRIMARY SAM session I create a STREAM sub-session that does a STREAM ACCEPT which gets an OK. Then in another program I create a similar stream session that does a STREAM CONNECT to the first one. This also gets an OK. I am expecting the first session to see a "$destination FROM_PORT= TO_PORT=" line, but it never comes even though the calling end got an OK back form the CONNECT. I am misunderstanding
robin something.
robin I know the two programs are in fact connected because if I force the first (server) program to quit, the second (client) side sees the socket close.
robin Both programs are connected to the same I2P router.
zzz yes robin you should get the destination line
robin All the other SAM messages come through fine, on both ehe primary and sub-session sockets
robin I use the default for the SILENT parameter, which is 'false'
robin The server program uses co-routines so it is keeping reads pending on both sockets all the time, so I should not be missing anything
zzz what i2p version?
robin 2.3.0
robin I am writing my own SAM wrapper in Lua
zzz I know it works with regular 3.1 stream sessions. Can you try it with that?
zzz that should prove if it's your problem or ours
robin That is just doing a single STYLE=STREAM without having a PRIMARY?
robin I can do that.
zzz yeah. see the quick start section at the top of the spec
robin will do, tnx.
robin @zzz Using the 'old style' of accepting a stream does work as it should.
robin SO either sub-sessions don'
robin t work right or I did it wrong
zzz thanks robin for the report. That makes it likely it's our bug. Do you have an account on our gitlab to file a ticket, or would you like me to enter the ticket?
robin I will assemble log files showing the two tests
robin There are several git-things and I have an account onoone of them - let me see
zzz git.idk.i2p / i2pgit.org
robin I have an account on i2pgit.org
dr|z3d then you also have an account on git.idk.i2p - same credentials.
robin Which project is the one I should put the ticket on?
dr|z3d either is fine, robin, same site.
zzz account is i2p-hackers and the project is i2p.i2p
robin Ok, I found that one.
robin Issue #456
zzz thanks again for the report. Hopefully you can continue to make progress on your library by using 'old style' :)
robin I have test programs in my repo that reproduce this btw. robin/SAM-Lua
robin Ask if you need instructions on running them. They do have some Lua pre-reqs
zzz ok. I'll probably just try to reproduce it with telnet, that's easiest for me
robin It does rewuire having two telnet sessions, but yes that is faster.
robin My code is probably hard to follow anyway. It is highly asynchronous and multi-threaded so the logic is scattered around a bit.