Ethereal-dev: Re: [Ethereal-dev] Packet misdetection

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: metatech <metatech@xxxxxxxxxxxxx>
Date: Wed, 07 Apr 2004 20:59:36 +0200
On Tue, Apr 06, 2004 at 02:07:24PM -0300, Fernando Machado Jr. wrote:
> I had lil bug here. Ethereal identified some packets as websphere
> protocol, and it presented in the statistics as hierarchically under tcp
> protocol. I've found no websphere protocol inside my sniffing, so, if
> this packet exists, it shuold be under http, not tcp.
>
> Do somebody know what happened?

What happend is that either

        1) it was traffic to or from port 1414, and not from or to some
           other port whose dissector saw the packet before the
           WebSphere dissector did

or

        2) it was traffic that looked enough like WebSphere traffic that
           the WebSphere dissector was willing to treat it as such.

If it was 1), perhaps we should change the WebSphere dissector so that
it uses the same tests for port-1414 traffic that it uses for other
traffic.

This is a problem that I have also encountered as well.
- The WebSphere MQ dissector heuristics should be very reliable, but the likelihood that another protocol uses the port 1414 is very high since usely machines start outgoing TCP connections from port 1025 onwards. But the problem is that the heuristics does not apply to every packet in a conversation, although only one (for instance the first one) is enough to mark it as "MQ" for the rest of the conversation. So the heuristics cannot be checked easily on every packet. Or if there was a "likelihood" value for each protocol, I would register as "lowest possible" so that only the heuristics would call it. In a general sense I think it would make sense to define a "likelihood" for each protocol so that we could put HTTP, FTP and POP3 on top priorities and mitigate false detections (statistically speaking). - I tried to remove the registration of the 1414 port, but in that case it is impossible to do a "Decode as..." with MQ... (for instance if another dissector stole the packet). Is there any trick (like creating two protocol handles, one is dummy and the other one is real) ? - Also I haven't found a way to "NAK" a packet once it is passed to a dissector through a port match, is there a way to pass it to another dissector ? (like the return boolean for the heuristic method). - I had the same problem for the NDPS protocol (port 3016 and port 3017) and the ICAP protocol (port 1344) that also stole a packet. I guess other protocols that have higher ports numbers are also concerned but happen less often. Maybe a solution is that when the first packet of a TCP conversation is captured (the SYN), we can deduce that the source address is the client side and the destination address is the server side. After that port matches could only be done for the server side. This trick does not work if the capture was started after the conversation started. Any reactions ? Guy, I also read carefully your answer of the 24/03 about the PDU. I am still the phase of implementing dissection of other STRUCTID (submission as soon as tested), and I will study the PDU thing after that.

See you,

metatech