Re: [RFC 01/12] doc: Add method call and signal for tethering information

Hi Martin, I do not even know what any of these information mean. What are they good for. What value are they providing. What would the user interface do with this information? >>> >>> The idea here is to provide a list of the clients that are tethered. >>> Some additional informat

Re: [PATCH v2] wifi: Preliminary fix for autoscanning known hidden SSIDs

Hi Sameer, Hello Tomasz, I tested your patch and it works when there is only one provisioned hidden service (as expected). Thanks for testing it. I will do a patch for scanning the whole set, but I am a bit busy right now. Let's say end of next week. Br, Tomasz __

Re: [PATCH v2] wifi: Preliminary fix for autoscanning known hidden SSIDs

Hello Tomasz, I tested your patch and it works when there is only one provisioned hidden service (as expected). I will use this patch for now. Thanks and Regards ~Sameer On Fri, Mar 1, 2013 at 4:47 PM, Tomasz Bursztyka < tomasz.burszt...@linux.intel.com> wrote: > Currently, it relies on max_ss

Re: [RFC 01/12] doc: Add method call and signal for tethering information

Hi Martin, 1. MAC address of the remote devices What's the use case? Is there a plan to filter the access by MAC address like in android afterwards? Br, Tomasz ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman

Re: [RFC 01/12] doc: Add method call and signal for tethering information

Marcel: > >> I do not even know what any of these information mean. What are they > >> good for. What value are they providing. What would the user interface > >> do with this information? > > > > The idea here is to provide a list of the clients that are tethered. > > Some additional information

Re: [RFC 01/12] doc: Add method call and signal for tethering information

Hi Patrik, >> this does not look like an useful interface. I find it actually pretty >> ugly and glued on. It does not fit. So lets not do it this way. > > Yes, all attributes you mentioned describes it well. Martin wanted to > see the code, so it was better to send it here early as an RFC. > >>

Re: [PATCH] service: Restart wispr on nameserver change

Hi Patrik, On Fri, Jan 04, 2013 at 12:33:36PM +0200, Patrik Flykt wrote: > On Wed, 2012-12-05 at 16:44 -0500, Forest Bond wrote: > > From: Forest Bond > > > > This is needed to make a service go online in the case where it was > > already connected and then manual IPv4 & nameservers settings are

Re: [PATCH 1/2] ofono: Create CDMA device sooner

Hi Denis, On Sun, Dec 30, 2012 at 05:36:30AM -0600, Denis Kenzior wrote: > On 01/02/2013 09:32 AM, Daniel Wagner wrote: > >Hi Forest, > > > >On 28.12.2012 20:22, Forest Bond wrote: > >>From: Forest Bond > >> > >>Previously, the CDMA device was created only after the CDMA > >>ConnectionManager inte

Re: [PATCH] tethering: Include definition for struct in6_addr

On 04.03.2013 15:17, Daniel Wagner wrote: From: Daniel Wagner The kernel header linux/if_bridge.h was updated with kernel 3.8 which includes a new 'struct br_mdb_entry' which has a member of type 'struct ip6'. See mainline kernel commit: ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 should be 'in

[PATCH] tethering: Include definition for struct in6_addr

From: Daniel Wagner The kernel header linux/if_bridge.h was updated with kernel 3.8 which includes a new 'struct br_mdb_entry' which has a member of type 'struct ip6'. See mainline kernel commit: ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6 --- src/tethering.c | 1 + 1 file changed, 1 insertion(+)

Re: [RFC 01/12] doc: Add method call and signal for tethering information

Hi, On Fri, 2013-03-01 at 08:33 -0800, Marcel Holtmann wrote: > this does not look like an useful interface. I find it actually pretty > ugly and glued on. It does not fit. So lets not do it this way. Yes, all attributes you mentioned describes it well. Martin wanted to see the code, so