After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 161376 - Want support for WPA/WPA2/802.11i
Want support for WPA/WPA2/802.11i
Status: RESOLVED FIXED
Product: gnome-system-tools
Classification: Deprecated
Component: network-admin
unspecified
Other Linux
: High enhancement
: ---
Assigned To: Carlos Garnacho
Carlos Garnacho
Depends on:
Blocks:
 
 
Reported: 2004-12-15 14:51 UTC by Reinhard Tartler
Modified: 2007-10-25 12:16 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Reinhard Tartler 2004-12-15 14:51:30 UTC
currently, gnome-network-admin does not give any possibility for connection to
an wpa secured network. I have to use wpasupplicant found here:
http://hostap.epitest.fi/wpa_supplicant/

It would be very helpful if gnome-network-admin could provide an easy frontend
to wpasupplicant dealing with certificates and preshared keys.
Comment 1 Sukant Hajra 2005-10-19 02:17:53 UTC
I was talking to garnacho on #gst, and he recommended that I post some comments
regarding wpa_supplicant here.  My intention is to motivate a discussion of how
G-S-T might be sensibly augmented.

Just for some background, I'm running a Debian testing distribution (Etch), and
I've got the ifupdown, wireless-tools, wpasupplicant, and gnome-system-tools
packages working comfortably together.  This discussion might be inherently
Debian-centric, but hopefully you're in a position to recognize differences from
other distributions.

First off, I wanted to talk a little about networking administration outside of
wpa_supplicant so that when I introduce wpa_supplicant the comparision is more
clear.

I think that G-S-T's network-admin works well enough for addressing ifupdown in
conjunction with wireless-tools.  wireless-tools provides the iwconfig command
for configuring wireless interfaces. A quick 'man iwconfig' shows the following
options:

       iwconfig interface [essid X] [nwid N] [freq F] [channel C]
                          [sens S] [mode M] [ap A] [nick NN]
                          [rate R] [rts RT] [frag FT] [txpower T]
                          [enc E] [key K] [power P] [retry R] 

The wireless-tools package is pretty well integrated with the ifupdown package.
 For instance, commands like 'iwconfig eth1 power period 2' can be effectively
hooked into executions of 'ifup eth1' by putting a 'wireless-power period 2'
line in the eth1 "iface" stanza of the /etc/network/interfaces file.  In fact,
all the iwconfig commands, say XXXX, can be executed with a wireless-XXXX line
in the appropriate stanza in /etc/network/interfaces.  This is all pretty well
documented in the wireless-tools man pages.   

G-S-T supports these "wireless-" hooks pretty well, but there are a few iwconfig
options that are not supported.  I guess there's two ways to go about fixing
this.  1) We can meticulously implement all the wireless-XXXX options in the
front- and back-end.  iwconfig's man page is pretty clear about what options are
available.  Or we can 2) implement some user-custom "wireless/iwconfig" fields
in the front-end in such a way that they can be easily translated into the most
reasonable line-entries for /etc/network/interfaces stanzas.  Malformed entries,
though, will prevent ifup and ifdown from successfully executing.

Note that WEP keys are managed in the /etc/network/interfaces file using
"wireless-key" lines.  However, WEP is notoriously insecure, and I think that
GNOME would be well advised to think about how to offer some sort of WPA
offering.  wpa_supplicant is as far as I can see the dominant implementation for
WPA, but I know there are others (such as hostapd).  If wpa_supplicant remains a
dominant implementation of WPA, then maybe it is a good candidate for
integration into G-S-T.

Okay, so here's what changes when wpa_supplicant is introduced.  wpa_supplicant
is run as a daemon, for instance via

    /usr/sbin/wpa_supplicant -B -i eth1 -D ipw -c /etc/wpa_supplicant.conf -w

As you can see, the location of the configuration for wpa_supplicant is not set
in stone.  The Debian package /does/ set up the wpa_supplicant.conf in /etc, but
wpa_supplicant is new enough that there's no strong motivation to keep it there
as a matter of policy.  For that matter, there's nothing really even strongly
binding the name this configuration file.  

The configuration file /can/ be changed while wpa_supplicant is running, but a
'killall -HUP wpa_supplicant' must be run to have wpa_supplicant recognize the
new changes.

The grammar for the configuration file is not rigorously documented in a man
page, but the authors provide a heavily commented example file with many example
configurations.  The grammar for simple options of wpa_supplicant is pretty
straight-forward -- just a keyword followed by some argument(s).  However,
wpa_supplicant's configuration file sets WPA for various Access Points (APs) by
specifying "network block" such as

       network={
           ssid="TNKS' Wireless Network"
           key_mgmt=NONE
           wep_key0=FFFFFFFFFFFFFFFFFFFFFFFFF
           priority=1
       }

       network={
           ssid="Zisson"
           proto=WPA
           key_mgmt=WPA-PSK
           psk="Secret Password"
           priority=1
       }

       ### Associate with any open access point
       network={
           ssid=""
           key_mgmt=NONE
           priority=0
       }

As you can see, these network blocks subsume a good portion of the functionality
of the "iface" stanzas in /etc/network/interfaces, supporting not only WPA, but
also WEP key management.  You still need "iface" stanzas, but generally you
don't make a new one for every AP (indivdual APs are specified in wpa_supplicant
network blocks instead).  Rather, "iface" stanzas have just
location/profile-specific lines, like dns-nameservers and dns-search.  What
wpa_supplicant does is scan the available APs (or checks for known networks if
configured to do so); the best network is then chosen on basis of a simple
formula that involves the level of security and the specified priority. 
wpa_supplicant is pretty good about rolling AP association in the event that,
say, a laptop is moved out of one AP's range and into another's.  The network
doesn't even need to be brought down and back up.  It has some hiccups, though,
and occasionally requires a 'killall -HUP wpa_supplicant' to jump-start AP
association.  

So finally, you can see that if G-S-T's network-admin is to really support
wpa_supplicant well, there should be a good deal of modification not only to the
front-end, but also to the back-end.  Given detection of wpa_supplicant's
installation on a system, it makes more sense to store AP-specific information
in wpa_supplicant's configuration file's network blocks (instead of
/etc/network/interfaces).  Non-wpa_supplicant systems, though, still need to be
supported in roughly the same manner as they are now.

Well, that's about it.  I know this discussion is on the verge of interminable,
but hopefully it provided some information for those not sure what it takes to
integrate wpa_supplicant into G-S-T.
Comment 2 Daniel Holbach 2005-10-20 09:13:52 UTC
http://bugzilla.ubuntu.com/show_bug.cgi?id=18151 has another request for it.
Comment 3 gbauman 2006-03-27 21:20:49 UTC
There have been some changes to the way wpa_supplicant is invoked in Debian and by proxy, Ubuntu. It's gotten a whole lot simpler.

Instead of dealing with /etc/default/wpasupplicant and /etc/wpasupplicant.conf, and starting wpa_supplicant from init.d, now all we need to do is edit /etc/network/interfaces as follows:

iface wlan0 inet dhcp
        wpa-driver yourdriver
        wpa-ssid MyCoolNetwork
        wpa-psk 685bac1393023d......

Perhaps this kind of setup would make it easier to get some kind of WPA support into the backends?
Comment 4 Reinhard Tartler 2006-04-08 10:22:28 UTC
This change is now in both debian and ubuntu, I expect other derivatives to merge this ifupdown integration as well.

Providing support for WPA should be now work quite like support for WEP secured networks.

If you have any questions or problems with the new ifupdown integration of wpasupplicant, do not hesitate to ask me as maintainer for wpasupplicant in debian/ubuntu.
Comment 5 Maxim Burgerhout 2006-04-23 07:12:35 UTC
It would be welcome if network-admin could also be used to set up WPA for cards based on rt2500 (and possibly other rt2??0) chipsets, which have built-in WPA and do not need to use wpa_supplicant. I'm not sure whether using wpa_supplicant is at all possible with such a card.

WPA can be used with a rt2500 card by issueing the following commands on my computer:

ifconfig ra0 up
iwconfig ra0 channel the_channel_one_uses
iwpriv ra0 set SSID=the_essid_one_uses
iwpriv ra0 set NetworkType=Infra
iwpriv ra0 set AuthMode=WPAPSK
iwpriv ra0 set EncrypType=TKIP
iwpriv ra0 set WPAPSK="the_psk_one_uses"
dhclient ra0

I am aware the "iwpriv ... set" combination is not correct. It does however work, without the need of running wpa_supplicant.

Maybe other cards exist which do not need wpa_supplicant. Being able to setup WPA for cards like this in network-admin would be a great feature.
Comment 6 Maxim Burgerhout 2006-05-22 14:53:03 UTC
The rt2400, rt2500 and rt2570 modules from http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page can NOT work with wpa_supplicant. I read a short conversation on networkmanager-list gnome org the other day in which Pete O'Grady made clear you need wpa_supplicant in order to do gui configuration of wpa wireless cards in gnome.

This basically rules out using a card that uses one of these modules above. Luckily, the new and yet experimental module from the same site (rt2x00) should be able to do wpa_supplicant. 

Just so yall know ;-)

Conversation on nerworkmanager-list is here: http://mail.gnome.org/archives/networkmanager-list/2006-February/msg00038.html
Comment 7 Reinhard Tartler 2006-05-22 15:18:52 UTC
(In reply to comment #6)
> The rt2400, rt2500 and rt2570 modules from
> http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page can NOT work with
> wpa_supplicant. 

I'm not sure how relevant this comment is for this bug, because this is a bug in rt2x00 driver, which I expect to be fixed some time in the future. Most nearly all wifi drivers under linux work with wpasupplicant, most of them with the driver backend 'wext'. Debian uses 'wext' by default, which can be overriden by the 'wpa-driver' stanza.

In fact, wpasupplicant should be able to do even static wep encryption with every card. Cards which don't work indicate bugs in the drivers: They do not implement Linux Wireless extensions completly 

Comment 8 Sven Arvidsson 2007-04-24 16:15:44 UTC
Isn't this bug solved by the NM integration?
Comment 9 Carlos Garnacho 2007-07-05 23:45:27 UTC
I've added basic wpa/wpa2 psk encryption support in system-tools-backends, at the moment it just works for debian-like distros, if someone wants explicit support for other distros, I accept patches :), or at least some indications about the configuration format, but at the moment other distros just won't show the option. Marking as FIXED

@Sven, IMHO the n-m integration is quite loose, so it's worth having this option in g-s-t
Comment 10 Reinhard Tartler 2007-10-25 12:16:35 UTC
(In reply to comment #8)
> Isn't this bug solved by the NM integration?

as long as NM doesn't offer to configure static IP, NM cannot be considered as a replacement for g-s-t in usecases where you need that.