> I was chasing down some invalid packet lengths in dissect_tftp, and it
> seems to me that all ethernet packets have an FCS on the end, and in a lot
> of cases we are treating it as data, which screws things up.
That may depend on the networking card and driver - in a capture I just
took on a Solaris 2.5.1 machine here, the last two bytes of an NNTP
response are the CR and LF at the end of the line, so it looks as if, at
least with the Happy Meal Ethernet driver on Solaris 2.5.1, the FCS
isn't part of the packet handed up to DLPI.
> Am I correct in this? If so, I suspect that we need to deal with it.
Ideally, all UNIX-flavored OSes would either refrain from supplying the
FCS as part of the frame in their "raw packet capture" mechanism, or
would provide an "ioctl" or something to specify that it shouldn't be
included, or would, at least, either always do so for devices of a
particular data link type or would provide a way that a library such as
"pcap" or "wiretap" could find out what stuff it needs to strip off from
the end to provide a uniform interface to applications.
Which OS are you using, and which networking card are you using?
> However, packets captured from the loopback interface do not seem to have
> an FCS.
Right - they generally rely on the parity or ECC bits to detect data
corruption. :-)
