On June 14, 2016 7:26:20 PM GMT+02:00, Jonas Danielsson <[email protected]> wrote: >> ________________________________________ >> 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?
I'd take it either way, preferably even with getpid() but of course with the filter part, too :) So, to restate my question: what MAC was that seen with, just out of curiosity? thanks, _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
