@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+goose2_
+hagen
+orignal
+postman
+weko
An0nm0n
Arch
Danny
DeltaOreo
DiCEy1904
FreefallHeavens
Irc2PGuest48909
Irc2PGuest69244
Irc2PGuest71836
Nausicaa
Onn4l7h
SoniEx2
T3s|4_
Teeed
anon2
b3t4f4c3__
bak83_
boonst
cumlord
dr4wd3
eyedeekay_bnc
goose2
hk
itsjustme
j6
numberwang
onon_1
poriori
profetikla
qend-irc2p
rapidash
shiver_
u5657
unwr
user
veiledwizard
w8rabbit
x74a6
zzz
wow, the bitcoin PR went through on a rocket, 2 days from report to PR to merged. Vort got credited for his libtorrent patch
zzz
will be in 26.1 and 27.0
zzz
thanks to the i2pd folks that tracked it down for qbittorrent/libtorrent
zzz
I updated our SAM and bittorrent docs
orignal
zzz, we have another issue, not sure aboyt it
orignal
do we support connectivity to ourself?
orignal
i tend to respond with CANT_REACH_PEER in this case
zzz
don't know, maybe eyedeekay does
orignal
anyway we should clarify it in the specs
zzz
I doubt sam cares but maybe i2cp does for us
orignal
I don't allow connectiivty to myslef for security reasons
zzz
also streaming
orignal
I also do it at destination level
orignal
basically I don't allow own LS in the netdb
zzz
that's probably right, not so much security but probably means it's a bug if a client is trying it
orignal
because who might need it
zzz
sounds right
orignal
this guy claims that Java SAM allows it
zzz
then why did he file the bug on you instead of us ))
orignal
because they believe I have a bug ))
orignal
that I don't allow it
orignal
well I have a bug that I don;t reply to such STREAM CONNECT prorerly
zzz
"qbittorrent seems to like to connect to itself." but they don't say why they need that
zzz
tell OP not-a-bug unless they can explain why they need it
orignal
well it is bug because sich connect hangs
orignal
instead resposning with error
zzz
ok
orignal
I thought that you allow it intentionally
zzz
no
zzz
blame jrandom?
eyedeekay
In SAM? We definitely can connect to ourselves
zzz
eyedeekay, can you think of any reason why it should be allowed?
eyedeekay
I tend to use it pretty extensively for tests, i.e. set up listener, sleep for a few seconds, dial aforesaid listener to see if it works
zzz
I've always used two sessions to test, not that hard
zzz
depends what you're trying to test, what's the expectation on where the loopback happens? sam? i2cp? router? out tunnels and back?
eyedeekay
No, it isn't hard, but that's just the first thing that came to me
zzz
I agree w/ orignal it's preferable to disallow it, to protect against client bugs (like qbittorrent apparently)
eyedeekay
This is just the last phase in a test which ensures that the library implementation works as-expected, IMO if the expectation changes so can the library
eyedeekay
Therefore I think I also agree
eyedeekay
I certainly can't think of a very good reason a session needs to listen then connect to itself
zzz
ok I'm going to post on the i2pd ticket saying we agree with orignal and we'll change to send CANT_REACH_PEER unless somebody comes up with a good reason
orignal
if it's for testing only make it configurable