Hi Eduardo,
When interface was already created in wpa_supplicant,
p2p detection was failing. Thus, calling p2p detection
after interface property has been signaled fixes this
detection failure.
Wpa_supplicant should not create interface before ConnMan asks for it.
The only case when it does
Hi,
peer-groups store group's path, not GSupplicantGroup, so get it
from group_mapping
Of course... Don't ask me why I introduced this bug. Nice catch.
@Patrik: Apply that patch in priority please!
Thanks,
Tomasz
___
connman mailing list
Hi Eduardo,
ACK
Left over from first patch-set and second patch-set.
Thanks,
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Hi Eduardo,
That's a very old left over!
ACK
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
On Thu, Aug 7, 2014 at 8:21 AM, Tomasz Bursztyka
tomasz.burszt...@linux.intel.com wrote:
When interface was already created in wpa_supplicant,
p2p detection was failing. Thus, calling p2p detection
after interface property has been signaled fixes this
detection failure.
Wpa_supplicant
Hi Richard,
Wpa_supplicant should not create interface before ConnMan asks for it.
The only case when it does so, is when it creates the virtual p2p interface,
on that one we don't care to check any support.
What if connman is restarted while wpa_supplicant is still running?
When connman
On Thu, 2014-08-07 at 09:35 +0800, Guoqiang Liu wrote:
From: Guoqiang Liu guoqiang@archermind.com
peer-groups store group's path, not GSupplicantGroup, so get it
from group_mapping
Applied, thanks!
Patrik
___
connman mailing list
On Wed, 2014-08-06 at 23:58 -0400, Eduardo Abinader wrote:
Removing a previous interface assignment, although the correct value
was assigned at last.
Applied, thanks!
Patrik
___
connman mailing list
connman@connman.net
On Wed, 2014-08-06 at 23:31 -0400, Eduardo Abinader wrote:
Just code cleaning a meaningless return on the last
line of a void function.
Applied, thanks!
Patrik
___
connman mailing list
connman@connman.net
It can happen that, after a unproper ConnMan exit, a device is still up.
Once ConnMan is restarted cleanup_devices() will put this device down.
But then, it will never set it up again.
04:08:45 connmand[254]: src/device.c:__connman_device_init()
04:08:45 connmand[254]:
It can happen that, after a unproper ConnMan exit, a device is still up.
Once ConnMan is restarted cleanup_devices() will put this device down.
But then, it will never set it up again.
04:08:45 connmand[254]: src/device.c:__connman_device_init()
04:08:45 connmand[254]:
On Thu, Aug 7, 2014 at 11:05 AM, Tomasz Bursztyka
tomasz.burszt...@linux.intel.com wrote:
It can happen that, after a unproper ConnMan exit, a device is still up.
Once ConnMan is restarted cleanup_devices() will put this device down.
But then, it will never set it up again.
04:08:45
Hi Eduardo,
Finally it seems possible for connman to sync up with wpa_supplicant and
existing interface
(see patch [PATCH v2] device: Make sure the device is up and running
before enabling it and logs
from Richard Röjfors http://pastebin.com/4Bsk5B2N )
So ACK to this patch!
Tomasz
Good news!
Thanks, Tomasz.
On Thu, Aug 7, 2014 at 7:43 AM, Tomasz Bursztyka
tomasz.burszt...@linux.intel.com wrote:
Hi Eduardo,
Finally it seems possible for connman to sync up with wpa_supplicant and
existing interface
(see patch [PATCH v2] device: Make sure the device is up and running
14 matches
Mail list logo