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
::
Re: [DNG] wpa_supplicant/ifup integ…
