@eyedeekay
&zzz
+R4SAS
+RN
+T3s|4
+dr|z3d
+hk
+orignal
+postman
+snex
Arch
BravoOreo
Dann
FreefallHeavens_
Irc2PGuest11045
Irc2PGuest3921
Irc2PGuest59134
Irc2PGuest60478
Irc2PGuest62721
Leopold_
Onn4l7h
Onn4|7h
Sleepy_
Soni
T3s|4_
Teeed_
acetone_
aeiou_
aisle
ardu
b3t4f4c3___
b4dab00m
bak83_
bpb
cumlord
dickless
dr4wd3
enoxa
eyedeekay_bnc
hagen_
mesh
not_bob_afk
plap
poriori
profetikla
qend-irc2p
radakayot_
rapidash
shiver_
solidx66_
u5657
uop23ip
w8rabbit
weko_
wodencafe2
x74a6h
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.