Rare project developers

[Alexander Gall <>]

On Thu, 9 Jun 2022 14:34:00 +0200, mc36 <> said:

> first of all, thanks for spotting... so the easiest way to have such 
> packets decoded is doing the capture directly from freerouter...
> "packet capture sdnXXX" should record you the exact failing ones with cpu 
> headers stripped down already...
> (if you go for pack cap eth0 then you should get the same result as what 
> you did...)
> but for now, as we already have something and we need to manipulate this 
> hex dumps, k12 format is for rescue (attached)
> is what you sent, with (pack1) and without (pack2) the cpu header.... just 
> wireshark zzz.txt will give you the same red checksum error...
> finally the 2nd capture is how freertr emits an igmp query toward my 
> notebook... it's all green... so for now, cisco was wrong...:)

Thanks. That would be a really astonishing bug. But, sadly, it would
not surprise me (I have a TAC case open since 1.5 years where our
NCS5500 sometimes create bogus destination MAC addresses in IPv6 NS
messages...)

I'd like to look at the packet right after it leaves the 8201, just to
be sure. I'll look at that later.

-- 
Alex

> br,
> cs



> On 6/9/22 14:22, Alexander Gall wrote:
>> Hi
>> 
>> I have RARE/freertr running on my Tofino2 switch. The switch is
>> connected to a Cisco 8201 running IOS-XR 7.5.2. I just tested LLDP and
>> ping and that works fine AFAICS.
>> 
>> However, freertr reports 2 packets per minute with failed checksums,
>> e.g,
>> 
>> 2022-06-09 21:33:16 info ipCor4.parseIPheader:ipCor4.java:91 got bad 
>> checksum from 192.168.10.2
>> 2022-06-09 21:33:26 info ipCor4.parseIPheader:ipCor4.java:91 got bad 
>> checksum from 192.168.10.2
>> 
>> 192.168.10.2 is the address of the 8201. I'm not sure whats's the best
>> way to analyze this. Here are the dumps of the packets taken on the
>> bf_pci0 interface (the destination MAC addresses correspond to
>> 224.0.0.1 and 224.0.0.22)
>> 
>> 21:33:16.726974 00:01:68:87:c6:06 > 00:a8:01:00:5e:00, ethertype Unknown 
>> (0x2240), length 62:
>> 0x0000:  00a8 0100 5e00 0001 6887 c606 2240 0800
>> 0x0010:  46c0 0024 326e 0000 0102 dafe c0a8 0a02
>> 0x0020:  e000 0001 9404 0000 1164 ec5f 0000 0000
>> 0x0030:  023c 0000 0000 0000 0000 0000 0000
>> 
>> 21:33:26.127290 00:16:68:87:c6:06 > 00:a8:01:00:5e:00, ethertype Unknown 
>> (0x2240), length 72:
>> 0x0000:  00a8 0100 5e00 0016 6887 c606 2240 0800
>> 0x0010:  46c0 0038 3276 0000 0102 dacd c0a8 0a02
>> 0x0020:  e000 0016 9404 0000 2200 37d5 0000 0003
>> 0x0030:  0200 0000 e000 0002 0200 0000 e000 000d
>> 0x0040:  0200 0000 e000 0016
>> 
>> The first byte is the CPU header with the source port 168 (front-panel
>> port 5/0 on this device). The first packet is a IGMP membership query,
>> the second a IGMPv3 membership report. I don't have a
>> "hexdump-to-ipchecksum" tool handy, so didn't check the sums in these
>> dumps.
>> 
>> Generic checksum-offloading is disabled on the interface (and I would
>> expect this to not be a problem since the kernel would not be able to
>> determine that this is a IPv4 packet due to the CPU header). Also, the
>> ICMP echo packets appear to have correct checksum (at least freertr
>> doesn't complain about those).
>> 
>> The IGMP packets have the router alert IP option, but I'm sure freertr
>> is handling that correctly :)
>> 
>> I'm also sure you'll see immediately what's wrong here :)
>>