SV: [PATCH] networking: ping: Avoid zero checksum in simple ping

[Bernhard Reutner-Fischer]

On June 14, 2016 7:26:20 PM GMT+02:00, Jonas Danielsson <jonas.danielsson at axis.com> wrote:
>> ________________________________________
>> Från: Bernhard Reutner-Fischer <rep.dot.nop at gmail.com>
>> Skickat: den 14 juni 2016 17:01
>> Till: Jonas Danielsson; Jonas Danielsson; Timo Teras
>> Kopia: busybox at busybox.net
>> Ämne: RE: [PATCH] networking: ping: Avoid zero checksum in simple
>ping
>
>> On June 14, 2016 4:12:29 PM GMT+02:00, Jonas Danielsson
><jonas.danielsson at axis.com> 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,