Re: [PATCH] counter: fix possible memory leak
On Thu, 2015-01-08 at 23:56 +0200, pasi.sjoh...@jolla.com wrote: From: Pasi Sjöholm pasi.sjoh...@jollamobile.com DBusMessage message leaks memory if not cleaned when counter is not found. Applied, thanks! Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] dnsproxy: Don't try to destroy NULL hashtable on exit
On Wed, 2015-01-28 at 22:27 +0200, Slava Monich wrote: glib doesn't like it. Applied, thanks! Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connman test in C#
On 30 January 2015 at 08:29, techi eth techi...@gmail.com wrote: Hi All, Do we have any sample test written in C# for testing connman ? I am trying to integrate one of my C# application running on Linux with connman. I am not aware of existing code, but as long as C# has decent D-Bus bindings, implementing the basics (like knowing when the system is online) should be fairly trivial. Any D-Bus tutorial that shows how to connect to a signal should get you started. The Connman API documentation in doc/-directory is pretty good and most importantly you can play with the actual implementation without writing code with e.g. the d-feet application (included in most distros): that should help getting the interface names, object paths etc correct. HTH, Jussi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: Use OPEN auth_alg for open wifi networks
On Thu, 2015-01-29 at 15:48 +0200, Slava Monich wrote: With auth_alg set to OPEN SHARED some drivers (particularly bcmdhd) won't connect to open wifi access points. Works for me at least. Applied, thanks! Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Patch to fix struct in6_pktinfo redefinition
On Thu, 2015-01-29 at 22:32 -0800, Chris Hiszpanski wrote: Here is the patch with a description of the issue and fix: https://github.com/kuna-systems/connman/commit/685ec6af70824df85fe637f5f79565e9456211a0.patch Could you move the struct definition including added #ifdefs into gdhcp/common.h and send the result to the mailing list? Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: Issue found in service connman ordering
Hello Patrik,
Thanks for clarification.
I made my assumption from: https://01.org/connman/documentation
[General]
PreferredTechnologies = ethernet,wifi,cellular
With PreferredTechnologies enabled, the autoconnected services depend on the
order in which they are created. Let's say there is one service for ethernet
and another one for WiFi. If the WiFi service is detected before the ethernet
one, both will get connected as ethernet, connected later, is preferred over
WiFi. And as described above, WiFi can still have the default route if it goes
to state 'online' while the ethernet one stays in 'ready'. If the ordering is
the opposite with ethernet discovered first, the WiFi service will never be
considered as ethernet is preferred over WiFi and already connected.
-Converting this to my use case where: PreferredTechnologies =
wifi,ethernet,Bluetooth
With PreferredTechnologies enabled, the autoconnected services depend on the
order in which they are created. Let's say there is one service for ethernet
and another one for WiFi. If the Ethernet service is detected before the WiFi
one, both will get connected as WiFi, connected later, is preferred over
Ethernet. And as described above, Ethernet can still have the default route if
it goes to state 'online' while the WiFi one stays in 'ready'.
If the ordering is the opposite with WiFi discovered first, the ethernet
service will never be considered as WiFi is preferred over ethernet and already
connected.
But as I understood from you, priority ordering is decided by:
i) online service over ready service
ii) In case of same connection status(online or ready), then
PreferredTechnologies ordering will be considered.
Sometime better connectivity state (better signal strength) also considered.
Default gateway should not drop its connection status
iii) Services of same technology will be ordered according to
online status and then order in which they are created
iv) Order in which service created really matters?
Thanks in advance.
Best Regards,
PriyaranjanS
-Original Message-
From: connman [mailto:connman-boun...@connman.net] On Behalf Of Patrik Flykt
Sent: Friday, January 30, 2015 1:49 PM
To: connman@connman.net
Subject: Re: Issue found in service connman ordering
Hi,
On Fri, 2015-01-30 at 07:55 +, Priyaranjan Singh wrote:
PreferredTechnologies = wifi,ethernet,Bluetooth
If the services end up with equal states, i.e. all in 'ready' or all can
possbly go 'online' the order is wifi first, ethernet second and bluetooth
third.
The start of a documentation at https://01.org/connman/documentation
tries to explain this.
Step 2) Connect Ethernet device/phone (data usage on) with target
Actual Service ordering:
#connmanctl services
List of all services:
*AO Wired{ ethernet_22d3f9d281a8_cable }
*AR uttejSir { wifi_001cc1a25dff_757474656a536972_managed_none }
Expected Service ordering:
#connmanctl services
List of all services:
*AR uttejSir { wifi_001cc1a25dff_757474656a536972_managed_none }
*AR Wired{ ethernet_22d3f9d281a8_cable }
If the services had both stayed at 'ready' the expected service ordering would
be the one used. But now ethernet successfully finished the online check, and
entered 'online' state as a result. PreferredTechnologies is valid for services
in the same state, and 'online' state is always preferred over 'ready'. If
there are more than one services that can go 'online', PreferredTechnologies is
consulted again and the most preferred technology type is the one that is
selected as the one and only 'online' service at that time.
So this case works as expected.
Cheers,
Patrik
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
This message contains information that may be privileged or confidential and is
the property of the KPIT Technologies Ltd. It is intended only for the person
to whom it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain copy, disseminate, distribute, or use this
message or any part thereof. If you receive this message in error, please
notify the sender immediately and delete all copies of this message. KPIT
Technologies Ltd. does not accept any liability for virus infected mails.
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Issue found in service connman ordering
Hi,
On Fri, 2015-01-30 at 07:55 +, Priyaranjan Singh wrote:
PreferredTechnologies = wifi,ethernet,Bluetooth
If the services end up with equal states, i.e. all in 'ready' or all can
possbly go 'online' the order is wifi first, ethernet second and
bluetooth third.
The start of a documentation at https://01.org/connman/documentation
tries to explain this.
Step 2) Connect Ethernet device/phone (data usage on) with target
Actual Service ordering:
#connmanctl services
List of all services:
*AO Wired{ ethernet_22d3f9d281a8_cable }
*AR uttejSir { wifi_001cc1a25dff_757474656a536972_managed_none }
Expected Service ordering:
#connmanctl services
List of all services:
*AR uttejSir { wifi_001cc1a25dff_757474656a536972_managed_none }
*AR Wired{ ethernet_22d3f9d281a8_cable }
If the services had both stayed at 'ready' the expected service ordering
would be the one used. But now ethernet successfully finished the online
check, and entered 'online' state as a result. PreferredTechnologies is
valid for services in the same state, and 'online' state is always
preferred over 'ready'. If there are more than one services that can go
'online', PreferredTechnologies is consulted again and the most
preferred technology type is the one that is selected as the one and
only 'online' service at that time.
So this case works as expected.
Cheers,
Patrik
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Issue found in service connman ordering
Hi,
On Fri, 2015-01-30 at 07:55 +, Priyaranjan Singh wrote:
2) Test 2:
*AO Wired{ ethernet_4afaf413be54_cable }
Step 2) First connect target device with WiFi mobile phone (portable
host spot enabled in Access point mode: data usage off)
Actual Service ordering:
~# connmanctl services
List of all services:
*AR Wired{ ethernet_4afaf413be54_cable }
*AR uttejSir { wifi_001cc1a25dff_757474656a536972_managed_none }
Ethernet should not be able to drop down to 'ready' state like that.
Check if this problem persists with upstream git as there's been tons of
fixes since 1.23. Knowing the amount of fixes applied, I would not use
1.23 anywhere anymore...
Cheers,
Patrik
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Patch to fix struct in6_pktinfo redefinition
Good idea, here's the revised patch: https://github.com/kuna-systems/connman/commit/348973959e386327dc16aeed6a558b9a6bdd733b.patch -- Chris Hiszpanski, Engineering Kuna | San Francisco, CA | Direct: (650) 561-6255 http://www.getkuna.com On Fri, Jan 30, 2015 at 1:27 AM, Patrik Flykt patrik.fl...@linux.intel.com wrote: On Thu, 2015-01-29 at 22:32 -0800, Chris Hiszpanski wrote: Here is the patch with a description of the issue and fix: https://github.com/kuna-systems/connman/commit/685ec6af70824df85fe637f5f79565e9456211a0.patch Could you move the struct definition including added #ifdefs into gdhcp/common.h and send the result to the mailing list? Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
