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
will avoid prodding the hornets nest.
Signed-off-by: Jonas Danielsson <[email protected]>
---
networking/ping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/networking/ping.c b/networking/ping.c
index 5d71fe8..24fb10a 100644
--- a/networking/ping.c
+++ b/networking/ping.c
@@ -214,6 +214,7 @@ static void ping4(len_and_sockaddr *lsa)
pkt = (struct icmp *) G.packet;
/*memset(pkt, 0, sizeof(G.packet)); already is */
pkt->icmp_type = ICMP_ECHO;
+ pkt->icmp_id = (uint16_t) getpid();
pkt->icmp_cksum = inet_cksum((uint16_t *) pkt, sizeof(G.packet));
xsendto(pingsock, G.packet, DEFDATALEN + ICMP_MINLEN, &lsa->u.sa,
lsa->len);
--
2.1.4
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
