On Wed, Sep 02, 2015 at 10:05:01AM +0200, Didier Kryn wrote:
> Le 01/09/2015 04:10, Isaac Dunham a écrit :
> >I simply would like to write to the file without *losing* all the comments
> >that are there, which is what will happen if you use
> > wpa_cli save_config
> >or similar features in wpa_gui.
>

>     Consider a file like resolv.conf . Either you write it by hand (and put
> comments at your will) or you let resolvconf write it for you, in which case
> it adds the comment "please do not edit this file". I think the situation is
> similar here: either you edit wpa_supplicant.conf by hand, or you rely on
> some tool to do it. IMHO mixing both behaviours is such a serious burden for
> little need that nobody ever did it for any config file.

Frequently I find myself thinking that a GUI is good for getting things
roughly correct, but it's much more useful to edit it when you want to
fine-tune things.

> >The only race in adding a network is when you (a) start wpa_supplicant,
> >(b) invoke "wpa_cli reconfigure", or (c) use a respawner and have
> >wpa_supplicant randomly crashing, in the midst of writing a new network
> >entry to the config.
> >Writing a new entry to a temp file, then appending it to the config,
> >then reloading, is the most reliable approach, because you can fail much
> >harder by using wpa_cli add_network/set_network/enable/save_config:
> >suppose that wpa_supplicant starts after you start adding a network or
> >crashes/restarts in the midst of it.
>

>     You certainly know this better than me. I was naively thinking "wpa_cli
> add_network" would just pass the command to wpa_supplicant and
> wpa_supplicant was the only process reading/writing the file. Having only
> one process reading/writing the file seems to me a trivial way to avoid race
> conditions; I certainly miss something here.

wpa_supplicant would be the only process reading/writing the file, but
you need five commands at minimum.
Here's roughly how you'd add an open network with wpa_cli:
NETNUM=`wpa_cli add_network` || fail
wpa_cli set_network $NETNUM ssid "$SSID" || fail
wpa_cli set_network $NETNUM key_mgmt NONE || fail
wpa_cli enable_network $NETNUM || fail
wpa_cli save_config || fail

And doing it manually:
cat $CONFIG >$TEMPFILE || fail
echo -e "network={\n\tssid=$SSID\n\tkey_mgmt=NONE\n}\n" >>$TEMPFILE || fail
cp $TEMPFILE $CONFIG


> >Finally, there's one fundamental flaw in wpa_gui, which actually was the
> >initial motive for wpa_config:
> >it's rather exasperating to have a tool to configure a program that won't
> >work until the program is properly configured.
> >The people who most need a tool for configuring wpa_supplicant are those
> >who cannot configure it themselves.
> >This means that wpa_config needs to write out a basic wpa_supplicant.conf
> >itself on request.
>

>     Don't you think this initial file could be created during package
> installation? For wpa_gui as well. It could be re-created with
> dpkg-reconfigure.

Theoretically, it would be nice if this happened when wpa_supplicant
was installed; no other package has a logical reason to provide a
systemwide default config file.
Practically,
(a) no distro that I'm aware of ships wpa_supplicant with a configuration
file, and
(b) I originally wrote it without any expectation of it being properly
packaged; I use a built-from-scratch musl/busybox system frequently,
and this was one of the main targets.


> >I think wpa_id_str is adequate as far as a "description phrase",
> >apart from the fact that you don't want it to be invalid for a logical
> >interface.
>

>     I am pretty sure there are very few cases where a wifi connection needs
> a static IP config. For the vast majority of cases, the config is dynamic
> and one single id_str is enough for all; doing otherwise would bloat the
> interfaces file for the sole sake of this description. By just putting
> "iface default inet dhcp" you cover all cases with dynamic IP config, that
> is 99.99 of cases. This also can be done during package installation.

True.
However, it may be desireable to use multiple configs for some dynamic
configs:
if it's best to use <vpn configuration A> with one network, you can put
that in the post-up field.

Eg:
iface chico inet dhcp
    post-up vpnc --username /etc/vpnc/csuc.conf

(this is how I'd make http://myweb.csuchico.edu/~idunham/csuc-vpn.htm
work with the networking service.)

But in general, I'd assume that people don't need custom configurations,
or special network identification.
After all, the vast majority of UIs don't offer the latter.

Thanks,
Isaac