Le 01/09/2015 04:10, Isaac Dunham a écrit :
On Mon, Aug 31, 2015 at 09:38:12AM +0200, Didier Kryn wrote:
Sorry, this thread became private my my mis-clicking on Icedove.
Le 30/08/2015 22:37, Isaac Dunham a écrit :
On Sun, Aug 30, 2015 at 12:58:59PM +0200, Didier Kryn wrote:
Le 28/08/2015 04:28, Isaac Dunham a ??crit :
I could make something similar to wpa_config but using wpa_cli more
rather than writing a config file; *however*, this would be harder to
edit and would lose comments if you make the changes permanent.
wpa_gui works by interaction with wpa_supplicant, through the control
socket, I guess, and the changes can be made permanent.
Actually I am perfectly happy with wpa_gui; it is just perfect; I don't need
anything else on my laptop. But some people consider that Qt is too big, and
I agree that a lighter version with the same functionality is always a
progress. Also a version working without X windows, but still GUI-like (ie
ncurses), could be usefull.
wpa_gui works through the control socket, as does wpa_cli.
If you "make the changes permanent", you send a command over the control
socket that writes out the in-memory config.
Comments are not part of that in-memory config, so you will lose them.
dialog is an ncurses-based tool for the "GUI-like" interface you mentioned.
So the only thing which this UI would miss is that it couldn't put
comments in the config file. I agree that most ESSIDs have no meaning and
therefore motivate a description. This is a minor problem which no UI
currently addresses. I don't think a comment is the proper method to do
that. Comments are meant for humans who read the file, not for use by
applications. What is missing is a formal field which could be called
'description' and should be managed by wpa_supplicant.
To summarize, I see three possibilities
1) hack wpa_supplicant.conf from the UI to put a specially formatted
comment. Very bad for the reason explained above and because it needs root
permission and incurs race conditions with wpa_supplicant itself.
2) put the load on the user: let him choose or ask for sensible ESSIDs.
3) patch wpa_supplicant so that it accepts and stores a description
phrase for every ESSID.
Things could be staged: 2, then 3. And 3 might be just a request to the
author of wpa_supplicant. What do you think?
I'm *not* saying that I'd like to be able to *write* comments.
In fact, I don't want to write any comments that aren't important for the
person who edits wpa_supplicant.conf manually, and wpa_config currently
doesn't write any comments except the ones wpa_passphrase makes.
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.
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.
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.
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.
As you understand, my philosophy is that the UI should not try to
do difficult things like preserving comments in the config file (a whole
project in itself), nor tricky things such as modifying root-owned
files, with possible race conditions in addition. This way it can be
kept simple, small and secure.
I have learnt with time to not jump into the text editor to write a
program before a carefull maturation of what it should do and how, and
it seems to be your philosophy as well. So thank-you for your patience,
and thank-you for this usefull discussion. I will eventually write this
UI, given some time, unless you do a good one before :-)
Didier
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
