> - i captured the dataflow from a RAS to a WAP-Gateway with: tcpdump -i eth0
> -w dump.log.
> - i want to move the dump in a human readable file with : tethereal -r
> dump.log -x -V > dump.readable
> - less dump.readable tells me a data length of 26 Bytes (every unknown
> UDP-Packet) and the hexdump shows this bytes
I.e., you have a 14-byte Ethernet header, a (probably) 20-byte IP
header, an 8-byte UDP header, and 26 bytes of UDP payload (rather than
the entire packet, including all headers, being 26 bytes)?
That would add up to the 68 bytes that is tcpdump's default, as per
Gilbert's mail.
> - but the UDP-part tells length of 505 bytes and tcpdump shows, with a
> small binary-dump patch, that there is much more data
tcpdump shows more than 26 bytes with the *same* capture file?
That sounds like a bug in tcpdump; it shouldn't be going past the end of
the 68 bytes of captured data, even if the packet included more data
that wasn't provided to tcpdump because it had asked to see only the
first 68 bytes.
> - i open the dump.log with ethereal and its the same!
Not surprisingly, given that Ethereal and Tethereal use the same code
(the Wiretap library) to read capture files, and use the same packet
dissector code.
> i try to change to change :
> #define END_OF_FRAME (pi.captured_len - offset)
> to :
> #define END_OF_FRAME (pi.captured_len)
END_OF_FRAME is really "length of data remaining in the captured data in
the frame, starting at the offset in the variable named 'offset'",
rather than "total length of frame"; the name may be a bit confusing.
I.e., END_OF_FRAME should be defined as (pi.captured_len - offset), as
it currently is.
> but there is still the problem of losing bytes (now i can see 68 Bytes)
Yup, that's the default capture length for tcpdump.
As noted in my previous mail message, you can either tell tcpdump to
capture more data, or use Tethereal rather than tcpdump to capture the
data - Tethereal defaults to "show me the entire packet" (well, it
defaults to 65535, as there's no way to specify "show me the entire
packet" to the packet capture library that Ethereal, Tethereal, and
tcpdump all use, but 65535 should be more than enough) rather than to
"show me only the first 68 bytes of the packet".
By the way, is the protocol used for the dataflow to the WAP gateway
documented? If so, we could perhaps write a dissector for it, if that'd
be useful (at least if it's on a standard port number, or if you can
deduce from the packet contents whether it's a packet for that
protocol).
