N600 Wireless Dual Band PCI card will not connect to internet

Hi, Can anyone please help!!! This is my last attempt with opensuse before I try something else. Installed opensuse 13.2. In Network Settings in Yast I configured wireless card. When doing so I clearly saw that the WIFI network (SSID) had been picked up because its name was listed in the list of available wifi connections. I then wrote to wpa_supplicant.conf file.

wpa_passphrase SSID  WIFI password >> wpa_supplicant.conf 

  

I ran wpa_supplicant with the new configuration file:

wpa_supplicant -B -D ath9k -i wlp2s0 -c wpa_supplicant.conf 

  

ath9k was the driver listed for the wireless card when I ran “hwinfo --wlan”. The statement that came up was: "successfully initialized wpa_supplicant wlp2s0. Unsupported driver ‘ath9k’.
When I ran

iw wlp2s0 link 


it showed that there was no connection. What could be the reason for failure to connect to internet? I have a feeling it could be to do with unsupported driver ‘ath9k’ although opensuse 13.2 has a package ‘ath9k’???

Hi
Why do it that way and not use the tools provided -> YaST Network Settings and configure here, assuming your not running a desktop? Or via NetworkManager?

Hi
Further to above, if you select the device, then edit, it asks for the SSID, paraphrase etc, it should then automatically create any files wpa_supplicant) needed etc.

Do not confuse wpa_supplicant driver with kernel driver. What makes you believe you need any -D option at all? Something does not work if you do not provide it?

Post:

hwinfo --wlan

Besides all of the above, you can try running wpa_supplicant <without> specifying the driver…
If you don’t specify an option, if a default exists (which likely would be the case here due to udev) that would be used.

But, aside from…

  • You’re installing an old, soon to be unsupported version of openSUSE
  • If you installed a graphical Desktop, then you have tools like Network Manager which can save and manage multiple network configurations (especially useful for wireless and mobile devices)

As for using wpa_supplicant directly…
I don’t ever enter options at the command line, I always create a wpa_supplicant config file entry.
Then, you can just run wpa_supplicant and the configuration will make the connection.

To do this,
I generally go find an open access point so that I don’t have to pass any special options. You can issue your wpa_supplicant command without any options and connect.
The result then is that your network configuration to the open AP is written and saved which provides a nice template, so
When you go back to your secured AP,
You can create a copy of the saved configuration and modify it for your secured AP.
Be sure to use the WPA utility to hash the password…

HTH,
TSU

None of wpa_supplicant command line options has corresponding config file entry (at least, documented).

Whenever you run wpa_supplicant, it will always read the contents of its config file unless a different config file is specified.

And, all the command options can be specified in the network connection section of the config file (AFAIK).

As I also described, if you look at the default config file before any connection has been established, you won’t find any entries. Only after that first connection has been made (my recommendation is to find an open AP without password so no configuration is necessary) will you find an entry.

TSU

Am Mon, 28 Nov 2016 01:36:02 GMT
schrieb raydona <raydona@no-mx.forums.microfocus.com>:

>
> Code:
> --------------------
> wpa_supplicant -B -D ath9k -i wlp2s0 -c wpa_supplicant.conf
>
>

Well, that -D ath9k is of course non sense as it was already pointed out.

And for the idea of creating your own wpa_supplicant.conf file for frameworks
calling wpa_supplicant (i.e. wicked AND NetworkManager) via dbus:

https://forums.opensuse.org/showthread.php/521165-Wicked-configuration-for-wlan0?p=2800989#post2800989

The best you cant get from that idea would be “your entries are being ignored”,
the worst is breaking your setup (which happened here).

It is (somehow) possible to run your own wpa_supplicant process for some
wireless card when using wicked, but it is not worth the effort, see also

https://forums.opensuse.org/showthread.php/521165-Wicked-configuration-for-wlan0?p=2801172#post2801172

AK


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

Reading those forum threads, I see plenty wrong in those discussions so IMO those threads have limited usefulness…

  1. The wpa_supplicant.service file should not be touched, for the most part it should be used only to run the wpa_supplicant app and should not be used for network configurations.

  2. The posts about using wpa_passphrase are at times incorrect. wpa_passphrase is only a utility to hash the passphrase and is used completely separately (and infrequently) so that the passphrase is stored securely because whether hashed or not, the passphrase is stored as text in the network connection stanza of wpa_supplicant.config for that network connection.

wpa_supplicant can be invoked directly or through another app.
AFAIK there is no substitute for wpa_supplicant (and its parts) and so wpa_supplicant will function the same way no matter whether wicked or Network Manager invokes it, or invoked directly.

But yes, as described in those threads and here, it can be difficult to correctly edit wpa_supplicant.config manually which is why I described my method for generating a template for the network connections stanzas. It’s far more convenient to just use Network Manager (better than Wicked if you connect to more than one network) so all those config edits are created automatically.

IMO,
TSU

Am Mon, 28 Nov 2016 18:56:01 GMT
schrieb tsu2 <tsu2@no-mx.forums.microfocus.com>:

> Akoellh;2802084 Wrote:
> > Am Mon, 28 Nov 2016 01:36:02 GMT
>
> Reading those forum threads, I see plenty wrong in those discussions so
> IMO those threads have limited usefulness…

Yeah, too bad my comments were ignored, but why does that make the thread
less useful?

> 1. The wpa_supplicant.service file should not be touched, for the most
> part it should be used only to run the wpa_supplicant app and should
> not be used for network configurations
.
>
> 2. The posts about using wpa_passphrase are at times incorrect.
> wpa_passphrase is only a utility to hash the passphrase and is used
> completely separately (and infrequently) so that the passphrase is
> stored securely because whether hashed or not, the passphrase is stored
> as text in the network connection stanza of wpa_supplicant.config for
> that network connection.
>

That’s exactly what I wrote in that thread, so again, if it is less useful, why
do you repeat it?

> wpa_supplicant can be invoked directly or through another app.
> AFAIK there is no substitute for wpa_supplicant (and its parts) and so
> wpa_supplicant will function the same way no matter whether wicked or
> Network Manager invokes it, or invoked directly.
>

Well, that’s just not correct, it makes a big difference if you run it manually
or if you invoke it via dbus, as I also stated in that thread.

If you use a framework calling wpa_supplicant via dbus, you should not add any
network credentials at all and …

> But yes, as described in those threads and here, it can be difficult to
> correctly edit wpa_supplicant.config manually which is why I described
> my method for generating a template for the network connections stanzas.

that’s wrong again, there is no way to do that, when using dbus (as NWM and
wicked do) any credentials/network settings in wpa_supplicant.conf are -at best-
being ignored.

So in fact it is VERY easy to edit the wpa_supplicant.conf when using
wicked/NWM.
The easiest and least error-prone way to do that is NOT to touch the
wap_supplicant.conf at all.

> It’s far more convenient to just use Network Manager (better than Wicked
> if you connect to more than one network) so all those config edits are
> created automatically.

Yes, that’s exactly what I wrote in that thread, maybe it is not being ignored
this time.

AK


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