> ________________________________________ > Från: Bernhard Reutner-Fischer <[email protected]> > Skickat: den 14 juni 2016 17:01 > Till: Jonas Danielsson; Jonas Danielsson; Timo Teras > Kopia: [email protected] > Ämne: RE: [PATCH] networking: ping: Avoid zero checksum in simple ping
> On June 14, 2016 4:12:29 PM GMT+02:00, Jonas Danielsson > <[email protected]> wrote: >>> What are you asking here? Currently the non-fancy ping sets >>identification to >>> 0. Which is ok by RFC. The host that replies looks at that and sends >>an Echo >>> reply with identification of 0. The problem can arise if we have two >>different >>> ping applications pinging the same host, then we could get the >>replies >>> confused, I guess. Right now the non-fancy ping has no protection >>against >>> that. The fancy one uses getpid() if we think using getpid() is too >>fancy for >>> the non-fancy ping we could switch to a constant. But if we are >>adding >>> identification to non-fancy ping maybe we could add protection >>against >> mismatch as well? >>> >> >>Sorry, now I understand. The non-fancy ping does not check the icmp >>Id on the ping reply. Only the fancy ping does. So I guess using >>getpid() >>Is moot. A non-zero constant would do. >> Right. So.. doesn't the initial problem of allegedly wrong checksum more >> sound like a bug in Linux? >> Maybe you can have a look. Right. It is probably a bug. I write as much in the commit message. I am not sure though since there does seem to be ambiguity around the checksum algorithm with respect to this case: http://www.microhowto.info/howto/calculate_an_internet_protocol_checksum_in_c.html Some background, we saw this on embedded system with a certain type of ethernet MAC. And only on that one. The checksum offloading engine threw away frames that had this "incorrect" checksum. All the other embedded systems with other ethernet MACs we did not see the problem. The frame arrived to the Linux stack and ping worked. It seems that the ethernet MAC in question, along with wireshark marks this as incorrect. But it is maybe not totally clear that a checksum of 0x0000 is a real bug. I will look at where bugs are listed for iptables and file a bug if there isn't one. Unfortunately I will however not have time to look for the bug myself. I think this patch, to avoid having a ICMP packet with all zeroes is worthwhile, not to fix a bug, but to avoid a hornets nest of what the checksum should be, positive or negative zero, in this case. And I understand wanting to fix "the real bug" Would an updated patch with a constant instead of getpid() have a chance of getting applied? >> thanks, Thank you for your time! _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
