@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+T3s|4
+acetone
+dr|z3d
+orignal
+polistern
+postman
+weko
+wodencafe
An0nm0n
Arch
FreefallHeavens
Gid
Hikari
Irc2PGuest2974
Irc2PGuest3558
Irc2PGuest4253
Irc2PGuest51959
Leopold
Minogami
Onn4l7h
Sleepy
Soni
T3s|4_
Teeed
aargh1
admin
anon
apt0110
b3t4f4c3__
cheddah
eyedeekay_bnc
itsjustme
j6
limak
not_bob_afk
pihole2
poriori
profetikla
qend-irc2p_
rapidash
tbqdrn
theglitch
u5657
user101
w8rabbit
x74a6
yourtrueself
zer0bitz
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.