Wireless connection to router works with WPA but not without encryption

English Network/Internet
1

Hi there!

I am using SuSE 11.3 and have the following problem. I’m trying to connect to a router via the wireless port on my Toshiba laptop. (I’m not using NetworkManager, I’ve set it up with the ifup/ifdown method.)

If I’m setting up the router such that it requires WPA2/AES authentication (called WPA/PSK in the Linux settings), everything works fine. But if I set the security mode to “disabled” on the router and the authentication method to “No Encryption” in yast, it cannot connect.

I’ve tried this with 3 routers actually (2 different Linksys routers and a TPLink) and the same thing happened. Thus it seems that I will probably have to set up something in a different way.

Does anyone have any idea what/how?

Thanks,
Agoston

P.S.: Please don’t advise me to use NetworkManager. First I started with that back when I was connecting through regular cable (i.e., using eth0) and for a few days it worked, then never again. I’ve read afterwards that it is considered highly unreliable and I wouldn’t like to start fighting with all its strange problems now.

P.S.2: Neither should you tell me to “use WPA then”, because right now I’m at a place where I cannot change the router settings but have to adjust them on my own SuSE instead.

2

On 02/08/2012 09:26 AM, agostonbejo wrote:
>
> Hi there!
>
> I am using SuSE 11.3 and have the following problem. I’m trying to
> connect to a router via the wireless port on my Toshiba laptop. (I’m not
> using NetworkManager, I’ve set it up with the ifup/ifdown method.)
>
> If I’m setting up the router such that it requires WPA2/AES
> authentication (called WPA/PSK in the Linux settings), everything works
> fine. But if I set the security mode to “disabled” on the router and the
> authentication method to “No Encryption” in yast, it cannot connect.
>
> I’ve tried this with 3 routers actually (2 different Linksys routers
> and a TPLink) and the same thing happened. Thus it seems that I will
> probably have to set up something in a different way.
>
> Does anyone have any idea what/how?
>
>
> Thanks,
> Agoston
>
> P.S.: Please don’t advise me to use NetworkManager. First I started
> with that back when I was connecting through regular cable (i.e., using
> eth0) and for a few days it worked, then never again. I’ve read
> afterwards that it is considered highly unreliable and I wouldn’t like
> to start fighting with all its strange problems now.
>
> P.S.2: Neither should you tell me to “use WPA then”, because right now
> I’m at a place where I cannot change the router settings but have to
> adjust them on my own SuSE instead.

You have so many caveats, that it may be hard to get you going. In addition,
11.3 is pretty old, and not many of us are still running such a system.

Using ifup with wireless is a PITA and you must know what you are doing. The
configuration file that controls everything is
/etc/sysconfig/network/ifcfg-wlan0. Please set up everything the way you think
it should be for an unencrypted connection, and then compare what you have with
the description in /etc/sysconfig/network/ifcfg.template. If nothing is obvious,
then post the contents of that file. As encrypted connections are “harder” than
unencrypted, your hardware is fine.

3

Thanks for the answer.

In advance: sorry for the long post below, I’ve tried to split it up into separate points to make it easier to read…

I checked the config file but found nothing particularly suspicious. (I’ve copied it in at the bottom, however.) The only parameters that are different when I do use

WPA-PSK encryption are (not surprisingly)
WIRELESS_AUTH_MODE (‘psk’/‘no-encryption’ respectively)
WIRELESS_WPA_PSK (password/empty respectively)

What is a bit suspicious is WIRELESS_AP_SCANMODE=‘1’ about which the comment in the template file says:

Mode 0 means the driver

performs the scan. Mode 1 means wpa_supplicant takes care of scanning. Mode

2 is basically the same as mode 0 but the access point gets chosen by

security policy and SSID

Nevertheless, I’ve tried with both 0 and 2 as well, with the same result.

What’s also little bit strange is that even for the no-encryption case it tries to start something called a wpa_supplicant. I don’t know what it is, but wouldn’t it

actually only have to do with the WPA encryption?

linux-a9gl:~ # ifup wlan0
wlan0 device: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
wlan0 starting wpa_supplicant
Line 6: WPA-PSK accepted for key management, but no PSK configured.
Line 6: failed to parse network block.
Failed to read or parse configuration ‘/var/run/wpa_supplicant-wlan0.conf’.
Starting DHCP4 client on wlan0. . . . . . . .
wlan0 DHCP4 continues in background

But again, I have actually commented out the part from /etc/sysconfig/network/scripts/ifup-wireless where this wpa_supplicant call takes place (I put in tracing

messages to ensure I was commenting it out at the right place, so I’m sure it wasn’t called), but still, as always with the non-encrypted connection:

ping the router’s address:

linux-a9gl:~ # ping 192.168.1.1
connect: Network is unreachable

I have also tried out NetworkManager: it did see the router, it did try to start up the wireless connection, but didn’t succeed either.

This is what it says in /var/log/messages, maybe it can give a further clue (to me it didn’t)

Feb 10 14:05:49 linux-a9gl ifup: wlan0 device: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
Feb 10 14:05:49 linux-a9gl ifup-wireless: wlan0 starting wpa_supplicant
Feb 10 14:05:50 linux-a9gl kernel: [12142.077042] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Feb 10 14:05:50 linux-a9gl ifup-dhcp: Starting DHCP4 client on wlan0
Feb 10 14:05:50 linux-a9gl dhcpcd[26943]: wlan0: dhcpcd 3.2.3 starting
Feb 10 14:05:50 linux-a9gl dhcpcd[26943]: wlan0: hardware address = 00:18:de:78:52:e2
Feb 10 14:05:50 linux-a9gl dhcpcd[26943]: wlan0: broadcasting for a lease
Feb 10 14:05:50 linux-a9gl ifup-dhcp: .
Feb 10 14:05:52 linux-a9gl ifup-dhcp: .
Feb 10 14:05:55 linux-a9gl ifup-dhcp: .
Feb 10 14:05:57 linux-a9gl ifup-dhcp: .
Feb 10 14:06:00 linux-a9gl ifup-dhcp: .
Feb 10 14:06:03 linux-a9gl ifup-dhcp: .
Feb 10 14:06:05 linux-a9gl ifup-dhcp: .
Feb 10 14:06:08 linux-a9gl ifup-dhcp: .
Feb 10 14:06:09 linux-a9gl ifup-dhcp:
Feb 10 14:06:09 linux-a9gl ifup-dhcp: wlan0 DHCP4 continues in background
Feb 10 14:06:10 linux-a9gl dhcpcd[26943]: wlan0: timed out
Feb 10 14:06:10 linux-a9gl dhcpcd[26943]: wlan0: trying to use old lease in /var/lib/dhcpcd/dhcpcd-wlan0.info' Feb 10 14:06:10 linux-a9gl dhcpcd[26943]: wlan0: lease expired 252568 seconds ago Feb 10 14:06:10 linux-a9gl dhcpcd[26943]: wlan0: broadcasting for a lease Feb 10 14:06:30 linux-a9gl dhcpcd[26943]: wlan0: timed out Feb 10 14:06:30 linux-a9gl dhcpcd[26943]: wlan0: trying to use old lease in /var/lib/dhcpcd/dhcpcd-wlan0.info’
Feb 10 14:06:30 linux-a9gl dhcpcd[26943]: wlan0: lease expired 252588 seconds ago
Feb 10 14:06:30 linux-a9gl dhcpcd[26943]: wlan0: broadcasting for a lease
…

Any further ideas? :frowning:

P.S.: The contents of /etc/sysconfig/network/ifcfg-wlan0 :

BOOTPROTO=‘dhcp4’
BROADCAST=’’
ETHTOOL_OPTIONS=’’
IPADDR=’’
MTU=’’
NAME=‘PRO/Wireless 3945ABG [Golan] Network Connection’
NETMASK=’’
NETWORK=’’
REMOTE_IPADDR=’’
STARTMODE=‘auto’
USERCONTROL=‘yes’
WIRELESS_AP=’’
WIRELESS_AP_SCANMODE=‘1’
WIRELESS_AUTH_MODE=‘no-encryption’
WIRELESS_BITRATE=‘auto’
WIRELESS_CA_CERT=’’
WIRELESS_CHANNEL=’’
WIRELESS_CLIENT_CERT=’’
WIRELESS_CLIENT_KEY=’’
WIRELESS_CLIENT_KEY_PASSWORD=’’
WIRELESS_DEFAULT_KEY=‘0’
WIRELESS_EAP_AUTH=’’
WIRELESS_EAP_MODE=’’
WIRELESS_ESSID=‘linksys’
WIRELESS_FREQUENCY=’’
WIRELESS_KEY=’’
WIRELESS_KEY_0=’’
WIRELESS_KEY_1=’’
WIRELESS_KEY_2=’’
WIRELESS_KEY_3=’’
WIRELESS_KEY_LENGTH=‘128’
WIRELESS_MODE=‘Managed’
WIRELESS_NICK=’’
WIRELESS_NWID=’’
WIRELESS_PEAP_VERSION=’’
WIRELESS_POWER=‘yes’
WIRELESS_WPA_ANONID=’’
WIRELESS_WPA_IDENTITY=’’
WIRELESS_WPA_PASSWORD=’’
WIRELESS_WPA_PSK=’’

4

And still I’m telling you that for the situation you’re in, you need the Networkmanager. To add: on my openSUSE 12.1 it is, both in GNOME and KDE completely reliable.
Like lwfinger writes, using ifup in your situation can be a true PITA. Specially in buildings where multiple network ranges (and the IP’s belonging to those networks) vary. Configuring from scratch for every situation is not very reliable either. Just my 2 cents.

5

OK, thanks for the advice. Once I upgrade to a newer version of SuSE, I’ll give NetworkManager another try, I’m all the happier if it has become more reliable.

In the meantime, though, I’ve figured out the solution:

iwconfig wlan0 essid <essid-of-the-router>

and this every time ifup wlan0 is called or even when the machine is woken up from sleep mode

The “PITA” part is indeed that for non-encrypted versions Yast somehow forgets to do this.

Other than that, I’ve found that the way it can be set up with Yast is pretty straightforward and is nowhere in complexity compared to “setting up everything manually from scratch”. Still, if NetworkManager really offers an even simpler and more reliable solution, all the better.

Anyway, case solved, thanks for your comments and suggestions!

6

When I was investigating how WiFi works awhile ago and unless anything has changed (unlikely)

Although Network Manager runs on top of wpa_supplicant, wpa_supplicant is still the fundamental app that enables WiFi connections and can be invoked directly. I’m not that familiar with the relationship between YAST and wpa_supplicant, but my impression is that if you decide not to use Network Manager for wireless connections (highly inadvisable), you’d probably have best chances of success invoking wpa_supplicant directly(and forget about what you’re configuring in YAST beyond simply enabling the interface). In fact, if for some reason Network Manager isn’t working, I go directly to wpa_supplicant immediately for wpa connections, and use iw for WEP or open wireless connections.

Yes, especially if you’re not running Network Manager, IMO you do need to look at wpa_supplicant, it will contain the entries for configured WPA connections including the encrypted password (hash). I suspect you will need to clear that value if you’re not using Network Manager, which ordinarily should supercede and use values stored in KDE wallet.

eg, from a root CLI


vi /etc/wpa_supplicant/wpa_supplicant.conf

You should also be able to get more info about wpa_supplicant from the MAN pages or help


$ wpa_supplicant --help
{/CODE]

HTH,
TS
7

On 2012-02-11 16:46, agostonbejo wrote:
>
> OK, thanks for the advice. Once I upgrade to a newer version of SuSE,
> I’ll give NetworkManager another try, I’m all the happier if it has
> become more reliable.

I happily use wifi with ifup, see no problem. It is only a problem if you
move. Or use no encryption, as you found.

> In the meantime, though, I’ve figured out the solution:

Good!

> The “PITA” part is indeed that for non-encrypted versions Yast somehow
> forgets to do this.

Maybe nobody tests unencrypted connections. No reason to use them :-p

So, you found a bug. Please report it in Bugzilla. Although… it might
already be corrected, your version is old. Check first.

> Anyway, case solved, thanks for your comments and suggestions!

One thing: next time use code tags for posting code, makes for much easier
reading at the other side.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

8

> The “PITA” part is indeed that for non-encrypted versions Yast somehow
> forgets to do this.

Maybe nobody tests unencrypted connections. No reason to use them :-p

So, you found a bug. Please report it in Bugzilla. Although… it might
already be corrected, your version is old. Check first.

I suspect there isn’t a bug, at least compared to what I’d expect.
As I posted, you may need to manually modify wpa_supplicant.conf to remove the encrypted hash if you’re not connecting using that string.

Otherwise, as I posted my preference is to just use iw to connect to unencrypted connections (as well as WEP).

It’s why I have iw installed… between iw and wpa_supplicant I can connect to any type of WAP from command line and not dependent on any Desktop app.

TS

9

On 2012-02-15 23:16, tsu2 wrote:

>> So, you found a bug. Please report it in Bugzilla. Although… it might
>> already be corrected, your version is old. Check first.
>
> I suspect there isn’t a bug, at least compared to what I’d expect.
> As I posted, you may need to manually modify wpa_supplicant.conf to
> remove the encrypted hash if you’re not connecting using that string.

If yast did not do all that automatically, it is a bug in yast.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

10

I’d like to make the case that this <is not> a bug…

Everything that follows in this post is based on my personal investigation a couple years ago, I don’t know that “how network manager works” has been detailed by anyone the way I’m posting here.

  • When YAST configures networking to use “classical” ifup/ifdown instead of Network Manager,the main purpose is to disable “managed” networking and the User is then left to manually configure networking.

  • When YAST has disabled Network Manager, YAST does little more than to perform the most basic networking interface configuration…

    • When networking is enabled (eg system boot, detection of a working network interface, detection of a working network connetion, etc),
    • Basic networking is configured using DHCP or fixed values, plus some possible options.
    • YAST has no obvious and easily configured way by itself to fully support various types of wireless networking.

So, it stands to reason that if Network Manager is disabled (enable ifup/ifdown)

  • If a working physical connection requiring no authentication is detected (eg wired connection), then a network connection is successful.
  • If a working physical connection using pre-configured credentials(eg proxy or pre-existing wireless config) is detected, then a network connection is successful.
  • If neither of the above conditions is met, then no network connection can be made immediately with a simple YAST ifup/ifdown configuration.

To understand why the OP failed is to understand what happened when he first created a WiFi connection using WPA Personal (shared secret) encryption, then attempted to clear the encryption and then disable network manager it’s important to understand what actually is happening below the surface.

The first thing to know is that wpa_supplicant is the universal basic tool for WPA connections, it’s fully featured, can be invoked on its own and is so rock solid and dependable it would be near foolish for any network manager to not use its functionality, so it shouldn’t be surprising that both Gnome Network Manager as well as the Knetworkmanager variant both do so.

Note that wpa_supplicant supports <only> WPA connections, it does not support WEP connections at all. I personally use another utility called iw to connect to WEP and for reasons that next will be made clear, also for “open” WiFi (no security). Both wpa_supplicant and iw can maintain their own store of pre-configured connections in XML-like format and can scan for available networks.

The critical thing to know is that when you create a WPA connection using Knetworkmanager, the encrypted hash (password) is written to wpa_supplicant.conf(because it’s standard practice) even though typically it’s not used by Network Manager… Knetworkmanager typically also stores the hash in KDE Wallet and uses the value stored there, not the value in wpa_supplicant.conf.

This is why when you clear the WPA hash (making the connection “anonymous”), only the value in KDE wallet is changed. Knetworkmanager does not expect changes need to be made anywhere else… But, if you disable Kneworkmanager (enabling ifup/ifdown) and attempt to make a connection using wpa_supplicant, wpa_supplicant.conf will still contain the hashed encrypted password.

This is just another example of a very common issue I’ve seen many times in Management software… Component logic usually assumes a cascading one way path, so it doesn’t “bubble up” changes in a reverse direction. This is a bug only if you feel that Knetworkmanager should be writing nulls to wpa_supplicant.conf when ordinarily that would be totally irrelevant and unnecessary to the operation of Knetworkmanager.

So,
I’d suggest that this is not a bug, the anomaly is noticed only because the User is doing something “out of design parameters” but the solution is simple… My suggestion to use iw will work because iw maintains its own separate store of configurations (WEP security) so will not use the wpa_supplicant.conf configuration.

IMHO,
TS

11

On 2012-02-18 21:46, tsu2 wrote:

> I’d like to make the case that this <is not> a bug…
>
> Everything that follows in this post is based on my personal
> investigation a couple years ago, I don’t know that “how network manager
> works” has been detailed by anyone the way I’m posting here.

…

Nice explanation, thanks.

But I still think it is a bug if the user interface is not capable to
configure whatever is below in a manner that works. The user doesn’t have
to know whatever is under it, although it may help to solve/bypass the problem.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)