Wireless only with ifup as root

Wireless works excellent if the traditional method with ifup is used (configured with Yast) as root. Trying the same as normal user with NetworkManager results in a timeout without connection:


Oct 24 15:10:56 nue-j1 NetworkManager: <info>  (wlan0): device state change: 2 -> 3 (reason 42)
Oct 24 15:13:00 nue-j1 NetworkManager: <info>  (wlan0): device state change: 3 -> 2 (reason 0)
Oct 24 15:13:00 nue-j1 NetworkManager: <info>  (wlan0): deactivating device (reason: 0).

Executing


/sbin/ifup wlan0 -o ifplugd

as normal user gives


No configuration found for wlan0

Eventually I found that


# ll /etc/sysconfig/network/ifcfg-wlan0
-rw------- 1 root root 

A first try to add the user to group “dialout” didn’t help.

:\ What is the configuration trick?

openSUSE 11.3 (x86_64)
Linux 2.6.34.7-0.4-desktop x86_64
KDE 4.5.2 “release 10”

All system files belong to root, so that is normal. Anytime you change your networking configuration, you normally must be root. What is not normal, is the need to login at the very first as root. It was not clear to me if that is indeed what you are doing, but running anything within YaST, must be done as root. Files that are not located in your home area, but somewhere else in the system, most often require root permissions in order to edit or modify these files.

I have a script file that can obtain a lot of information on your network setup. If you are up to it, download the script, run it in terminal and use the text file it creates to copy and past the information from it into a message here in the forum for us to look at:

netinfo - Read Network & PC Information into a Local Text File

Message number 11 had the most recent version of netinfo and message number 23 had another script called blip that also might be useful.

Thank You,

Sorry for being not clear enough.
The intention is to use NetworkManager under KDE as normal user.
The system is a fresh install of openSUSE 11.3 (x86_64), Linux 2.6.34.7-0.4-desktop x86_64, KDE 4.5.2 “release 10”.
Initially Yast was configured to use NetweorkManager to do the job.
NetworkManager always failed with the timeout described in post #1

So I tried without NetworkManager and went back to Yast and configured to use “traditional method”. I happend to work on a root konsole and everything looked fine!
Even now, when the system boots, the wireless connection is there!

I realized that this might be an access rights issue and so I tried as normal user.
And voila, there are access rights problems. I separate the description into subsequent posts, in order not to spoil this one. I also executred the recommende script and will post the output in a subsequent post.

I wonder, how NetworkManager should get the information

  • If ifcfg-wlan0 is only readable by root,
  • There is no group associated with this file, like e.g. ‘dialout’.

when NetworkManager is run by an ordinary user.

A first try with simply adding the user to group ‘dialout’ and changing the group of ‘ifcfg-wlan0’ to group ‘dialout’ (and making it group readable) just showed, that the next errir message regarding missing access rights appeared.

So I believe I missed something essential in setting up the wireless system? :’(

This is the output of the script. In my opinion we don’t see the prblem here, since ‘ifcfg-wlan0’ is not checked, for example.

Initial state after bootup: Wireless works like a charm

  1. Issuing
ifdown wlan0 -o ifplugd

as root: Wlan goes down, o.k.

  1. Issuing
ifup wlan0 -o ifplugd

as root: Wlan comes up, o.k.

  1. Issuing
ifdown wlan0 -o ifplugd

as user:


> ifdown wlan0 -o ifplugd
Absolute path to 'ifdown' is '/sbin/ifdown', so running it may require superuser privileges (eg. root).
> /sbin/ifdown wlan0 -o ifplugd
    wlan0     device: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
              No configuration found for wlan0 
              Nevertheless the interface will be shut down.
scripts/ifdown-services: Zeile 98: ./ifcfg-wlan0: Keine Berechtigung
scripts/ifdown-connection: Zeile 99: ./ifcfg-wlan0: Keine Berechtigung
/sbin/ifdown-dhcp: Zeile 85: ./ifcfg-wlan0: Keine Berechtigung
/etc/sysconfig/network/scripts/ifdown-route: Zeile 100: ./ifcfg-wlan0: Keine Berechtigung
Error while executing:
   Command 'ip route del to 169.254.0.0/16 dev wlan0' returned:
  RTNETLINK answers: Operation not permitted
   Configuration line: 169.254.0.0/16 - - wlan0  
scripts/ifdown-wireless: Zeile 85: ./ifcfg-wlan0: Keine Berechtigung
cat: /var/run/wpa_supplicant/wlan0.pid: Keine Berechtigung

(sorry, ‘Keine Berechtingung’ means ‘no access’)

  1. Issuing
ifup wlan0 -o ifplugd

as user:


> /sbin/ifup wlan0 -o ifplugd
    wlan0     device: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
              No configuration found for wlan0

  1. Issuing
ifup wlan0 -o ifplugd

as root: Wlan comes up, o.k.

So, it is an access rights problem, isn’t it? :\

So it is early morning here and not so much time to look at your setup, but when you are at the console using ifup or ifdown, you should be root, even when you log in as a normal user (Try using the ‘su -’ terminal command first). Log in as normal and startup up YaST / Network Devices / Network Settings and elect to run Network Manager at startup. Once done, you should be good to go. If you are using wireless and the KDE desktop, you may need to run KWallet to keep track of any WAP passwords, when required. In order to run YaST, you must enter the root user password, this is normal. You should get into a setup that should stick on each restart of your PC, logging in as a normal user each time.

Thank You,

The scripts ifup/ifdown require root privilege. The files named
/etc/sysconfig/network/ifcfg-wlanx will contain your network secrets, thus only
root should have any access to them.

Running /sbin/ifup as a normal user should/must fail.

Running sudo /sbin/ifup should work. Is that not true on your system?

Hello lwfinger. Thanks for the help. Is it my imagination or have you been out for a while? I recall trying to send you a message a while back and it did not seem to work. In any event, even if it is my imagination running wild, it is good to see you here.

Thank You,

On 10/25/2010 04:06 PM, jdmcdaniel3 wrote:
>
> Hello lwfinger. Thanks for the help. Is it my imagination or have you
> been out for a while? I recall trying to send you a message a while
> back and it did not seem to work. In any event, even if it is my
> imagination running wild, it is good to see you here.

I took a long vacation. I am now peeking in from time to time and will comment
occasionally.

Now, that’s exactly what I did initially. But as described earlier, NetworkManager simply turns the device off after about 2min without any detailed error message in /var/log/NetworkManager. So I tried to investigate the problem without NetworkManager and accordingly configured the device with Yast to use “traditional” ifup. Is there an option to make NetworkManager more verbose?

Yes, that is true, sudo /sbin/ifup works.

O.K. so using ifup/ifdown is not the right way.
Should I use wpa_supplicant instead to debug this problem?
What would you recommend?

So you use KDE. When you are configured to use NetworkManager by default (not ifup), I was thinking you needed to use Kwallet to manage/keep your WAP passwords for you. Did you know about or try to do such a thing? Its real name is kwalletmanager I think.

Thank You,

Actually I tried both, using KWallet - and since I was never asked to enter the KWallet password - by storing the password directly in KNetworkManager. This also didn’t help…

On 10/25/2010 05:06 PM, pinysuse wrote:
>
> lwfinger;2243445 Wrote:
>>
>> …
>> Running /sbin/ifup as a normal user should/must fail.
>>
>> Running sudo /sbin/ifup should work. Is that not true on your system?
>
> Yes, that is true, sudo /sbin/ifup works.
>
> O.K. so using ifup/ifdown is not the right way.
> Should I use ‘wpa_supplicant’
> (http://de.opensuse.org/Probleme_bei_Drahtlosnetzwerken_finden) instead
> to debug this problem?
> What would you recommend?

I would go back to NM. When the connection drops out, what information occurs in
the output of dmesg.

As I have tried to point out in this forum, once NM makes the connection it
becomes passive until the connection needs attention. Switching to ifup is not
likely to help, and it is a lot harder to manage, as you have found.

You need to have wpa_supplicant configured whether you use ifup or NM. It is
used to handle WPA or WPA2 encryption. The only difference would be that NM
needs wpa_supplicant WEP whereas ifup only uses the supplicant for WPA/WPA2.

O.K., after a little more searching and being motivated by It’s All KDE’s Fault I tried cNetworkManager (no configuration change, just switching back to NetworkManager in Yast).

> cnetworkmanager -C MYSSID --wpa-pass=MYPSKWITH$AND?
Entering mainloop
(00:12:50) State: CONNECTING
Getting secrets: /MyConnection/1
SECMAP {'802-11-wireless-security': {'pairwise': 'tkip', 'ccmp'], 'group': 'tkip', 'ccmp'], 'psk': '5d3b4eca06e2137cbc82309b93036db84e682ad636e2d31bb292da893a3ee65b', 'key-mgmt': 'wpa-psk'}}
Getting secrets: /MyConnection/1
SECMAP {'802-11-wireless-security': {'pairwise': 'tkip', 'ccmp'], 'group': 'tkip', 'ccmp'], 'psk': '5d3b4eca06e2137cbc82309b93036db84e682ad636e2d31bb292da893a3ee65b', 'key-mgmt': 'wpa-psk'}}
Getting secrets: /MyConnection/1
SECMAP {'802-11-wireless-security': {'pairwise': 'tkip', 'ccmp'], 'group': 'tkip', 'ccmp'], 'psk': '5d3b4eca06e2137cbc82309b93036db84e682ad636e2d31bb292da893a3ee65b', 'key-mgmt': 'wpa-psk'}}
^CLoop exited

where the endless loop needed to get interrrupted by ^C.

These are the corresponding /var/log/NetworkManager entries:

Oct 27 00:14:05 nue-j1 NetworkManager: <info>  (wlan0): supplicant connection state:  4-way handshake -> disconnected
Oct 27 00:14:05 nue-j1 NetworkManager: <info>  Config: set interface ap_scan to 1
Oct 27 00:14:05 nue-j1 NetworkManager: <info>  (wlan0): supplicant connection state:  disconnected -> scanning
Oct 27 00:14:06 nue-j1 NetworkManager: <info>  (wlan0): supplicant connection state:  scanning -> associating
Oct 27 00:14:06 nue-j1 NetworkManager: <info>  (wlan0): supplicant connection state:  associating -> associated
Oct 27 00:14:06 nue-j1 NetworkManager: <info>  (wlan0): supplicant connection state:  associated -> 4-way handshake

Googling for this “4-way handshake → disconnected” message lead to
Fritz WLAN Stick doesn´t connect (in DE, sorry) which pointed to Special characters (DE)

So, after removing the ´?´ and the ´$´ from the PSK in the access point configuration we have

> cnetworkmanager -C MYSSID --wpa-pass=MYPSKWITHOUT$OR?
Entering mainloop                                                                      
(00:35:17) State: CONNECTING
(00:35:25) State: CONNECTED

et voila (no accents here>:))

Now it´s time to try KNetworkManager …

>:( Still no connection with KNetworkManager (or this plasma applet thing) >:)

No message in /var/log/NetworkManager

… too late now, executing

sleep 6h -t now

:sarcastic:

After booting, there suddenly where some messages in /var/log/NetworkManager, so I stumbled over a Potential BSSID issue in KNetworkManager and so deleted the BSSID entry in the Wireless Connection tab. Still didn’t work. Actually, somehow this settings couldn’t be deleted.
So I deleted the wireless connection entry completely. Afterwards I chose the wireless connection again from the display of available connections and this just worked out. I merely had to add the PSK.

Now strange: Only when the connection is added as fresh entry, the wireless connection functions:
(This is reproducible!)

On 10/28/2010 05:36 PM, pinysuse wrote:
> Now strange: Only when the connection is added as fresh entry, the
> wireless connection functions:
> (This is reproducible!)

You get rid of the garbage by deleting the old one. It was particularly
important with early 11.2 to clear a bug on the distribution media.

Despite what you read here, NM does work.

As far as I understand, NM does work (proven with cNetworkManager, right?), but the KNM-applet might not interact correctly.
Any idea, where to look for the “garbage”?
Are there any “verbosity” or “debug” flags, that could be set?

That’s uggly. It’s a comon recommendation to use special characters like ?#$% in a WLAN passphrase to make dictionary attacks useless. pinysuse reported me a problem with collectNWData because it failed to masquerade the PSK key in the generated output listing (fixed now). That way he detected it might be a good idea to remove ? and $ from the PSK - and succeeded now - at least with cnetworkmanager. (? and $ do have special semantic in perl and bash … don’t know which language is used by cnetworkmanager … - at least this was the masquerading issue in collectNWData).
Now I’m wondering whether this is a feature or a bug of cnetworkmanager and it makes sense to add an additional check in collectNWdata for these exceptional characters in the PSK and to generate at least a warning - or even an error message.