Wireless mess in GNU/Linux

dakt · 2010-10-06 10:24:51

I haven't been messing around with wireless on Linux since I used to hang on Fedora where it worked out of the box. Since arch install...I have to....which is a good thing.
But I'm a bit confused on how things work...
First we used to have wireless-tools (iw*) which never worked for me (iwl3945 driver), then wpa_supplicant for which I'm not certain how it really works.
AFAIK, wpa_supplicant is user mode back end for managing wireless networks on which every front end app. like wpa_cli/gui, nm-applet, wicd relys on...rigt?
And it talks directly to wireless driver. Great...now what on earth is "wext" in -D flag?

man wpa_supplicant
...
wext   Linux wireless extensions (generic).
...

That tells me everything!? So wpa_supp is using both iwl3945 and wext (which is deprecated according to kernel.org)? I'm confused on how wireless stack on Linux looks like.
More confusion...what is cfg80211 then? Isn't that supposed to be layer above wireless driver?
Why don't we have ONE front end for managing ALL network connections?
Why is it called wpa_supplicant when it was made to manage all types of wireless networks?

Mektub · 2010-10-06 10:39:37

Dakt,

Why don't we have ONE front end for managing ALL network connections?

We have wicd. You shouldn't have to mess with wpa_supplicant.

http://wiki.archlinux.org/index.php/Wicd

Mektub

eldragon · 2010-10-06 11:02:24

archlinux has netcfg which is imo, simple, elegant, and actually works

but that is just command line.

.:B:. · 2010-10-06 11:29:27

You could have picked a less trollish topic title .

You have an elaborate opening post but it's not clear whether you have a problem or are simply venting about the multitude of tools. I suggest you talk to the wpa_supplicant devs about a name change if you really think that is warranted .

Mac80211 is the wireless network stack in the kernel, on which drivers build (IPW2200 drivers use the old wireless stack for example afaik, IPW3945, IPW4965 and up use the mac80211 stack exclusively). For more info on iwconfig and the likes you can read up on the wireless-tools utilities collection. Wpa_supplicant is exclusively used for authentication afaik. Wireless-tools is still around, but the authentication functions it had have been largely (if not completely) replaced by wpa_supplicant (which can also do WEP). You need iwconfig to set stuff like bitrate, channel, etc., manually.

Linux is about modularity, and the wireless landscape on Linux reflects that. You can hate it, but that won't make it go away.

tomk · 2010-10-06 12:39:37

dakt wrote:

wext (which is deprecated according to kernel.org)

Link please - hadn't heard about that myself.

dakt · 2010-10-06 12:55:35

eldragon wrote:

archlinux has netcfg which is imo, simple, elegant, and actually works
but that is just command line.

That's one of the problems...every distribution has it's own front end. It would be so much simpler to have one network manager, one configuration file.

falconindy · 2010-10-06 12:58:33

From wireless.kernel.org:

Some discussion surrounding when to drop support for hardware that do not support cfg80211. There are still a significant number of current drivers (about half dozen) that need to be converted before wext can be removed. Now listed on cfg80211-conversion . wext will be put in feature-removal and marked as deprecated.

dakt · 2010-10-06 13:10:28

.:B:. wrote:

You could have picked a less trollish topic title .

Naah, I think it suits the case.

You have an elaborate opening post but it's not clear whether you have a problem or are simply venting about the multitude of tools.

I'm venting

I suggest you talk to the wpa_supplicant devs about a name change if you really think that is warranted .

let's just call it...I don't know...wld. Not sure if it's very accurate but much more descriptive then wpa_*. At first, I taught it's something dedicated only to WPA protocol.

Linux is about modularity, and the wireless landscape on Linux reflects that. You can hate it, but that won't make it go away.

I love modularity, I really do...but more then that I like well established, well documented, clean system. I'm still confused about wext vs. cfg80211 and how it relates to wl driver and wpa_supplicant.

..maybe I'm having a bad day?

dakt · 2010-10-06 13:12:36

tomk wrote:

dakt wrote:
wext (which is deprecated according to kernel.org)
Link please - hadn't heard about that myself.

http://wireless.kernel.org/en/developer … Extensions

dakt · 2010-10-06 13:20:41

falconindy wrote:

From wireless.kernel.org:
Some discussion surrounding when to drop support for hardware that do not support cfg80211. There are still a significant number of current drivers (about half dozen) that need to be converted before wext can be removed. Now listed on cfg80211-conversion . wext will be put in feature-removal and marked as deprecated.

Good find. Thanks!

So...this is the picture?

+-------------------------+-----------------------------user space------------
   nm/wicd/wpa_cli
+-------------------------+
  wpa_supplicant/wl-tools/ioctl()
+--------+---------------+---------------------------kernel space------------
   wext        cfg80211   
+--------+---------------+
   wl driver
+-------------------------+--------------------------------------------------

.:B:. · 2010-10-06 13:24:09

Wext is a driver/interface wpa_supplicant uses afaik. That's all I can say. There are plenty of things marked 'deprecated' in the kernel, I understand it can be confusing. It usually means though that that stuff will be removed somewhere in the future so new programs should not make use of it, and existing programs should use the new interface/API/whatever.

PUE · 2010-10-06 15:03:19

Mektub wrote:

Dakt,
Why don't we have ONE front end for managing ALL network connections?
We have wicd. You shouldn't have to mess with wpa_supplicant.
http://wiki.archlinux.org/index.php/Wicd
Mektub

The wicd dev uses NM in the meanwhile and looks for maintainers. I have lots of issues with wicd, can't recommend it.

schivmeister · 2010-10-13 21:05:39

dakt wrote:

Why don't we have ONE front end for managing ALL network connections?

We DO have one and it's called network-manager-applet.

Heller_Barde · 2010-10-18 14:08:21

on a related note: why does it take significantly longer to scan for WLANs in my ArchLinux compared to my Windows? Also to connect to a Network after it found it. If anyone can tell me where the bottleneck seems to lie, I would much appreciate it, because it's driving me insane sometimes. (I have an Intel iwl5300 or something like that)

there seem to be a few possibilities:

Binary Firmware Blob from Intel (although I would assume that this is the same in Windows.)
Kernel Driver from Intel (fixable, but I probably don't have the skills for it)
wext interface (I don't know whether this is even involved *shrug*)
wpa_supplicant
dhcpcd

those last two I can try out on my own. but as far as I can remember dhcpcd did provide a significant speed barrier, but not all of the speed loss.

now where is the relevance of this post? I don't really expect an answer here, but it illustrates rather nicely how people in general are rather unaware of the state of things. Because with well know topics, I would have found my answer a long time ago on the interwebs.

cheers
Barde.

.:B:. · 2010-10-18 16:35:19

I suggest you open a separate topic for your issue .

Last edited by .:B:. (2010-10-19 09:19:10)

Heller_Barde · 2010-10-19 05:26:37

.:B:. wrote:

I suggest you open a separate topic for your issue instead of hijacking this one .

fair enough, I probably drifted off too far. But I didn't really post to get an answer to my (non-)problem. I wanted to comment on $THREAD_TITLE and I thought this would illustrate it nicely. Apparently I overdid it

cheers
Barde

ise · 2010-10-19 07:16:36

PUE wrote:

The wicd dev uses NM in the meanwhile and looks for maintainers. I have lots of issues with wicd, can't recommend it.

Then you know more than I do about myself. I'm the maintainer of the wicd package and I don't look for another maintainer, where have you read that?
About the issues, wicd runs perfect on my computer. Can you tell me in a new topic what problems you have?

Heller_Barde · 2010-10-19 07:20:04

ise wrote:

I'm the maintainer of the wicd package and I don't look for another maintainer, where have you read that?

I think he meant the dev that develops wicd itself, not the package.

Barde

Barrucadu · 2010-10-19 09:03:47

If you want to be even more confused, wpa_supplicant can be used for wired networks, too. I'm having to use it for the network at university (802.1x authentication)

.:B:. · 2010-10-19 09:18:46

Heller_Barde wrote:

.:B:. wrote:
I suggest you open a separate topic for your issue instead of hijacking this one .
fair enough, I probably drifted off too far. But I didn't really post to get an answer to my (non-)problem. I wanted to comment on $THREAD_TITLE and I thought this would illustrate it nicely. Apparently I overdid it
cheers
Barde

My tone might have been a bit harsh, but that was not my intention (the tone, that is).

dakt · 2010-10-19 15:01:46

Barrucadu wrote:

If you want to be even more confused, wpa_supplicant can be used for wired networks, too. I'm having to use it for the network at university (802.1x authentication)

First word.
Anyway, I figured whole wireless stack. I'm might write a short description of it when I get some free time.

Ranguvar · 2010-10-19 17:00:33

I do agree that the *BSD way (in my small amount of experience with it) of using ifconfig pretty much as the sole tool is enjoyable.

dakt · 2010-10-19 19:46:21

Ranguvar wrote:

I do agree that the *BSD way (in my small amount of experience with it) of using ifconfig pretty much as the sole tool is enjoyable.

Yeah, BSD is closer to UNIX philosophy...well it is Unix.

ifconfig wlan0 scan
ifconfig wlan0 dhcp

orlandu63 · 2010-10-21 22:19:38

eldragon wrote:

archlinux has netcfg which is imo, simple, elegant, and actually works
but that is just command line.

I find wicd to be _way_ more convenient for detecting, connecting to, and saving wireless networks. It's essentially netcfg with an optional GUI. I don't see any reason to not use it over netcfg other than in the case that the user is mostly dealing with wired connections and when working in a low-memory environment: wicd is overkill for managing wired networks (well, unless you have multiple wired networks or something) and the python-based daemon consumes a sizable amount of memory (around 12M). If you're seeking a portable, convenient network manager, give wicd a try.

ChoK · 2010-10-21 22:38:58

cnetworkmanager brings network-manager to the CLI, it's simple without the problems the GUI apps have (scanning, connecting to an hidden WPA2 network)

Arch Linux

#1 2010-10-06 10:24:51

Wireless mess in GNU/Linux

#2 2010-10-06 10:39:37

Re: Wireless mess in GNU/Linux

#3 2010-10-06 11:02:24

Re: Wireless mess in GNU/Linux

#4 2010-10-06 11:29:27

Re: Wireless mess in GNU/Linux

#5 2010-10-06 12:39:37

Re: Wireless mess in GNU/Linux

#6 2010-10-06 12:55:35

Re: Wireless mess in GNU/Linux

#7 2010-10-06 12:58:33

Re: Wireless mess in GNU/Linux

#8 2010-10-06 13:10:28

Re: Wireless mess in GNU/Linux

#9 2010-10-06 13:12:36

Re: Wireless mess in GNU/Linux

#10 2010-10-06 13:20:41

Re: Wireless mess in GNU/Linux

#11 2010-10-06 13:24:09

Re: Wireless mess in GNU/Linux

#12 2010-10-06 15:03:19

Re: Wireless mess in GNU/Linux

#13 2010-10-13 21:05:39

Re: Wireless mess in GNU/Linux

#14 2010-10-18 14:08:21

Re: Wireless mess in GNU/Linux

#15 2010-10-18 16:35:19

Re: Wireless mess in GNU/Linux

#16 2010-10-19 05:26:37

Re: Wireless mess in GNU/Linux

#17 2010-10-19 07:16:36

Re: Wireless mess in GNU/Linux

#18 2010-10-19 07:20:04

Re: Wireless mess in GNU/Linux

#19 2010-10-19 09:03:47

Re: Wireless mess in GNU/Linux

#20 2010-10-19 09:18:46

Re: Wireless mess in GNU/Linux

#21 2010-10-19 15:01:46

Re: Wireless mess in GNU/Linux

#22 2010-10-19 17:00:33

Re: Wireless mess in GNU/Linux

#23 2010-10-19 19:46:21

Re: Wireless mess in GNU/Linux

#24 2010-10-21 22:19:38

Re: Wireless mess in GNU/Linux

#25 2010-10-21 22:38:58

Re: Wireless mess in GNU/Linux

Board footer