Wicked configuration for wlan0

English Network/Internet
1

Hi there,

I’ve been using a manual network config (without any manager) for eth0 and wlan0 (usb dongle) since Opensuse 12.3. However, now I’m trying to configure it using wicked in my new systems (tumbleweed or Leap 42.2, both of them) but I can’t do it for wlan0 (eth0 works fine without config any thing else).
This is my ifcfg-wlan0 config file:


BOOTPROTO='dhcp4'
STARTMODE='ifplugd'
USE_DHCP='yes'

This is my wpa_suppplicant.conf file:


ctrl_interface=/var/run/wpa_supplicant
update_config=1

network={
        ssid="My_wlan"
        scan_ssid=1
        psk=fa91fa7288be9750d0843000cb435a2f7d64da999c057cec4249e7fa801287fd
        key_mgmt=WPA-PSK
        group=CCMP TKIP
        priority=10
}

the passphrase has been generated using wpa_passphrase command, this passphrase is not included directly in ifcfg-wlan0 file because if I do that wicked shows a passphase lenght error like: Invalid passphrase length 64 (expected: 8…63) ‘fa91fa7288be9750d0843000cb435a2f7d64da999c057cec4249e7fa801287fd"’. Which I think could be a system bug because as you can see passphrase is generated directly by wpa_passphase command.

This is wpa_supplicant.service:


[Unit]
Description=WPA Supplicant daemon
Before=network.target
After=dbus.service

[Service]
Type=dbus
BusName=fi.w1.wpa_supplicant1
ExecStart=/usr/sbin/wpa_supplicant **-i wlan0** -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log

[Install]
WantedBy=multi-user.target

(I’ve added “-i wlan0” because without it anything works)

and obviously wpa_supplicant (enabled by me), wicked, wickedd, wicked-nanny, … services are enabled and running.

Using the above configuration and after a system reboot wlan0 is not working, I must type:


systemctl restart wpa_supplicant.service

to be able to connect my wifi.

What’s wrong in my configuration files?
I’m really stuck. Any body could help me, please?
Thanks a lot!

2

One possible reason, wpa_supplicant takes time to associate with AP, so it happens too late and wicked already gives up. Do you have nanny enabled?

3

Not yet, unless there is any one by default…
Anyway, should wicked and wpa_supplicant not understand each other? What should I do to “synchronize” both of them? or How to use nanny if needed?
I’m a little bit out as for wicked, as you can imagine. I’m starting to understand and use it…

Thanks

4

Am Mon, 21 Nov 2016 17:26:02 GMT
schrieb dpatino82 <dpatino82@no-mx.forums.microfocus.com>:

> Anyway, should -wicked- and -wpa_supplicant- not understand each other?

Yes, and that is (most likely) the reason why your idea does not work here.

Wicked and wpa_supplicant “talk” to each other via dbus and wicked is the one
who “tells” wpa_supplicant which configuration variables to use.

Therefor anything else you add manually to wpa_supplicant.conf will most likely
be ignored.

You should configure the wireless specific stuff (encryption etc.) directly
inside the ifcfg-file (see man ifcfg for a start) and not inside the
wpa_supplicant.conf.

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

5

You should also hide your password from the public, just in case. :wink:

6

It is enabled by default if you did not do anything.

OK, so please change your wpa_supplicant.service to be Before=network-pre.target. Otherwise there is no ordering between wicked and wpa_supplicant - both are configured to start concurrently before network.target.

Anyway, should wicked and wpa_supplicant not understand each other?

Probably if you tell wicked that you have wireless interface; but as configured I am not sure it is smart enough to detect it. You just told it to wait for link up and start DHCP on this interface.

How to use nanny if needed?

Should be used by default, in which case it waits for link up before trying to configure interface.

7

If you talk about ESSID and passphrase I’ve posted here, those are not real name and pass just created ad-hoc for this post to represent a real lenght created from wpa_passphrase command. Anyway, thanks for the advice :wink:

8

Ok, are you talking about being ignored by wicked? Then, how could I add, for example, specific roaming configuration, like *bgscan=“simple:30:-45:300”. *I guess I’ll write it in wpa_supplicant.conf file but now I’m lost …

How could I write passphrase into ifcfg-wlan0 config file? Because every time I try using the result of wpa_passphrase command, wicked shows length error:

Invalid passphrase length 64 (expected: 8..63) 'fa91fa7288be9750d0843000cb435a2f7d64da999c057cec4249e7fa801287fd"'.

That’s the reason I’ve decided to use wpa_supplicant.conf, due to passphrase length error.
Is there another way to generate the passphrase?

9

Because this is not passphrase but actual key. Key is generated by wpa_passphrase from passphrase. So you should give to wicked the same passphrase you gave to wpa_passphrase, not generated key.

10

OMG, I’ve totally understood the command backwards.

The unbelievable is that I’ve use, for example:


root@test82:~# wpa_passphrase MYSSID 123456789abcdefghijk

network={
        ssid="MYSSID"
        #psk="123456789abcdefghijk"
        psk=fa91fa7288be9750d0843000cb435a2f7d64da999c057cec4249e7fa801287fd
}

Which I’ve used in wpa_supplicant.conf file and the authentication was successful :?

My goal was to hide the wifi password because is into “open file” in “open hardware”.
Obviously I have the SSID and the password, how could I generate a hash or a “passphrase”, to use the password not in the clear into ifcfg-wlan0 file? Is that possible?

11

wpa_supplicant assumes that if you gave it exactly 64 hexadecimal characters, this is key and not passphrase.

Obviously I have the SSID and the password, how could I generate a hash or a “passphrase”, to use the password not in the clear into ifcfg-wlan0 file? Is that possible?

Hmm … it seems that when wicked sends secret to wpa_supplicant it always sends it as passphrase; the error you shown comes from wpa_supplicant, right?

I suggest opening bug report for this.

12

I’ve changed the suggested line in /usr/lib/systemd/system/wpa_supplicant.conf:


[Unit]
Description=WPA Supplicant daemon
Before=network-pre.target
After=dbus.service

[Service]
Type=dbus
BusName=fi.w1.wpa_supplicant1
ExecStart=/usr/sbin/wpa_supplicant -i wlan0 -dddt -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log

[Install]
WantedBy=multi-user.target

However, I have no connection after reboot (no IP, no link and wlan0 is not running) so I have to run:

systemctl wpa_supplicant.service restart
wicked ifup wlan0

(or even reversing the order of these commands).

It could be a mistake in my ifcfg-wlan0 file?


BOOTPROTO='dhcp4'
STARTMODE='ifplugd'
USE_DHCP='yes'
DHCLIENT_SET_DEFAULT_ROUTE='yes'
DHCLIENT_ROUTE_PRIORITY='10'

I’ve changed STARTMODE option to:

STARTMODE='auto'

But still no connection in wlan0 after reboot.
What could I do?

13

Could you upload “journalctl -b” and wpa_supplicant.log to http://susepaste.org/ and post link here?

14

Here it is “journalctl -b”: SUSE Paste
And here wpa_supplicant.log: SUSE Paste

15

I do not see any trace of wpa_suplicant in this log. Is service enabled? What is the output of “systemctl status wpa_supplicant” immediately after boot before you restart it?

If it is not typo, it is wrong and has no effect. This file is never read by systemd.

16

Am Mon, 21 Nov 2016 23:36:01 GMT
schrieb dpatino82 <dpatino82@no-mx.forums.microfocus.com>:

> My goal was to hide the wifi password because is into “open file” in
> “open hardware”.

Erm

So what?

There is absolutely NO gain in security by doing that.

If I were the attacker and I were actually able to read that file, then why
should I bother to get the “real” passphrase?

I already have some other string which will also grant me access to your wifi,
that’s good enough for me.

The only real security measure is restricting access to that file during
runtime, which is done automatically when setting up ifcfg-$INTERFACE through
yast.

ls -l /etc/sysconfig/network/ifcfg-wlan0
-rw------- 1 root root 1181 29. Okt 15:56 /etc/sysconfig/network/ifcfg-wlan0

So your normal user will not get access to that file unless (s)he has root
privileges.

Now you could also argue:

“So what, if the attacker can boot a live distro off an
external medium (s)he will be able to read those files as (s)he will have root
privileges in that live distro”.

which is absolutely correct, and this will go for any sensitive information on
that machine, not only some wifi credentials.

However, there is only one real way in preventing that, encrypting your
harddisk so booting off an external medium will not yield the data from the
hard disk without any extra work (=knowing the pass phrase for disk encryption).

As long as you don’t think of securing your system against such a simple attack
like “booting off an external medium and getting all the data” in the first
place, all other measures are funny little security placebos and nothing more.

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

17

I’m so sorry, it was my fault. I had disabled it for other tests and I forgot to enable it before paste your requested logs. The wpa_supplicant service on boot fails.
Here you are the correct requested logs:

Even here it was my fault, just a typing error. I was talking about /usr/lib/systemd/system/wpa_supplicant**.service** to say that I’ve already apply your suggested change: Before=network-pre.target

18

Sorry, my bad. Please add “Wants=network-pre.target” to wpa_supplicant.service. Otherwise network-pre.target is not active, so ordering against it has no effect.

19

Am Tue, 22 Nov 2016 12:16:01 GMT
schrieb arvidjaar <arvidjaar@no-mx.forums.microfocus.com>:

> dpatino82;2801139 Wrote:
> >
> >
> > > > >
> - -“journalctl -b”-: http://susepaste.org/1bae564e
> > > >
> >
> Sorry, my bad. Please add “Wants=network-pre.target” to
> wpa_supplicant.service. Otherwise network-pre.target is not active, so
> ordering against it has no effect.
>
>

Just a little hint:

Never, Never, EVER edit service files in /usr/lib/systemd/system.

Just DON’T!

Use a copy of the respective file, put it into /etc/systemd/system and
edit that one.

If you just think one second about the “why shouldn’t I do that” then you might
get it.

If not, then I will give you another hint:

What would happen if that package gets updated?

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

20

Thanks Akoellh, you’re absolutely right!