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