scapy “Ether()” does not have “chksum” argument

[abrahamclose]

The "frame check sequence" is a 32-bit CRC "checksum" over the entire Ethernet frame, starting with the DMAC and covering the SMAC, type, and payload. It's transmitted as the last four bytes of an Ethernet frame, just before the interpacket gap.

I expect Scapy's Ether() method to have an argument for a packet attribute for this field. It does not.

Note that Scapy methods like IP() and TCP()/UDP() contain a checksum argument ("chksum") for the additional checksums defined for those protocols.

For example...

> IP( raw(UDP(chksum=0) / IP(version=4, chksum(0)) )
<IP  version=0 ihl=0 tos=0x35 len=53 id=28 flags= frag=0 ttl=69 proto=hopopt chksum=0x14 src=0.1.0.0 dst=64.0.0.0 |<Raw load='\x7f\x00\x00\x01\x7f\x00\x00\x01' |>>
> ls(Ether)
dst    : DestMACfield    = (None)
src    : SourceMACfield  = (None)
type   : XShortEnumField = (36864)
> Ether( raw(Ether()) )
<Ether dst=ff:ff:ff:ff:ff:ff src=12:34:56:78:9a:bc type=LOOP |>
> Ether.chksum()
AttributeError: chksum

Will FCS be implemented on Ethernet frames in Scapy?

[gpotter2]

The Ethernet FCS is added in the last bytes of a Packet, even though it doesn't look obvious when looking at a wireshark dissection.

See: https://stackoverflow.com/a/55918627/5459467

The FCS isn't implemented on Ethernet frames in Scapy for two reasons.

• First, historically, Scapy had trouble to get a FCS if it was at the end of a packet (but that's no longer the case, as FCSField is a thing now).
• Secondly, most OSes don't supply it by default and when they do, there's no way of knowing that there actually is a FCS other than assuming that the padding at the end of the packet is the FCS. If you feel that it should be added, you should probably open an issue on their tracker.

In fact, most OSes have decided that they should be managing the FCS, and that applications shouldn't have access to those. Only some (usually Linux) let you see them.

This is how they say it on Wireshark

Most Ethernet interfaces also either don't supply the FCS to Wireshark or other applications, or aren't configured by their driver to do so; therefore, Wireshark will typically only be given the green fields, although on some platforms, with some interfaces, the FCS will be supplied on incoming packets.

To parse the FCS, we would need to be so sure that our implementation of the various protocols is correct, that if (as there often isn't) a padding is present at the end of a packet we just dissected, it's the checksum.

That's what wireshark does. See https://stackoverflow.com/a/30515791/5459467

But because Scapy let you mess around with packets, and build very inconsistent stuff, it wouldn't make much sense.

Hope this answers your question :-)

[abrahamclose]

Darn, well thanks for the confirmation and further explanation; I understand. I had read that stackoverflow post and wanted to reach out.

I was looking to use scapy to specify a bad fcs and cause a crc error. I'll look at other approaches.

[gpotter2]

If your OS does support FCS, you can craft this behavior quite easily:

packet = Ether()/IP()/ICMP()
chksum = b"\0\0\0\0"
packet /= chksum
sendp(packet)

and on dissection:

pkt = sniff(count=1)[0]
chksum = bytes(pkt)[-4:]

[lwintermelon]

@gpotter2
But it will change ip header length, so you should do something like below. I hope scapy will support Ethernet FCS.

packet/Padding(b"\0\0\0\0")