Seems like 0.75 detects active /passive for RES not by SU but by presence of U4 flag ...
so its crucial for backwrds compatibility that 0.76 should not send out an U4 flag if in passive mode.
---------------------
15:42]<Pirre> same happens inhere, when passive searching only clients 0.76 based respond
[BE][15:44]<Pirre> and the others respond to my UDP port as specified in my settings alto i indicating that i am passive
[BE][15:44]<Pirre> nice puzzle :)
[BE][15:48]<Pirre> to reproduce uses a 0.76 based client that is realy a active user, put him in passive mode and search inhere, then change your udp port in settings (keep passive) and search again , the results will be complete diff
[DE][15:51]<Quicksilver> could you please search again?
[DE][15:51]<Quicksilver> so I can have a look at the SCH
[BE][15:51]<Pirre> sure
[BE][15:51]<Pirre> let me first put pasive again
[BE][15:52]<Pirre> done
[DE][15:53]<Quicksilver> search looks fine .... even hit som,e results on this end
[BE][15:53]<Pirre> i have 28 hits
[BE][15:54]<Pirre> now i keep passive but use a udp port thats reacheble
[BE][15:55]<Pirre> 59 hits
[DE][15:55]<Quicksilver> again passive search
[BE][15:55]<Pirre> it was a passive search
[BE][15:55]<Pirre> will repeat
[DE][15:55]<Quicksilver> got 2 INF from you in short time
15:54:49.535 < BINF BCGX SUADC0
15:54:39.995 < BINF BCGX U4442 SUADC0,TCP4,UDP4
[BE][15:56]<Pirre> yeps
[BE][15:56]<Pirre> Protocol supports: ADC0
Protocol supports: ADC0
[DE][15:56]<Quicksilver> and besides jucy the ownly answers are from 0.76 clients?
[BE][15:57]<Pirre> Protocol supports: ADC0
so i am passive
[BE][15:57]<Pirre> it seems so yes
[BE][15:58]<Pirre> it seems that the rest is using my UDP even if i not show it in support
[BE][15:58]<Pirre> am a bit lost there :)
[DE][15:58]<Quicksilver> might be a bug in older dc++ i.e. checking U4 if udp results are available rather than looking in SU for UDP4
[BE][15:59]<Pirre> i verifyed in my client for a BSCH but its not shown in my debug window
[15:59]<Pretorian> What is ADC0?
[BE][15:59]<Pirre> SSL transfers
[BE][16:00]<Pirre> let me change my INF again
[BE][16:00]<Pirre> the last result should be no I4 or U4 field
[DE][16:00]<Quicksilver> ADC= = preliminary ADCS
[DE][16:01]<Quicksilver> ADC0
[16:01]<Pretorian> In lieu of "ADCS"?
[16:01]<Pretorian> Right.
[16:01]<Pretorian> Fair enough.
[DE][16:01]<Quicksilver> usual convention .. as long as new feature is in development last letter is replaced with a number..
[BE][16:02]<Pirre> now the last info received by all clients should not contain a U4 field
[16:02]<Pretorian> I was considering reserving one of the four to mean just specifically that the feature is in development.
[16:02]<Pretorian> I agree that a number is... Meh.
[BE][16:02]<Pirre> and still all older clients seem to send to it
[DE][16:02]<Quicksilver> Pirre seems like DC++ does not send out emty U4 for deletion .. so the U4 field will stay with the clients.. only SU changed..
[DE][16:03]<Quicksilver> you will have to reconnect for deleting...
[BE][16:03]<Pirre> ok let me do
[BE][16:04]<Pirre> 59 hits
[DE][16:05]<Quicksilver> and now you joined with active settings
[BE][16:05]<Pirre> mmm no
[DE][16:05]<Quicksilver> 16:04:10.582 < BINF 3YR3 I462.235.173.205 U4442 IDYR2WNLIO274XSESSAAMGWRVKCTAPUCLYWTEJ6MY DEOle\sGuy\s:)\s\s\s[512/512] VEStrgDC++\s2.40 SF100061 NIPirre SL4 HN2 HO2 OP1 HR0 SS570218095732 US26214 CT4 SUADC0
[DE][16:05]<Quicksilver> ah right
[DE][16:05]<Quicksilver> still it sends out U4 even though passive
[BE][16:06]<Pirre> grrrrrrrrrrrrrrrr lol
[DE][16:06]<Quicksilver> this might be a problem of 0.76 ... if older clients don't detect passive by SU but by U4
[16:06]<Pretorian> Shouldn't hash algorithm be part of that SU?
[DE][16:06]<Quicksilver> no
[16:06]<Pretorian> Why not?
[DE][16:06]<Quicksilver> hashalg is only shown to hub
[16:06]<Pretorian> According to what?
[DE][16:06]<Quicksilver> ADC spe
[DE][16:06]<Quicksilver> c
[BE][16:06]<Pirre> thx Quicksilver that would explain alot
[16:06]<Pretorian> Hm, where does it state that?
[16:08]<Pretorian> I mean, client may wish to only do a C-C between those that support X algorithm..
[DE][16:09]<Quicksilver> yes but its not that nice with ADC... you don't even know what version of Protocol the other supports exactly... i.e. may be you support ADCS/0.10 in client client but the other has ADCS/0.11 voila problem...
[DE][16:09]<Quicksilver> I woulöd assume that all clients in the same hub are using the same hash function.. it wouldn't make much sense any other way..
[16:10]<Pretorian> You do on CTM/RCM.
[16:10]<Pretorian> Yes, C-H wise, sure.
[16:10]<Pretorian> But you can pick whatever you want in C-C.
[DE][16:10]<Quicksilver> yes but you have to send a CTM to find out if the other has that protocol support
[DE][16:10]<Quicksilver> not really
[DE][16:10]<Quicksilver> you could indentify yourself then with any CID ...
[DE][16:11]<Quicksilver> especially you would get multiple CIDs per user..
[16:11]<Pretorian> And?
[16:11]<Pretorian> What's the problem?
[16:11]<Pretorian> You got the token to sort it out, really...
[16:12]<Pretorian> ("You *can* pick whatever you want in C-C.")
[16:12]<Pretorian> Oh, well. I digress.
[16:13]<Pretorian> I suppose you could add protocol version to INF.
[DE][16:14]<Quicksilver> multiple Hashfunctions per hub just add a lot of complexity without any real benefit
[16:14]<Pretorian> Granted.
[DE][16:14]<Quicksilver> one hashfunction per hub is all we need... decide which on connect and let it be like that...
[DE][16:15]<Quicksilver> especially I don't like the idea of mixed hubs for searches.. i.e. only one half of the clients responding to SCH for hashvalues..
[DE][16:16]<Quicksilver> is DC++ 0.76 already released?
[SE][16:16]<Toast> no
[BE][16:18]<Pirre> do you report this as a bug Quicksilver or ... ?
[DE][16:18]<Quicksilver> I am all for the "Devs can read here and fix it immediately"
[DE][16:18]<Quicksilver> its not a bug per se...
[BE][16:19]<Pirre> well its not logic sending a i4 and u4 when you dont have one :)
[SE][16:19]<Toast> doesnt always work out that way QS thats why each bug found its best to make an lp report
[DE][16:19]<Quicksilver> its actually bug that is probablyfixed in 0.76... its more now a workaround for better compatibility in bugged 0.75 version
[SE][16:19]<Toast> cause it tends to get missed in the chatter often
[DE][16:21]<Quicksilver> now I have to look up my lp account?
[SE][16:21]<Toast> yupp
[SE][16:22]<Toast> or u can make pirre report it :P
[BE][16:22]<Pirre> :beer: <----------- for the effort :)
[DE][16:22]<Quicksilver> pirre you report it.. you found the problem
[SE][16:22]<Toast> lol
[BE][16:22]<Pirre> lol
[DE][16:22]<Quicksilver> I can try
[DE][16:22]<Quicksilver> give me a sec
[BE][16:23]<Pirre> i dont have a place where i can put bugs for a non released dc :)
[SE][16:23]<Toast> lp works for unrlsed since we do encourage bzr reports to
[SE][16:23]<Toast> less fucking reports when the official version is rlsed later on
tldr, but DC++ perfectly clears out U4 when switching to passive mode here.
any particular step to reproduce?