Bugzilla Bug 118516

Latest madwifi-driver ebuild suggests inserting the following into
/etc/conf.d/net to create the ath0 device:

preup() {
        if [ "\${IFACE}" = "ath0" ]; then
                /sbin/wlanconfig ath0 create wlandev wifi0 wlanmode sta
                return \$?
        fi
}

postdown() {
        if [ "\${IFACE}" = "ath0" ]; then
                /sbin/wlanconfig ath0 destroy
                return \$?
        fi
}

  This is wrong. The if condition should test whether the device being
configured is "wifi0" not "ath0". You also need to set config_wifi0=( "null" )
in and create /etc/init.d/net.wifi0 -> net.lo symlink. 

  Currently, when plugging in a wireless PCMCIA card, wifi0 device is created
but nothing happens. I need to manually say /etc/init.d/net.ath0 start to bring
it up.

  With my changes, when PCMCIA card is inserted, wifi0 device is created =>
system starts to bring it up, with null config => preup() is ran and ath0 is
created => system starts to bring it up => wireless access via ath0,
automatically.

thank you, I will change that asap.
How do you like brix-overlay way of doing it with an udev-rule?

http://dev.gentoo.org/~brix/files/overlay/net-wireless/madwifi-tools/madwifi-tools-0.1372.20051231.ebuild

As a matter of fact, I was going to suggest going for udev/hotplug approach (a
much more logical place to do it), since you cannot really be completely sure
that will your device be named "wifi0" or something else (with different
numbers or something else entirely, perhaps to separate builtin wifi vs. pcmcia
cards).

The ruleset at
http://dev.gentoo.org/~brix/files/overlay/net-wireless/madwifi-tools/files/madwifi-tools-0.1372.20051231-udev.rules
seems like a good starting point. Of course it only creates a standard device
(for infrastructure mode, ie. connecting to an access point with the ad-hoc
config commented out). 

  I'm not sure I completely understand the madwifi developers on why the
virtual device type (Ad-hoc/Infrastructure/AP) has to be specified on creation
and cannot be changed with 'iwconfig ath0 mode X' commands afterwards. 

  It's just that providing wireless options at multiple places (beyond
/etc/conf.d/wireless and net) is a bit inconvenient and perhaps a bit
unintuitive (especially since there are LOTS of madwifi-driver users these days
due to the Atheros chipset being integrated to laptop motherboards). 

  Is there any knowledge on whether virtual device modes can be changed
afterwards with iwconfig on the later versions of madwifi-driver? Ie. run the
iwconfig ath0 mode Managed/Ad-hoc/Monitor/Master command? Then the udev rule
would work fine (ie. it would only create the device, but actual configuration
would happen via iwconfig (or wpa_supplicant) and standard configuration
files). 

  If not, maybe
   a) two devices should be created, one for ad-hoc and one for infrastructure
mode
   b) a separate "wlanconfig" module for wireless (like there are
wpa_supplicant and iwconfig modules) to /lib/rcscripts/net.modules.d should be
written, specifically for madwifi-driver. Then the udev rule could be forgotten
and all the configs would be happening at one place.

(In reply to comment #2)
>   It's just that providing wireless options at multiple places (beyond
> /etc/conf.d/wireless and net) is a bit inconvenient and perhaps a bit
> unintuitive (especially since there are LOTS of madwifi-driver users these days
> due to the Atheros chipset being integrated to laptop motherboards). 

Agreed.

>   Is there any knowledge on whether virtual device modes can be changed
> afterwards with iwconfig on the later versions of madwifi-driver? Ie. run the
> iwconfig ath0 mode Managed/Ad-hoc/Monitor/Master command? Then the udev rule
> would work fine (ie. it would only create the device, but actual configuration
> would happen via iwconfig (or wpa_supplicant) and standard configuration
> files). 

I don't think that is possible, but please take this up with upstream
developers.

>   If not, maybe
>    a) two devices should be created, one for ad-hoc and one for infrastructure
> mode

This doesn't sound logical to me - I doubt many people use ad-hoc wireless
networking. I can add a commented example to the udev configuration file,
though.

>    b) a separate "wlanconfig" module for wireless (like there are
> wpa_supplicant and iwconfig modules) to /lib/rcscripts/net.modules.d should be
> written, specifically for madwifi-driver. Then the udev rule could be forgotten
> and all the configs would be happening at one place.

That would certainly be nice. Feel free to submit such a script.

Upstream ticket is at http://madwifi.org/ticket/176 - not going to happen soon,
it seems.

Anyway, creating a 'wlanconfig' module should probably work out simply as
something that sets up ath0 - basically just create a virtual interface based
on wireless setting:

# Set the mode of the interface (managed, ad-hoc, master or auto)
# The default is auto
# If it's ad-hoc or master you also may need to specify the channel below
mode_ath0="auto"

Unfortunately, the fallback to ad-hoc and other similar automations are easier
said than done. The mode has to be fixed (or the only way to change is destroy
& recreate).

Anyway, regarding creating the module..the situation is basically similar to
creating bridges or tunnels or other virtual interfaces. So the configuration
could probably be similarly in /etc/conf.d/net, like so:

wlanconfig_ath0="wifi0"  ie. specify the virtual device(ath0) and the master
device. Like with bridges, you need to set wifi0_config=( "null" ) to prevent
dhcp and other stuff happening on the master interface. And also depend_ath0 {
need net.wifi0 }.

So, the module would basically be, in pseudoish-code

wlanconfig_provides { wlanconfig }

wlanconfig_start {
if mode ($iface) == "auto" || "managed" 
 {wlanconfig create ath0 in STA mode }
if mode ($iface) == "adhoc" {wlanconfig create ath0 in AD-Hoc mode}
}

What do you think? I could try coming up with something functional one of these
days. As long as the operating mode is visible to the module it shouldn't be
too difficult..Does this work in hotplugging scenarios? I would think so, at
least if the depend is set.

The ad-hoc fallback functionality needs to be either bundled to the iwconfig
module OR the user can just do what I suggested (altough it's a bit dirty, but
since the driver mandates it) and create two virtual devices, ath0 for STA and
ath1 for ad-hoc or something..

Comments?

Fixed in net-wireless/madwifi-tools-0.1401.20060117.

Do you want me to open another bug if I get the wlanconfig-module working? You
see to have committed the udev-method.

(In reply to comment #6)
> Do you want me to open another bug if I get the wlanconfig-module working? You
> see to have committed the udev-method.

Yes, please open that as a seperate enhancement request.