Bug 152291

Created attachment 69381 [details]
patch for /etc/sysconfig/network/scripts/ifup-wireless

Informations to add to /etc/sysconfig/network/wireless template file :

## Type:        string
## Default:     ""
# AP scanning/selection
# By default, wpa_supplicant requests driver to perform AP scanning and then
# uses the scan results to select a suitable AP. Another alternative is to
# allow the driver to take care of AP scanning and selection and use
# wpa_supplicant just to process EAPOL frames based on IEEE 802.11 association
# information from the driver.
# 1: wpa_supplicant initiates scanning and AP selection
# 0: driver takes care of scanning, AP selection, and IEEE 802.11 association
#    parameters (e.g., WPA IE generation); this mode can also be used with
#    non-WPA drivers when using IEEE 802.1X mode; do not try to associate with
#    APs (i.e., external program needs to control association). This mode must
#    also be used when using wired Ethernet drivers.
# 2: like 0, but associate with APs using security policy and SSID (but not
#    BSSID); this can be used, e.g., with ndiswrapper and NDIS drivers to
#    enable operation with hidden SSIDs and optimized roaming; in this mode,
#    the network blocks in the configuration file are tried one by one until
#    the driver reports successful association; each network block should have
#    explicit security policy (i.e., only one option in the lists) for
#    key_mgmt, pairwise, group, proto variables
WIRELESS_AP_SCANMODE=""

## Type:        string
## Default:     ""
# WPA cipher selection
# CCMP = AES in Counter mode with CBC-MAC [RFC 3610, IEEE 802.11i/D7.0]
# TKIP = Temporal Key Integrity Protocol [IEEE 802.11i/D7.0]
# NONE = Use only Group Keys (deprecated, should not be included if APs support
#       pairwise keys)
# If not set, this defaults to: CCMP TKIP
# Only used if WIRELESS_AP_SCANMODE="2"
WPA_CIPHER_SELECT=""

Christian: If this is nothing to you, assgin it back to us.

Submitted a similar solution to the sysconfig repository.

I am complaining here about 2 points :

1) I have written this bug report for SUSE 10.0 product and one month later, I haven't got any sysconfig update.

2) I have installed opensuse 10.1 beta 9 on my laptop and I can't associate with my acces point. Your solution does not work either with TKIP or AES (CCMP) cyphering because the parameter " group " you have added in wpa_supplicant configuration is awkward.

Although you are right reading the comment above, a bug in wpa-supplicant prevents it to operate correctly.

Please, could you add only WIRELESS_CYPHER_GROUP if this variable is already defined in /etc/sysconfig/network/wireless, instead of using it in a mandatory way ?

Also, don't forget to add a template for wireless parameters file, I mean wireless.template file in /etc/sysconfig/network/ for example.

1) You most probably won't get one. It admittedly fixes a bug in conjunction with ndiswrapper. We do not officially support ndiswrapper, so it's unlikely that project management approves an online update for this.

2) Thanks for your report. Could you explain why this is awkward?

(In reply to comment #6)
> 1) You most probably won't get one. It admittedly fixes a bug in conjunction
> with ndiswrapper. We do not officially support ndiswrapper, so it's unlikely
> that project management approves an online update for this.
You are saying that there is NO solution for suse 10.0. So, why have you changed the state of the bugreport to RESOLVED ??? Do you think that marketing policy solves always magically technical problems ?
Sorry, but I am trying to get the wireless network running out of the box since SUSE 9.1 with my laptop centrino ACER TM800, but it is always a hassle !!!
Personally, I have upgraded kernel module ndiswrapper and ndiwrapper loader with my own rpm software packets : technically speaking, solutions do exist for suse 10.0. But, surely, kernel module ndiswrapper has to be overwritten.
Due to conflicting file, rpm installation has to be forced.

> 
> 2) Thanks for your report. Could you explain why this is awkward?
> 
I should have been more specific. I performed many tests around wpa_supplicant. The parameter " group " is awkward because it prevents wpa_supplicant to work properly, when present. Strangely, even if you are very specific, like : group=TKIP
Moreover, this parameter was not included in my solution, which HAVE BEEN TESTED with both my laptop and my desktop computers AND WORKS (with latest ndiwrapper 1.10 and wpa_supplicant 0.4.8)

Now, it's up to you ...

I'm "only" a beta-tester with some experience how bugs are handled, but please let me say some words ;-)

(In reply to comment #7)
> You are saying that there is NO solution for suse 10.0. So, why have you
> changed the state of the bugreport to RESOLVED ??? Do you think that
> marketing policy solves always magically technical problems ?

It's not marketing, it's reality.

The SUSE team is currently working on 10.1.

I'm afraid they don't have the time to fix every little bug on older distributions (yes, 10.0 is old if you are versionitis-infected ;-) or a developer).

"FIXED" most probably means that it is fixed in 10.1 beta - you may want to install the latest beta to confirm the fix (and if it still doesn't work, you _really_ have a reason to reopen this bug).

This bug handling is not unique to SUSE, but common to many projects/products.
Example: report a bug at bugs.kde.org and you will notice that there will never be a backport for released KDE versions - bugs are fixed in SVN only and the next KDE release includes the bugfix.

If there's a critical bug or a security problem, there will be a YOU update of course - with the fix backported _by SUSE_ (not KDE/$project) in most cases.


> Sorry, but I am trying to get the wireless network running out of the box 
> since SUSE 9.1 with my laptop centrino ACER TM800, but it is always a 
> hassle !!!

Huh? I also have such a laptop (TM 803) - and WLAN works without problems. (WLAN rarely used in 9.x (with WEP) due to lack of WLAN @home, heavily used in 10.0 and 10.1 beta using WPA2 encryption because of new internet connection.)

I just wonder why you use ndiswrapper at all because the ipw2100 driver works pretty good.


BTW: You should have adjusted the tone of your last comment. Upset developers are bad developers in most cases ;-)


(skipping the technical part as I don't know much about ndiswrapper)

Christian,


I am answering to you. I did not intend to upset the developpers. I have been myself a developper and performed complex systems integration for 15 years as an engineer. So, I understand very well they are in a rush with 10.1.
I have more difficulties to understand why bug state has changed so fast to RESOLVED state. Developpers have to reach a weekly resolved bug quota, and they have got a big pressure on them ?


> I'm afraid they don't have the time to fix every little bug on older
> distributions (yes, 10.0 is old if you are versionitis-infected ;-) or a
> developer).

I am keeping SUSE 9.3 and SUSE 10.0 because :
1) I have " production " servers and I need stability
2) I want to keep a stable development environment

Hence, I need also bug fix for older distributions.
Also, connectivity problem on a laptop is NOT a little bug !

>"FIXED" most probably means that it is fixed in 10.1 beta - you may want to
>install the latest beta to confirm the fix (and if it still doesn't work, you
>_really_ have a reason to reopen this bug).

I reopened this bug report for 10.0 since I have no sysconfig update for 10.0;
I have opened bug #163711 because the fix does not work yet for 10.1 beta 9
I consider SUSE 10.0 and SUSE 10.1 as two different products.

>This bug handling is not unique to SUSE, but common to many >projects/products.
>Example: report a bug at bugs.kde.org and you will notice that there will >never be a backport for released KDE versions - bugs are fixed in SVN only
>and the next KDE release includes the bugfix.

From you point of view, there are no update anymore for 9.3, 10.0 ? Even security update ?


>I also have such a laptop (TM 803) - and WLAN works without problems.
>(WLAN rarely used in 9.x (with WEP) due to lack of WLAN @home, heavily used
> in 10.0 and 10.1 beta using WPA2 encryption because of new internet
> connection.)

Does WLAN work yet without problems whenever you disable Wireless SSID broadcast ?

There are perhaps more than 6 (!) other wireless devices in my neighborhood. One day, my wireless connection dropped down. I stopped then all my wireless devices and kept only one up. I opened network stumbler to " sniff the air " and saw clearly that my own SSID wireless name was brodcasted from another device : someone else tried to connect to my network and even if he failed to, he prevented me to work normally. This is why, for security reasons, it is very important to disable wireless SSID broadcast. Otherwise you are a good candidate for hackers.


>I just wonder why you use ndiswrapper at all because the ipw2100 driver works
> pretty good.

1) ipw2100 is limited to 11 Mb/s wireless connections
2) ipw2100 firmware is only added on SUSE ftp servers as " extra " package for Opensuse 10.1 which you can only download when you have no connectivity problem !


By the way, I don't care that SUSE team promotes my solution. I tried to be careful and to limit modifications size. In my opinion, the problem does not rely in ndiswrapper bug, but rather, in wpa_supplicant configuration : I think that the analysis which concluded only to a ndiswrapper problem is false or partial.

My solution brings also a low risk in project management because only 2 files are concerned with the modifications : wireless and ifup-wireless.
wireless brings 2 new parameters which are empty by default, and allows to keep older configuration. ifup_wireless ONLY corrects wpa_supplicant parameters in case of " ap_scan = 2 ". Also, " ap_scan = 2 " parameter is forced when found undefined in wireless configuration file and used in conjunction with ndiswrapper driver in ifup-wireless script.

Last one is the only dared modification.

I am willing to collaborate since I consider that SUSE team performs a great job. I see SUSE distribution as the most reliable distribution among great commercial distributions.

(In reply to comment #9)
> I have more difficulties to understand why bug state has changed so fast to
> RESOLVED state. Developpers have to reach a weekly resolved bug quota, and
> they have got a big pressure on them ?

I don't think so ;-) - but I don't know the SUSE internals.

> > I'm afraid they don't have the time to fix every little bug on older
> > distributions (yes, 10.0 is old if you are versionitis-infected ;-) or a
> > developer).
[...]
> Hence, I need also bug fix for older distributions.
> Also, connectivity problem on a laptop is NOT a little bug !

Accepted - for you.

But it seems that there aren't many people affected (didn't read about this problem in any mailinglist yet) - therefore this doesn't seem to be a problem for the mass of SUSE users.

> I reopened this bug report for 10.0 since I have no sysconfig update for 
> 10.0;

For the reason I mentioned above, I guess there won't be one - but let Joachim and/or AJ decide this ;-)

> I have opened bug #163711 because the fix does not work yet for 10.1 beta 9

OK, then let's see what happens there ;-)

> I consider SUSE 10.0 and SUSE 10.1 as two different products.
> 
> >This bug handling is not unique to SUSE, but common to many >projects/products.
> >Example: report a bug at bugs.kde.org and you will notice that there will >never be a backport for released KDE versions - bugs are fixed in SVN only
> >and the next KDE release includes the bugfix.
> 
> From you point of view, there are no update anymore for 9.3, 10.0 ? Even
> security update ?

Try not to mix up KDE (or any $project) releases and SUSE YOU updates ;-)

KDE/$project usually fixes bugs by releasing a new version.
If a security problem is found in KDE 3.4, the KDE project most probably won't release a 3.4.0.1 - they will say "please upgrade to the latest KDE release - it includes the fix". Unfortunately there are also lots of other non-related changes that might worry customers or even break existing setups (OK, KDE is a bad example for this ;-)

If the bugs are critical enough (like security problems), SUSE backports the fix to the version they shipped with, say, 9.3.
This means there is an additional workload for backporting the fix - it depends how difficult this is, but it isn't as simple as "install/package new version". Also, QA needs to be done etc.

Why backporting at all? Customers usually don't want new versions appearing in their SUSE installation because there could be several changes besides the bug fix. This could cause some "surprises" (think of a new PHP version with register_globals disabled ;-) which is not acceptable if "only" a security problem is fixed.

If you understand german, you may want to read http://suse-linux-faq.koehntopp.de/q/q-install-updatepolitik.html

> Does WLAN work yet without problems whenever you disable Wireless SSID
> broadcast ?

Good question, I didn't test it yet.

> >I just wonder why you use ndiswrapper at all because the ipw2100 driver 
> > works pretty good.
> 
> 1) ipw2100 is limited to 11 Mb/s wireless connections

Hmm, does the hardware support more? (Anyway, I use it for 2 Mbit internet access, so WLAN isn't the bottleneck.)

> 2) ipw2100 firmware is only added on SUSE ftp servers as " extra " package 
> for Opensuse 10.1 which you can only download when you have no connectivity 
> problem !

I know - the old chicken - egg problem ;-)
(The drivers needed in ndiswrapper have the same problem, BTW.)

I could also ask how you downloaded the distribution... *g*



Joachim: IMHO the "political" part is clear now - what about the technical part? ;-)

*** Bug 163711 has been marked as a duplicate of this bug. ***

Increasing version. What is the status of this bug?
Christian: Can you add a comment here?

Comment #7:
> You are saying that there is NO solution for suse 10.0. So, why have you
> changed the state of the bugreport to RESOLVED ??? Do you think that
> marketing policy solves always magically technical problems ?

No, of course not. It is common practice as Christian explained. It may be a bit misleading but was not intended to annoy you.

> I should have been more specific. I performed many tests around 
> wpa_supplicant. The parameter " group " is awkward because it prevents 
> wpa_supplicant to work properly, when present. Strangely, even if you are 
> very specific, like : group=TKIP
> Moreover, this parameter was not included in my solution, which HAVE BEEN
> TESTED with both my laptop and my desktop computers AND WORKS (with latest
> ndiwrapper 1.10 and wpa_supplicant 0.4.8)

It was not included in your solution, right. OTOH, I did test the ap_scan=2 support not with ndiswrapper, but with ipw2200. And with this driver it worked with specified group cipher. Even more, trying the same with an Atheros device requires the group parameter, or else it does not work. So it seems there is no "one size fits all".

Comment #9:
> I have more difficulties to understand why bug state has changed so fast to 
> RESOLVED state. Developpers have to reach a weekly resolved bug quota, and 
> they have got a big pressure on them ?

There is no such quota. I committed a solution that did work (for me), so I did set it to RESOLVED. If it does not fix the bug for you, than you are free to reopen it again. That's the way how it is intended.

> I am keeping SUSE 9.3 and SUSE 10.0 because :
> 1) I have " production " servers and I need stability
> 2) I want to keep a stable development environment
>
> Hence, I need also bug fix for older distributions.

Yes. But we do not guarantee to fix bugs in older distributions. We fix security bugs and other severe problems. If you need more, you have to buy an Enterprise Server and maintance for it.

> Also, connectivity problem on a laptop is NOT a little bug !

Depends. A general connectivity problem is. A not supported driver (ndiswrapper) not working in a special case (hidden SSID) is not.

> There are perhaps more than 6 (!) other wireless devices in my neighborhood.
> One day, my wireless connection dropped down. I stopped then all my wireless
> devices and kept only one up. I opened network stumbler to " sniff the air "
> and saw clearly that my own SSID wireless name was brodcasted from another
> device : someone else tried to connect to my network and even if he failed 
> to, he prevented me to work normally. This is why, for security reasons, it 
> is very important to disable wireless SSID broadcast. Otherwise you are a 
> good candidate for hackers.

Sorry, this is ridiculous. The only thing you can prevent by hiding your SSID is that somebody accidentally associates to your access point (or tries to). Hiding your SSID does not gain you security. It was never intended to. I don't know how somebody trying to associate to your AP prevented you from work normally. A hacker will not care at all about hidden SSIDs.

> 1) ipw2100 is limited to 11 Mb/s wireless connections

Indeed. It's more than most DSL connections provide, though. If I really need network performance, I usually plug in an ethernet cable, but that's my preference only, of course.

> 2) ipw2100 firmware is only added on SUSE ftp servers as " extra " package >
> for Opensuse 10.1 which you can only download when you have no connectivity 
> problem!

Yes. Usually you also download openSUSE itself, so I don't see the problem.

> By the way, I don't care that SUSE team promotes my solution. I tried to be
> careful and to limit modifications size. In my opinion, the problem does not
> rely in ndiswrapper bug, but rather, in wpa_supplicant configuration : I 
> think that the analysis which concluded only to a ndiswrapper problem is 
> false or partial.

Sorry, I don't fully understand this. It is true that the ap_scan=2 was not working, at least not for all devices. But ap_scan=2 is usually needed, so it's not a general problem.

> My solution brings also a low risk in project management because only 2 
> files are concerned with the modifications : wireless and ifup-wireless.
> wireless brings 2 new parameters which are empty by default, and allows to 
> keep older configuration. ifup_wireless ONLY corrects wpa_supplicant 
> parameters in case of " ap_scan = 2 ". Also, " ap_scan = 2 " parameter is 
> forced when found undefined in wireless configuration file and used in 
> conjunction with ndiswrapper driver in ifup-wireless script.

Besides forcing ap_scan=2 when not defined (we use ap_scan=1 as default), the current solution does not differ much. The defaults for WPA protocol and ciphers also are only enforced when ap_scan=2 is used. We set also a default group cipher, yes, but above I did explain why.

(In reply to comment #14)
> > There are perhaps more than 6 (!) other wireless devices in my neighborhood.
> > One day, my wireless connection dropped down. I stopped then all my wireless
> > devices and kept only one up. I opened network stumbler to " sniff the air "
> > and saw clearly that my own SSID wireless name was brodcasted from another
> > device : someone else tried to connect to my network and even if he failed 
> > to, he prevented me to work normally. This is why, for security reasons, it 
> > is very important to disable wireless SSID broadcast. Otherwise you are a 
> > good candidate for hackers.
> 
> Sorry, this is ridiculous. The only thing you can prevent by hiding your SSID
> is that somebody accidentally associates to your access point (or tries to).
> Hiding your SSID does not gain you security. It was never intended to. I don't
> know how somebody trying to associate to your AP prevented you from work
> normally. A hacker will not care at all about hidden SSIDs.
> 
This is not ridiculous. This practice avoids " wireless network kiddies " whose ones want to play with other wireless networks. Most security wireless reviews disadvice you to such highligh your wireless network.
Of course, disabling your wireless network is only one security measure you have to take. I use also WPA ciphering, MAC access filtering and also reduced group key renewal time (15 mn max).

> > 1) ipw2100 is limited to 11 Mb/s wireless connections
> 
> Indeed. It's more than most DSL connections provide, though. If I really need
> network performance, I usually plug in an ethernet cable, but that's my
> preference only, of course.
> 
I have a 19 Mb/s ADSL internet connection, and for example, I am able to download a CD within 7/8 minutes! Hence, I need a fast wireless LAN towards my laptop, also for local exchanges.

> > 2) ipw2100 firmware is only added on SUSE ftp servers as " extra " package >
> > for Opensuse 10.1 which you can only download when you have no connectivity 
> > problem!
> 
> Yes. Usually you also download openSUSE itself, so I don't see the problem.
>
You dont see the problem ? Try to imagine then ! Going to the cybercofee to get back centrino firmware and have support ? Nice solution ...

> This is not ridiculous. This practice avoids " wireless network kiddies " 
> whose ones want to play with other wireless networks. Most security wireless 
> reviews disadvice you to such highligh your wireless network.
Ok, a really unexperienced kiddie may be not able to find your network. Virtually all potential attackers will use a wireless sniffer to detect networks in range. And it reveals your network, whether hidden or not.

> Of course, disabling your wireless network is only one security measure you
> have to take.
No, it is no security measure at all.

> I use also WPA ciphering, MAC access filtering and also reduced group key 
> renewal time (15 mn max).
Good. :-) This will keep attackers away, not the hidden ssid.

> You dont see the problem ? Try to imagine then ! Going to the cybercofee to 
> get back centrino firmware and have support ? Nice solution ...
What I wanted to say is, when you have the possibility to download openSUSE, you should have the possibility to the firmware package as well. In case you are updating a SL 10.0 to openSUSE, you may lose your connectivity through Intel wireless LAN cards, that's true. But you'll lose other things too, as openSUSE is only a subset of SUSE Linux.

However, bugzilla is not the right place for such a discussion. In case there is a technical problem left in your opinion, please open a new bugreport for it. The core issue of the bugreport (means, better support for ap_scan=2) has status FIXED for 10.1 and WONTFIX for 10.0.

I have packaged wpa_supplicant 0.5.2 and installed it on suse 10.1 :
it solves the problem for ifup network activation with original sysconfig, but not for network manager.

I can conclude that this bug is a wpa_supplicant bug, not a ndiswrapper bug.
Will we get a wpa_supplicant upgrade before 10.1 official release ?

I found a notebook with a Broadcom BCM4309 802.11abg adapter to reproduce the problem you're reporting, but association with group cipher set works fine as well. NetworkManager uses ap_scan=1 as default and ndiswrapper does not support per-ssid-scanning, this is probably the cause of the failure. I'll open a bug report for this.

> I can conclude that this bug is a wpa_supplicant bug, not a ndiswrapper bug.
> Will we get a wpa_supplicant upgrade before 10.1 official release ?

As said, I can not confirm this. And no, we won't update wpa_supplicant from the latest stable release to a development version in that phase.