On 12/31/10 11:17 AM, Grant Erickson wrote:
> On 12/31/10 9:21 AM, Grant Erickson wrote:
>> On 12/31/10 8:05 AM, Grant Erickson wrote:
>>> On 12/30/10 12:25 PM, Marcel Holtmann wrote:
>>>>> 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.
>>>>
>>>> So it seems there is a bug somewhere that leads to creating these twice
>>>> and then confuse the system. This needs to be fixed, but I don't see
>>>> that one right now.
>> 
>> As I debug this further, in two debugging trials running connman in the
>> foreground with '-d' asserted, I found two blocks in the logs for each trial
>> that might be informative.
>> 
>> It appears that the code path for hidden networks gets triggered from
>> connect_service(), even though this "linksys" SSID / BSSID is not a hidden
>> network and is clearly broadcasting its SSID.
> 
> As far as I can see, the root cause of the problem seems to be the two
> independent and slightly different group creation routines. The first:
> 
>     connman-0.64/plugins/supplicant.c:static char *build_group(...);
> 
> which has the handling for "special" SSIDs and the second:
> 
>     connman-0.64/src/wifi.c:char *connman_wifi_build_group_name(...);
> 
> which lacks this special handling. I'll look at unifying these.

Looking at the code further, it appears that there are two D-Bus interface
entry points for connecting to services: the manager interface and the
service interface.

At present, the user interface in question for this bug uses the manager
interface which then funnels into manager.c:connect_service() which then
funnels into service.c:__connman_service_create_and_connect().

Unfortunately, in __connman_service_create_and_connect() there does not
appear to exist enough information to correctly call a theoretically-unified
connman_wifi_create_group_name() which would need the network identifier and
name and which are also not yet retrievable given the available information
when __connman_service_create_and_connect is called.

The other alternative might be to get the service path from the D-Bus
message; however, that appears to be "/", which is of no utility for looking
up the service.

Which is the preferred/correct interface for requesting service connections,
service or manager?

Regards,

Grant


_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman

Reply via email to