[PATCH 3/5] -m <ifname_match> matches interface names via fnmatch(3) and assigns them the default configuration file, like so

[Roy Marples]

Jouni Malinen wrote:
> On Tue, May 26, 2009 at 10:25:16PM +0100, Roy Marples wrote:
>> wpa_supplicant -c /etc/wpa_supplicant.conf -m "*"
>>
>> This makes every interface try to initialize with the default driver,
>> whch distribution setup a lot easier.
>> This can be used in the future to for wpa_supplicant to startup
>> on interfaces that do not exist at boot, like for say pcmcia interfaces.
> 
> How portable code is this? I did not test this yet, but I would expect
> this to break the build with MinGW and Visual Studio..

I've only supplied patches for driver_bsd to actually use this.
I have patches for driver_wext also, but it stops the other drivers from
working so I've not sent it. My quick look shows that driver_bsd works
because the receive event is a simple wrapper to wpa_supplicant_event
whereas driver_wext does a lot of work before that happens.

I may be able to spend time over the next few days looking at making it
work better on Linux - maybe a driver_linux is required.

I lack a MinGW environment, but do have Visual Studio 2008. If it can
compile without MinGW then I can test any compile breakage, but I have
no wireless in the Windows machine. BTW, what kind of breakage are you
expecting? The net/if.h include?

> Furthermore, I'm not sure this type of functionality should really be
> part of wpa_supplicant. The more common way of doing this has been to
> have an external component that is tracking hotplug devices add new
> interfaces (e.g., through dbus or the global control interface; or by
> running one wpa_supplicant process per interface, if desired).

I'm surprised by that :)
driver_bsd and driver_wext both have code that almost works for this and
there are pre existing events for interfaces being added and removed.
I'm just providing the last piece (well, for driver_bsd anyway).

Yes, more common way is through an external component tracking devices
and I myself wrote such code into Gentoo (well, the glue scripts at any
rate).

However, no BSD has dbus in the base system, nor is the global control
interface a constant. Also, it requires script integration into the
system which is not desirable for NetBSD, nor minimal Gentoo Linux
installs. Going via kernel messages is a much cleaner and efficient method.

Thanks

Roy