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 3/5] client: add session allowed interface config
(Daniel Wagner)
2. Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment (Andr? Draszik)
3. Re: [PATCH 4/5] session: add source ip rule (Daniel Wagner)
4. Re: [PATCH 5/5] client: add session source ip rule (Daniel Wagner)
5. Re: Tether WiFi to cellular modem uplink (Evade Flow)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Dec 2016 14:55:58 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH 3/5] client: add session allowed interface config
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Lukasz,
On 12/12/2016 07:35 PM, [email protected] wrote:
> From: Lukasz Nowak <[email protected]>
>
> Add ability to set allowed interface in session config.
> Using --ifname without a second argument, clears the
> allowed interface, i.e. any interface is allowed.
In case we ending up having the D-Bus API, you need to update the man
pages as well.
Thanks,
Daniel
------------------------------
Message: 2
Date: Wed, 14 Dec 2016 14:19:41 +0000
From: Andr? Draszik <[email protected]>
To: Shrikant Bobade <[email protected]>
Cc: [email protected], Patrik Flykt <[email protected]>
Subject: Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Fri, 2016-12-09 at 19:07 +0530, Shrikant Bobade wrote:
>
[...]
> Further observed with less available entropy.. on the setup causing the
> delay. So continuing with v1.33.
>
> e.g.
>
>
> *:~# cat
> /proc/sys/kernel/random/entropy_avail
> 0*
>
> Getting connman waiting/stuck at
> *getrandom (_rnd_get_system_entropy_getrandom) (by default gnutls
> enabled)*
> So tried to increase entropy with help of /dev/urandom & and with
> sufficient ~3k+ entropy count observed the getrandom call completed
> successfully.
> Is this know behaviour Or experienced by anyone.. ?
I think I have seen something similar here, but never investigated in depth as
of yet.
>
> [...]
> reasons and not /dev/urandom ? thoughts if any for other ways to deal with
> less/no entropy available with /dev/random?
> http://security.stackexchange.com/questions/122155/how-bad-it-is-to-feed-d
> ev-random-with-dev-urandom
> http://stackoverflow.com/questions/3690273/did-i-understand-dev-urandom#co
> mment30985465_3709644
>
> Any pointers or references will be a great help..
For me, the combination of removing GnuTLS usage in ConnMan (disable wispr)
as well as switching all applications to use OpenSSL rather than GnuTLS
(wpa-supplicant in particular) was sufficient to work around this for the
time being. Probably because OpenSSL handles /dev/random & /dev/urandom
differently than GnuTLS.
I had also considered adding timer-entropyd https://www.vanheusden.com/te/
but didn't need to in the end.
Cheers,
Andre'
------------------------------
Message: 3
Date: Wed, 14 Dec 2016 15:26:34 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH 4/5] session: add source ip rule
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 12/12/2016 07:35 PM, [email protected] wrote:
> From: Lukasz Nowak <[email protected]>
>
> Implement an option for a session to enable packet filtering
> based on interfce source ip address. This allows an application
type: interface
> to create a session, and direct traffic to a specific network
> interface, on which the session is connected.
>
> Applications can use bind before connect on a socket to specify
> the source ip address.
>
> This mechanism re-uses the routing table created by the session,
> iproute fwmark rule, and adds a new iptables source ip rule.
> ---
> include/session.h | 1 +
> src/connman.h | 3 ++-
> src/firewall-iptables.c | 12 ++++++++-
> src/firewall-nftables.c | 5 ++--
> src/session.c | 65
> ++++++++++++++++++++++++++++++++++++++++++++++---
> 5 files changed, 78 insertions(+), 8 deletions(-)
I think you need to split up this patch a bit. There are too many things
going on in one go. At least you should try to split out the firewall-*
changes.
> diff --git a/include/session.h b/include/session.h
> index e8d7e93..48f1510 100644
> --- a/include/session.h
> +++ b/include/session.h
> @@ -66,6 +66,7 @@ struct connman_session_config {
> bool ecall;
> GSList *allowed_bearers;
> char *allowed_interface;
> + bool source_ip_rule;
Could you write a small document for doc/ which explains how everything
is supposed to work. For example I am not sure why you want this
additional boolean. It isn't clear to me when you define
allowed_interface (from patch #2) that you need to enable it via this bool?
> };
>
> typedef int (* connman_session_config_func_t) (struct connman_session
> *session,
> diff --git a/src/connman.h b/src/connman.h
> index 577c808..51c3c03 100644
> --- a/src/connman.h
> +++ b/src/connman.h
> @@ -1013,7 +1013,8 @@ int __connman_firewall_enable_snat(struct
> firewall_context *ctx,
> int __connman_firewall_disable_snat(struct firewall_context *ctx);
> int __connman_firewall_enable_marking(struct firewall_context *ctx,
> enum connman_session_id_type id_type,
> - char *id, uint32_t mark);
> + char *id, const char *src_ip_address,
src_ip_address is a bit long, src_ip should be enough.
> + uint32_t mark);
> int __connman_firewall_disable_marking(struct firewall_context *ctx);
>
> int __connman_firewall_init(void);
> diff --git a/src/firewall-iptables.c b/src/firewall-iptables.c
> index c58efc1..e7a966d 100644
> --- a/src/firewall-iptables.c
> +++ b/src/firewall-iptables.c
> @@ -495,7 +495,8 @@ static void firewall_disable_connmark(void)
>
> int __connman_firewall_enable_marking(struct firewall_context *ctx,
> enum connman_session_id_type id_type,
> - char *id, uint32_t mark)
> + char *id, const char *src_ip_address,
> + uint32_t mark)
> {
> int err;
>
> @@ -514,11 +515,20 @@ int __connman_firewall_enable_marking(struct
> firewall_context *ctx,
> "-m owner --gid-owner %s -j MARK --set-mark %d",
> id, mark);
> break;
> + case CONNMAN_SESSION_ID_TYPE_UNKNOWN:
> + break;
> case CONNMAN_SESSION_ID_TYPE_LSM:
> default:
> return -EINVAL;
> }
>
> + if (src_ip_address)
> + {
The braket goes on the line above.
> + firewall_add_rule(ctx, "mangle", "OUTPUT",
> + "-s %s -j MARK --set-mark %d",
> + src_ip_address, mark);
> + }
> +
> return firewall_enable_rules(ctx);
> }
>
> diff --git a/src/firewall-nftables.c b/src/firewall-nftables.c
> index 4d47f20..dc4c934 100644
> --- a/src/firewall-nftables.c
> +++ b/src/firewall-nftables.c
> @@ -800,7 +800,8 @@ err:
>
> int __connman_firewall_enable_marking(struct firewall_context *ctx,
> enum connman_session_id_type id_type,
> - char *id, uint32_t mark)
> + char *id, const char *src_ip_address,
> + uint32_t mark)
> {
> struct nftnl_rule *rule;
> struct mnl_socket *nl;
> @@ -811,7 +812,7 @@ int __connman_firewall_enable_marking(struct
> firewall_context *ctx,
> DBG("");
>
>
> - if (id_type != CONNMAN_SESSION_ID_TYPE_UID)
> + if (id_type != CONNMAN_SESSION_ID_TYPE_UID || src_ip_address)
> return -ENOTSUP;
Obviously, you need to add this nftables implementation as well.
>
> pw = getpwnam(id);
> diff --git a/src/session.c b/src/session.c
> index 2dfd428..28a4f77 100644
> --- a/src/session.c
> +++ b/src/session.c
> @@ -273,8 +273,11 @@ static int init_firewall_session(struct connman_session
> *session)
> {
> struct firewall_context *fw;
> int err;
> + struct connman_ipconfig *ipconfig;
> + const char *addr = NULL;
>
> - if (session->policy_config->id_type == CONNMAN_SESSION_ID_TYPE_UNKNOWN)
> + if (session->policy_config->id_type == CONNMAN_SESSION_ID_TYPE_UNKNOWN
> &&
> + !session->info->config.source_ip_rule)
> return 0;
So you don't need to identify your application? The test is here because
the firewall didn't make to start if there is no rule to install. I was
tempted to suggest to define a new CONNMAN_SESSION_ID_TYPE for this use
case but I think it would be good to stay as generic as possible and
still allow application identification and source routing.
At least I would say you should add a small helper for test which tells
us what is tested.
static bool firewall_needed() {}
or a something with a better name.
BTW, I think now I get why you want to expose the interface name via
D-Bus. The application use this information to bind to the interface, no?
>
> DBG("");
> @@ -283,10 +286,15 @@ static int init_firewall_session(struct connman_session
> *session)
> if (!fw)
> return -ENOMEM;
>
> + ipconfig = __connman_service_get_ip4config(session->service);
> + if (session->info->config.source_ip_rule && ipconfig) {
> + addr = __connman_ipconfig_get_local(ipconfig);
> + }
> +
> err =__connman_firewall_enable_marking(fw,
> session->policy_config->id_type,
> session->policy_config->id,
> - session->mark);
> + addr, session->mark);
> if (err < 0) {
> __connman_firewall_destroy(fw);
> return err;
> @@ -313,7 +321,8 @@ static int init_routing_table(struct connman_session
> *session)
> {
> int err;
>
> - if (session->policy_config->id_type == CONNMAN_SESSION_ID_TYPE_UNKNOWN)
> + if (session->policy_config->id_type == CONNMAN_SESSION_ID_TYPE_UNKNOWN
> &&
> + !session->info->config.source_ip_rule)
> return 0;
>
> DBG("");
> @@ -520,6 +529,7 @@ struct creation_data {
> enum connman_session_type type;
> GSList *allowed_bearers;
> char *allowed_interface;
> + bool source_ip_rule
> };
>
> static void cleanup_creation_data(struct creation_data *creation_data)
> @@ -897,6 +907,17 @@ static void append_notify(DBusMessageIter *dict,
> info_last->config.allowed_interface =
> info->config.allowed_interface;
> }
>
> + if (session->append_all ||
> + info->config.source_ip_rule !=
> info_last->config.source_ip_rule) {
> + dbus_bool_t source_ip_rule = FALSE;
> + if (info->config.source_ip_rule)
> + source_ip_rule = TRUE;
> + connman_dbus_dict_append_basic(dict, "SourceIPRule",
> + DBUS_TYPE_BOOLEAN,
> + &source_ip_rule);
> + info_last->config.source_ip_rule = info->config.source_ip_rule;
> + }
> +
> session->append_all = false;
> }
>
> @@ -917,7 +938,8 @@ static bool compute_notifiable_changes(struct
> connman_session *session)
>
> if (info->config.allowed_bearers != info_last->config.allowed_bearers ||
> info->config.type != info_last->config.type ||
> - info->config.allowed_interface !=
> info_last->config.allowed_interface)
> + info->config.allowed_interface !=
> info_last->config.allowed_interface ||
> + info->config.source_ip_rule !=
> info_last->config.source_ip_rule)
> return true;
>
> return false;
> @@ -1165,6 +1187,27 @@ static DBusMessage *change_session(DBusConnection
> *conn,
> goto err;
> }
> break;
> + case DBUS_TYPE_BOOLEAN:
> + if (g_str_equal(name, "SourceIPRule")) {
> + dbus_bool_t source_ip_rule;
> + dbus_message_iter_get_basic(&value, &source_ip_rule);
> +
> + cleanup_firewall_session(session);
> + cleanup_routing_table(session);
> +
> + info->config.source_ip_rule = source_ip_rule;
> + update_session_state(session);
> +
> + init_routing_table(session);
check the return type
I don't think you handle on-off-on toggling for routing initializtion
and the firewall session setup.
Thanks,
Daniel
------------------------------
Message: 4
Date: Wed, 14 Dec 2016 15:27:23 +0100
From: Daniel Wagner <[email protected]>
To: [email protected], [email protected]
Subject: Re: [PATCH 5/5] client: add session source ip rule
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 12/12/2016 07:35 PM, [email protected] wrote:
> From: Lukasz Nowak <[email protected]>
>
> Add a session config field to enable/disable creation of the
> source ip rule in iptables by a session.
Don't forget to update the man page if we agree on this feature.
Thanks,
Daniel
------------------------------
Message: 5
Date: Wed, 14 Dec 2016 10:34:14 -0500
From: Evade Flow <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: Patrik Flykt <[email protected]>, [email protected]
Subject: Re: Tether WiFi to cellular modem uplink
Message-ID:
<CAMAb8ZNAhcHK08=8q6EsP40Ksw52uv-19OhFEX=ganwmmge...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the detailed reply! It doesn't look like ofono is
recognizing the modem (a Sierra Wireless AC340U). First, I confirmed
that ofonod was actually running and exporting the expected
interfaces to D-Bus:
```
root@embedded $ ps ax | grep ofono | grep -v grep
1739 ? Ss 0:00 /usr/sbin/ofonod -n
root@embedded $ ofonod --version
1.17
root@embedded $ gdbus introspect --recurse --system --dest=org.ofono
--object-path=/
node / {
...
interface org.ofono.Manager {
methods:
GetModems(out a(oa{sv}) modems);
signals:
ModemAdded(o path,
a{sv} properties);
ModemRemoved(o path);
properties:
};
...
}
```
NOTE: `gdbus` results elided to save space. Full output here:
- https://gist.github.com/evadeflow/8ae65f6874b8dd5b0802a5a947ad3cee
After that, when I ran:
```
root@embedded $ ./monitor-ofono
```
and then plugged in the modem, the `monitor-ofono` program never
output anything. But the following was emitted in a separate
terminal window where I was running `dmesg`:
```
[ 1450.136992] usb 1-2.4: new high-speed USB device number 9 using xhci_hcd
[ 1450.209767] usb 1-2.4: config 1 has an invalid interface number: 9 but
max is 0
[ 1450.209772] usb 1-2.4: config 1 has no interface number 0
[ 1450.210269] usb 1-2.4: New USB device found, idVendor=1199,
idProduct=0fff
[ 1450.210281] usb 1-2.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 1450.210288] usb 1-2.4: Product: AirCard 340U
[ 1450.210290] usb 1-2.4: Manufacturer: Sierra Wireless, Incorporated
[ 1450.210293] usb 1-2.4: SerialNumber: 013323000518432
[ 1450.211348] usb-storage 1-2.4:1.9: USB Mass Storage device detected
[ 1450.212393] usb-storage: probe of 1-2.4:1.9 failed with error -5
[ 1453.522157] usb 1-2.4: USB disconnect, device number 9
[ 1453.941143] usb 1-2.4: new high-speed USB device number 10 using xhci_hcd
[ 1454.013939] usb 1-2.4: config 1 has an invalid interface number: 8 but
max is 4
[ 1454.013943] usb 1-2.4: config 1 has an invalid interface number: 9 but
max is 4
[ 1454.013947] usb 1-2.4: config 1 has no interface number 1
[ 1454.013949] usb 1-2.4: config 1 has no interface number 4
[ 1454.014438] usb 1-2.4: New USB device found, idVendor=1199,
idProduct=9051
[ 1454.014444] usb 1-2.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 1454.014447] usb 1-2.4: Product: AirCard 340U
[ 1454.014450] usb 1-2.4: Manufacturer: Sierra Wireless, Incorporated
[ 1454.014453] usb 1-2.4: SerialNumber: 013323000518432
[ 1454.016464] qcserial 1-2.4:1.2: Qualcomm USB modem converter detected
[ 1454.016688] usb 1-2.4: Qualcomm USB modem converter now attached to
ttyUSB0
[ 1454.017264] qcserial 1-2.4:1.3: Qualcomm USB modem converter detected
[ 1454.017444] usb 1-2.4: Qualcomm USB modem converter now attached to
ttyUSB1
[ 1454.017988] qmi_wwan 1-2.4:1.8: cdc-wdm0: USB WDM device
[ 1454.018302] qmi_wwan 1-2.4:1.8 wwan0: register 'qmi_wwan' at
usb-0000:00:15.0-2.4, WWAN/QMI device, f6
:a5:93:07:8e:ef
[ 1454.018916] usb-storage 1-2.4:1.9: USB Mass Storage device detected
[ 1454.019099] scsi host7: usb-storage 1-2.4:1.9
[ 1454.019689] qcserial 1-2.4:1.0: Qualcomm USB modem converter detected
[ 1454.019823] usb 1-2.4: Qualcomm USB modem converter now attached to
ttyUSB2
[ 1455.009325] scsi 7:0:0:0: Direct-Access Aircard Disk Drive
1.00 PQ: 0 ANSI: 2
[ 1455.009655] sd 7:0:0:0: Attached scsi generic sg0 type 0
[ 1455.010749] sd 7:0:0:0: [sda] Attached SCSI removable disk
```
RE: entering a PIN, I don't believe my SIM card is PIN-locked. I ran
`enter-pin` for fun, anyway, but `org.ofono.Manager.GetModems()`
appears to be returning an empty list:
```
root@embedded $ ./enter-pin whatever 1234
Traceback (most recent call last):
File "./enter-pin", line 16, in <module>
path = modems[0][0]
IndexError: list index out of range
```
This isn't surprising, I suppose, given that `monitor-ofono` never
received any signals from ofono, either.
Any recommendations on how to troubleshoot this? I'm guessing that
our embedded target is missing some required udev rule(s):
```
root@mel-automotive-gr-mrb $ cd /lib/udev/
root@mel-automotive-gr-mrb $ grep -rli ofono *
root@mel-automotive-gr-mrb $ cd /usr/lib/udev/
root@mel-automotive-gr-mrb $ grep -rli ofono *
root@mel-automotive-gr-mrb $ cd /etc/udev/
root@mel-automotive-gr-mrb $ grep -rli ofono *
```
No hits for ofono/OFONO anywhere. I guess I'll try copying
`plugins/ofono.rules` from the ofono source and see if it helps,
but... any other advice/guidance much appreciated?thanks!
On Wed, Dec 14, 2016 at 8:41 AM, Daniel Wagner <[email protected]> wrote:
> On 12/14/2016 11:50 AM, Patrik Flykt wrote:
> > On Tue, 2016-12-13 at 14:51 -0500, Evade Flow wrote:
> >> Do you mean that it's not possible for the tether to access the
> >> cellular link unless I configure oFono?
> >
> > Yes.
> >
> >> I'm not opposed to trying this, but... I have no idea where to
> >> start. How does one 'configure' oFono? Pointers to any available
> >> docs, tutorials, videos, books, etc. would be much appreciated.
> >
> > I have a note which says to run the following commands manually from
> > the ofono source directory:
> >
> > test/enter-pin pin XXXX
> > (maybe a test/list-modems to find the modems)
> > test/enable-modem /XXXXXX
> > test/online-modem /XXXXXX
> > (now org.ofono.ConnectionManager Attached=1 should appear, perhaps this
> > was detected with test/monitor-modem; nevertheless, not important as
> > such)
> > test/activate-context
> >
> > Maybe others can correct me with the above and know if ConnMan can take
> > care of the last step(s)? Wagi?
>
> You need to do the pin entering but that's all. The rest does the plugin.
> You can run monitor-ofono which tells you what ConnMan is seeing.
>
> {Manager} [ModemAdded] /stktest { Emergency = False, Features = [], Type =
> test, Online = False, Powered = False, Lockdown = False, Interfaces = [] }
> {Manager} [ModemAdded] /hso_0 { Emergency = False, Features = [], Type =
> hardware, Online = False, Powered = False, Lockdown = False, Interfaces =
> [] }
> {Modem} [/hso_0] Powered = True
> {Modem} [/hso_0] Interfaces = org.ofono.SimManager
> {Modem} [/hso_0] Features = sim
> {Modem} [/hso_0] Manufacturer = Option N.V.
> {Modem} [/hso_0] Model = GlobeTrotter HSUPA Modem
> {Modem} [/hso_0] Revision = 2.12.0.0Hd (Date: Oct 29 2009, Time: 09:56:48)
> {Modem} [/hso_0] Serial = 351721030157214,PK29997020
> {SimManager} [/hso_0] Retries = { pin = 3, puk = 10 }
> {SimManager} [/hso_0] SubscriberIdentity = 262011648051223
> {SimManager} [/hso_0] MobileCountryCode = 262
> {SimManager} [/hso_0] MobileNetworkCode = 01
> {Modem} [/hso_0] Interfaces = org.ofono.AllowedAccessPoints
> org.ofono.SimManager
> {Modem} [/hso_0] Features = sim
> {Modem} [/hso_0] Online = True
> {Modem} [/hso_0] Interfaces = org.ofono.VoiceCallManager
> org.ofono.AllowedAccessPoints org.ofono.SimManager
> {Modem} [/hso_0] Features = sim
> {Modem} [/hso_0] Interfaces = org.ofono.SupplementaryServices
> org.ofono.VoiceCallManager org.ofono.AllowedAccessPoints
> org.ofono.SimManager
> {Modem} [/hso_0] Features = ussd sim
> {Modem} [/hso_0] Interfaces = org.ofono.RadioSettings
> org.ofono.SupplementaryServices
> org.ofono.VoiceCallManager org.ofono.AllowedAccessPoints
> org.ofono.SimManager
> {Modem} [/hso_0] Features = rat ussd sim
> {Modem} [/hso_0] Interfaces = org.ofono.NetworkRegistration
> org.ofono.RadioSettings org.ofono.SupplementaryServices
> org.ofono.VoiceCallManager org.ofono.AllowedAccessPoints
> org.ofono.SimManager
> {Modem} [/hso_0] Features = net rat ussd sim
> {Modem} [/hso_0] Interfaces = org.ofono.CellBroadcast
> org.ofono.NetworkRegistration org.ofono.RadioSettings
> org.ofono.SupplementaryServices
> org.ofono.VoiceCallManager org.ofono.AllowedAccessPoints
> org.ofono.SimManager
> {Modem} [/hso_0] Features = cbs net rat ussd sim
> {NetworkRegistration} [/hso_0] Status = unregistered
> {Modem} [/hso_0] Interfaces = org.ofono.ConnectionManager
> org.ofono.CellBroadcast org.ofono.NetworkRegistration
> org.ofono.RadioSettings org.ofono.SupplementaryServices
> org.ofono.VoiceCallManager org.ofono.AllowedAccessPoints
> org.ofono.SimManager
> {Modem} [/hso_0] Features = gprs cbs net rat ussd sim
> {Modem} [/hso_0] Interfaces = org.ofono.SmartMessaging
> org.ofono.PushNotification org.ofono.MessageManager
> org.ofono.ConnectionManager org.ofono.CellBroadcast
> org.ofono.NetworkRegistration org.ofono.RadioSettings
> org.ofono.SupplementaryServices
> org.ofono.VoiceCallManager org.ofono.AllowedAccessPoints
> org.ofono.SimManager
> {Modem} [/hso_0] Features = sms gprs cbs net rat ussd sim
> {NetworkRegistration} [/hso_0] Status = searching
> {NetworkRegistration} [/hso_0] Status = denied
>
> As you can see my SIM card is not valid anymore and the NetworkRegistration
> fails. Currently I don't have any data SIM lying around.
>
> > I was going to test the above, but realized that my SIM card needs an
> > adapter which is at home right now...
>
> Note some modems are tricky to get working. oFono does a lot to make sure
> that all modems just work, though not all modems can be tricked into
> working mode.
>
> cheers,
> daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20161214/c99957e1/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 14, Issue 20
***************************************
