Rare project developers

[mc36 <>]

hi,
i also did not believed this so i simply replayed the previous igmps through 
the tofino dataplane vm,
and i also got the checksum error so at least it's something.... :)
https://github.com/rare-freertr/freeRtr/blob/f24232b5332ed9f4eeeaa1daa8b9301e70b63c1e/misc/p4bf/include/ig_ctl_dprs.p4#L34
is what updates the checksum, and well, rsvp is the other protocol with 
router alert option.... lemme fix it real quick... :)
br,
cs

sid#packet capture pw1
% capturing=true
sid#packet capture sdn1
% capturing=true
sid#packet replay pw1 /nfs/zzz.txt
% tx:  01 00 5e 00 00 01 00 76 16 02 74 79 | | 08 00 46 00 00 24 00 00 00 00 
01 02 3a cc 0a 08 ff fe e0 00 00 01 94 04 00 00 11 0a ec b9 00 00 00 00 02 3c 
00 00
% tx:  01 00 5e 00 00 01 00 76 16 02 74 79 | | 08 00 46 00 00 24 00 00 00 00 
01 02 3a cc 0a 08 ff fe e0 00 00 01 94 04 00 00 11 0a ec b9 00 00 00 00 02 3c 
00 00
% tx:  01 00 5e 00 00 01 00 76 16 02 74 79 | | 08 00 46 00 00 24 00 00 00 00 
01 02 3a cc 0a 08 ff fe e0 00 00 01 94 04 00 00 11 0a ec b9 00 00 00 00 02 3c 
00 00
% tx:  01 00 5e 00 00 01 00 76 16 02 74 79 | | 08 00 46 00 00 24 00 00 00 00 
01 02 3a cc 0a 08 ff fe e0 00 00 01 94 04 00 00 11 0a ec b9 00 00 00 00 02 3c 
00 00
info ipCor4.parseIPheader:ipCor4.java:91 got bad checksum from 10.8.255.254
info ipCor4.parseIPheader:ipCor4.java:91 got bad checksum from 10.8.255.254
info ipCor4.parseIPheader:ipCor4.java:91 got bad checksum from 10.8.255.254
info ipCor4.parseIPheader:ipCor4.java:91 got bad checksum from 10.8.255.254
sid#packet capture pw1
% capturing=false
sid#packet capture sdn1
% capturing=false
sid#



On 6/9/22 14:54, Alexander Gall wrote:
> 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.