SV: [PATCH v2] networking: ping: Avoid zero checksum in simple ping
Jonas Danielsson
jonas.danielsson at axis.com
Wed Jun 22 05:25:26 UTC 2016
> The ICMP RFC says that identifier and sequence number may be zero.
> Having them zero for a Echo message, along with a data of zero:s
> as well will result in a Echo reply message with only zero:s.
>
> Some NAT implementations seem to get the checksum wrong on these
> packages. Setting a checksum of 0x0 instead of 0xffff.
>
> Through NAT:
> Internet Control Message Protocol
> Type: 0 (Echo (ping) reply)
> Code: 0
> Checksum: 0x0000 [incorrect, should be 0xffff]
> Identifier (BE): 0 (0x0000)
> Identifier (LE): 0 (0x0000)
> Sequence number (BE): 0 (0x0000)
> Sequence number (LE): 0 (0x0000)
> Data (56 bytes)
> Data: 000000000000000000000000000000000000000000000000...
> [Length: 56]
>
> Without NAT:
> Internet Control Message Protocol
> Type: 0 (Echo (ping) reply)
> Code: 0
> Checksum: 0xffff [correct]
> Identifier (BE): 0 (0x0000)
> Identifier (LE): 0 (0x0000)
> Sequence number (BE): 0 (0x0000)
> Sequence number (LE): 0 (0x0000)
> [Request frame: 189]
> [Response time: 0.024 ms]
> Data (56 bytes)
> Data: 000000000000000000000000000000000000000000000000...
> [Length: 56]
>
> And this in turn will make some hardware MAC checksum offloading
> engines drop the packet.
>
> This change can be seen as a workaround for bugs in other layers.
> But just setting an identifier for the Echo message packet will
> avoid prodding the hornets nest.
>
> Signed-off-by: Jonas Danielsson <jonasdn at axis.com>
> ---
> networking/ping.c | 6 ++++++
> 1 file changed, 6 insertions(+)
[...]
Ping. (No pun intended)
Is there anything else needed to get something like this fix merged?
More information about the busybox
mailing list