Ritesh Raj Sarraf <r...@researchut.com> writes:
>> Setting level 6 restores the default:
>>
>> nemi:/etc# echo 6 > /sys/class/net/wlan0/device/power_level
>> nemi:/etc# cat /sys/class/net/wlan0/device/power_level
>> SYSTEM:auto MODE:auto INDEX:0
>>
>>
>> However level 7 seem to be gone, as reported by Clemens:
>>
>> nemi:/etc# echo 7 > /sys/class/net/wlan0/device/power_level
>> bash: echo: write error: Invalid argument
>>
>>
>> So there still is a difference between 0 and 6. I have absolutely no
>> idea which one should be used on AC, but I do note that 6 seems to be
>> the default.
>
> I'm not sure about this as I don't have that device. I'm copying Clemens
> since
> he was the one of first pointed the changes.
Clemens is correct. Use 0 and 3. Sorry for adding confusion.
I've looked a bit at what's coming, and there seem to be more changes in
this area queued up for both the next 2.6.30.x and for 2.6.31 and
2.6.32. The plan is obviously to get rid of the kernel based policy
(MODE:auto) and leave this to userspace as it should be done. So mode 6
will disappear soon, even though it still is present in the current
Debian 2.6.30 kernel.
>> A side note: The "wireless" node seems to be gone in 2.6.30:
>>
>> nemi:/etc# ls -la /sys/class/net/wlan0/wireless
>> ls: cannot access /sys/class/net/wlan0/wireless: No such file or directory
>>
>>
>
> Again, on my box with ipw2200 device, 2.6.30 still presents the wireless
> folder.
>
> r...@champaran:/usr/share/man $ ls /sys/class/net/eth1/wireless/
> beacon crypt fragment level link misc noise nwid retries status
>
> You must be using the newer iwlwifi drivers.
>
> Oops!!. There's LP Bug #369113 where I fixed similar bug for ipw2200.
> I'm not sure how the wireless folder has reappeared in 2.6.30. It was
> reported
> to not be present in 2.6.29. Sigh!!
>
> Perhaps wireless-tools is what should be used here too....
That would be great. But I don't think the driver supports it (yet?).
I always get
Power Management:off
from iwconfig regardless of the /sys/class/net/wlan0/device/power_level setting
>>
>> You may want to apply this or something similar to get 2.6.30 support.
>> I must admit that I didn't really understand the need for the
>> "-d $DEVICE/wireless" test. Testing the driver name should be safe
>> enough.
>>
>
> I'm not sure how you plan testing the driver name ? As wlan* ?
> Take my case, the wireless device is listed as eth1. Checking for the
> "wireless" folder's existence was one way to identify it a wireless device.
I meant the test the script already does:
It runs this with $1 set to iwl3945, iwl4965 or iwlagn depending on
which of these modules that are loaded:
LINK_TARGET=`readlink $DEVICE/device/driver`
LINK_TARGET=${LINK_TARGET##*/}
if [ "$LINK_TARGET" = "$1" ] ; then
AFAICS, this effectively tests the driver name of the device. It can't
matter much whether you end up running this test for *all* network
devices or just for the wireless ones?
On my system, this will end up tesing 4 LINK_TARGETs where 2 of them
matches:
bj...@nemi:~$ for DEVICE in /sys/class/net/*; do if [ -h $DEVICE/device/driver
]; then readlink $DEVICE/device/driver; fi; done
../../../bus/pci/drivers/e1000e
../../../../../../bus/usb/drivers/cdc_ether
../../../../bus/pci/drivers/iwlagn
../../../../bus/pci/drivers/iwlagn
If we had the wireless directory we could have avoided running readlink
for the e1000e and cdc_ether, but I doubt that you'll notice that in
practice anyway...
Note that only physical network ports matter here, as they are the only
ones with a driver symlink. So you can have a large number of VLANs,
bridges, tap interfaces, tunnels etc without and performance hit even if
you remove the "-d wireless" test
> The sysfs breakage is one reason why I want to rely on tools instead. Or if
> we
> were using a high level language, libraries.
Yes, working libraries would be preferred. Let's hope wireless tools
support is coming.
Bjørn
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
