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

Miika Komu <[email protected]>
Newsgroups gmane.linux.ipv6.usagi.users,gmane.network.ipv6.general
Message-ID <[email protected]>
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 <[email protected]>
To: [email protected]
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              [email protected]          http://www.iki.fi/miika/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.