/proc/net/wireless


Vitel

Active Member
Joined
May 16, 2009
Messages
560
Website
vminko.org
This is from /lib/rcscripts/net/wpa_supplicant.sh (gentoo stage3):

Code:
# Checks to see if wireless extensions are enabled on the interface
wpa_supplicant_exists() {
    # Support new sysfs layout
    [[ -L /sys/class/net/$1/wiphy || -d /sys/class/net/$1/wireless ]] \
        && return 0

    [[ ! -e /proc/net/wireless ]] && return 1
    grep -q "^[ \t]*$1:" /proc/net/wireless
}

It fails because `/proc/net/wireless` is empty even when iface is up.
Both ifconfig and iwconfig shows wlan0 before I start wpa_supplicant.
But in the current implementation the driver populates the `/proc/net/wireless` only when wpa_supplicant is already started.
That's why the gentoo scripts fail. I don't know for sure, but it looks like a driver bug.
 
tsh said:
how about other drivers for wireless which ought to do similar things?

1. I don't think that other drivers behavior is a convincing argument. I believe there is a spec describing the /proc/net/wireless behavior. Kernel devs should know such things.

2. But anyway, I have two another wifi cards (DLink 660W and Atheros AR5007EG), whose drivers do populate the file even when iface is down.
 
Last edited by a moderator:
Vitel said:
1. I don't think that other drivers behavior is a convincing argument. I believe there is a spec describing the /proc/net/wireless behavior. Kernel devs should know such things.
I wasn't really questioning your finding, more thinking more along the lines of finding where the driver code differs between ours and any other driver which works. I am not sure who wrote our wireless driver code initially, but it's much more likely to be the chipset manufacturer than one of the Pandora kernel devs. Quite likely to have originally been aimed at a specific platform with more limited expectations in use cases.

I got the impression that you'd already checked some of the code (but I'm not sure where from!)
 
Last edited by a moderator:
Back
Top