network-manager does not really deactivate ipw2200

On Mon, Jul 23, 2007 at 11:48:28AM -0000, Kliment Yanev wrote:
> Public bug reported:
>
> Binary package hint: network-manager
>
> Use case:
> I tell network-manager to disable my wireless, expecting this to gain me some battery life or because I am entering a no-radio zone (airplane, hospital etc). My laptop has no hardware switch or led to indicate wireless status, so I assume network-manager has switched it off
>
> Current behavior:
> The radio interface is still active and the number of interrupts reported by powertop for the ipw2200 driver goes up drastically. The "disabled" interface thus uses more power and misleads the users. Using rf_kill manually disables the radio and stops the interrupts, as expected.
>
> I am using 2.6.22 on gutsy with all updates.
>
> Proposed solution:
> Make network-manager aware of rf_kill state and disable radio when wireless is disabled.

OK, thanks for the report. maybe one of the next updates will help
... anyway, does your wireless setup in gutsy work with ipw2200 driver
in general? What setup are you running?

 - Alexander

Other than this issue, I sometimes have a disconnect where I have to
unload and reload the driver, but that is rare (happened 5 or 6 times in
the past year, I can't reproduce it). Beyond this, I am running a fresh
feisty install later upgraded to gutsy and the ipw2200 works perfectly
in every situation I've managed to throw at it. I have never tried ad
hoc networking with it but I've never had a problem connecting to a network.

Kliment

Alexander Sack wrote:
> On Mon, Jul 23, 2007 at 11:48:28AM -0000, Kliment Yanev wrote:
>> Public bug reported:
>>
>> Binary package hint: network-manager
>>
>> Use case:
>> I tell network-manager to disable my wireless, expecting this to gain me some battery life or because I am entering a no-radio zone (airplane, hospital etc). My laptop has no hardware switch or led to indicate wireless status, so I assume network-manager has switched it off
>>
>> Current behavior:
>> The radio interface is still active and the number of interrupts reported by powertop for the ipw2200 driver goes up drastically. The "disabled" interface thus uses more power and misleads the users. Using rf_kill manually disables the radio and stops the interrupts, as expected.
>>
>> I am using 2.6.22 on gutsy with all updates.
>>
>> Proposed solution:
>> Make network-manager aware of rf_kill state and disable radio when wireless is disabled.
>
> OK, thanks for the report. maybe one of the next updates will help
> ... anyway, does your wireless setup in gutsy work with ipw2200 driver
> in general? What setup are you running?
>
> - Alexander
>

the ipw2200 driver is loaded as "auto-associating" by default. Reassigning to appropriate package.

I tryed to load ipw2200 with associating=0, but this dusn't solved this problem. But after i set "iwconfig eesid off channel 0" it decreased count of wakeups to NULL. So i think network-manager should do it.

I am assigning this bug to the 'ubuntu-kernel-team' per their bug policy. For future reference you can learn more about their bug policy at https://wiki.ubuntu.com/KernelTeamBugPolicies .

In regards to your wireless connection disconnecting this is bug 24776 regarding the ipw2100 driver. This is a known issue with the ipw2100 driver and you can learn more about it in that bug and the corresponding upstream bug report. Thanks!

In regards to my ipw2100 comment - I've commented on the wrong bug report. Sorry about that.

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

I have this bug on intrepid. Seems like nobody care about it. As far i know ipw2200 team mean this is not driver bug. So why networkmanager just not set "iwconfig eesid off channel 0" ....it das not look for me like a hack.

i digged a bit in to source of ipw2200:

.... line 91
/* here we have default module parametr set to seec all the time for new APs.
ewen we disable wlan on networkmanager */
static int associate = 1;

.... line 8530
/* here we geve new name practicly rename associate -> CFG_ASSOCIATE */
        if (associate)
                priv->config |= CFG_ASSOCIATE;
        else
                IPW_DEBUG_INFO("Auto associate disabled.\n");

..... line 7590
/* and here we chack: if associate=0 and no static ESSID choisen (essid = any/off)
and no static channel choisen (chan = 0) and no static bssid (???), we will do anything */
        if (!(priv->config & CFG_ASSOCIATE) &&
            !(priv->config & (CFG_STATIC_ESSID |
                              CFG_STATIC_CHANNEL | CFG_STATIC_BSSID))) {
                IPW_DEBUG_ASSOC("Not attempting association (associate=0)\n");
                return 0;
        }

So this is not a bug in driver or kernel. Every thin was geven but not realy good documented. So, if you say: try associate=0 you should say and set "iwconfig eth1 essid off chan 0" . This is networkmanager issue.

why isnt it a bug in the kernel module to not deactive just because we have associate=0? if the second check above really prevents that from happening then it could probably be fixed there too?

i subscribed, so will get the messages. for now i keep nm invalid.

incorect! associate=0 do not working if frequency set to some channel. NM do not do it at all, but should do it.

here is iwconfig after disabling wlan with nm:

eth1 unassociated ESSID:off/any
          Mode:Managed Frequency=2.452 GHz Access Point: Not-Associated
          Bit Rate:0 kb/s Tx-Power=20 dBm Sensitivity=8/0
          Retry limit:7 RTS thr:off Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

if you see "Frequency=2.452 GHz" is there and it keep ipw2200 beasy. nm should it set to 0 or chan=0.

 vi Documentation/networking/README.ipw2200:

  associate
        Set to 0 to disable the auto scan-and-associate functionality of the
        driver. If disabled, the driver will not attempt to scan
        for and associate to a network until it has been configured with
        one or more properties for the target network, for example configuring
        the network SSID. Default is 1 (auto-associate)

please ping pong bug states i changed to invalid. I am subscribed to this bug and will reopen when i see evidence that this is NMs fault. Thanks!

Am Sonntag, den 19.10.2008, 23:12 +0000 schrieb Alexander Sack:
> please ping pong bug states i changed to invalid. I am subscribed to
> this bug and will reopen when i see evidence that this is NMs fault.
> Thanks!

What kind of evidenc do you steal need?

Other argument: ipw2200 hase this issue becouse it do not support
hardwarescan. so it should be done by CPU. ipw3945 use hardware scan by
default, and wie should probably do not bother about CPU any more. See:

linux-2.6/drivers/net/wireless/iwlwifi/iwl3945-base.c:

7875
        /* Disabling hardware scan means that mac80211 will perform scans
7876 * "the hard way", rather than using device's scan. */
7877 if (iwl3945_param_disable_hw_scan) {
7878 IWL_DEBUG_INFO("Disabling hw_scan\n");
7879 iwl3945_hw_ops.hw_scan = NULL;
7880 }

the question is: haw are this things done by software mac80211 scan?

On Thu, Oct 16, 2008 at 06:47:14AM -0000, fishor wrote:
> incorect! associate=0 do not working if frequency set to some channel.
> NM do not do it at all, but should do it.
>

NM shouldnt do tweaks for individual drivers (not that i see what NM
should tweak here). if associate=0 breaks this, it seems like the
driver should be fixed.

Have you looked what code portion causes associate=1/0 to make this
succeed/fail?

 - Alexander

I do not know if i brake some thing alse, but this puth working perfektly to me.

Hmm... but this putch is not real fix of the problem. Yes powertop will
not complain any more about ipw2200 and awerything is still working but
actually the card stay working and consume power. only possible is
rfkill or unload the module.

Alexey

On Tue, Oct 21, 2008 at 06:49:01AM -0000, fishor wrote:
> Hmm... but this putch is not real fix of the problem. Yes powertop will
> not complain any more about ipw2200 and awerything is still working but
> actually the card stay working and consume power. only possible is
> rfkill or unload the module.
>

are you sure that this isnt the case when associate=1 ? what other
corner case could there be in code besides from the patch you had?

maybe essid is OFF, but bssid is still set?

 - Alexander

On Tue, Oct 21, 2008 at 06:31:40AM -0000, fishor wrote:
> I do not know if i brake some thing alse, but this puth working
> perfektly to me.
>
> ** Attachment added: "ipw2200_associate.diff"
> http://launchpadlibrarian.net/18761870/patch_net.diff
>

this looks like a good first attempt. I wonder if we could try to
implicitly unset the other config values (bssid, channel) config when
the essid config goes from a real value to OFF.

 - Alexander

On Tuesday 21 October 2008 18:03:45 Alexander Sack wrote:
> I wonder if we could try to
> implicitly unset the other config values (bssid, channel) config when
> the essid config goes from a real value to OFF.

I do not know a lot about wifi implementation, are the any needs to have a
association scan with essid=off and bssid=some:ap:mac:adress ?

On Tuesday 21 October 2008 18:01:05 Alexander Sack wrote:
> are you sure that this isnt the case when associate=1 ? what other
> corner case could there be in code besides from the patch you had?
>
> maybe essid is OFF, but bssid is still set?

I sure. I mean with this patch ipw2200 do not wake up CPU any more, so it use
less power but steel use it. There is nothing we can do about in driver. I
think, only correct way is to use rfkill to poweroff it. The question is haw?
With NM? My laptop do not have hardware rfkill switch.

On Wed, Oct 22, 2008 at 10:39:33AM -0000, fishor wrote:
> On Tuesday 21 October 2008 18:03:45 Alexander Sack wrote:
> > I wonder if we could try to
> > implicitly unset the other config values (bssid, channel) config when
> > the essid config goes from a real value to OFF.
>
> I do not know a lot about wifi implementation, are the any needs to have a
> association scan with essid=off and bssid=some:ap:mac:adress ?
>

not sure either. i think even for hidden essid the essid set here
would be the name of the hidden essid and not empty. Most likely essid
being set to "off" means that no association should be tried. Normal
network scans might be required though.

 - Alexander

On Wednesday 22 October 2008 16:09:27 Alexander Sack wrote:
> not sure either. i think even for hidden essid the essid set here
> would be the name of the hidden essid and not empty. Most likely essid
> being set to "off"  means that no association should be tried. Normal
> network scans might be required though.

IMHO, completly automaited association is security issue. at leas essid or
bssid should be set. NM renew the AP list, so it should not be done by driver
in background. Association do not needet in monitor mode see driver:

        if (priv->ieee->iw_mode == IW_MODE_MONITOR) {
                IPW_DEBUG_ASSOC("Not attempting association (monitor
mode)\n");
                return 0;
        }

May be for adhoc mode... but essid is needed. And we use by defaul managed
mode. So may bi it is ok jus to do:
   if (priv->ieee->iw_mode == IW_MODE_MANAGED){
                IPW_DEBUG_ASSOC("Not attempting association (managed
mode)\n");
                return 0;
        }

On Thu, Oct 23, 2008 at 09:53:23AM -0000, fishor wrote:
> On Wednesday 22 October 2008 16:09:27 Alexander Sack wrote:
> > not sure either. i think even for hidden essid the essid set here
> > would be the name of the hidden essid and not empty. Most likely essid
> > being set to "off"  means that no association should be tried. Normal
> > network scans might be required though.
>
> IMHO, completly automaited association is security issue. at leas essid or
> bssid should be set. NM renew the AP list, so it should not be done by driver
> in background. Association do not needet in monitor mode see driver:
>
> if (priv->ieee->iw_mode == IW_MODE_MONITOR) {
> IPW_DEBUG_ASSOC("Not attempting association (monitor
> mode)\n");
> return 0;
> }
>
> May be for adhoc mode... but essid is needed. And we use by defaul managed
> mode. So may bi it is ok jus to do:
> if (priv->ieee->iw_mode == IW_MODE_MANAGED){
> IPW_DEBUG_ASSOC("Not attempting association (managed
> mode)\n");
> return 0;
> }
>

Could you come up with a patch so we can get a test package in some
PPA?

Thanks!

 - Alexander

On Thursday 23 October 2008 12:33:12 Alexander Sack wrote:
> Could you come up with a patch so we can get a test package in some
> PPA?

I played around with this driver and my card... so now i see how it's working.
The part with association is realy importen, wuithout it nothing will work.
But i think the driver in some part just too smart. If you give one variable
to config it will take the best AP to variable. Look at this log:
------------------------------------log--------------------------------------
ipw2200: I ipw_rx_notification type = 13 (4 bytes)
ipw2200: I ipw_rx_notification Scan completed: type 13, 32 channels, 1 status
ipw2200: U ipw_best_network Network 'ap1 (mac:adress)' excluded because of
privacy mismatch: off != on.
ipw2200: U ipw_best_network Network 'ap2 (mac:adress)' excluded because of
age: 15558728ms.
ipw2200: U ipw_best_network Network 'Speedport W 501V (00:15:0c:70:d9:14)'
excluded because of age: 15521544ms.
ipw2200: U ipw_best_network Network 'FRITZ!Box Fon WLAN 7170 Tatonka
(mac:adress)' excluded because of age: 16393684ms.
ipw2200: U ipw_best_network Network 'FRITZ!Box Fon WLAN 7113 (mac:adress)'
excluded because of age: 16427056ms.
ipw2200: U ipw_best_network Network 'dd-wrt_vap (mac:adress)' is a viable
match.
ipw2200: U ipw_associate_network Assocation attempt: 'dd-wrt_vap', channel 6,
802.11b [4], long[:long], enc=off.
----------------------------------end-----------------------------------------
this is unpatched driver with associate=0

i _disabled_ Wlan by NM, as result the card was configured like channel=6,
essid=off/any, ap=any. For this driver it's mean: find any available connection
with this variable and connect to it. In log you can see: it found one
connection and connected to one AP on channel=6 without encryption. In some
cantryes it is eligal to connect to somebodys AP, ist it? You can make this
test at home. 1.configure your AP without encryption and disable Wlan in NM.
2.check iwconfig or your AP. My ddwrt show connected laptop, even i do not wont
to use wlan. I think this is more security issue.

Thouths about second patch was wrong, it will not working. The first one is
correct. It sound like: if you not configured essid and bssid probably you do
not know what you doing. If you realy wont it load module with assocaite=1 .

Plese use my first patch. it is correct for most ubuntu users. The peaple who
need this will know haw to load this module with associate=1 and it should be
properly documented.

Alexey

thanks for that info. Tim, you think this would be worthwhile for a eventual SRU too? otherwise, please get this added to jaunty - unless you think the patch is unappropriate.

The patch is here: https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/127711/comments/19

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu development release http://cdimage.ubuntu.com/daily-live/current/ . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]