Re: Best place to discuss other lightweight libraries?

[idunham@lavabit.com]

On Tue, Apr 23, 2013 at 09:47:24AM -0400, Rich Felker wrote:
> On Mon, Apr 22, 2013 at 10:04:30PM -0700, Isaac Dunham wrote:
> > On Mon, 22 Apr 2013 21:46:40 -0400
> > Rich Felker <dalias@aerifal.cx> wrote:
> > 
> > > 
> > > > "There's always room for dropbear". And polarssl, and so on.
> > > 
> > > cyassl looked promising too. I would probably mention tomcrypt too
> > > even though it's not sufficient to do SSL; it has the most slim,
> > > clean, portable implementations of crypto algorithms I've seen.
> > 
> > wpa_supplicant can use tomcrypt (external or internal) as fallback
> > if no other encryption method (ie, openssl/gnutls) is configured, so
> > I'd say it merits a mention.
> 
> In that case I don't even see why they bother including the code to
> use openssl/gnutls...

There are one or two features that need to be disabled to use tomcrypt.
I wish I could remember what they were.  But upstream has provided many
options that only duplicate functionality with additional bloat.
(sockets and plain C, vs. DBUS + glib)

> > I wonder if some notes should be put somewhere to point out that a
> > network mangler on top of wpa_supplicant is not needed (the learning
> > curve for configuring it is pretty steep, due to the need to find
> > and understand the docs, but wpa_supplicant + wpa_cli -a script +
> > wpa_cli in command mode can handle most situations, including dhcp).
> > I mention this because it seems to be "accepted wisdom" (but false)
> > that you need wpa_supplicant as a tool and a network manager to make
> > it useable. And most of the network managers I've encountered are
> > bloat of the highest order: NetworkManager, wicd, wifiradar... But
> > this might be better put somewhere else.
> 
> Well the accepted wisdom is "almost true": for practical use of mobile
> wifi, you need not just wpa_supplicant but also some controlling
> process that's capable of:
> 
> 1. Choosing which network to connect to.
Oh, like wpa_cli select_network ?

> 2. Managing keys.

wpa_cli [ passphrase | otp | password | new_password | pin | wps_pbc ]
(though figuring it out may be difficult, even with the help messages)

> 3. Logic for what to do when signal is lost.
wpa_supplicant reassociates on non-user-specified disconnects, and
wpa_cli -a <script>
allows configuration of the commands to run on CONNECTED and
DISCONNECTED events.

> 4. Automating nonsense click-through agreements on public wifi.
> ...

Nothing for this, as far as I know.  (On the other hand, I tend to dislike
software that pretends that I agreed to something I never saw.
Weird, I know ;-). )

> The existing solutions all manage the above very poorly...
What's worse is how some of them handle changing networks.

wpa_supplicant comes with wpa_cli for a reason: you need to be able to
tell the existing process to change its configuration.
The WRONG way to do things is to create a new config file, start a new 
instance of wpa_supplicant using that config file, and leave the old
wpa_supplicant running.
(wicd, I hope you've figured that out by now.)

Of course, setting up wpa_supplicant so that wpa_cli works is not easy.
And while wpa_gui (the Qt interface that corresponds to wpa_cli) is
available, it needs as much preconfiguration as wpa_cli, and the UI
could use some improvement before it's easy to understand (I can follow
it readily, but that's after using wpa_cli without anything else for a year or
two).  
A tool capable of producing a functional wpa_supplicant.conf and
providing a gui corresponding to wpa_cli in functionality would handle
most scenarios.
Unfortunately, the existing tools tend not to do that; I should see how
ceni works sometime-it's the only one I know of and haven't tried yet.

--
Isaac Dunham