> 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 <[email protected]> > --- > 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? _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
