Re: wpa_supplicant gets points for trying, I suppose....
On Tuesday, November 02, 2010 22:55:18 David Wolfskill wrote: On Tue, Nov 02, 2010 at 06:30:10PM +0100, Bernhard Schmidt wrote: Thanks. I had quick look into that and I currently do not see an easy way to address that issue, as in tell wpa_supplicant about the device's state. This might change though once a newer wpa_supplicant has been imported. I'm not entirely surprised -- a quick look I took at sys/dev/iwn seemed to indicate to me that whiule iwn(4) could whine about the switch, it didn't have much in the way of ability to actually provide information about that status in some other way (e.g., a non-zero return from attempt to mess with the device). But I don't claim extensive expertise in that area. There is ieee80211_notify_radio(), granted iwn(4) misses the calls.. that function is supposed to notify upper layers about the radio state (0 = off, 1 = on). Anyways, once wpa_supplicant import/update is done, I'll probably have a look into that again. For now just add wpa_supplicant_flags=- to rc.conf. : :-} That, or decide to ignore the silly messages Noted, thanks. Peace, david -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant gets points for trying, I suppose....
On Wed, Nov 03, 2010 at 08:27:02AM +0100, Bernhard Schmidt wrote: ... There is ieee80211_notify_radio(), granted iwn(4) misses the calls.. that function is supposed to notify upper layers about the radio state (0 = off, 1 = on). Anyways, once wpa_supplicant import/update is done, I'll probably have a look into that again. Cool. If you want/need testing, I'll be happy to help. :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpuH2SpqAw5Z.pgp Description: PGP signature
Re: wpa_supplicant gets points for trying, I suppose....
On Monday, November 01, 2010 23:32:49 Paul B Mahol wrote: On 11/1/10, David Wolfskill da...@catwhisker.org wrote: FreeBSD 9.0-CURRENT #31 r214621M Nov 1 15:09:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:10:10 d130 last message repeated 3 times Nov 1 15:10:50 d130 last message repeated 4 times ... Nov 1 15:11:00 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:10 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:20 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:30 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:50 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:12:10 d130 last message repeated 2 times Nov 1 15:14:10 d130 last message repeated 12 times I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? I don't recall stable/8 doing this, though I could be wrong. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? I don't recall stable/8 doing this, though I could be wrong. Next time I booted stable/8, I checked /var/log/messages, and verified that wpa_supplicant is also persistent in that environment. So I did the above within script(1); I've attached a copy of the typescript file. This was done while running: FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. Script started on Tue Nov 2 08:45:28 2010 d130# ps axwwl | grep wpa_s 0 3528 3523 0 45 0 3500 1240 piperd S+180:00.01 grep wpa_s d130# wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d Initializing interface 'wlan0' conf '/etc/wpa_supplicant.conf' driver 'bsd' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' - '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' Priority group 93 id=17 ssid='lmdhw-net' id=18 ssid='lmdhw-net' Priority group 85 id=19 ssid='NETGEAR' id=20 ssid='wifi' Priority group 17 id=0 ssid='DojoTest' Priority group 16 id=1 ssid='HackerDojoDownstairs' id=2 ssid='HackerDojoUpstairs' id=3 ssid='LINKEDIN-GUEST' id=4 ssid='LINKEDIN-GUEST' id=5 ssid='LINKEDIN-GUEST' id=6 ssid='LINKEDIN-GUEST' id=7 ssid='LINKEDIN-GUEST' id=8 ssid='LINKEDIN-GUEST' id=9 ssid='LINKEDIN-GUEST' id=10 ssid='LINKEDIN-GUEST' id=11 ssid='LINKEDIN-GUEST' id=12 ssid='LINKEDIN-GUEST' id=13 ssid='LINKEDIN-GUEST' id=14 ssid='LINKEDIN-GUEST' id=15 ssid='LINKEDIN-GUEST' id=16 ssid='LINKEDIN-GUEST' Initializing interface (2) 'wlan0' Own MAC address: 00:21:6a:26:34:c0 wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 RSN: flushing PMKID list in the driver Setting scan request: 0 sec 10 usec EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED Added interface wlan0 State: DISCONNECTED - SCANNING Starting AP scan (broadcast SSID) Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (0 BSSes) Scan results: 0 Cached scan results are empty - not posting Selecting BSS from priority group 93 Try to find WPA-enabled AP Try to find non-WPA AP Selecting BSS from priority group 85 Try to find WPA-enabled AP Try to find non-WPA AP Selecting BSS from priority group 17 Try to find WPA-enabled AP Try to find non-WPA AP Selecting BSS from priority group 16 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec EAPOL: disable timer tick Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID) ioctl[SIOCS80211, op 103, len 128]: Device not configured Failed to initiate AP scan. Setting scan request: 10 sec 0 usec Starting AP scan (broadcast SSID)
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 2, 2010 at 16:53, David Wolfskill da...@catwhisker.org wrote: On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? I don't recall stable/8 doing this, though I could be wrong. Next time I booted stable/8, I checked /var/log/messages, and verified that wpa_supplicant is also persistent in that environment. So I did the above within script(1); I've attached a copy of the typescript file. This was done while running: FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 Thanks. I had quick look into that and I currently do not see an easy way to address that issue, as in tell wpa_supplicant about the device's state. This might change though once a newer wpa_supplicant has been imported. For now just add wpa_supplicant_flags=- to rc.conf. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 2, 2010 at 10:30 AM, Bernhard Schmidt bschm...@freebsd.org wrote: On Tue, Nov 2, 2010 at 16:53, David Wolfskill da...@catwhisker.org wrote: On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? I don't recall stable/8 doing this, though I could be wrong. Next time I booted stable/8, I checked /var/log/messages, and verified that wpa_supplicant is also persistent in that environment. So I did the above within script(1); I've attached a copy of the typescript file. This was done while running: FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 Thanks. I had quick look into that and I currently do not see an easy way to address that issue, as in tell wpa_supplicant about the device's state. This might change though once a newer wpa_supplicant has been imported. For now just add wpa_supplicant_flags=- to rc.conf. Device states could and should be periodically polled via the SIOCGIFMEDIA ioctl, but currently isn't (even in the CURRENT version of wpa_supplicant). This seems like a worthy enhancement. Cheers, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 2, 2010 at 19:06, Garrett Cooper gcoo...@freebsd.org wrote: On Tue, Nov 2, 2010 at 10:30 AM, Bernhard Schmidt bschm...@freebsd.org wrote: On Tue, Nov 2, 2010 at 16:53, David Wolfskill da...@catwhisker.org wrote: On Tue, Nov 02, 2010 at 08:40:54AM +0100, Bernhard Schmidt wrote: I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? Well, that should actually be the case. I don't see how it might differ between stable/8 and head. Can you post the output of wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -d while the RF kill button is in disabled state? I don't recall stable/8 doing this, though I could be wrong. Next time I booted stable/8, I checked /var/log/messages, and verified that wpa_supplicant is also persistent in that environment. So I did the above within script(1); I've attached a copy of the typescript file. This was done while running: FreeBSD 8.1-STABLE #20 r214672: Tue Nov 2 04:19:13 PDT 2010 Thanks. I had quick look into that and I currently do not see an easy way to address that issue, as in tell wpa_supplicant about the device's state. This might change though once a newer wpa_supplicant has been imported. For now just add wpa_supplicant_flags=- to rc.conf. Device states could and should be periodically polled via the SIOCGIFMEDIA ioctl, but currently isn't (even in the CURRENT version of wpa_supplicant). This seems like a worthy enhancement. Not necessarily, we have a event based facility for that, the functions are empty though because the consumer, wpa_supplicant, is not able to make any use of it. There were some changes in 0.7 for interface states but I'm not sure what exactly changed, it might be possible to use events for the 'rfkill on' case, the 'rfkill off' might still need polling.. Once Rui has imported the new wpa stuff, someone should implemented the proper calls :) -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: wpa_supplicant gets points for trying, I suppose....
On Tue, Nov 02, 2010 at 06:30:10PM +0100, Bernhard Schmidt wrote: Thanks. I had quick look into that and I currently do not see an easy way to address that issue, as in tell wpa_supplicant about the device's state. This might change though once a newer wpa_supplicant has been imported. I'm not entirely surprised -- a quick look I took at sys/dev/iwn seemed to indicate to me that whiule iwn(4) could whine about the switch, it didn't have much in the way of ability to actually provide information about that status in some other way (e.g., a non-zero return from attempt to mess with the device). But I don't claim extensive expertise in that area. For now just add wpa_supplicant_flags=- to rc.conf. :-} That, or decide to ignore the silly messages Noted, thanks. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpUWaGmedrbL.pgp Description: PGP signature
Re: wpa_supplicant gets points for trying, I suppose....
On 11/1/10, David Wolfskill da...@catwhisker.org wrote: FreeBSD 9.0-CURRENT #31 r214621M Nov 1 15:09:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:10:10 d130 last message repeated 3 times Nov 1 15:10:50 d130 last message repeated 4 times ... Nov 1 15:11:00 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:10 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:20 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:11:30 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:40 d130 wpa_supplicant[569]: Failed to initiate AP scan. ... Nov 1 15:11:50 d130 wpa_supplicant[569]: Failed to initiate AP scan. Nov 1 15:12:10 d130 last message repeated 2 times Nov 1 15:14:10 d130 last message repeated 12 times I have the switch on this laptop in position to disable the wireless device (iwn(4)). Is there some way wpa_supplicant (or something) might be able to recognize that this is a pointless exercise? Well iwn could bring device down when radio is turned off and bring it up when radio is turned on ??? I don't recall stable/8 doing this, though I could be wrong. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
