On Jul 18, 2014, at 3:09 PM, Stuart Henderson <s...@spacehopper.org> wrote:
> On 2014-07-17, Daniel Melameth <dan...@melameth.com> wrote: >> It should have tried WEP first and, if that failed, WPA. ifconfig in >> -current can now discern WEP or WPA so this can readily be improved. > > ...as long as you have a wifi nic where "ifconfig scan" works, for example > not "Intel Centrino Advanced-N 6205 rev 0x34"... > Out of curiosity, what happens? Does this mean you’re flying blind when you parachute in somewhere and want to know what wi-fi networks are around? On my machine, which uses iwn, “ifconfig scan” does work, but there is an odd behavior that wiconfig happens to trigger, at least in my environment. Configuring the interface for WPA manually (or via hostname.if) works fine, but I had trouble with wiconfig until I increased its connect timeout value. This was due to an odd set of circumstances. wiconfig attempts to configure the interface with WPA, waits for a bit and, if the connection isn’t successful, tries again with WEP. My machine doesn'tt connect within the wiconfig's 3 second timeout interval, and then things get weird. After the second connection attempt (with WEP, using the “nwkey” param), the connect fails again (my AP only does WPA). After this, the interface cannot connect successfully with WPA until after a reboot. I first noticed this behavior with wiconfig and determined what it was doing specifically with help from wiconfig’s author. To confirm what was going on, I issued the same sequence of “ifconfig” invocations manually. Sure enough, an ifconfig with the nwkey parameter was a buzzkill: it prevented connection with a subsequent “ifconfig” invocation: one that certainly works if it is the first ifconfig that happens. This is certainly a corner case, but it did trip me up.
