Spurious error from i[pf]_carp

Tom Judge tom at tomjudge.com
Fri Dec 14 06:38:40 PST 2007


Hi,

I have just looked into the source of an error that we are seeing a lot 
on our FreeBSD 6.2-p5 systems. The error is:

"carp_input: received len 20 < sizeof(struct carp_header)"

The messages are coming from a pair of systems that are configured to 
have a pair of load balancing carp interfaces.  However I do not believe 
that these errors are from packets generated by other FreeBSD hosts on 
the same segment.

The hosts are also on the same segment as a pair of Dell PowerConnect 
6224 Layer 3 switches.  These switches are using VRRP to do fail over of 
the router ip address on each vlan.

Here is a tcpdump of one such packet (sensitive data masked):

085815 00:00:5e:00:01:14 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), 
length 60: (tos 0x0, ttl 255, id 1, offset 0, flags [none], proto: VRRP 
(112), length: 40) XXX.XXX.XXX.XXX > 224.0.0.18: VRRPv2, Advertisement, 
vrid 20, prio 100, authtype simple, intvl 1s, length 20, addrs: 
XXX.XXX.XXX.XXX auth "XXXXXX^@^@"

This packet is being sent by the Dell switch.

Here are the offenging lines of code generating the error:

sys/netinet/ip_carp.c (RELENG_6_2)lines: 481:519-526
carp_input(struct mbuf *m, int hlen) {
<SNIP>
     if (m->m_pkthdr.len < iplen + sizeof(*ch)) {
         carpstats.carps_badlen++;
         CARP_LOG("carp_input: received len %zd < "
             "sizeof(struct carp_header)\n",
             m->m_len - sizeof(struct ip));
         m_freem(m);
         return;
     }
</SNIP>


It would be nice if this error was only printed when the debug flag was 
set on the carp interface as this is just over running log files.  I 
think that it would be safe just to drop the packet if it does not fit 
the size constraints.

I guess that there will be more than one VRRP implementation that does 
not generate packets with a header the same size as the carp header.

I have taken a look at the code on HEAD and it is the same as the code 
on RELENG_6_2.

I will look into generating a patch for this over the weekend,  however 
any thoughts/suggestions would be appreciated before I start working on it.


Tom


More information about the freebsd-pf mailing list