Ok, i assume you use NFS with Linux which will cause lots of
IP fragments in an "unusual" but more efficient order.
When you read the capture, it is not until ethereal has seen the fragment
with offset==0 that it knows whether the packet contains udp (.rpc.nfs)
or not.
Ethereal is also limited to read all packets sequentially, it can not go
back
to earlier packets and redissect them.
This means that if the very first fragment that has been seen is not the one
with
offset==0, then ethereal cant know what it contains. Ethereal wont even know
if it is
tcp or udp or icmp or something else.
By the time ethereal finds the fragment with offset==0 then its too late
because the
previous fragments have already been registered as IP unknown protocol or
something.
We cant go back, remove the earlier ones from the stats, and redissect the
earlier ones.
A workaround might be possible:
Try to activate IP reassembly. (which will not solve the problem directly)
and then after you have read the entire file you just apply an empty display
filter
to cause ethereal to rescan the packetlist.
That might work.
It is a difficult problem to solve in general since we must scan the packet
list linearly
but some packets just dont have any meaning until we have looked at other
packets
later in teh capture.
----- Original Message -----
From: "Khachaturov Vassilii"
Sent: Saturday, September 07, 2002 7:23 AM
Subject: [Ethereal-dev] problems with reassembled dgrams in stats
> I've discovered the following problem with the hier. stats
> while analyzing NFS traffic with large packets.
>
> When there is a lot of fragmented frames some of them
> get reordered in transit (fragments relative to each other).
> The packets that arrive ahead of time are treated just as
> "IP DATA" whereas if they arrive properly in sequence
> the reassembly is OK and they're also counted properly
> in the stats.
>
> Maybe there are some factors that contribute to the fragments
> of NFS (udp.rpc.nfs) frames to be treated as ip.data, but I
> only noticed the sequencing thing above. Does anyone need
> a capture to look at it further for debugging?
>
> V.
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
