Hi all,
I'm experiencing a bad behaviour of rfkill / iwlang driver. Here the
description:
Kernels: 2.6.30.[5,6] 2.6.31
Hardware: HP EliteBook 6930p
Behaviour: once a working wireless is killed activating the rfkill button,
there is no way to turn off the rfkill and riactivate wifi network. Even a
reboot is not able to reset the situation; to get again the control of rfkill
button is to reboot under windows xp and activate wifi. After that I can boot
inder linux with wifi active and kill it with rfkill button and the loop
starts again :)
I'm pretty sure that this issue is present since some kernel before the one
I've reported, but I'm not sure about the versions.
I don't know if this is iwlagn or acpi related bug (or my fault), I'm
available for any test.
HW:
Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network
Connection
Subsystem: Intel Corporation Device 1211
Flags: bus master, fast devsel, latency 0, IRQ 33
Memory at d0100000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-21-6b-ff-ff-74-2b-28
Kernel driver in use: iwlagn
Kernel modules: iwlagn
Let me know if more information are needed.
Thanks for any answer (I'm not subscribed to this list, so please CC me on
answers, thanks)
On Wed, Sep 16, 2009 at 11:05 PM, Fabio Coatti <[email protected]> wrote:
> In data mercoled? 16 settembre 2009 18:30:19, reinette chatre ha scritto:
>
>> On Wed, 2009-09-16 at 07:57 -0700, Fabio Coatti wrote:
>> > But the behaviour of wifi sybsystem is still weird, (maybe for some
>> > faults on my side). Basically if the laptop starts with wifi enabled
>> > (rfkill off) wpa_supplicant can establish a connection, that can be
>> > killed by rfkill switch (both wifi and bluetooth seems to be killed). But
>> > when I turn off rfkill switch wpa_supplicant is unable to connect again;
>> > looking at syslog/dmesg I can see activity in bt stack, but no messages
>> > regarding wlan0.
>>
>> I think at this point you need to bring the interface back up. When you
>> enable rfkill the interface is brought down, the opposite (bringing
>> interface up) is not done automatically when you disable rfkill.
>>
>
> Ok, I understand your point. In fact I can bring up the interface using
> "ip link set wlan0 up"
> but this leads me to another question: I fail to see how restart the interface
> automatically when rfkill switch is turned off.
> The expected behaviour in this case should be, imho, that wpa_supplicant wakes
> up and restarts the connection.
> IIRC netplug doesn't work with wireless connections and this leaves me
> wondering how I can have wireless la to wake up after turning off rfkill
> switch :)
Hmm, I recently looked to the interaction between rfkill and hal, and
may be able to answer that. The kernel rfkill module also exports its
state via either /dev/rfkill or sysfs's /sys/class/rfkill (depending
on kernel version; I think /dev/rfkill is new to
2.6.31/wireless-testing/compat-wireless, and not in 2.6.30). hald or
devicekit (again, depend on distro/kernel version) monitors those, and
informs NetworkManager via d-bus messaging when the rkfill state
changes. NetworkManager then if up/down the device and tell
wpa_supplicant accordingly. So the ifconfig-interface-up is supposed
to happen automatically, if hald/devicekit works and talk to
NetworkManager.
i.e. the waking-up should happen automatically if you have the
combination of hald/devicekit and networkmanager.
Does this answer your question?
Is the hp-wmi module loaded?
On Wed, Sep 16, 2009 at 03:21:15PM +0200, Fabio Coatti wrote:
> Hi all,
> I'm experiencing a bad behaviour of rfkill / iwlang driver. Here the
> description:
>
> Kernels: 2.6.30.[5,6] 2.6.31
> Hardware: HP EliteBook 6930p
>
> Behaviour: once a working wireless is killed activating the rfkill button,
> there is no way to turn off the rfkill and riactivate wifi network. Even a
> reboot is not able to reset the situation; to get again the control of rfkill
> button is to reboot under windows xp and activate wifi. After that I can boot
> inder linux with wifi active and kill it with rfkill button and the loop
> starts again :)
> I'm pretty sure that this issue is present since some kernel before the one
> I've reported, but I'm not sure about the versions.
>
> I don't know if this is iwlagn or acpi related bug (or my fault), I'm
> available for any test.
>
> HW:
> Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network
> Connection
> Subsystem: Intel Corporation Device 1211
> Flags: bus master, fast devsel, latency 0, IRQ 33
> Memory at d0100000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: [c8] Power Management version 3
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [e0] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Device Serial Number 00-21-6b-ff-ff-74-2b-28
> Kernel driver in use: iwlagn
> Kernel modules: iwlagn
>
> Let me know if more information are needed.
>
> Thanks for any answer (I'm not subscribed to this list, so please CC me on
> answers, thanks)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
Hi Fabio,
On Wed, 2009-09-16 at 07:57 -0700, Fabio Coatti wrote:
> But the behaviour of wifi sybsystem is still weird, (maybe for some faults on
> my side). Basically if the laptop starts with wifi enabled (rfkill off)
> wpa_supplicant can establish a connection, that can be killed by rfkill switch
> (both wifi and bluetooth seems to be killed). But when I turn off rfkill
> switch wpa_supplicant is unable to connect again; looking at syslog/dmesg I
> can see activity in bt stack, but no messages regarding wlan0.
I think at this point you need to bring the interface back up. When you
enable rfkill the interface is brought down, the opposite (bringing
interface up) is not done automatically when you disable rfkill.
Reinette
In data mercoledì 16 settembre 2009 18:30:19, reinette chatre ha scritto:
> On Wed, 2009-09-16 at 07:57 -0700, Fabio Coatti wrote:
> > But the behaviour of wifi sybsystem is still weird, (maybe for some
> > faults on my side). Basically if the laptop starts with wifi enabled
> > (rfkill off) wpa_supplicant can establish a connection, that can be
> > killed by rfkill switch (both wifi and bluetooth seems to be killed). But
> > when I turn off rfkill switch wpa_supplicant is unable to connect again;
> > looking at syslog/dmesg I can see activity in bt stack, but no messages
> > regarding wlan0.
>
> I think at this point you need to bring the interface back up. When you
> enable rfkill the interface is brought down, the opposite (bringing
> interface up) is not done automatically when you disable rfkill.
>
Ok, I understand your point. In fact I can bring up the interface using
"ip link set wlan0 up"
but this leads me to another question: I fail to see how restart the interface
automatically when rfkill switch is turned off.
The expected behaviour in this case should be, imho, that wpa_supplicant wakes
up and restarts the connection.
IIRC netplug doesn't work with wireless connections and this leaves me
wondering how I can have wireless la to wake up after turning off rfkill
switch :)
I
> Hmm, I recently looked to the interaction between rfkill and hal, and
> may be able to answer that. The kernel rfkill module also exports its
> state via either /dev/rfkill or sysfs's /sys/class/rfkill (depending
> on kernel version; I think /dev/rfkill is new to
> 2.6.31/wireless-testing/compat-wireless, and not in 2.6.30). hald or
> devicekit (again, depend on distro/kernel version) monitors those, and
> informs NetworkManager via d-bus messaging when the rkfill state
> changes. NetworkManager then if up/down the device and tell
> wpa_supplicant accordingly. So the ifconfig-interface-up is supposed
> to happen automatically, if hald/devicekit works and talk to
> NetworkManager.
>
> i.e. the waking-up should happen automatically if you have the
> combination of hald/devicekit and networkmanager.
>
> Does this answer your question?
>
Indeed; it's a good explanation of what's going on. Now I'll follow each step
of your descripiton and I'll try to find out where the chain breaks :)
Many thanks for your help.
Thanks for the answer;
In fact, it wasn't loaded.
I've inserted that module and the behaviour changed: now the rfkill switch
reacts in the correct way and I'm able to turn on and off bluetooth system.
But the behaviour of wifi sybsystem is still weird, (maybe for some faults on
my side). Basically if the laptop starts with wifi enabled (rfkill off)
wpa_supplicant can establish a connection, that can be killed by rfkill switch
(both wifi and bluetooth seems to be killed). But when I turn off rfkill
switch wpa_supplicant is unable to connect again; looking at syslog/dmesg I
can see activity in bt stack, but no messages regarding wlan0.
Any suggestion?
dmeIn data mercoled? 16 settembre 2009 15:25:49, John W. Linville ha scritto:
> Is the hp-wmi module loaded?
>
> On Wed, Sep 16, 2009 at 03:21:15PM +0200, Fabio Coatti wrote:
> > Hi all,
> > I'm experiencing a bad behaviour of rfkill / iwlang driver. Here the
> > description:
> >
> > Kernels: 2.6.30.[5,6] 2.6.31
> > Hardware: HP EliteBook 6930p
> >
> > Behaviour: once a working wireless is killed activating the rfkill
> > button, there is no way to turn off the rfkill and riactivate wifi
> > network. Even a reboot is not able to reset the situation; to get again
> > the control of rfkill button is to reboot under windows xp and activate
> > wifi. After that I can boot inder linux with wifi active and kill it with
> > rfkill button and the loop starts again :)
> > I'm pretty sure that this issue is present since some kernel before the
> > one I've reported, but I'm not sure about the versions.
> >
> > I don't know if this is iwlagn or acpi related bug (or my fault), I'm
> > available for any test.
> >
> > HW:
> > Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh]
> > Network Connection
> > Subsystem: Intel Corporation Device 1211
> > Flags: bus master, fast devsel, latency 0, IRQ 33
> > Memory at d0100000 (64-bit, non-prefetchable) [size=8K]
> > Capabilities: [c8] Power Management version 3
> > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> > Capabilities: [e0] Express Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [140] Device Serial Number 00-21-6b-ff-ff-74-2b-28
> > Kernel driver in use: iwlagn
> > Kernel modules: iwlagn
> >
> > Let me know if more information are needed.
> >
> > Thanks for any answer (I'm not subscribed to this list, so please CC me
> > on answers, thanks)
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> > in the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Thu, Sep 17, 2009 at 10:16 AM, Fabio Coatti <[email protected]> wrote:
> I
>> Hmm, I recently looked to the interaction between rfkill and hal, and
>> may be able to answer that. The kernel rfkill module also exports its
>> state via either /dev/rfkill or sysfs's /sys/class/rfkill (depending
>> on kernel version; I think /dev/rfkill is new to
>> 2.6.31/wireless-testing/compat-wireless, and not in 2.6.30). hald or
>> devicekit (again, depend on distro/kernel version) monitors those, and
>> informs NetworkManager via d-bus messaging when the rkfill state
>> changes. NetworkManager then if up/down the device and tell
>> wpa_supplicant accordingly. So the ifconfig-interface-up is supposed
>> to happen automatically, if hald/devicekit works and talk to
>> NetworkManager.
>>
>> i.e. the waking-up should happen automatically if you have the
>> combination of hald/devicekit and networkmanager.
>>
>> Does this answer your question?
>>
>
> Indeed; it's a good explanation of what's going on. Now I'll follow each step
> of your descripiton and I'll try to find out where the chain breaks :)
>
>
> Many thanks for your help.
>
On my system - hal knows about the killswitch:
$lshal |grep -i killswitch
info.addons.singleton = {'hald-addon-rfkill-killswitch'} (string list)
info.capabilities = {'killswitch'} (string list)
info.category = 'killswitch' (string)
info.interfaces = {'org.freedesktop.Hal.Device.KillSwitch'} (string list)
info.product = 'phy0 wlan Killswitch' (string)
killswitch.access_method = 'rfkill' (string)
killswitch.name = 'phy0' (string)
killswitch.state = 1 (0x1) (int)
killswitch.type = 'wlan' (string)
and NM also wrote to syslog saying it found the switch, and other
stuff when the switch is turned on and off:
#grep kill /var/log/message
...
Sep 16 00:08:48 localhost NetworkManager: <info> Wireless now
disabled by radio killswitch
Sep 16 00:10:09 localhost NetworkManager: <info> Wireless now enabled
by radio killswitch
Sep 16 01:40:18 localhost NetworkManager: <info> Found radio
killswitch /org/freedesktop/Hal/devices/usb_device_XXXXXXX_if0_rfkill_phy0_wlan
...