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 connman@connman.net http://lists.connman.net/listinfo/connman