Spurious error from i[pf]_carp

[Tom Judge]

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