Re: Best place to discuss other lightweight libraries?

[Rich Felker <dalias@aerifal.cx>]

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...

> 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.
2. Managing keys.
3. Logic for what to do when signal is lost.
4. Automating nonsense click-through agreements on public wifi.
...

The existing solutions all manage the above very poorly. Respectively,
they have:

1. No way to manage network priority/preference order.
2. Annoying popups to ask for key rather than having it be part of the
configuration of the network, and storing the keys in obscure places.
3. Annoying network-hopping.
4. Minimal or no auto-click-through; even when it does work, you can
get burned if your web browser happens to attempt a load before it
succeeds. A correct one needs to encapsulate the connection somehow so
that no connection is exposed to the user at all until the
click-through succeeds.

Rich