You can select static addresses - it's just not the scenario for which it's intented.  WEP is supported.  Please give some details on what fails.

Timo, where are static address documented?

Frank-Michael, please provide details on how WEP fails.

Andreas, for static configurations we have the same procedure as always:  Use YaST to setup the interface.  NM will honor those settings.  However, I do not know if we have any documenation bits which make this clear.

Frank-Michael, can you please attach the output from /var/log/messages to this report for the failing connection attempt?

Changing summary.

Created attachment 66468 [details]
iwconfig output plus /var/log/messages

As one can see iwconfig shows an empty WEP key. Despite it has been specified. After using YaST2 for configuration the connection works without problems.

BTW when using YaST2 for configuration it will complain every time, that resolv.conf has been modified so one has no idea how and when to specify static name servers. And, please, "You can select static addresses" is a true statement. Even true without YaST2 and/or NetworkManager. The thing is: NetworkManager does NOT provide the functionality of configuring static ip addresses.

Thanks for the logs, Frank-Michael.

(In reply to comment #6)
> And, please, "You can select static addresses" is a true
> statement. Even true without YaST2 and/or NetworkManager. The thing is:
> NetworkManager does NOT provide the functionality of configuring static ip
> addresses.

We never had the intention for NM offering the functionality to set up static configurations.  It is the distribution's job to do this. YaST in our case.

Robert, can you see something suspecious in the log or is it just the DHCP timeout?

cc'ing Robert.

The logs look fine.  The AP is associated with, which is the usual problem.  It just looks like there is no DHCP server on the network.

But, with WEP, there is no way to know whether the security authentication was done correctly.  The only sign is that DHCP fails.

So, we need to make sure that the correct WEP type is selected.  Right keysize, passphrase versus hex, etc.  And, obviously, double check the key.

Frank-Michael, are you trying to use a static configuration on the wireless interface?

1. DHCP is running and working.
2. Yes I am running a static configuration
3. And there is no place in NetworkManager to specify WEP key type or length. The only "option" you have is enter a key passphrase or not.
4. Any SUSE 10.0 or 9.3 clients works just fine with this AP.
5. Easy logic: clients without NetworkManager do function, clients with it do not, therefore NetworkManager does not function (or some component it's using).

To me this flaw seems to be the result of a basic misunterstanding coming up with 10.1; Ofocourse networking is by design part of the O/S (one of the strong sides  of Linux/Unix) In 10.1 some engineers in charge now claim "KDE is part of the O/S" or "Gnome" you name it. But if so KDE has to play with all the parts of the O/S. If it does not, you have got another proof that KDE is NOT part of the O/S.

Slowly killing YaST2 is one matter and can be done without big emotions. But giving a user the default! option of using a toy like NetworkManager instead lacks seriosity and turns 10.1 into a toy itself. If this is intended then fine just let us know in advance.

Frank-Michael: I am sorry that you do not like NetworkManager.  It is nice to see that our users are so emotionally invested in our product, however.  Rest assured that NM use is not mandatory.  You can revert to the previous collection of scripts by setting NETWORKMANAGER to no in /etc/sysconfig/network/config.

A few thoughts.  If a static configuration were in place, DHCP would not be used.  So a static configuration has not been specified.

Timo: Does KNM allow the user to specify the size and type (hex, ASCII, or passphrase) of the key?  The encoding options are all different.

Frank-Michael, I'm happy to assist getting things working for you using NM, but please respect that this is not the correct place for fights.  Feel free to use one of our mailing lists to discuss your concerns.

1. & 2.: Are you running DHCP on the wireless interface or not?  This is unclear.

3.: There is no need to specify the length of the key as we check whether the user input is reasonable or not (and hence enable or disable the OK button)

4. & 5.: Off-topic.

Needinfo for 1. & 2.

(In reply to comment #11)

> Timo: Does KNM allow the user to specify the size and type (hex, ASCII, or
> passphrase) of the key?  The encoding options are all different.

KNM provides WEP Passphrase, WEP 40/128-bit hex and WEP 40/128-bit ASCII. KNM uses libnm to validate the user input.  This should be the same as with nm-applet, I guess.

Timo: Ah, good.  Should be okay, then.

Frank-Michael: You must be sure to pick the right type.

I would guess that DHCP is failing because the encryption is wrong or because there simply is no DHCP server on the network.

As with Timo, I am confused as well by points 1 & 2.

    1 & 2. How can I know if I am running DHCP on this interface, when using NetworkManager? Is there a place in NetworkManager where it either displays it or lets me specify it? When resorting to YaST2 I am setting static IPs (turned DHCP off).

    I just did a little experiment for you: first I deleted all interfaces (also the wireless) with YaST2. Then I used YaST2 to set the network interfaces under NetworkManager control. After that: reboot. I am asked for the root password when knetworkmanager starts. Click on its icon: "Connection in progress", clicking on "Options" I get two choices: "Disable wireless" and "Switch to Offline Mode". That's all.
    After a few minutes while: knetworkmanager shows me my WLAN "CP" (how is that possible, my AP does NOT broadcast the ESSID?) I click on it, it tries connecting, fails and up comes the window where I pick "WEP Passphrase" and enter my passphrase. Then I hit "Connect". After a while it fails again, windows pops up asking me to pick the WPA protocol. That's the end of the journey, because I did not enable WPA on my AP.
    The brute force to deinstall WPA supplicant to get rid of this vicious connecting cycle is impossible, because NetworkManager depends on it. So if I want to connect to my WLAN without WPA enabled I have to deinstall NetworkManager.

You have the following choices: 

Yes, I do specify the right key type. And iwconfig shows me still: "Encryption key:off"

(In reply to comment #15)

>     After a few minutes while: knetworkmanager shows me my WLAN "CP" (how is
> that possible, my AP does NOT broadcast the ESSID?)

I guess KNM knows the ESSID because of a previous connection attempt.  I bet you've entered the ESSID once.

> I click on it, it tries
> connecting, fails and up comes the window where I pick "WEP Passphrase" and
> enter my passphrase. Then I hit "Connect". After a while it fails again,
> windows pops up asking me to pick the WPA protocol. That's the end of the
> journey, because I did not enable WPA on my AP.

This sounds like a KNM bug.

Please give it a try using nm-applet.  If this works we can investigate, why KNM fails.

Sorry, what do you mean by "nm-applet"?

My fault, the binary of the GNOME applet for NetworkManager is called nm-applet.  If not installed, you find it by installing the package NetworkManager-gnome.

Ok, will do (but need the WLAN interface for that :-) Give me minute or two.

Meanwhile: The ESSID is a security sensitive item. So when I delete an interface (using YaST2) I would not want to leave this info as a residue on my notebook.

Speaking for KNM:  We're currently implementing an interface which gives users the possibility to modify and delete stored networks.  For now you'd have to delete knetworkmanagerrc from ~/.kde/share/config.

For nm-applet you'd have to delete the corresponding gconf entries.

As YaST has no influence on the wireless networks when using NM it can not (and should not) delete those settings.

with nm-applet the WEP key is also not accepted. The only improvement: I am not asked for any WPA info. I just do not get connected.

Questions: may I turn NetworkManager off now in sysconfig so I can start testing other things using my network? Or is there any other information you need?

(In reply to comment #15)
>     1 & 2. How can I know if I am running DHCP on this interface, when using
> NetworkManager? Is there a place in NetworkManager where it either displays it
> or lets me specify it? When resorting to YaST2 I am setting static IPs (turned
> DHCP off).

This is still unclear.

Please state whether you're running a DHCP server (e.g. on your AP).

There is a DHCP server running, but not on the AP. And when setting the interface card as DHCP client it is getting a usable IP address from that DHCP server. And the other six computers in the LAN are getting IP addresses, too, if not set to static addresses.

(In reply to comment #26)
> And when setting the interface card as DHCP client it is getting a usable IP 
> address from that DHCP server.

This is when using ifup instead of NM, correct?

yes, exactly. And I am pretty sure that with the wrong (empty) encryption key one will never get an IP address from any DHCP server.

bug 148285 seems to be somehow related to this one.

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

Does it work with Beta6?

If not: Does it work with the latest packages available at http://primates.ximian.com/~rml/misc/NetworkManager/ ?

sorry to tell you: problem is still there, also with the 20060303 package. iwconfig tells me that my wireless interface does not just miss the WEP key but also the ESSID specified.

Setting it up with static ip with YaST2 works just fine.

It seems somehow "complements" bug #140124. Because in Beta 6 not even a wired interface comes up when using DHCP.

Please provide the output of /var/log/NetworkManager while connecting.  Would be nice to have to separate logs:  One for the connection attempt using the wired and one for connecting using the wireless interface.

Created attachment 71267 [details]
NetworkManager log

after deleting all "traditional" interfaces in YaST2 and rebooting, Networkmanager established successfully a DHCP wired connection. Unfortunately now KNetworkManager says: "No network device found". So I cannot even try the wireless connection.

Known problem.  Please use KNetworkManager packages available at:

  http://www.fh-augsburg.de/~thoenig/KNetworkManager/

Thanks!

Created attachment 71268 [details]
NetworkManager log after fixing the knetworkmanager bug

Known problem fixed. However no wireless connection possible. NetworkManager tries WEP, one more time WEP then WPA and fails. After each attempt iwconfig shows Encryption: off.

Thanks for testing.

Robert, anything in the log which rings a bell for you?  Are there any reports about the current status of cards unsing the prism54 driver?

I have added some prism54 workarounds to NetworkManager.

Frank-Michael, can you please test these packages:

http://primates.ximian.com/~rml/misc/NetworkManager/

You can use them with the KNM that Timo put up at:

http://www.fh-augsburg.de/~thoenig/KNetworkManager/

If you want to use the KDE applet (the changes are all in the daemon).

Please make sure you successfully restart the daemon after upgrading the packages, or, even better, reboot.

Let us know.  Thank you!

Ok, installed as ordered, no change, means no connection. iwconfig says: empty ESSSID and encryption off. The KNetworkManager "pretends" to see my network, however with 0 signal, which is impossible. KNetworkManager also shows (with right click) the correct ESSID and Encryption protocol: "WEP".
My gut feeling tells me this is most likely not a prism54 problem. Just my wild guess as an old software guy.

It is a prism54 problem.

Not really: Knoppix 4.02 works from the box on the same hardware, Mandriva 2006, Ubuntu 10.1 too, all SUSEs from 9.1 on. Including 10.1 beta 6 unless I do not use the NetworkManager. So it should be NetworkManager, shouldn't it?

Nope.

NetworkManager and wpa_supplicant make for a much more taxing networking system than traditional ifconfig(8) and iwconfig(8) setups.  NetworkManager reveals bugs and issues in networking drivers that more simplistic setups do not illuminate.

By your same logic, however: NetworkManager works fine on most systems and with most cards, but it does not work with any prism54 cards, so it must be prism54.  But I don't make that argument, I make the argument that I specifically know prism54 and wpa_supplicant do not get along.

What about making NetWorkManager not dependent on the wpa_supplicant module? Would that be a way? So one just deinstalles wpa_supplicant and things should work.

No, NM uses wpa_supplicant for all wireless association.

The fix is to get wpa_supplicant and prism54 working nicely together.

ok, now, workaround: after hand-installing ndiswrapper-1.10-5.i586.rpm and
ndiswrapper-kmp-default-1.10_2.6.16_rc5_git2_3-5.i586.rpm from factory,
ndiswrapper works with YaST2 setup. Finally, also NetworkManager is able to
handle my wlan card device. Which YaST2 handles directly, not
using ndiswrapper, through the prism54 module

I'd reconsider including NetworkManager in the distribution considering its
present stage if the ndiswrapper module is not part of the distribution
anymore (bug 155723). One needs ndiswrapper for most configurations not involving Centrino CPUs, independent whether traditional if-up or NetworkManager is used.

Meanwhile bug 155723 got fixed, so no problem having NetworkManager included. Good!

Marking as fixed.

Where are comments 46,48,49? Where is the fix for download to I can test it, please? How did it get fixed?

Comments #45 and #47 clearly state that things are working for you.  If this is not true with Beta 8 feel free to reopen.

1. a workaround is no fix.
2. in beta 8 there is not even a  workaround, since there are no ndiswrapper rpms in the distro anymore.

ndiswrapper is part of the factory tree, get it from the ftp server!

yes, I can install it from factory but then I get a new kernel as well, because of dependency. Is that what I should want? Should I report bugs and bug updates as beta 8 bugs after updating the kernel because of ndiswrapper?

Plus: the only reason for installing ndiswrapper is to work around a bug in NetworkManager which (unlike traditional setup) does not support the prism54 wlan chipset properly (or not at all)?

How will a user get later on the information that when enabling NetworkManager and having a prism54 wlan card one needs to install and enable ndiswrapper first? Since the NetworkManager maintainers maintain the notion that ndiswrapper is a fix for this bug? Can't we be less messy?

Please consider reading comment #12 for a second time, thanks.

Currently wpa_supplicant seems to have issues wrt Prism chips.  We're working on a solution.  NM depends on wpa_supplicant to make things work.

As we're aware of the problem, please relax watch us doing the work and enjoy the results.  If we can not make wpa_supplicant play fine with Prism you still have the freedom of choice:  Use ifup and things work out of the box or use ndiswrapper with some work of post-install configuration.

I have no problem with my patience at all. I just do not like to have bugs marked FIXED when they are not fixed. Keep it open and I will test the goldmaster for the fix, or earlier if you provide me with one.

No. It does not work this way. Bugs are marked FIXED once the fix is submitted. You can later mark the bug as VERIFIED or reopen it.
This is the only way to keep track of the work to do.

What does "fix is submitted" mean in reality (outside Bugzilla)? When can we expect the fix to show up in the factory tree?