(usagi-users 03574) Re: 2.6.14.3 Kernel issue with rtnetlink/af_netlink

[Miika Komu <miika@xxxxxx>]

On Fri, 16 Dec 2005, Bellino, Phil wrote:

> Hello,
> We had been running the Linux kernel 2.6.13.
> We have an application process that listens for rtnl messages using
> "busybox-1.00/networking/libiroute/libnetlink(rtnl_listen routine)".
>
> Specifically, the kernel gets IPV6 Global prefix RA packets via a radvd
> server.
> When the kernel gets the RA packet and verifies it, our application looks to
> see that the rtnl generated message  "nlmsg_type == RTN_NEWADDR".
> Based on this, the listen sockets and binds for these addresses are then set
> up..
> This all worked well with 2.6.13.
>
> We upgraded to 2.6.14 R3 and we no longer are getting any messages when new
> addresses are learned.
>
> Has anyone seen this issue or anything remotely similar? If not, any other
> help would be appreciated.

Confirm. Tested to be broken also in 2.6.14.2

---------- Forwarded message ----------
Date: Wed, 14 Dec 2005 14:08:19 +0200
From: Kristian Slavov <kristian.slavov@xxxxxxxxxxxxxx>
To: netdev@xxxxxxxxxxxxxxx
Subject: Some RTNLGRPs "missing" in linux/rtnetlink.h?

Hi,

I was using UML 2.6.13.1 to listen RTMGRP_IPV6_ADDR netlink group, but
after updating to UML 2.6.14.3, I no longer received any messages. I also
tested "ip -6 monitor addr", but it remained silent as well.
However, "ip -4 monitor addr" works ok.

Checking the linux/rtnetlink.h, it seems like there should be some dummy
RTNLGRPs between RTNLGRP_IPV4_ROUTE and RTNLGRP_IPV6_ADDR, as well as
later in RTNLGRP_DECnet_* and RTNLGRP_IPV6_PREFIX.

So, I tested adding a dummy entry between IPV4_ROUTE and IPV6_ADDR, and
both, my program and ip, received ipv6 address notifications.

Looks like do_one_broadcast if af_netlink.c checks wrong bits.


-- 
Miika Komu              miika@xxxxxx          http://www.iki.fi/miika/