Re: network roaming convenience
On 2014/07/21 17:17, Charles Musser wrote: 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? It prints the status, iwn0: flags=8847UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 8c:70:5a:62:b7:f8 priority: 4 groups: wlan egress media: IEEE802.11 autoselect (DS1 mode 11g) status: active ieee80211: nwid TP-LINK_8F014A chan 6 bssid f8:1a:67:8f:01:4a 189dB then there's a 30 second pause during which the led flashes, then ifconfig exits without further output. Then I have to ifconfig iwn0 down, ifconfig iwn0 up, and start dhclient again which has exited due to the interface state change If I have previously set ifconfig iwn0 debug, when the scan is started I see some beacon and probe_resp initially, then a bunch of received beacon (10 a second or so) which continues after ifconfig exits until I down the interface. dmesg below, fwiw (this is an x220). (I also need down+up if I use the rf kill switch on my laptop). Jul 22 08:40:13 bamboo /bsd: iwn0: received beacon from f8:1a:67:8f:01:4a rssi -67 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received probe_resp from 00:27:22:8e:72:3e rssi -46 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -68 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received beacon from f8:1a:67:8f:01:4a rssi -68 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -68 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -69 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -69 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -68 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -68 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received beacon from 00:27:22:8e:72:3e rssi -48 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received beacon from f8:1a:67:8f:01:4a rssi -68 mode 11g Jul 22 08:40:13 bamboo /bsd: iwn0: received beacon from f8:1a:67:8f:01:4a rssi -67 mode 11g Jul 22 08:40:13 bamboo last message repeated 2 times Jul 22 08:40:13 bamboo /bsd: iwn0: received beacon from f8:1a:67:8f:01:4a rssi -68 mode 11g snip Jul 22 08:40:49 bamboo /bsd: iwn0: received beacon from f8:1a:67:8f:01:4a rssi -67 mode 11g Jul 22 08:40:49 bamboo /bsd: iwn0: received beacon from f8:1a:67:8f:01:4a rssi -66 mode 11g Jul 22 08:40:49 bamboo /bsd: iwn0: received beacon from f8:1a:67:8f:01:4a rssi -67 mode 11g ifconfig down at 08:40:49 ifconfig up at 08:41:03 and it reconnects Jul 22 08:41:03 bamboo /bsd: iwn0: begin active scan Jul 22 08:41:03 bamboo /bsd: iwn0: received probe_resp from 00:27:22:8e:72:3e rssi -55 mode 11g Jul 22 08:41:03 bamboo /bsd: iwn0: received probe_resp from 00:27:22:8e:72:3e rssi -49 mode 11g Jul 22 08:41:03 bamboo /bsd: iwn0: received beacon from f8:1a:67:8f:01:4a rssi -70 mode 11g Jul 22 08:41:03 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -67 mode 11g Jul 22 08:41:03 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -67 mode 11g Jul 22 08:41:03 bamboo /bsd: iwn0: received beacon from 00:27:22:8e:72:3e rssi -49 mode 11g Jul 22 08:41:03 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -67 mode 11g Jul 22 08:41:03 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -68 mode 11g Jul 22 08:41:03 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -69 mode 11g Jul 22 08:41:03 bamboo /bsd: iwn0: received probe_resp from f8:1a:67:8f:01:4a rssi -66 mode 11g Jul 22 08:41:03 bamboo /bsd: iwn0: received beacon from f8:1a:67:8f:01:4a rssi -73 mode 11g Jul 22 08:41:06 bamboo /bsd: iwn0: end active scan Jul 22 08:41:06 bamboo /bsd: iwn0: sending auth to f8:1a:67:8f:01:4a on channel 6 mode 11g Jul 22 08:41:06 bamboo /bsd: iwn0: sending assoc_req to f8:1a:67:8f:01:4a on channel 6 mode 11g Jul 22 08:41:06 bamboo /bsd: iwn0: received auth from f8:1a:67:8f:01:4a rssi -66 mode 11g Jul 22 08:41:06 bamboo /bsd: iwn0: associated with f8:1a:67:8f:01:4a ssid TP-LINK_8F014A channel 6 start 1Mb long preamble short slot time Jul 22 08:41:06 bamboo /bsd: iwn0: received assoc_resp from f8:1a:67:8f:01:4a rssi -69 mode 11g Does this mean you’re flying blind when you parachute in somewhere and want to know what wi-fi networks are around? If I'm going in somewhere new I tend to just use my phone to connect and don't even bother starting up the laptop unless I particularly need
Re: network roaming convenience
On Jul 22, 2014, at 12:59 AM, Stuart Henderson s...@spacehopper.org wrote: Out of curiosity, what happens? It prints the status, iwn0: flags=8847UP,BROADCAST,DEBUG,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 8c:70:5a:62:b7:f8 priority: 4 groups: wlan egress media: IEEE802.11 autoselect (DS1 mode 11g) status: active ieee80211: nwid TP-LINK_8F014A chan 6 bssid f8:1a:67:8f:01:4a 189dB then there's a 30 second pause during which the led flashes, then ifconfig exits without further output. Then I have to ifconfig iwn0 down, ifconfig iwn0 up, and start dhclient again which has exited due to the interface state change Yeah, that is interesting. I didnt really notice it before, but scan doesnt return anything if Im connected to my network, but the act of doing it changes the status from active to no network. Then it returns a list if invoked again. I thought I might run scan periodically to check connectivity, but the act of doing so seems to knock me off the air. A related wrinkle is that the status never changes to no network if the AP is powered off. So you cant check actively (with scan anyway) and you cant be informed passively if youve moved out of range. Darn. About the only thing I noticed was that the mode listed in the media line changes. Not sure thats actually indicative of anything While I don't dispute that this behaviour is a bug, it doesn't seem right for the script to be doing this, surely if you know the password you should also know if wep is needed? It would seem safer generally to only use the expected protocol. True. wiconfigs author is open to changing how this works. Apparently, in an upcoming OBSD release, ifconfig will display the security offered by the AP. Do you need a full reboot at this point, or does restarting the interface (ifconfig down+up) work? Do you get anything interesting (look in /var/log/messages) if ifconfig iwn0 debug is set? Turns out, no. What I needed to do was clear the WEP key (by using the -nwkey parameter) and then the interface was usable. A subsequent ifconfig with wpakey specified got me connected.
Re: network roaming convenience
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.
Re: network roaming convenience
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...
network roaming convenience
Hi, I'm looking to create or cobble together functionality that automates network connections as a user roams around with a laptop. The idea is to respond to changing network availability: wifi network is known, so connect, or cable was plugged in, or connect for the first time and remember, etc). On Linux, this is provided by program called NetworkManager. I'm pretty sure it's are Linux-specific and, anyway, it depends on DBus (a separate messaging system). I was hoping to create something a little more self contained. I did explore a couple of avenues. One was the wiconfig script mentioned on Undeadly a while back. This didn't connect, seemingly because it tried to use WEP, not WPA. I didn't want to debug a shell script to find out why. Another possibility is using ifstated. However it looks like WiFi interfaces are always up, even in the no network state, so it's unclear whether the required state transitions would actually happen But I haven't verified that, so I can't dismiss this as a solution. An argument could be made that this is of marginal utilty. How hard is it to use ifconfig, anyway? But I figured it might be an interesting exercise and may be a nice convenience. Any advice, or discussion would be appreciated. Chuck
Re: network roaming convenience
On Thu, Jul 17, 2014 at 1:51 PM, Charles Musser cmus...@sonic.net wrote: I'm looking to create or cobble together functionality that automates network connections as a user roams around with a laptop. The idea is to respond to changing network availability: wifi network is known, so connect, or cable was plugged in, or connect for the first time and remember, etc). On Linux, this is provided by program called NetworkManager. I'm pretty sure it's are Linux-specific and, anyway, it depends on DBus (a separate messaging system). I was hoping to create something a little more self contained. I did explore a couple of avenues. One was the wiconfig script mentioned on Undeadly a while back. This didn't connect, seemingly because it tried to use WEP, not WPA. I didn't want to debug a shell script to find out why. 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. An argument could be made that this is of marginal utilty. How hard is it to use ifconfig, anyway? But I figured it might be an interesting exercise and may be a nice convenience. Any advice, or discussion would be appreciated. Have you taken a look at beck@'s wifinwid at http://undeadly.org/cgi?action=articlesid=20130208141628? FWIW, there's a GSoC for a NetworkManager at http://www.openbsdfoundation.org/gsoc2014.html, but I don't know it's gotten any love.
