Hi,
Somebody asked me if it was possible to monitor wireless
configuration change on 802.11 interfaces.
Looking into the kernel, I noticed that RTnetlink was the
prefered way to export events related to interface changes. So, I
quickly hacked some RTnetlink Wireless Events, and it basically work
the way I want.
Now, I've got some questions :
o Have I done it the right way ? Is there anything I forgot ?
o Is there a way to do a reverse of SIOCGIFINDEX ? If you have
an interface index, how do you get its name ?
o Should I put the full interface name in the event ? That
would make events larger but help query the interface when receiving
the event.
o Any other comments ?
My plan is to continue experimenting with this patch a few
days and collect comments, and then do a new update of Wireless
Extensions with this patch.
Regards,
Jean
On Tue, Oct 09, 2001 at 06:47:00PM -0700, jt wrote:
> Hi,
>
> Somebody asked me if it was possible to monitor wireless
> configuration change on 802.11 interfaces.
> Looking into the kernel, I noticed that RTnetlink was the
> prefered way to export events related to interface changes. So, I
> quickly hacked some RTnetlink Wireless Events, and it basically work
> the way I want.
>
> Now, I've got some questions :
> o Have I done it the right way ? Is there anything I forgot ?
> o Is there a way to do a reverse of SIOCGIFINDEX ? If you have
> an interface index, how do you get its name ?
> o Should I put the full interface name in the event ? That
> would make events larger but help query the interface when receiving
> the event.
> o Any other comments ?
>
> My plan is to continue experimenting with this patch a few
> days and collect comments, and then do a new update of Wireless
> Extensions with this patch.
> Regards,
>
> Jean
I'll probably get more comments if I attach the patch, isn't
it ?
Jean
Hello!
> o Is there a way to do a reverse of SIOCGIFINDEX ? If you have
> an interface index, how do you get its name ?
SIOCGIFNAME.
But this does not matter, applications using rtnetlink should
not use these ioctls. They have all the information from rtnetlink.
> o Should I put the full interface name in the event ? That
> would make events larger but help query the interface when receiving
> the event.
Never. They are known from context.
> o Any other comments ?
I am not sure that it is right and in right place. I would not create one
more message type for such... mmm... special case.
Probably, you could add a new attribute to RTM_*LINK sort of
IFLA_MISC and to send ifinfo messages.
But I see logical flaw: no way to _retrieve_ information about state
on demand. Hence no right application cannot rely only on these messages.
Hence you should go all the way and to allow to dump this and,
probably, to add statistics shown in /proc/net/wireless.
Alexey
On Wed, Oct 10, 2001 at 09:49:52PM +0400, [email protected] wrote:
> Hello!
>
> > o Is there a way to do a reverse of SIOCGIFINDEX ? If you have
> > an interface index, how do you get its name ?
>
> SIOCGIFNAME.
Err... I feel stupid...
> But this does not matter, applications using rtnetlink should
> not use these ioctls. They have all the information from rtnetlink.
That would not be the case of Wireless Events, the event would
just contain the type of change and the interface index. See reasons
for that below.
> > o Any other comments ?
>
> I am not sure that it is right and in right place. I would not create one
> more message type for such... mmm... special case.
> Probably, you could add a new attribute to RTM_*LINK sort of
> IFLA_MISC and to send ifinfo messages.
The problem is that I need to propagate the "command" field
(the ioctl number leading to the event), and there is no space for
that in the ifinfo structure. None of the flags in the ifinfo
structure would change when those ioctls are called.
I don't mind adding a new attribute to struct ifinfo, but that
will break existing netlink apps (unless I missed something).
> But I see logical flaw: no way to _retrieve_ information about state
> on demand.
Hu ? Just query any of the Wireless IOCTLs, and you get the
info you need. Check iwconfig.c on how to do that. I don't see the
need of duplicating the ioctl functionality in netlink, especially
that those ioctl can be big (encryption key, iwspy), complex (power
management) and have a variable geometry.
The IOCTLs have been working to satisfaction, and I don't want
to duplicate this code. What I want is just a channel to propagate an
event.
> Hence no right application cannot rely only on these messages.
> Hence you should go all the way and to allow to dump this and,
> probably, to add statistics shown in /proc/net/wireless.
On the contrary. The app get the event and can query the
related ioctl to see what has changed. I want those event to be *very*
lightweigth so that it is minimal overhead for the vast majority of
applications that could not care less about them and will end up
discarding them anyway.
The whole Wireless configuration is in the order of 624 bytes
(including /proc/net/wireless, excluding iwspy/aplist and assuming
only one encryption key). You surely don't want me to push that with
every event ?
The idea is like select() + read(). Select gives you the basic
event, you need to use read to get the data.
> Alexey
It seems to me that what you are implying is that RTnetlink is
not the right place for me to propagate events. Any idea of what
mechanism might be better to propagate those events ? Maybe I should
create my own event channel.
Thanks for the comments !
Jean
Hello!
> That would not be the case of Wireless Events, the event would
> just contain the type of change and the interface index. See reasons
> for that below.
See below. :-)
> > I am not sure that it is right and in right place. I would not create one
> > more message type for such... mmm... special case.
> > Probably, you could add a new attribute to RTM_*LINK sort of
> > IFLA_MISC and to send ifinfo messages.
>
> The problem is that I need to propagate the "command" field
> (the ioctl number leading to the event), and there is no space for
> that in the ifinfo structure. None of the flags in the ifinfo
> structure would change when those ioctls are called.
> I don't mind adding a new attribute to struct ifinfo, but that
> will break existing netlink apps (unless I missed something).
You missed.
All the rtnetlink messages contain a minimal fix part, followed
by variable attributes. New attributes can be added any time
not breaking anything.
> Hu ? Just query any of the Wireless IOCTLs,
OK. I see.
> The whole Wireless configuration is in the order of 624 bytes
> (including /proc/net/wireless, excluding iwspy/aplist and assuming
> only one encryption key). You surely don't want me to push that with
> every event ?
624? Not a big deal.
> The idea is like select() + read(). Select gives you the basic
> event, you need to use read to get the data.
Sorry, I am inclined against issuing lots of sequences of ioctls to get
information. This approach is fragile because you never
get a self-consistent state when state is subject to change.
Logic of rtnetlink is a bit different: you get atomic pieces of information,
which are meaningfull itself.
> It seems to me that what you are implying is that RTnetlink is
> not the right place for me to propagate events.
Not at all.
But approach which you outlined really contradicts to logic of rtnetlink yet.
It is not a select(), it is real read(). :-)
> Any idea of what
> mechanism might be better to propagate those events ? Maybe I should
> create my own event channel.
Probably. There lots of unused channels. Well, choose the best approach.
Alexey
On Wed, Oct 10, 2001 at 10:48:22PM +0400, [email protected] wrote:
> Hello!
Second try...
I'm now using RTM_NEWLINK and pass the full and complete
wireless event in a RTA structure (therefore, there is no need to
query the ioctl after the event).
Ready for more comments...
Jean