ADC same CID problem

[Jan Vidar Krey]

user_992 (AA7A) has same CID {AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7C} as user_994 (AA7C), ignoring.
(Repeat with various data)

This message looks familiar right? It occurs pretty much regardless of hubsoft, so I wrote a small testcase in Perl for user with inetd or netcat.

Script attached.

[Big Muscle (bigmuscle)]

I don't see it as bug. There can be 2 reason why this happens:

1) my client crashes (so ghost user remains in the hub). I try to re-enter the hub which assigns me new SID, but I will send the same CID as before (which is now taken by ghost user. Similar to the problem "Nick already taken" in NMDC

2) I want to login with 2 clients, but both use same DCPlusPlus.xml (so same CID, nick etc.). The hub assigns different SID to each client (but their CID will be same)

[Jan Vidar Krey (janvidar)]

*Read* the fscking Perl script and *SEE* that neither is true. It is a TEST CASE that shows the problem...
All you need is netcat to replicate the result.

[Jan Vidar Krey (janvidar)]

Small bug in the script it sends SID AAAX, should be something else, like ZZZZ

[Toast (swetoast-deactivatedaccount)]

Pietry says:
 While my testing on dshub and cid bug, i connected with a client and see what happens when dc++ is printing the same cid message. i used adc debug on to see what messages the hub sends. And according to my opinion, and what i've seen, dshub was sending BINFs for users before sending IQUI for them ( sometimes they were reversed or dshub did not send IQUI ). As a conclusion i thought dshub had a bug
 in managing users quitting/logging in

an update from pietry he didnt have his login to this place

[suzumia (reg64)]

mistake in script!

39 base32-chars contains 195 bits, but only first 192 are used for CID.
lower 'digits' are ignored in base32-CID decoder.

so, script produces invalid CIDs, that can't be generated by hub or client software

just move SID to begin of CID, not end. and you will ensure that clients works fine

[Toast (swetoast-deactivatedaccount)]

Reverting from vandalizing

[suzumia (reg64)]

anyway, it is not a client-side problem
(or there is no *correct* test case for reproducing)

just FYI:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD
...

decodes to same binary 24-bytes CID. that is why script should not pass these CIDs as CIDs of different clients

[Toast (swetoast-deactivatedaccount)]

Some other developers beg the differ and this is still not a closed issue since this problem is under investigation and the script can be fixxed when offset has some time over, btw mind id yourself ?

[suzumia (reg64)]

script should be fixed:

print "BINF " . $sid . " IDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" . $sid . " NIuser_" . $i . "\n"
replace to
print "BINF " . $sid . " ID" . $sid . "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA NIuser_" . $i . "\n"

in this case all SID bits goes to binary CID and client does not show errors

[Big Muscle (bigmuscle)]

I agree with suzumia even though he isn't allowed to change report status. The bug is really in script (invalid CIDs are used there) and not in the client.The sanity check should be added to client not to accept invalid CID strings.

[Jacek Sieka (arnetheduck)]

afaict suzumia is right even if I haven't given it much though or tested...
from the rfc: "and therefore
   decoders MAY chose to reject an encoding if the pad bits have not
   been set to zero. The specification referring to this may mandate a
   specific behaviour.
"
so it's no error unless the adc spec requires it and it doesn't (since we know the length of the data we don't need to) so...