Wireshark · Ethereal-users: RE: [Ethereal-users] Possible Protocol Mismatch

[Lambrecht Joris <joris.lambrecht@xxxxxxxxxxxxxxxxxxxxxxx>]

Reply in text below ...

>-----Original Message-----
>From: Martin Regner [mailto:martin.regner@xxxxxxxxx]
>Sent: woensdag 4 juni 2003 22:13
>To: Lambrecht Joris
>Cc: ethereal-users@xxxxxxxxxxxx
>Subject: Re: [Ethereal-users] Possible Protocol Mismatch
>
>
>Joris Lambrecht wrote:
>>Yup, that one i figured out, browsing the data i noticed some 
>'select from'
>>wich gave me a clue. Port 5000 : 2600 seemed to be the comms 
>between Sybase
>>Server/ Application Client wich i had not been told about. 
>Chief was quite
>>amased i got that information, seemed happy enough :-)
>
>It seems that port 5000 is a quite normal TCP server port 
>(listening port) for Sybase.
>A search with Google on "sybase tcp port 5000" resulted in a 
>lot of Sybase related documents with portnumber 5000 indicated in them.
>
>When setting up a TCP connection towards a server then the 
>port used on the client side will normally be a port
>in a very wide range of port numbers, 1024 and upwards 
>(something like 1024 - 30000, I think, may vary dependent on 
>the OS and configurations). As you see from a sample netstat 
>printout below I have some HTTP connections established 
>towards port 80. The local port on my machine differs for the 
>different TCP connections.
>
> TCP    10.19.14.12:1197    216.239.33.99:80       ESTABLISHED
> TCP    10.19.14.12:1198    216.239.33.99:80       ESTABLISHED
> TCP    10.19.14.12:1202    212.112.162.203:80     ESTABLISHED
> TCP    10.19.14.12:1203    212.112.162.203:80     ESTABLISHED
> TCP    10.19.14.12:1222    217.16.193.80:80       ESTABLISHED
> TCP    10.19.14.12:1223    217.16.193.80:80       ESTABLISHED
>
>If I make a printout later today I might have some HTTP 
>connection with client side port 2600. Ethereal will still dissect that
>packet with the HTTP dissector since lower port number has 
>priority when selecting what non-heurestic dissector to be used.
>
>I guess that the port number is 2600 in your case may just be 
>a coinsidence. If the TCP connection is re-established then 
>the local port number will probably be different, and then 
>Ethereal will dissect it as TDS/Netlib or maybe another 
>protocol, e.g. the Diameter dissector if the client side port 
>number is 1812,  since 1812 is also lower than 5000.
>
>>the answer is Yes. From what i've seen i'd have to conclude 
>the traffic is of the same
>>stream (TDS) but either recognised as TDS or as ZEBRA. Thus 
>there might
>>either by an intrusion of this network, some other cause like 
>exceptional
>>circumstance, or something erronous.
>

		The ZEBRA packets only occured in two or three captures.
AFAIK there are no other occurencies yet, i'll try to find out what caused
this, maybe some newbie-enabled setting in combination with some other event
triggered this behaviour.

>If the packet is sent from e.g. port number 2601 towards port 
>5000 then I understand it, but for packets sent between port 2600
>and 5000 I don't currently understand it, but it may be 
>related to the "converstion" stuff. I haven't look in detail on that.
>

		Yesterday i have verified this to be correct, the contents
of the packets also made this clear.
		There is no need to look into this any further as the client
uses port 2600 and sybase:5000.
		

>>That's the funny part above. It might be worthwhile 
>mentioning i'm using
>>Ethereal Win32 because i don't have clearance for enabling a 
>*nix box (yet).
>>Ethereal-packet-dissection is not part of my active 
>knowledge, i know close
>>to nothing about this.
>
>I think that you will have similar behaviour when using 
>Ethereal on Unix. 
>

		Okay, thanks. Since you asked for input on Ethereal but i'm
no developper or network-expert (yet:-)) i refrain to these aestethic
suggestions. If i'm missing out on some feature of Ethereal you can
obviously discard my remarks. I'll find out sooner or later, or when i have
some time to do some reading up on the Ethereal-Documentation.

		Ethereal could use : 

			* a display of the date/time (detailed view in
win32) of the capture-files to load.
			* Some sort of scheduler (AT-like) in the
GUI-version could be nice as well
			* In the file menu a list of most recently used
capture-files could be usefull as well.
			* Marking the packets wich are tricky-to-identify as
you indicated below is a very good idea.
			* A way of selecting packets and saving them without
marking them would be a nice feature as well.
			* More statistics would be welcome as well,
indicating for example wich ports are used, this would be very handy to
overview the live-status of a network. Unforseen port-usage could
immediately surface that way.
			

>>Cycling the packet thru heuristic / non-heuristic dissectors 
>might be better
>>?
>>
>>Figured these would appear as an 'Unknown' type instead of a 
>best-guess
>>type.
>
>I think that there is certain things that could be improved to 
>how Ethereal recognizes packets.
>At least one thing could be to change some of the 
>non-heursitic dissectors to do certain checks if the packets 
>looks correct, i.e.
>use the new_create_dissector_handle() or 
>new_create_dissector_handle() etc.
>http://www.ethereal.com/lists/ethereal-dev/200210/msg00077.html
>
>The Skinny dissector is one disector that I have already 
>planned to update in the near future:
>http://www.ethereal.com/lists/ethereal-users/200305/msg00161.html
>
>I guess that there is several others that could be improved.
>
>Another thing could maybe be to try the packets against other 
>dissectors even if one dissector already has claimed the
>packet (non-heuristic dissectors that has been updated to use 
>new_create_dissector_handle and heuristic dissectors). 
>I don't know if it could be posible to add this with the 
>current design of dissectors etc. 
>

	I'm afraid you lost me around here for now. I'll look into the
dissector-chunk today.


>How should Ethereal handle a packet that matches several 
>different dissectors? How should this be presented?
>I gues that this would also make Ethereal at least a bit slower.
>I think that the default behaviour probably should probably be 
>similar to what it is to day, but it might be good to have an option
>to turn on when needed.
>


	I agree this i a good idea for reasons of oversight. The way to go
might be a step one should trigger from a menu. The proposal below of
indicating the packets wich are multi-dissectable could prove very usefull.


>It could maybe be good to indicate the packets that are 
>matching more than one non-heursitic disectors in a special way,
>i.e. when destination port matches one protocol and the source 
>port matches another protocol.
>
>One idea I got right now is that maybe Ethereal could indicate 
>if there is a protocol registered in Ethereal for the 
>different port numbers,
>e.g. similar to below. I guess that a complete "/etc/services" 
>file covering all IANA registered port numbers and other commonly
>used port numbers may hower be even better since that will 
>also work when Ethereal uses heursitic disectors. 
>I haven't looked into if it is possible to use something 
>similarto "/etc/services" on Windows. 
>http://www.ethereal.com/lists/ethereal-dev/199912/msg00339.html
>


	There is such a file on windows (etc/services) wich is to be found
in the WINNT\system32\etc directory. However, i am not up-to-speed on how
windows makes use of this file troughout the different versions in the
field. The beforementioned directory lists some other usefull files as well.
Overwriting this file with a more complete version would probably not harm
anything on the system(s) involved.


>Transmission Control Protocol, Src Port: 1812 (1812), Dst 
>Port: 2000 (2000), Seq: 3488678205, Ack: 1393327998, Len: 208
>    Source port: 1812 (1812) [Diameter]
>    Destination port: 2000 (2000) [Skinny]
>    Sequence number: 3488678205
>    Next sequence number: 3488678413
>    Acknowledgement number: 1393327998
>
>However this wouldn't help in the case of TDS/NetLib since 
>that dissector is a heursitic dissector (not registering a 
>port number).
>
>>As far as i know a packet or a protocol i assumed that each
>>protocol-related-packet had a clear identifier, this could 
>offcourse be to
>>little to work on at times. This probably also means i'll have to stop
>>looking for a protocol-signature database.
>
>There are some protcols with clear identifiers (one example is 
>SIP) but I guess that most protocols doesn't have clear identifiers.
>One reason is probably to limit the number of data sent.
>
>Many protocols have certain things that can be checked to see 
>if the packet looks reasonable:
>For example a normal TPKT header has the first octet set to 
>0x03 and next octet is 0x00 (but really only for TPKT version 3 - but
>I don't think that there is any other version used currently 
>AND if the reserved byte is set to 0x00 as it should. However 
>I think that some older H.323 specifications didn't state that 
>the reserved byte should be set to 0x00)
>
>RTP packets may be difficult to distinguish from other 
>packets. For RTP version 2 there is two bits that should be in 
>a certain way,
>and thene there are some other checks that can be done. 
>  
>>Here we are at the 'Malformed packet' part of my findings. 
>For some reason
>>some packets are described as 'Malformed Packet : Browser' 
>I'm running out
>>of time to take a good look at this but from what i found 
>these are "Intel
>>NetPort" packets. But i'm strongly suspecting the Sybase 
>Server as well. 
>

		The 'Malformed Packets' only appear with netbios and only
then with 'Host Announcements' from printservers. The 'Printserver Host
announcements' are very different then those made by other hosts on the
network wich is probably why they're being reported as 'Malformed'. A
valuable addition to the Ethereal dissectors ?

		The most notable difference's are in the SMB-block and the
'Microsoft Windows Browser Protocol'-block. I don't fully understand why
these devices set such exotic properties but hope to find a reason for
eliminating this since they're probably also messing up the Master Browser
election and/or netbios-performance on this network.

		
>What port numbers is there for these packets? Is the packets 
>sent to/or from port 5000 then it might be a similar problem
>as with the Zebra dissector that they are really TDS packets.
>Or there could be someother kind of protcol mismatch.
>
>When you have "malformed packets" then there could be several 
>different explanations, e.g.:
>
>-The wrong dissector is used (port number and/or heuristics 
>problem). In this case you could start to check what port is
>the server port, and check what programs are runned on the 
>computer and similar things.
>
>-Packet reassembly/desegmentation is not enabled for TCP 
>and/or the other protocols involved. The default setting is that
> "Allow subdissector to desegment TCP streams" is disabled. I 
>always turn it on otherwise I will get a lot of packets shown
>as "malformed" for the protcols I'm normally looking at.
>
>-There is one or several faults in one or several of the 
>dissectors. In this case you could compare with protocol descriptions
>and similar.
>Another alternative could be to send some sample packets to 
>the ethereal list (with non-sensitive data) and hopefully 
>someone can try to help you what is wrong and maybe also fix 
>the problem.
>
>-Perference settings might be set to wrong values. There is 
>for example some protocols where you have to set the "IETF 
>draft version"
>and if you don't have the correct value some packets may 
>appear as "malformed". Only some protcols have the
>protocol version in the packets.
>
>-You have maybe not captured the full packets (the "snapshot 
>lenght" is to short).
> Ethereal/Tetheral defaults to capture the full packet - but 
>tcpdump and some other capture program doesn't.
>So if the capture was done with another program or if you 
>actually configured Ethereal/Tethereal to use a snapshot
>length then that could be an explanation.
>
>-The dissector may not work with the protocol version used in 
>your network. Some Ethereal dissectors has not been updated
>for a while.
> 
>-The packets are really malformed.
>
>
>>Since i'm not an expert by far i'd say "This rieks." because of the
>>frequency of these "Malformed Packets" either of type TDS or of type
>>BROWSER. Are the malformed packets normal in a network ? 
>There was some
>>mention on the Cisco website for the router we're using but 
>most, if not
>>all, of these packets were not routed at all.
>>
>
>See above
>
>
>
>

Many thanks for the completenes within your reply's, it's nice to have this
kind of feedback while still fresh.


Regards,

Joris