Summary: | gentoo-sources-2.6.19-r4 - wep without module autoload is confusing | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daniel Barkalow <barkalow> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED INVALID | ||
Severity: | trivial | CC: | markphipps, mobile+disabled, phreak |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | .config |
Description
Daniel Barkalow
2007-02-15 19:56:08 UTC
Reopen with some logs output and kernel .config, we really can't guess. In dmesg I get: ieee80211_crypt_wep: could not allocate crypto API arc4 wireless: could not initialize WEP: load module ieee80211_crypt_wep From /etc/init.d/net.wireless start: Error for wireless request "Set Encode" (8B2A) : SET failed on device wireles ; Operation not supported. * wireless does not support setting keys * or the parameter "mac_key_newWLAN" and "key_newWLAN" is incorrect Created attachment 110355 [details]
.config
It turns out that the crypto API module auto-loading support is defective. It works if I load "cryptomgr" and "ecb" (I already had arc4 loaded, so I don't know if it handles that). I'm reporting this upstream, but a workaround or at least a note to users would be helpful to future people with this issue. Turns out that I didn't have CONFIG_KMOD enabled, and module dependancies and udev were taking care of so much that I didn't realize that the kernel wasn't autoloading anything at all. It really comes down to confusing messages and comments for this case: the message from wep only mentions arc4, when it needs other things as well (which I think used to be inherent to the crypto system), and the core stuff doesn't give any feedback that it needs some particular module and autoloading isn't enabled. It's also kind of confusing that wep selects ecb and cryptomgr in kbuild, but doesn't depend on them in depmod, and doesn't select KMOD, so you've got these modules installed because of wep, but they're still not available to wep. Thanks for the report, although as you have observed, this isn't a bug. You wouldn't have had this problem if you had compiled the items into your kernel as opposed to as modules. Users are commonly hit by unexpected behaviour when dealing with modules since the kernel really doesn't effort to load them for you (with a couple of exceptions such as this case in part) and it is not designed to either. The kernel configuration guide has some notes on this. |