Wireshark-bugs: [Wireshark-bugs] [Bug 3033] many zero edonkey layers for tcp(port: 4582, 4662)
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Tue, 29 Jan 2013 15:23:31 +0000

changed bug 3033

What Removed Added
CC   mmann78@netscape.net

Comment # 3 on bug 3033 from 
(In reply to comment #2)
> Seems like eDonkey would be better suited as a heuristic dissector than
> blatantly steal ports from the registered protocols of kar2ouche, oms,
> noteit, contclientms and rfa.  Also, eDonkey makes use of
> tcp_dissect_pdus(), so what's this "continuation data"?  Shouldn't
> dissect_edonkey_tcp_pdu() get called only when all the data is present and
> reassembled by TCP?  I'm not familiar enough with eDonkey to confidently go
> any further with it; just posing some questions for someone who might be.

In looking at the eDonkey/eMule documentation I can find, it appears that it
doesn't have a strong enough hueristic to really work, just a single "magic
byte".  If it were a "magic guint32", than I would feel more comfortable with
the heuristic approach.

Looking at the IANA port list, I suspect kar2ouche to be the Kademlia2
extention of eDonkey.  Based on what eDonkey is intended for, I wouldn't be
surprised if the other "Message Service" ports used it.   However, I would be
perfectly happy with eDonkey just supporting a preference range of ports
(defaulting to 0)

It looks like the "continuation data" was in there from the beginning and
should have been removed when tcp_dissect_pdus() was added.

You are receiving this mail because:
  • You are the assignee for the bug.
  • You are watching all bug changes.