Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 118516 - madwifi-driver preup- and postdown-hints wrong
Summary: madwifi-driver preup- and postdown-hints wrong
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Mobile Herd (OBSOLETE)
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks:
 
Reported: 2006-01-10 04:44 UTC by Antti Mäkelä
Modified: 2006-01-17 08:46 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antti Mäkelä 2006-01-10 04:44:33 UTC
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.
Comment 1 Stefan Schweizer (RETIRED) gentoo-dev 2006-01-10 05:24:05 UTC
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
Comment 2 Antti Mäkelä 2006-01-10 14:40:11 UTC
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.
Comment 3 Henrik Brix Andersen 2006-01-13 07:31:40 UTC
(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.


Comment 4 Antti Mäkelä 2006-01-13 11:56:03 UTC
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?
Comment 5 Henrik Brix Andersen 2006-01-17 07:21:08 UTC
Fixed in net-wireless/madwifi-tools-0.1401.20060117.
Comment 6 Antti Mäkelä 2006-01-17 08:41:41 UTC
Do you want me to open another bug if I get the wlanconfig-module working? You see to have committed the udev-method.
Comment 7 Henrik Brix Andersen 2006-01-17 08:46:58 UTC
(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.