I recently came across a use case in which connmand-0.64 generates two
conflicting network service entries for a wireless access point with an SSID
from the "special" list that ultimately results in not being able to connect
to the SSID at all.
In this scenario, I bring up my user interface to configure and connect to a
network service via the D-Bus interface to connman.
At times, the connection succeeds and other times the connection fails. If
the connection does succeed, on a subsequent reboot, the system will not
connect to the access point.
I've discovered that this all appears to come down to two entries in
/var/lib/connman/default.profile.
The first entry contains the expected key/value pairs from the user
interface connection attempt: Favorite=true, AutoConnect=true and
Passphrase=<...>.
[wifi_000c294c56a2_6c696e6b737973_managed_psk]
Name=linksys
SSID=6c696e6b737973
Favorite=true
Modified=2010-12-29T01:25:15.224273Z
Passphrase=<redacted>
IPv6.method=off
IPv6.netmask_prefixlen=0
IPv4.method=dhcp
IPv4.netmask_prefixlen=0
AutoConnect=true
The second entry, named according to the "special SSID" rules, contains
neither AutoConnect nor Passphrase and has Favorite=false:
[wifi_000c294c56a2_linksys_0012171baf73_managed_psk]
Name=linksys
SSID=6c696e6b737973
Favorite=false
Modified=1970-01-01T00:00:00Z
IPv6.method=off
IPv6.netmask_prefixlen=0
IPv4.method=dhcp
IPv4.netmask_prefixlen=0
I presume the addition of this entry is what is causing these connections to
fail.
Is it expected/correct that both of these entries get created? I can
understand why these special SSID cases might be necessary; however, what
was the original design intent here so I can propose a revised
implementation?
Best,
Grant
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
