On Wed, 2015-06-24 at 20:25 -0700, James Zipperer wrote:
> My problem was related to connman using wpa_supplicant in wext mode instead
> of nl80211. No patching required!
Actually, now that nl80211 works for you, you probably should disable
wext support from the kernel(s) to avoid these kind of n
On Wed, 2015-06-24 at 20:25 -0700, James Zipperer wrote:
> My problem was related to connman using wpa_supplicant in wext mode instead
> of nl80211. No patching required!
>
> Wext mode resulted in a WPA AP being selected if it had a higher signal
> strength than a WPA2 AP with the same ssid. nl8
My problem was related to connman using wpa_supplicant in wext mode instead
of nl80211. No patching required!
Wext mode resulted in a WPA AP being selected if it had a higher signal
strength than a WPA2 AP with the same ssid. nl80211 mode selects WPA2
regardless.
On Wed, Jun 24, 2015 at 3:08 P
Actually, my patch doesn't seem to work.
The problem does seem related to how connman is controlling
wpa_supplicant. If I use wpa_cli instead of connman, it seems to make the
right decision about which network to connect to.
Any ideas why using connman would result in choosing the WPA network ov
I think this may solve the problem I am seeing with WFA certification.
Please let me know if this is the right way to solve it. In the case where
both RSN and WPA are available, prefer RSN over WPA.
Thanks!
--
*James Zipperer*
Software Engineer
Synapse Product Development
mail 1511 6th Ave Su
Has anybody passed WFA certification with connman? I'm seeing some tests
fail that I would expect to "just work". For instance: choosing to connect
to an access point with WPA2-encryption over choosing to connect an access
point with the same ssid that has WPA-encryption.
con
