IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2024/01/09
@eyedeekay
&kytv
&zzz
+Anomaly
+R4SAS
+RN
+RN_
+T3s|4
+acetone
+dr|z3d
+hk
+orignal
+postman
+weko
+wodencafe
Arch
Danny
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest12106
Irc2PGuest32754
Irc2PGuest43409
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy_
Soni
T3s|4_
Teeed
aargh1
anon2
b3t4f4c3
bak83
boonst
cumlord
dr4wd3
eyedeekay_bnc
hagen_
itsjustme
khb
not_bob_afk
plap
poriori
profetikla
r3med1tz
rapidash
shiver_
solidx66
tr
u5657_1
uop23ip
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
orignal I thought that you allow it intentionally
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