Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH 5/6] mozjs: fix global variable storage (Patrik Flykt)
2. Re: avoid redundant saving to the file system (Patrik Flykt)
3. Re: API to get List of Connected STA's to an AP's (Patrik Flykt)
4. Re: Search domain persistence (Patrik Flykt)
5. Re: [PATCH 5/6] mozjs: fix global variable storage
(David Woodhouse)
6. Re: [PATCH] dhcp: remove the possible remaining dhcp_retry_cb
timer (Patrik Flykt)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Jun 2016 10:41:12 +0300
From: Patrik Flykt <[email protected]>
To: David Woodhouse <[email protected]>, [email protected]
Subject: Re: [PATCH 5/6] mozjs: fix global variable storage
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
Applied all patches for pacrunner, thanks!
On Mon, 2016-06-20 at 14:46 +0100, David Woodhouse wrote:
> It *does* work as-is, with the current single-context model and just
> changing context each time it needs to do a lookup in a different
> configuration. So I'm inclined to leave it as it is.
Let's leave it for now.
> Or maybe just *delete* the v8 back end completely. We added it for
> MeeGo because we were based on v8/Chromium there, but I think those
> days are long gone. We ought to be moving to duktape anyway.
duktape is definitively to be investigated and implemented if it is
found useful and there is time to do it. Apparently it has improved
since last time it was looked at some years ago.
Patrik
------------------------------
Message: 2
Date: Thu, 23 Jun 2016 10:44:03 +0300
From: Patrik Flykt <[email protected]>
To: "Nakamura, Yusuke (ADITJ/SWG)" <[email protected]>,
"[email protected]" <[email protected]>
Cc: "Hoyer, Marko (ADITG/SW2)" <[email protected]>, "Ishikawa,
Tetsuri (ADITJ/SWG)" <[email protected]>
Subject: Re: avoid redundant saving to the file system
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2016-06-22 at 05:09 +0000, Nakamura, Yusuke (ADITJ/SWG) wrote:
> Hi all,
> ?
> I had a looked at the piece of code in technology.c and found there
> was a redundant data saving.
> connman_technology_save_offline() always loads the keyfile and saves
> it even if OfflineMode is not changed.
> In order to avoid this I?d like to save the keyfile only when
> OfflineMode is actually changed.
> Do you agree with this ? If yes, I?ll send a patch to review.
Yes, that would be a good thing to check before unnecessary saving the
file again. Please send a patch.
Patrik
------------------------------
Message: 3
Date: Thu, 23 Jun 2016 11:37:56 +0300
From: Patrik Flykt <[email protected]>
To: "Lamsoge, Abhijit" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: API to get List of Connected STA's to an AP's
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Fri, 2016-06-10 at 11:25 +0000, Lamsoge, Abhijit wrote:
> ________________________________________
> From: Patrik Flykt [[email protected]]
> Sent: Friday, June 10, 2016 4:36 PM
> To: Lamsoge, Abhijit; [email protected]
> Subject: Re: API to get List of Connected STA's to an AP's
>
> On Thu, 2016-06-09 at 12:42 +0000, Lamsoge, Abhijit wrote:
> > Hi Patrick/All,
> >
> > I have a few queries after long time.
> >
> > 1) Does connman support list of connected station/client to AP?
>
> > No.
>
> > 2) If yes, how we can access list of connected station ?
> > 3) If no, then how/where we can implement this feature?
>
> > Good question.
>
> > I think it's quiet an important feature if it is not supported in
> > connman.
>
> > What is the planned use case for this?
>
> -- we intend to get the connected devices to our AP on the system
> where connman is running.
> The actual use case for this, is to update on the UX, at runtime the
> latest list of users connected to it's AP, as it keeps getting
> modified all the time.
Please notice that combining information obtained with the command
'brctl showmacs <interface>' and from /proc/net/arp will give the best
up to date information on the connected devices. See how 'brctl
showmacs <interface>' is implemented in order not to launch an
executable all the time. As ConnMan really is not a router, this is the
best up to date information about the active hosts on the tethered
network.
> For Ex. Like a Router's webpage, needs to show STA's connected to it.
Do remember that ConnMan is no router nor OpenWRT replacement, you will
hit ConnMan's use case boundaries if you attempt to present identical
information.
Patrik
------------------------------
Message: 4
Date: Thu, 23 Jun 2016 11:39:47 +0300
From: Patrik Flykt <[email protected]>
To: Sven Schwedas <[email protected]>, [email protected]
Subject: Re: Search domain persistence
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2016-06-20 at 14:34 +0200, Sven Schwedas wrote:
> # Generated by Connection Manager
> search shun.yaki-syndicate.de ad.tao.at ad.tao.at
> nameserver 192.168.10.1
Yes, this looks like a bug. Anyone on the ml with time to fix this?
Cheers,
Patrik
------------------------------
Message: 5
Date: Thu, 23 Jun 2016 09:58:49 +0100
From: David Woodhouse <[email protected]>
To: Patrik Flykt <[email protected]>, [email protected]
Cc: "Van De Ven, Arjan" <[email protected]>, Tudor Marcu
<[email protected]>
Subject: Re: [PATCH 5/6] mozjs: fix global variable storage
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On Thu, 2016-06-23 at 10:41 +0300, Patrik Flykt wrote:
> duktape is definitively to be investigated and implemented if it is
> found useful and there is time to do it. Apparently it has improved
> since last time it was looked at some years ago.
You're aware, I hope, that duktape support *has* been implemented
within Intel? But unfortunately never pushed upstream.
The education about working properly with open source projects
unfortunately hasn't quite permeated to all corners yet...
--
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL:
<http://lists.01.org/pipermail/connman/attachments/20160623/a5932f9a/attachment-0001.bin>
------------------------------
Message: 6
Date: Thu, 23 Jun 2016 13:24:43 +0300
From: Patrik Flykt <[email protected]>
To: Harish Jenny K N <[email protected]>, [email protected]
Subject: Re: [PATCH] dhcp: remove the possible remaining dhcp_retry_cb
timer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2016-06-17 at 18:19 +0200, Harish Jenny K N wrote:
> In the following scenario:
>
> 1. no_lease_cb() is called
> ?dhcp->ipv4ll_client = ipv4ll_client;
> ?err = g_dhcp_client_start(dhcp->ipv4ll_client, NULL);
> ?ipv4ll_start(dhcp_client);
>
> 2. switch_listening_mode
> --> listener_event
>
> 3. listener_event
> ?--> ipv4ll_recv_arp_packet
> ---> no_lease_cb
> ---- > creates a new timeout (dhcp->timeout) without removing the old
> timeout
>
> Logs:
> src/dhcp.c:no_lease_cb() No lease available ipv4ll 0 client (nil)
> src/dhcp.c:no_lease_cb() No lease available ipv4ll 1 client 0x1d1e808
> src/dhcp.c:dhcp_release() dhcp 0x1d14980
>
> There is a possibility if dhcp_retry_cb() Timeout is not called
> before first
> no_lease_cb, then the old timer is not removed before creating the
> new one.
> We are not sure if the dhcp object will be alive when the first
> timeout fires.
> This could result in a potential crash.
>
> This patch adds a defensive check to remove the potential existing
> timer
> before creating a new one.
And applied. Thanks!
Patrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 8, Issue 31
**************************************
