:: Re: [DNG] wpa_supplicant/ifup integ…
Forside
Slet denne besked
Besvar denne besked
Skribent: Isaac Dunham
Dato:  
Til: dng@lists.dyne.org
Emne: Re: [DNG] wpa_supplicant/ifup integration documentation
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.

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.

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.

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.

Hope this helps clarify things.

Thanks,
Isaac Dunham