Spurious error from i_carp

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
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

Tom Judge wrote:
> 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 will look into generating a patch for this over the
weekend,  
> however any thoughts/suggestions would be appreciated
before I start 
> working on it.
Sounds fine to me, thanks for doing this.

It is regrettable that CARP had to come into existence in
the first 
place because of the VRRP intellectual property situation,
and I guess 
this is one of the turds which end up floating in everyone's
midst as a 
result, if you'll pardon the analogy.

regards,
BMS
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

On Friday 14 December 2007, Bruce M. Simpson wrote:
> Tom Judge wrote:
> > 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 will look into generating a patch for this over
the weekend,
> > however any thoughts/suggestions would be
appreciated before I start
> > working on it.
>
> Sounds fine to me, thanks for doing this.

Alternatively you could change IPPROTO_CARP in netinet/in.h
to another 
unused protocol number.  This is really the preferred way of
dealing with 
mixed CARP and VRRP environments as the CARP packets might
in turn 
irritate the VRRP routers, too.

> It is regrettable that CARP had to come into existence
in the first
> place because of the VRRP intellectual property
situation, and I guess
> this is one of the turds which end up floating in
everyone's midst as a
> result, if you'll pardon the analogy.

/* no comment */

-- 
/"  Best regards,                      | mlaierfreebsd.org
 /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.l
ove2party.net/  | mlaierEFnet
/   ASCII Ribbon Campaign              | Against HTML Mail
and News

Max Laier wrote:
> Alternatively you could change IPPROTO_CARP in
netinet/in.h to another 
> unused protocol number.  This is really the preferred
way of dealing with 
> mixed CARP and VRRP environments as the CARP packets
might in turn 
> irritate the VRRP routers, too.
>   
This sounds like a common use case. Perhaps there is
motivation for 
making the protocol number used by CARP a loader tunable?

[I'd really like it if we had a kernel API for adding the
virtual MAC 
addresses to ifnet too, then again I'd like the cheat for
infinite 
chocolate fudge sundaes in life, bed and breakfast at The
Savoy with my 
choice of actress, etc]
> /* no comment */
>   
No disrespect to anyone intended, just that CARP does
duplicate the 
functionality of VRRP.

It's worth reiterating that this is what happens when
software patents 
are allowed to creep in to the nuts and bolts of the
operational 
Internet -- and thus, CARP was born, and thus Tom runs into
the issue he 
has seen.

later
BMS

_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

Bruce M. Simpson wrote:
> Max Laier wrote:
>> Alternatively you could change IPPROTO_CARP in
netinet/in.h to another 
>> unused protocol number.  This is really the
preferred way of dealing 
>> with mixed CARP and VRRP environments as the CARP
packets might in 
>> turn irritate the VRRP routers, too.
>>   

This seems to make the most sense to me.  At this time it
seems (in 
RELENG_6_2 at least) that because the protocol number is
shared with 
VRRP that tcpdump tries to decode the CARP frames as VRRP
frames and 
although the header/frame is very simple this does not
provide a useful 
decoding of the CARP frame.

After the protocol number is changed it would be possible to
write a 
proper carp decoder for tcpdump or at least make any
existing decoder be 
able to tell the difference between VRRP and CARP frames.

> This sounds like a common use case. Perhaps there is
motivation for 
> making the protocol number used by CARP a loader
tunable?
> 
> [I'd really like it if we had a kernel API for adding
the virtual MAC 
> addresses to ifnet too, then again I'd like the cheat
for infinite 
> chocolate fudge sundaes in life, bed and breakfast at
The Savoy with my 
> choice of actress, etc]
>> /* no comment */
>>   
> No disrespect to anyone intended, just that CARP does
duplicate the 
> functionality of VRRP.
> 

Please correct me if I am wrong, from the limited research I
have done, 
  carp was born because Cisco made a patent claim (based on
its patents 
for HSRP) against a VRRP implementation.

> It's worth reiterating that this is what happens when
software patents 
> are allowed to creep in to the nuts and bolts of the
operational 
> Internet -- and thus, CARP was born, and thus Tom runs
into the issue he 
> has seen.
> 
> later
> BMS
> 

Thoughts?

Tom
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"