Bugzilla – Bug 652
ifrename cannot rename if rf_kill is on
Last modified: 2005-10-09 12:16:36
You need to log in before you can comment on or make changes to this bug.
I'm trying to rename the interface with ifrename (from the wireless-tools). It works perfectly except when the rf_kill is turned on. In that case the ifrename command runs (without any error message), but the interface is not renamed.� This is a serious problem for me, because wpasupplicant cannot do its work until the interface is renamed and there is no trigger I can found for the event of turning off the rf_kill (so that I could rename the interface then).
Are you renaming the interface based on the MAC address?
Yes, you are correct: I'm trying to rename based on the MAC address. Shouldn't that work? The only other viable option I see is to rename based on the driver. I might just try that in the morning.
This is a known problem; the MAC address is not read from the card when the rf_kill switch is active.
And is the issue tracked somewhere? I could not find any bug regarding this.
If rf_kill is on during modprobe, the eeprom is not initialized. Since mac address is extracted from eeprom, ifrename get NULL instead of the correct mac address. If rf_kill is turned on after modprobe, there will be no problem since the mac address is already extracted from eeprom. There is no rf_kill event, but you can poll /sys/bus/pci/drivers/ipw2200/*/rf_kill.
The MAC address is not read because the driver chose not to - am I right? If yes, then this is an annoying driver limitation and not a hardware limitation. Couldn't we make the driver read just the MAC from eeprom even if the rf_kill switch is on?
If the rf_kill is active during modprobe, the driver even doesn't bother to load firmware. So getting mac address is not just read eeprom, it requires a lot of overhead the driver is not originally supposed to do. However I'll leave the bug open to discuss in the bug scrub.
Created an attachment (id=379) [details] Initializes EEPROM data even if RF KILL active Please try the attached patch against 1.0.3 and verify that it operates as expected. You should now be able to obtain the MAC address even if the device is loaded while RF KILL is active.
Your patch does not apply cleanly against 1.0.3. Specifically hunk 2 fails. There does not seem to be 'IPW_DEBUG_INFO("Took %dms to de-init\n", 1000 - i);' anywhere in 1.0.3 (and ipw_send_card_disable()is commented out, etc). I would like test this out, but I'm not sure how to fix the patch. Thanks Zsolt
Marking as TESTED_PATCH_EXISTS. Any help testing this is appreciated.
Do you mean that you have tested the patch and it works for you? How did you apply it, and against which version?
The patch is in 1.0.4. Just try the new version.
I have updated to 1.0.4 and tried out the fix. It works perfectly. Thanks.
reopen to mark as fixed.
Patch in 1.0.4. Works fine.
Mark as verified.