Hacker News Reader

They generally only get dropped if they have an invalid checksum.

Since checksums are hardware accelerated, the invalid packet probably had a valid checksum applied to it.

In addition, a valid checksum is no guarantee that the packet is valid. They are very weak hashes, not cryptographic. If a NIC goes haywire and sends "random" data at wire speed, there will be bad packets with valid checksums.

If cut-through is enabled in the switch, it won't even drop on bad checksum, since by the time the switch can tell the checksum is wrong, it has already forwarded the entire packet.

It is really unfortunate that the checksum is on the opposite end of the frame from the routing information on Ethernet frames.

Why? If it was at the start it’d remain useless until the whole frame was received anyway.

Makes sense to have it at the end.

It also allows you to calculate the checksum as your serialising the packet data onto the send buffer, without having to get the whole packet in memory, checksum it, write the checksum, then finally write the packet data.

It'll just log it... and then you get to play "let's find where it's coming from" as each switch just forwards that bad boy on as fast as possible.

Reply on news.ycombinator.com