v1.0.4: More solid connection

• clearer error reporting when connection fails
• cleanup Disconnect to remove unnecessary requirements
• even cleaner connection in the command line tool
• fixed AddOrUpdateNetwork some more to account for SSID vs. IDStr

id_str vs. id

These do not refer to the same thing.

From what I've seen, id_str can appear in the wpa_supplicant.conf file to help label a network. This is distinct from the id, which is simply a number wpa_supplicant assigned to the network when it read the configuration file, or when it received changes. The id can change, I suspect, when wpa_supplicant rereads the configuration file. The id_str doesn't change unless you change it.

As such, the original code's emphasis on using id_str to isolate the correct network when performing an update lead to a lot of confusion for me. I found it made more sense to search for this, then search for the SSID. I may have more work to do here yet, though, to make this more solid; none of my production code uses the id_str at the moment, but I might want to consider its use later.

For now, I think some of the changes I made here make it much easier to connect correctly to the desired networks.

connecting to a network

Trial and error taught me that if the interface's status is not already set to 'Disconnected', we should probably Disconnect before attempting a connection. This prevents some odd problems I saw where it seemed like the code would spin off into an infinite wait state or the like. At the very least, in my testing, this code allowed me to attempt back-to-back connections and get expected results each time... something that I couldn't get with the original code, nor with my previous modifications.

Disconnect cleanup

I think I was a tad confused when I made this function. I was following another pattern, and failed to notice that the connection didn't need a network at all... you can simply call DISCONNECT to make it stop SCANNING and ASSOCIATING, preferring to rest at a DISCONNECTED state. I haven't tried calling it when it's already DISCONNECTed... it'd be nice if it read success when you did that, but I wouldn't be surprised if it gave me an error because you can't disconnect from a disconnected interface or the like.

Clearer error reporting on connection failures

The simple 'FAIL' wasn't quite good enough, so I added a Wrap to tell me what failed. This immediately helped me zero in on the problems that lead to changes with IDStr in UpdateNetwork.