Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 120765 - madwifi & udev autoloading
Summary: madwifi & udev autoloading
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Other
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-28 14:37 UTC by Jacek Sieka
Modified: 2006-02-03 10:22 UTC (History)
1 user (show)

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 Jacek Sieka 2006-01-28 14:37:35 UTC
Hello,
I'm using baselayout-1.11.14-r2, udev-079-r1 and madwifi-driver/tools-0.1401.20060117. Whenever the module is loaded, the current solution asks udev to run wlanconfig to create it's interface using a udev rule. Because of (I suspect) http://bugs.gentoo.org/show_bug.cgi?id=118419, this no longer works when autoloading the module from modules.autoload.d/kernel-2.6 on boot. 
It works as expected when running "rmmod ath_pci && modprobe ath_pci" after the boot process is complete.

I would additionally comment on the net* scripts being run automagically when the interface comes up and how annoying that is, but someone did it before me (http://bugs.gentoo.org/show_bug.cgi?id=119613) but I won't. It's giving me some trouble with wpa_supplicant but I haven't been able to pinpoint it exactly, so I'll investigate some more before whining some more =)

Thanks!

Portage 2.0.54 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15-gentoo-r1 i686)
=================================================================
System uname: 2.6.15-gentoo-r1 i686 Intel(R) Pentium(R) M processor 1500MHz
Gentoo Base System version 1.6.14
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -march=pentium-m -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=pentium-m -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks nostrip sandbox sfperms strict"
GENTOO_MIRRORS="http://mirror.pudas.net/gentoo"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O,2"
LINGUAS="en sv jp it fr"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X Xaw3d a52 accessibility acpi alsa anthy artworkextra audiofile avi bash-completion bcp berkdb bjam bzip2 cdr cjk crypt cups dga divx4linux dvd dvdr emboss encode ethereal examples exif expat fam firefox flac foomaticdb fortran gcj gd gdbm glibc-omitfp glut gmp gnome gnutls gstreamer gtk gtk2 guile hal imagemagick imlib ithreads java jpeg junit lcms libg++ libwww mad madwifi mikmod mmap mmx mng mozdevelop mozilla moznocompose moznoirc mp3 mpeg ncurses nls no-htdocs nocommonsnet noplugin noxalan nptl nptlonly offensive ogg oggvorbis opengl pam pcre pdflib perl png pnp postgres pyste python quicktime readline real recode samba slang source spell sqlite sse sse2 ssl svg svga tcltk tcpd threads tiff truetype truetype-fonts trusted type1-fonts udev unicode usb vim-with-x vorbis xml xml2 xprint xrandr xv xvid zlib linguas_en linguas_sv linguas_jp linguas_it linguas_fr userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LC_ALL
Comment 1 Greg Kroah-Hartman (RETIRED) gentoo-dev 2006-01-28 14:54:43 UTC
So what exactly is this bug created for?  You seem to understand why the 
initial boot stuff has changed, and the way to prevent the interface
from being automatically created if you want to.

Comment 2 Jacek Sieka 2006-01-29 01:51:06 UTC
The bug report is for madwifi and its current way of automatically creating the ath0 interface using wlanconfig and udev.
This used to work with the old baselayouts, even when autoloading the module using modules.autoload.d. Right now I have to either reload the module manually every time I reboot my laptop, or create an additional rc-script myself to do it, and I believe this is something the casual user really shouldn't be bothered with. Just installing the madwifi package should "make it work", just as it did before the baselayout changes.
So this bug report was really two things, 1) to notify that the new baselayout changes led to problems with other packages (perhaps not only madwifi?), and 2) that madwifi needs a new way of creating ath0, otherwise it won't work for people that autoload the module at startup (which makes an awful lot of sense for me for example, since the wifi card is internal to my laptop, and I use it practically every time I boot my computer).

Sorry about the rant at the end of the report though, I do realise it's a bit out of place...I'll leave it at your discretion to reopen the bug or not, although I haven't found anything similar when searching the bugzilla. I hope I was more clear this time.
Comment 3 Roy Marples (RETIRED) gentoo-dev 2006-01-29 02:24:54 UTC
rc-update add net.ath0 default

OR use something like coldplug to load the module (and don't use modules.autoload.d) and trigger the chain of events again.

The key issue is loading the module AFTER sysinit and you get the exactly the same behaviour you're used to. As coldplug can load the module for you after sysinit then it works :)
Comment 4 Jacek Sieka 2006-01-29 03:20:53 UTC
Heh, yes, I do have net.ath0 in my default startup profile =)

Here's the complete story:
The madwifi module, when loaded into the kernel, creates a pseudo-interface named wifi0 which is not usable for anything. You then have to run a separate application to create ath0 from wifi0 setting the type of network interface you want (ad-hoc, managed, monitoring, etc etc...don't ask me why the madwifi developers chose to do it like this). 
The new madwifi packages take this into account and add a udev-rule (in /etc/udev/rules.d) that automatically run this application whenever wifi0 is created. Since the new baselayout blocks udev rules for network interfaces (and this still feels like a hack to me =), it means that ath0 never becomes available for net.ath0 to start since it's never created, and this rule is broken for autoloaded modules.

As you say, I *could* install coldplug, but in that case, coldplug should become a dependecy of madwifi-tools (the package that installs the application needed to create ath0 from wifi0), because things *do not work* without it (and to be frank, I really don't want coldplug either, when there's already udev installed on my computer which already did everything I wanted and didn't make my boot any longer that it absolutely had to be), or at least the should be an ewarn advising me to do so when installing the package because now I hade to wade through a bunch of obscure startup scripts and closed bugzilla reports to find out why something that used to work suddenly stopped working.
Comment 5 Roy Marples (RETIRED) gentoo-dev 2006-01-31 08:23:25 UTC
You can always do this in conf.d/net

preup() {
   if [[ ${IFACE} == "ath0" ]] ; then
      if ! interface_exists "${IFACE}" ; then
         if ! interface_exists "wifi0" ; then
            eerror "Cannot create ath0 as wifi0 does not exist"
            return 1
         else
            wlanconfig command to create ath0
         fi
      fi
   fi
}

There's also a wlanconfig baselayout module on bug #120519 which does something similar.

If you do re-open this bug, please re-assign to mobile@gentoo.org
Comment 6 Jacek Sieka 2006-02-03 10:22:00 UTC
That's a very neat solution (much neater than whatever I came up with =). I sent a mail to the madwifi maintainer and he agreed with you that this is up to the individual user...thanks for the help, hopefully this will help the next fella with the same problem as well =)