Guy Harris wrote:
OK, so it's not as if it uses BPF.
It might be Really Nice to convince the kernel folk to have some
mechanism by which code reading from a PF_PACKET socket could get
information supplied by drivers - such as:
an indication of how many bytes of FCS are in the packet (not just
"present or absent", as PPP can have 0, 2, or 4 bytes of FCS);
an indication of whether the packet had various link-layer errors
(if, for example, you plan to have a "capture even packets with bad
FCSes" setting for the driver).
That way, when we go to a next-generation libpcap format, we could
supply that information, and, when using that format, not have to guess
whether the FCS is present.
I'll look into this.
Ethereal shows the last 4 bytes (the checksum), it just shows them as
part of the normal ethernet packet.
"Part of the normal Ethernet packet" in what sense? Does it show them
as part of a trailer, or as part of the data for your protocol?
It shows no trailer, just part of the data for my protocol. I just tested,
and UDP packets do show the FCS as desired.
Yes, and when you capture (at least on Mac OS 10.3) on the 10/100/1000
interface on a G4 PowerMac, the last 4 bytes of captured packets (except
for outgoing packets, but that'll presumably be the case for your
changed driver as well) are always the FCS.
Actually, I am working on a way to specify the FCS so that I can purposefully
create bogus packets with CRC errors, but I doubt that will ever get into the
kernel. At any rate, just dealing with RX pkts is fine.
So, if I just had a checkbox in ethereal that said 'FCS is last 4
bytes, always!'
then ethereal would not have to parse any protocols to decode the FCS
correctly.
And if the protocols being used either run atop 802.3+802.2 or include a
length field, Ethereal would not have to be *changed* to decode the FCS
correctly.
The checkbox might be useful for other protocols, and for overriding
Ethereal's default behavior, but it is *NOT* necessary for IPv4 or IPv6
or IPX (they have length fields), or for a bunch of miscellaneous
protocols that run atop 802.3+802.2.
The checkbox would be a good crutch for strange and/or buggered protocols.
I am also working on driver changes to allow receiving bad CRC packets, and
in this case you cannot necessarily depend on being able to decode the protocol(s)
anyway.
As mentioned, I'll try to get the feature into the Linux kernel so
that ethereal
can automatically querry the interface when it starts its capture, making
the checkbox irrelevent (on these versions of Linux at least).
No, it doesn't - not unless there's something in the capture file to
indicate whether a packet has an FCS or not (and note that, for outgoing
packets, the answer is probably "not" regardless of whether the driver
has been configured to include the FCS in *received* packets or not).
Ahh, I had forgotten about saved capture files.
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
