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
