Date: Tue, 23 Apr 2013 17:50:26 -0700 From: idunham@...abit.com To: musl@...ts.openwall.com Subject: Re: Best place to discuss other lightweight libraries? 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@...ifal.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.