NETLINK upcalls and wireless events

NETLINK upcalls and wireless events

[Pavlin Radoslavov]

[Apology for the cross-post, but I am not sure which is the right
 mailing list for this question]


BACKGROUND:

I am using Linux NETLINK sockets to monitor network interface events
in the kernel such as "interface added/deleted", "address
added/deleted", etc.

The RTM_NEWLINK message type upcall from the kernel to user-space is
used to signal that a new network interface has been created (e.g.,
a tunnel interface, a PC-Card has been inserted, etc).
One of the attributes of that message (see rtnetlink(7)) is
IFLA_IFNAME and is used to store the device name (e.g., "tun0",
"eth0", etc).


PROBLEM:

So far everything worked fine on a desktop: whenever I add a tunnel,
the kernel sends to user-space RTM_NEWLINK, I check the IFLA_IFNAME
attribute to get the name of the new interface, etc.

However, a fellow tried same software on a laptop in wireless
environment, and then RTM_NEWLINK messages started to appear for no
apparent reason. Those messages did not contain the IFLA_IFNAME
attribute which was strange and I started to suspect that it could
be a kernel bug. After some investigation I found that the
RTM_NEWLINK message can be generated not only when there is a new
interface, but in some other cases as well. Inside file
linux/wireless.h (I am looking into version 15 from 12.7.02) I found
the following comment: 

/* ----------------------- WIRELESS EVENTS ----------------------- */
/*
 * Wireless events are carried through the rtnetlink socket to user
 * space. They are encapsulated in the IFLA_WIRELESS field of
 * a RTM_NEWLINK message.
 */


In other words, some wireless events may also generate RTM_NEWLINK
message as well. I don't have a laptop with Linux to verify that
myself, but I am quite sure that some wireless events do generate
RTM_NEWLINK with no IFLA_IFNAME.


QUESTION:

If I receive an RTM_NEWLINK message, is there a reliable way to
find-out whether the message is generated because of a wireless
event or because indeed there is a new network interface installed
in the kernel.

Checking whether the message contains the IFLA_WIRELESS field is
probably not an option, because I may be compiling the code on a
slightly older Linux box that doesn't have IFLA_WIRELESS defined.
The only solution I have so far is to check whether the message
contains the IFLA_IFNAME field, but this is more like a work-around
rather than a solution. Any suggestions?

Thanks,
Pavlin

RE: NETLINK upcalls and wireless events

[Gargi D]

Hi,

I was wondering if you could help me in understanding the usage of
netlink sockets.  Wireless events such as a signal that a new interface
has been created, can anyway be read from 

/proc/net and var/lib/pcmcia/stab

Why would then want to use netlink sockets to get an indication of the
same.


Regards, 


Miss. Gargi Dadhich 
Member Technical Staff 
Networking and Internet Software Group (NISG) 
C-DAC, Pune 

Tel:    020-25694000/1/2/3      Extn: 484 
Fax:    020-25694059 



-----Original Message-----
From: hostap-bounces+gargid=cdacindia.com@shmoo.com
[mailto:hostap-bounces+gargid=cdacindia.com@shmoo.com] On Behalf Of
Pavlin Radoslavov
Sent: Tuesday, March 23, 2004 7:43 AM
To: hostap@shmoo.com; netdev@oss.sgi.com
Cc: pavlin@icir.org
Subject: NETLINK upcalls and wireless events


[Apology for the cross-post, but I am not sure which is the right
mailing list for this question]


BACKGROUND:

I am using Linux NETLINK sockets to monitor network interface events in
the kernel such as "interface added/deleted", "address added/deleted",
etc.

The RTM_NEWLINK message type upcall from the kernel to user-space is
used to signal that a new network interface has been created (e.g., a
tunnel interface, a PC-Card has been inserted, etc). One of the
attributes of that message (see rtnetlink(7)) is IFLA_IFNAME and is used
to store the device name (e.g., "tun0", "eth0", etc).


PROBLEM:

So far everything worked fine on a desktop: whenever I add a tunnel, the
kernel sends to user-space RTM_NEWLINK, I check the IFLA_IFNAME
attribute to get the name of the new interface, etc.

However, a fellow tried same software on a laptop in wireless
environment, and then RTM_NEWLINK messages started to appear for no
apparent reason. Those messages did not contain the IFLA_IFNAME
attribute which was strange and I started to suspect that it could be a
kernel bug. After some investigation I found that the RTM_NEWLINK
message can be generated not only when there is a new interface, but in
some other cases as well. Inside file linux/wireless.h (I am looking
into version 15 from 12.7.02) I found the following comment: 

/* ----------------------- WIRELESS EVENTS ----------------------- */
/*
 * Wireless events are carried through the rtnetlink socket to user
 * space. They are encapsulated in the IFLA_WIRELESS field of
 * a RTM_NEWLINK message.
 */


In other words, some wireless events may also generate RTM_NEWLINK
message as well. I don't have a laptop with Linux to verify that myself,
but I am quite sure that some wireless events do generate RTM_NEWLINK
with no IFLA_IFNAME.


QUESTION:

If I receive an RTM_NEWLINK message, is there a reliable way to find-out
whether the message is generated because of a wireless event or because
indeed there is a new network interface installed in the kernel.

Checking whether the message contains the IFLA_WIRELESS field is
probably not an option, because I may be compiling the code on a
slightly older Linux box that doesn't have IFLA_WIRELESS defined. The
only solution I have so far is to check whether the message contains the
IFLA_IFNAME field, but this is more like a work-around rather than a
solution. Any suggestions?

Thanks,
Pavlin
_______________________________________________
HostAP mailing list
HostAP@shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap

Re: NETLINK upcalls and wireless events

[Pavlin Radoslavov]

> I was wondering if you could help me in understanding the usage of
> netlink sockets.  Wireless events such as a signal that a new interface
> has been created, can anyway be read from 
> 
> /proc/net and var/lib/pcmcia/stab
> 
> Why would then want to use netlink sockets to get an indication of the
> same.

Just to clarify: I am not interested in wireless events, but when
a new network interface has appeared (regardless whether it is a
wireless interface or not).

There are several reasons I want to use netlink:
 * I am interest in much more events (new interface addresses,
    routes added/deleted/etc), and NETLINK is the natural mechanism
    to do all of that.
 * I am not sure that I can use asynchronously /proc/net/dev &
   friends to obtain interface-related events (but I may be wrong
   here).
   I am not familiar with var/lib/pcmcia/stab, but looks like it is
   pccard-specific, and I am interested in any type of interface.
 * I would prefer that I deal with system calls to obtain the
   information rather than parsing ASCII output.

Thanks,
Pavlin

> 
> 
> Regards, 
> 
> 
> Miss. Gargi Dadhich 
> Member Technical Staff 
> Networking and Internet Software Group (NISG) 
> C-DAC, Pune 
> 
> Tel:    020-25694000/1/2/3      Extn: 484 
> Fax:    020-25694059 
> 
> 
> 
> -----Original Message-----
> From: hostap-bounces+gargid=cdacindia.com@shmoo.com
> [mailto:hostap-bounces+gargid=cdacindia.com@shmoo.com] On Behalf Of
> Pavlin Radoslavov
> Sent: Tuesday, March 23, 2004 7:43 AM
> To: hostap@shmoo.com; netdev@oss.sgi.com
> Cc: pavlin@icir.org
> Subject: NETLINK upcalls and wireless events
> 
> 
> [Apology for the cross-post, but I am not sure which is the right
> mailing list for this question]
> 
> 
> BACKGROUND:
> 
> I am using Linux NETLINK sockets to monitor network interface events in
> the kernel such as "interface added/deleted", "address added/deleted",
> etc.
> 
> The RTM_NEWLINK message type upcall from the kernel to user-space is
> used to signal that a new network interface has been created (e.g., a
> tunnel interface, a PC-Card has been inserted, etc). One of the
> attributes of that message (see rtnetlink(7)) is IFLA_IFNAME and is used
> to store the device name (e.g., "tun0", "eth0", etc).
> 
> 
> PROBLEM:
> 
> So far everything worked fine on a desktop: whenever I add a tunnel, the
> kernel sends to user-space RTM_NEWLINK, I check the IFLA_IFNAME
> attribute to get the name of the new interface, etc.
> 
> However, a fellow tried same software on a laptop in wireless
> environment, and then RTM_NEWLINK messages started to appear for no
> apparent reason. Those messages did not contain the IFLA_IFNAME
> attribute which was strange and I started to suspect that it could be a
> kernel bug. After some investigation I found that the RTM_NEWLINK
> message can be generated not only when there is a new interface, but in
> some other cases as well. Inside file linux/wireless.h (I am looking
> into version 15 from 12.7.02) I found the following comment: 
> 
> /* ----------------------- WIRELESS EVENTS ----------------------- */
> /*
>  * Wireless events are carried through the rtnetlink socket to user
>  * space. They are encapsulated in the IFLA_WIRELESS field of
>  * a RTM_NEWLINK message.
>  */
> 
> 
> In other words, some wireless events may also generate RTM_NEWLINK
> message as well. I don't have a laptop with Linux to verify that myself,
> but I am quite sure that some wireless events do generate RTM_NEWLINK
> with no IFLA_IFNAME.
> 
> 
> QUESTION:
> 
> If I receive an RTM_NEWLINK message, is there a reliable way to find-out
> whether the message is generated because of a wireless event or because
> indeed there is a new network interface installed in the kernel.
> 
> Checking whether the message contains the IFLA_WIRELESS field is
> probably not an option, because I may be compiling the code on a
> slightly older Linux box that doesn't have IFLA_WIRELESS defined. The
> only solution I have so far is to check whether the message contains the
> IFLA_IFNAME field, but this is more like a work-around rather than a
> solution. Any suggestions?
> 
> Thanks,
> Pavlin
> _______________________________________________
> HostAP mailing list
> HostAP@shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
> 

Re: NETLINK upcalls and wireless events

[Pavlin Radoslavov]

> > > Checking whether the message contains the IFLA_WIRELESS field is
> > > probably not an option, because I may be compiling the code on a
> > > slightly older Linux box that doesn't have IFLA_WIRELESS defined.
> > > The only solution I have so far is to check whether the message
> > > contains the IFLA_IFNAME field, but this is more like a work-around
> > > rather than a solution. Any suggestions?
> > 
> > 	The method I personally use is that I keep a little database
> > of interfaces (I need it for other reasons). Therefore, I know if the
> > interface is new (not in my database) or already exist (present in my
> > database).
> 
> This is the best way to do it.
> 
> > 	Note that in theory, RtNetlink messages may be lost (due to
> > memory pressure). Also, you won't only get NEWLINK when interface
> > register, but also when interface goes up and down, or when multicast
> > or promiscuous flags are changed. Which mean that in practice you want
> > to be much more clever than what you do now.
> 
> If you maintain a database in userspace the real good check would be
> the ifindex since this would be unique for the device and persistent. 
> The name can be changed. 
> If you already have the ifindex in your database then clearly thats just
> an event announcement.

Good point! I already have a database with all ifindex so the check
will be trivial.
I will try the other suggestions as well.

> Next thing to check would be the state of the flags/changemask to see if
> the admin status changed (eg ifconfig down ).
> And of course whatever the IFLA_* attribs (which are optionaly sent).
> Typically you can catch lost messages in netlink since the socket gets
> its error flag set. You can use that as an event to check for changes.
> 
> > 
> > 	Both methods you suggest would also work. If IFLA_WIRELESS
> > doesn't exist, just define it :
> > -----------------------------
> > #ifndef IFLA_WIRELESS
> > #define IFLA_WIRELESS	(IFLA_MASTER + 1)
> > #endif /* IFLA_WIRELESS */
> > -----------------------------
> > 
> > 	The latest method is to look at both ifi_flags and
> > ifi_change. If ifi_change is 0, it is usually a wireless event (but
> > not always).
> 
> mask should really indicate that something new is in the flags so
> hopefuly it is not being arbitrarily set to 0 to indicate events.
> Not too familiar with IFLA_WIRELESS - but is this a link event or is 
> something conviniently using the link message? What kind of things does
> it announce/configure?

I am not familiar with IFLA_WIRELESS either, so I don't know what
type of event is.

Thanks for all suggestions!
Pavlin

Re: NETLINK upcalls and wireless events

[jamal]

On Tue, 2004-03-23 at 12:57, jt@bougret.hpl.hp.com wrote:

> > Checking whether the message contains the IFLA_WIRELESS field is
> > probably not an option, because I may be compiling the code on a
> > slightly older Linux box that doesn't have IFLA_WIRELESS defined.
> > The only solution I have so far is to check whether the message
> > contains the IFLA_IFNAME field, but this is more like a work-around
> > rather than a solution. Any suggestions?
> 
> 	The method I personally use is that I keep a little database
> of interfaces (I need it for other reasons). Therefore, I know if the
> interface is new (not in my database) or already exist (present in my
> database).

This is the best way to do it.

> 	Note that in theory, RtNetlink messages may be lost (due to
> memory pressure). Also, you won't only get NEWLINK when interface
> register, but also when interface goes up and down, or when multicast
> or promiscuous flags are changed. Which mean that in practice you want
> to be much more clever than what you do now.

If you maintain a database in userspace the real good check would be
the ifindex since this would be unique for the device and persistent. 
The name can be changed. 
If you already have the ifindex in your database then clearly thats just
an event announcement.
Next thing to check would be the state of the flags/changemask to see if
the admin status changed (eg ifconfig down ).
And of course whatever the IFLA_* attribs (which are optionaly sent).
Typically you can catch lost messages in netlink since the socket gets
its error flag set. You can use that as an event to check for changes.

> 
> 	Both methods you suggest would also work. If IFLA_WIRELESS
> doesn't exist, just define it :
> -----------------------------
> #ifndef IFLA_WIRELESS
> #define IFLA_WIRELESS	(IFLA_MASTER + 1)
> #endif /* IFLA_WIRELESS */
> -----------------------------
> 
> 	The latest method is to look at both ifi_flags and
> ifi_change. If ifi_change is 0, it is usually a wireless event (but
> not always).

mask should really indicate that something new is in the flags so
hopefuly it is not being arbitrarily set to 0 to indicate events.
Not too familiar with IFLA_WIRELESS - but is this a link event or is 
something conviniently using the link message? What kind of things does
it announce/configure?
 
cheers,
jamal

Re: NETLINK upcalls and wireless events

[jt]

Pavlin Radoslavov wrote :
> 
> I am using Linux NETLINK sockets to monitor network interface events
> in the kernel such as "interface added/deleted", "address
> added/deleted", etc.
[...]
> In other words, some wireless events may also generate RTM_NEWLINK
> message as well. I don't have a laptop with Linux to verify that
> myself, but I am quite sure that some wireless events do generate
> RTM_NEWLINK with no IFLA_IFNAME.
[...]
> If I receive an RTM_NEWLINK message, is there a reliable way to
> find-out whether the message is generated because of a wireless
> event or because indeed there is a new network interface installed
> in the kernel.
> 
> Checking whether the message contains the IFLA_WIRELESS field is
> probably not an option, because I may be compiling the code on a
> slightly older Linux box that doesn't have IFLA_WIRELESS defined.
> The only solution I have so far is to check whether the message
> contains the IFLA_IFNAME field, but this is more like a work-around
> rather than a solution. Any suggestions?

	The method I personally use is that I keep a little database
of interfaces (I need it for other reasons). Therefore, I know if the
interface is new (not in my database) or already exist (present in my
database).
	Note that in theory, RtNetlink messages may be lost (due to
memory pressure). Also, you won't only get NEWLINK when interface
register, but also when interface goes up and down, or when multicast
or promiscuous flags are changed. Which mean that in practice you want
to be much more clever than what you do now.

	Both methods you suggest would also work. If IFLA_WIRELESS
doesn't exist, just define it :
-----------------------------
#ifndef IFLA_WIRELESS
#define IFLA_WIRELESS	(IFLA_MASTER + 1)
#endif /* IFLA_WIRELESS */
-----------------------------

	The latest method is to look at both ifi_flags and
ifi_change. If ifi_change is 0, it is usually a wireless event (but
not always).

	Have fun...

	Jean