@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest10850
Irc2PGuest19353
Irc2PGuest23854
Irc2PGuest46029
Irc2PGuest48064
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Sisyphus
Sleepy
Soni
T3s|4__
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cumlord
dr4wd3_
eyedeekay_bnc
hagen_
khb
mittwerk
plap
poriori
profetikla
rapidash
shiver_
solidx66
u5657_1
uop23ip
w8rabbit
weko_
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