Hi
On Monday 04 April 2011, Sune Vuorela wrote:
> > I do not think that reading documentation before trying to achieve
> > something is that elitist. And in the case of wpa_supplicant, it is
> > definitely not dozens of pages. Basically, it is just
> >
> > man interfaces
> > man wpa_supplicant.conf
> > zless /usr/share/doc/wpasupplicant/README.Debian.gz
>
> I don't consider myself 'stupid user', but I haven't yet been able to
> put my laptop on wpa network without the use of network manager.
The most simple case, one static wlan definition, no roaming:
/etc/network/interfaces:
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid <whatever>
wpa-psk <whatever>
Simple roaming, 2 example networks (with differing priorities) and
catch-all for open networks, this allows automatic roaming between the
defined network setups:
/etc/network/interfaces:
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa-roam.conf
iface home_network inet dhcp
iface my_work_net inet dhcp
iface default inet dhcp
/etc/wpa_supplicant/wpa-roam.conf:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=netdev
network={
priority=25
ssid="whatever"
id_str="home_network"
proto=WPA2
pairwise=CCMP
group=CCMP
psk="whatever"
}
network={
priority=10
ssid="whatever"
id_str="my_work_net"
proto=WPA2
pairwise=CCMP
group=CCMP
psk="whatever"
}
network={
priority=1
ssid=""
key_mgmt=NONE
}
proto, pairwise and group are not really mandatory, but avoid stepping
down to WPA1 or TKIP, if another access point only offers that. psk can
be ASCII- (in quotes) or hexadecimal keys (64 characters). More complex
setups like IEEE8021X, certificates, TTLS/ PAP etc. can be configured
just as well. /usr/share/doc/wpasupplicant/examples/ can help quite a
lot for more exotic setups. ADSL/ PPPoE dial-in setups, in the absence
of routers, aren't much more difficult.
What's so nice about ifupdown (and wpasupplicant integration)?
It simply works with minimal dependencies and can be configured through
your preferred {,cli-} editor, which is an important use case for me.
It doesn't break on changing D-Bus interfaces and doesn't need
functional X11/ D-Bus for configuration or operations, nor breaks ssh
sessions during upgrades.
Besides not using netlink internally, ifupdown's biggest drawback in my
personal opinion is not reacting dynamically to changing connection
methods, like switching from wlan0 to eth0, if an ethernet cable gets
temporarily connected - ifplugd can act as a bandaid here, but is not
overly reliable (and possibly doesn't cover UMTS connections or other
mobile connections either, but I'm not sure about this).
On the other hand n-m isn't an option for server or (quasi-) headless
systems at all, be it due to large dependency chains (there is no D-Bus
or X.org installed on my servers) or simply unreliable operations
during remote upgrades (restarting the interface upon n-m upgrades).
While it's certainly a convenient configuration method for notebook
users, who switch often between different connectivity methods (ADSL/
PPPoE, ethernet, wlan, PPP over bluetooth/ PAN, UMTS/ 3g, WiMAX/ 4g or
different VPN profiles). However for me personally, a "simple" and
dependable ifupdown like solution, which can be configured/ operated
through the cli, and with minimal dependency chains is more important
than a pretty GUI.
Maybe new solutions targetted at the embedded sector, like ConnMan or
the new netlink based network manager planned for OpenWrt, can fill
this void, but personally I doubt network-manager can (or at least
will-) be adapted to work reliably for the afforementioned server like
use cases.
Regards
Stefan Lippers-Hollmann
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104041742.29760.s....@gmx.de
