(The sniff traces you'll see are of the packets generated by DC++ client 0.231, which is the latest version that I know of. The sniff dumps are excerpts of dumps made with a sniffer I wrote. Please let me know if the rest of the packet information (IP header, MAC layer, etc) would help.)
Please forgive me if this topic has been discussed previously - I looked thru the forums for a similar post, but couldn't find one.
Ever since 2 releases ago (when I started sniffing the packets), I've noticed an frequent problem with the client <-> client protocol when active connections are enabled on my end. I am not sure if the problem is actually solved with the passive mode, or if the remote clients all have clients that doesn't exhibit this problem, but I haven't seen this problem in passive mode. I have only been able to test this problem with attempted downloads.
Here is the problem area of the client <-> client exchange when I try to download a file:
When I'm in active mode, the remote client connects to me, then sends their user ID packet (remote username removed)
Code: Select all
$MyNick username | 24 4D 79 4E 69 63 6B 20 ?? ?? ?? ?? ?? ?? ?? ??
|$Lock EXTENDEDP | 7C 24 4C 6F 63 6B 20 45 58 54 45 4E 44 45 44 50
ROTOCOLABCABCABC | 52 4F 54 4F 43 4F 4C 41 42 43 41 42 43 41 42 43
ABCABCABC Pk=DCM | 41 42 43 41 42 43 41 42 43 20 50 6B 3D 44 43 4D
OINSMOINS0.20ABC | 4F 49 4E 53 4D 4F 49 4E 53 30 2E 32 30 41 42 43
ABC| | 41 42 43 7C
During the times in which the exchange fails, my client sends an ACK with no payload, two or 3 seconds pass, then the remote client sends FIN ACK, and the connection closes after some expected TCP/IP packets.
When the exchange is successful, instead of just sending ACK, my client sends PSH ACK with the expected packet:
Code: Select all
$MyNick btx|$Loc | 24 4D 79 4E 69 63 6B 20 62 74 78 7C 24 4C 6F 63
k EXTENDEDPROTOC | 6B 20 45 58 54 45 4E 44 45 44 50 52 4F 54 4F 43
OLABCABCABCABCAB | 4F 4C 41 42 43 41 42 43 41 42 43 41 42 43 41 42
CABC Pk=DCPLUSPL | 43 41 42 43 20 50 6B 3D 44 43 50 4C 55 53 50 4C
US0.231ABCABC|$S | 55 53 30 2E 32 33 31 41 42 43 41 42 43 7C 24 53
upports BZList | | 75 70 70 6F 72 74 73 20 42 5A 4C 69 73 74 20 7C
$Direction Downl | 24 44 69 72 65 63 74 69 6F 6E 20 44 6F 77 6E 6C
oad 24478|$Key _ | 6F 61 64 20 32 34 34 37 38 7C 24 4B 65 79 20 14
_______A _____0_ | D1 C0 11 B0 A0 10 10 41 20 D1 B1 B1 C0 C0 30 D0
0_ 0_ 0_ 0_ 0_ 0 | 30 10 20 30 10 20 30 10 20 30 10 20 30 10 20 30
_| | 10 7C
If there is a debug mode that anyone thinks would provide helpful output, by all means let me know. I'd be happy to help out in any way...
I should say that I've only written a few Windows netsock programs, so I can't say I'm an expert in this topic unlike Unix network software... and I haven't looked at the source code. That being said, this problem acts like a race condition, an unproperly initialized variable(s), or a feature
FWIW, the systems this was tested on are:
- Dual P3 800 mhz w/1GB ram with 400MB free ram, windows XP pro, all current patches from windows update
- Single proc p2 450 laptop w/256MB free with 5MB free ram, win 2k pro, hasn't been patched in 2 years or so (I dug this thing out of my closet to run another test).
Any ideas?
Please don't take this post as a complaint - I'm trying to help out by posting a possible bug report. This software completely kicks ass- It is so nice to use filesharing software that isn't written in VB or Java. EXCELLENT work by the dev team, and thank you very much for this software!