["Martin Regner" <martin.regner@xxxxxxxxx>]

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.

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.

>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. 

>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. 

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.

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

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. 

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