Hi folks, On 25 Apr 2015, at 16:35, Chris Boot <[email protected]> wrote: > > Hi folks, > > I’m running bird6 1.4.5-1 (from Debian jessie) on my home network. Quite > regularly I see floods of "Received bad lsa checksum” message in my syslog on > the two routers that run BIRD, which causes connectivity interruptions.
So I did some of my own debugging and worked out what’s happening. Here is a captured LSA from my network: 00 4f 20 02 00 00 01 15 51 bb 37 66 80 00 01 36 00 c3 00 28 00 00 00 13 51 bb 37 66 0a 00 01 80 51 bb e5 a4 51 bb e5 a5 The checksum in the LSA is 00c3, which is at offsets 16 and 17. This LSA comes from my Dell PowerConnect 8024F. I’m not sure if this is valid or not; my reading of RFC905 Annex B suggests that it’s valid for either of the octets to be zero, but not both. I *think* that it’s an implementation detail shared with both Quagga and BIRD that the value 0 can never be generated for ‘x’, which comes from the RFC1008 reference implementation. The problem happens because BIRD doesn’t verify the checksum by running Fletcher against the received packet and testing for zero; rather it: - sets the checksum in the packet to 0 - runs the checksum calculation on the LSA data - updates the checksum in the packet (and comes up with a different result) - complains when the result is not the same as what was in the packet I believe the correct way to verify the checksum would be to run the algorithm against the unchanged packet (with the checksum intact) and verify that the result is zero. Would a patch that changes this behaviour be welcome? I’ve written something up against the current git master, but haven’t yet tested it. Cheers, Chris -- Chris Boot [email protected]
