Hello!
2 small problems:
I just tried (for the first time) to capture traffic on the loopback interface
on a SuSE Linux 6.3 system (kernel 2.2.16, current ethereal (one hour old),
libpcap 0.5). I found that ping 127.0.0.1 gave me 2 identical echo request
ICMP packets and two identical answers. Is this a known error? I could also
reproduce this with other local programs. The stock SuSE tcpdump had not
this problem (but uses the wrong magick 0xa1b2cd34 and a different layout in
the file, so I could not read it in ethereal.
I run ipchains with a lot of firewall rules (but lo is free for all), maybe
this causes some problems.
Another problem are too short packets. If I capture on a different Linux
computer (RedHat 5.2, ethernet interface, packets coming over an ISDN gateway)
I get padded packets. These are too short packets, which the ethernet cannot
send across the wire (64 bytes actually but libpcap does not see the CRC at the
end, so padding goes up to 60 bytes). I never encountered such packets in
RPC & NFS (because the headers are huge) but I find them frequently in
Quake traces (yes, the Quake dissector goes along very nicely).
What sould we do with these packets? In the hex bytes window, it shows all
60 bytes but the tvbuffer goes only up the end of the IP packet. So we
have a lot of bytes but no explanation in the tree view.
Something like dissect_padding() in dissect_ip() to mark the bytes behind the
IP data as padding would be nice.
Bye, Uwe
