Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe 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: Connman apparently not working on my embedded target
(Daniel Wagner)
2. Re: Connman apparently not working on my embedded target
(Michael Nazzareno Trimarchi)
3. Re: [[PATCH v2 1/2] ofono: set network name from context name
(Daniel Wagner)
4. Re: [[PATCH v2 2/2] ofono: store context apn value (Daniel Wagner)
----------------------------------------------------------------------
Date: Thu, 5 Mar 2020 09:24:16 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: Connman apparently not working on my embedded target
To: Mauro Condarelli <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
Hi Mauro,
> # [ 7082.009030] ------------[ cut here ]------------
> [ 7082.013743] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:443
> 0x8037056c
> [ 7082.020887] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
> [ 7082.027937] Modules linked in: mt7603e mt76 mac80211 cfg80211 mtk_eth
> ehci_platform ehci_hcd usbcore usb_common
> [ 7082.038206] CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-rc4 #2
> [ 7082.044291] Stack : 00000000 8004e5fc 80490000 80415810 00000000 00000000
> 00000000 00000000
> [ 7082.052772] 00000000 00000000 00000000 00000000 00000000 00000001
> 87c0bd78 80490000
> [ 7082.061249] 87c0be10 00000000 00000000 00000000 00000038 80407ca4
> 000000d8 00000000
> [ 7082.069728] 203a6d6d 87c0bbdc 80510000 70617773 80490000 00000000
> 00000009 00000009
> [ 7082.078208] 80480560 87c0bf0c 8037046c 00000122 00000003 802a7cbc
> 00000001 001d7f1f
> [ 7082.086688] ...
> [ 7082.089165] Call Trace:
> [ 7082.089177] [<8004e5fc>] 0x8004e5fc
> [ 7082.095185] [<80407ca4>] 0x80407ca4
> [ 7082.098720] [<8037046c>] 0x8037046c
> [ 7082.102254] [<802a7cbc>] 0x802a7cbc
> [ 7082.105788] [<8000aa38>] 0x8000aa38
> [ 7082.109321] [<8000aa40>] 0x8000aa40
> [ 7082.112856] [<8001d69c>] 0x8001d69c
> [ 7082.116390] [<8037056c>] 0x8037056c
> [ 7082.119924] [<8037056c>] 0x8037056c
> [ 7082.123456] [<8001d710>] 0x8001d710
> [ 7082.126993] [<8037056c>] 0x8037056c
> [ 7082.130527] [<80070274>] 0x80070274
> [ 7082.134064] [<80060254>] 0x80060254
> [ 7082.137596] [<8037046c>] 0x8037046c
> [ 7082.141129] [<8006040c>] 0x8006040c
> [ 7082.144665] [<80060c14>] 0x80060c14
> [ 7082.148199] [<8000d84c>] 0x8000d84c
> [ 7082.151732] [<800638e8>] 0x800638e8
> [ 7082.155267] [<80060c88>] 0x80060c88
> [ 7082.158801] [<804d0000>] 0x804d0000
> [ 7082.162334] [<8040e0e0>] 0x8040e0e0
> [ 7082.165875] [<80020740>] 0x80020740
> [ 7082.169409] [<80005910>] 0x80005910
> [ 7082.172939]
> [ 7082.174449] ---[ end trace c89d8f4203b47d1a ]---
This is a bug in the driver. Not much we can do in ConnMan.
> [ 7082.179141] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
> [ 7082.185770] mtk_soc_eth 10100000.ethernet eth0: Link is Down
> [ 7082.206411] mtk_soc_eth 10100000.ethernet eth0: configuring for fixed/mii
> link mode
> [ 7082.229320] mtk_soc_eth 10100000.ethernet eth0: Link is Up - 100Mbps/Full
> - flow control rx/tx
> [ 7984.005249] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
> [ 7984.011860] mtk_soc_eth 10100000.ethernet eth0: Link is Down
> [ 7984.027073] mtk_soc_eth 10100000.ethernet eth0: configuring for fixed/mii
> link mode
> [ 7984.045472] mtk_soc_eth 10100000.ethernet eth0: Link is Up - 100Mbps/Full
> - flow control rx/tx
> [ 8884.002287] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
> [ 8884.008898] mtk_soc_eth 10100000.ethernet eth0: Link is Down
> [ 8884.024123] mtk_soc_eth 10100000.ethernet eth0: configuring for fixed/mii
> link mode
> [ 8884.042515] mtk_soc_eth 10100000.ethernet eth0: Link is Up - 100Mbps/Full
> - flow control rx/tx
> [ 9783.999653] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
> [ 9784.006276] mtk_soc_eth 10100000.ethernet eth0: Link is Down
> [ 9784.021499] mtk_soc_eth 10100000.ethernet eth0: configuring for fixed/mii
> link mode
> [ 9784.039883] mtk_soc_eth 10100000.ethernet eth0: Link is Up - 100Mbps/Full
> - flow control rx/tx
Maybe related with the warning above? No idea. ConnMan doesn't
oscillate unless there are kernel message. Does 'ip monitor' show
anything useful?
> Unfortunately this results in further problems.
> Apparently this changes something in d-bus paths because
> trying to issue a Scan() command results in a failure after
> a very long wait.
> My guess is test-connman tries to talk to wpa_supplicant
> and, obviously, it gets no answer.
test-connman always talks to the same ConnMan the D-Bus API. I think
you see the abstraction leaking implementation details. Whereas
wpa_supplicant immediately returns on scan request the iwd plugin
doesn't reply immediately. It could also be something else. IIRC I
have seen some error message scan request response D-Bus message
getting lost.
> It is unclear (to me) how I should modify it (or my code,
> for that matter) to have it work with iwd.
You can start with iwd stand alone. iwd doesn't need ConnMan to be
around.
> # time ./test-connman scan wifi
> Traceback (most recent call last):
> File "./test-connman", line 152, in <module>
> technology.Scan()
> File "/usr/lib/python3.8/site-packages/dbus/proxies.py", line 72, in
> __call__
> File "/usr/lib/python3.8/site-packages/dbus/proxies.py", line 141, in
> __call__
> File "/usr/lib/python3.8/site-packages/dbus/connection.py", line 652, in
> call_blocking
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not
> receive a reply. Possible causes include: the remote application did not send
> a reply, the message bus security policy blocked the reply, the reply timeout
> expired, or the network connection was broken.
> Command exited with non-zero status 1
Yes, this looks like the problem I have seen.
> Related issue: I understood iwd is the new standard and
> it is developed alongside connman, but now I'm unsure.
iwd is handling WiFi devices in the same way BlueZ is handling the
Bluetooth devices.
> Please advise: is it a good choice to use iwd/connmand
> or should I revert to wpa_assistant and/or NetworkManager?
Depends on your situation. I clearly see iwd a way forward for
WiFi. wpa_supplicant is notorious hard to get working. It's possible
but you need good engineers to get problems sorted out. iwd does a lot
of things right and overall it's way simpler to use. If you just need
WiFi, use iwd without ConnMan or NetworkManager. If you have more
complex routing or want to switch from technology to another in a
dynamic way consider ConnMan or NetworkManager. For static setups you
could also just use systemd-networkd and iwd together.
> My needs are quite simple: I need to setup networking
> (single connection, *either* Ethernet *or* WiFi) using
> parameters provided over a serial line (currently in json
> format, but that is immaterial) *without* human intervention
> (no way to "ask for a passphrase" if one is not provided in
> the json packet).
For WiFi I strongly recommend to use iwd independ of the rest. With
iwd in place you can either use ConnMan to do the automatic switching
or you could build your soltution on to of iwd and
networkd-systemd. In this case you build your own connection manager.
In the past I would have recommended ConnMan to abstract from
wpa_supplicant but with iwd there is no need to have an UI centric
connection manager with a lot of logic build in you don't want or need.
Also don't have the Glib dependency. Safes a bit of space.
Thanks,
Daniel
------------------------------
Date: Thu, 5 Mar 2020 09:27:49 +0100
From: Michael Nazzareno Trimarchi <[email protected]>
Subject: Re: Connman apparently not working on my embedded target
To: Daniel Wagner <[email protected]>
Cc: Mauro Condarelli <[email protected]>, connman
<[email protected]>
Message-ID:
<CAOf5uwnVpA=n-skryl812_6ss88aarxe3qakwrgfe1vsz1k...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi
On Thu, Mar 5, 2020 at 9:24 AM Daniel Wagner <[email protected]> wrote:
>
> Hi Mauro,
>
> > # [ 7082.009030] ------------[ cut here ]------------
> > [ 7082.013743] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:443
> > 0x8037056c
> > [ 7082.020887] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed
> > out
> > [ 7082.027937] Modules linked in: mt7603e mt76 mac80211 cfg80211 mtk_eth
> > ehci_platform ehci_hcd usbcore usb_common
> > [ 7082.038206] CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-rc4 #2
> > [ 7082.044291] Stack : 00000000 8004e5fc 80490000 80415810 00000000
> > 00000000 00000000 00000000
> > [ 7082.052772] 00000000 00000000 00000000 00000000 00000000
> > 00000001 87c0bd78 80490000
> > [ 7082.061249] 87c0be10 00000000 00000000 00000000 00000038
> > 80407ca4 000000d8 00000000
> > [ 7082.069728] 203a6d6d 87c0bbdc 80510000 70617773 80490000
> > 00000000 00000009 00000009
> > [ 7082.078208] 80480560 87c0bf0c 8037046c 00000122 00000003
> > 802a7cbc 00000001 001d7f1f
> > [ 7082.086688] ...
> > [ 7082.089165] Call Trace:
> > [ 7082.089177] [<8004e5fc>] 0x8004e5fc
> > [ 7082.095185] [<80407ca4>] 0x80407ca4
> > [ 7082.098720] [<8037046c>] 0x8037046c
> > [ 7082.102254] [<802a7cbc>] 0x802a7cbc
> > [ 7082.105788] [<8000aa38>] 0x8000aa38
> > [ 7082.109321] [<8000aa40>] 0x8000aa40
> > [ 7082.112856] [<8001d69c>] 0x8001d69c
> > [ 7082.116390] [<8037056c>] 0x8037056c
> > [ 7082.119924] [<8037056c>] 0x8037056c
> > [ 7082.123456] [<8001d710>] 0x8001d710
> > [ 7082.126993] [<8037056c>] 0x8037056c
> > [ 7082.130527] [<80070274>] 0x80070274
> > [ 7082.134064] [<80060254>] 0x80060254
> > [ 7082.137596] [<8037046c>] 0x8037046c
> > [ 7082.141129] [<8006040c>] 0x8006040c
> > [ 7082.144665] [<80060c14>] 0x80060c14
> > [ 7082.148199] [<8000d84c>] 0x8000d84c
> > [ 7082.151732] [<800638e8>] 0x800638e8
> > [ 7082.155267] [<80060c88>] 0x80060c88
> > [ 7082.158801] [<804d0000>] 0x804d0000
> > [ 7082.162334] [<8040e0e0>] 0x8040e0e0
> > [ 7082.165875] [<80020740>] 0x80020740
> > [ 7082.169409] [<80005910>] 0x80005910
> > [ 7082.172939]
> > [ 7082.174449] ---[ end trace c89d8f4203b47d1a ]---
>
> This is a bug in the driver. Not much we can do in ConnMan.
>
> > [ 7082.179141] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
> > [ 7082.185770] mtk_soc_eth 10100000.ethernet eth0: Link is Down
> > [ 7082.206411] mtk_soc_eth 10100000.ethernet eth0: configuring for
> > fixed/mii link mode
> > [ 7082.229320] mtk_soc_eth 10100000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 7984.005249] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
> > [ 7984.011860] mtk_soc_eth 10100000.ethernet eth0: Link is Down
> > [ 7984.027073] mtk_soc_eth 10100000.ethernet eth0: configuring for
> > fixed/mii link mode
> > [ 7984.045472] mtk_soc_eth 10100000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 8884.002287] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
> > [ 8884.008898] mtk_soc_eth 10100000.ethernet eth0: Link is Down
> > [ 8884.024123] mtk_soc_eth 10100000.ethernet eth0: configuring for
> > fixed/mii link mode
> > [ 8884.042515] mtk_soc_eth 10100000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 9783.999653] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
> > [ 9784.006276] mtk_soc_eth 10100000.ethernet eth0: Link is Down
> > [ 9784.021499] mtk_soc_eth 10100000.ethernet eth0: configuring for
> > fixed/mii link mode
> > [ 9784.039883] mtk_soc_eth 10100000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
>
https://lkml.org/lkml/2019/12/30/161
Please refer here is you have this problem and the phy is the same.
The up and down can be
connected to a wrong reset of it
Michael
> Maybe related with the warning above? No idea. ConnMan doesn't
> oscillate unless there are kernel message. Does 'ip monitor' show
> anything useful?
>
> > Unfortunately this results in further problems.
> > Apparently this changes something in d-bus paths because
> > trying to issue a Scan() command results in a failure after
> > a very long wait.
> > My guess is test-connman tries to talk to wpa_supplicant
> > and, obviously, it gets no answer.
>
> test-connman always talks to the same ConnMan the D-Bus API. I think
> you see the abstraction leaking implementation details. Whereas
> wpa_supplicant immediately returns on scan request the iwd plugin
> doesn't reply immediately. It could also be something else. IIRC I
> have seen some error message scan request response D-Bus message
> getting lost.
>
> > It is unclear (to me) how I should modify it (or my code,
> > for that matter) to have it work with iwd.
>
> You can start with iwd stand alone. iwd doesn't need ConnMan to be
> around.
>
> > # time ./test-connman scan wifi
> > Traceback (most recent call last):
> > File "./test-connman", line 152, in <module>
> > technology.Scan()
> > File "/usr/lib/python3.8/site-packages/dbus/proxies.py", line 72, in
> > __call__
> > File "/usr/lib/python3.8/site-packages/dbus/proxies.py", line 141, in
> > __call__
> > File "/usr/lib/python3.8/site-packages/dbus/connection.py", line 652, in
> > call_blocking
> > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not
> > receive a reply. Possible causes include: the remote application did not
> > send a reply, the message bus security policy blocked the reply, the reply
> > timeout expired, or the network connection was broken.
> > Command exited with non-zero status 1
>
> Yes, this looks like the problem I have seen.
>
> > Related issue: I understood iwd is the new standard and
> > it is developed alongside connman, but now I'm unsure.
>
> iwd is handling WiFi devices in the same way BlueZ is handling the
> Bluetooth devices.
>
> > Please advise: is it a good choice to use iwd/connmand
> > or should I revert to wpa_assistant and/or NetworkManager?
>
> Depends on your situation. I clearly see iwd a way forward for
> WiFi. wpa_supplicant is notorious hard to get working. It's possible
> but you need good engineers to get problems sorted out. iwd does a lot
> of things right and overall it's way simpler to use. If you just need
> WiFi, use iwd without ConnMan or NetworkManager. If you have more
> complex routing or want to switch from technology to another in a
> dynamic way consider ConnMan or NetworkManager. For static setups you
> could also just use systemd-networkd and iwd together.
>
> > My needs are quite simple: I need to setup networking
> > (single connection, *either* Ethernet *or* WiFi) using
> > parameters provided over a serial line (currently in json
> > format, but that is immaterial) *without* human intervention
> > (no way to "ask for a passphrase" if one is not provided in
> > the json packet).
>
> For WiFi I strongly recommend to use iwd independ of the rest. With
> iwd in place you can either use ConnMan to do the automatic switching
> or you could build your soltution on to of iwd and
> networkd-systemd. In this case you build your own connection manager.
>
> In the past I would have recommended ConnMan to abstract from
> wpa_supplicant but with iwd there is no need to have an UI centric
> connection manager with a lot of logic build in you don't want or need.
> Also don't have the Glib dependency. Safes a bit of space.
>
> Thanks,
> Daniel
> _______________________________________________
> connman mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
------------------------------
Date: Thu, 5 Mar 2020 09:36:01 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [[PATCH v2 1/2] ofono: set network name from context name
To: Nicola Lunghi <[email protected]>
Cc: connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Nicola,
On Wed, Mar 04, 2020 at 10:43:40AM +0000, Nicola Lunghi wrote:
> previously connman was setting the network name using the netreg Name property
Start the sentence with a capital letter and use ConnMan instead of
connman.
> that value doesn't permit to know what context we are connected to.
>
> Set the network name from the context name instead
You didn't answer my question:
Could you please explain in the commit message why we don't need to
update the name netreg_properties_reply() callback? I'd like to
understand why it's safe to it later. I suppose the network hasn't
been registered to the core at this point? Though the updates from
oFono are not strictly ordered. So I am bit concerned that it's not
always working.
> ---
> plugins/ofono.c | 79 ++++++++++++++++++++++++-------------------------
> 1 file changed, 38 insertions(+), 41 deletions(-)
>
> diff --git a/plugins/ofono.c b/plugins/ofono.c
> index 82413b6..bb08cfd 100644
> --- a/plugins/ofono.c
> +++ b/plugins/ofono.c
> @@ -132,6 +132,7 @@ static GHashTable *context_hash;
>
> struct network_context {
> char *path;
> + char *name;
> int index;
> struct connman_network *network;
>
> @@ -293,6 +294,7 @@ static void network_context_unref(struct network_context
> *context)
> return;
>
> g_free(context->path);
> + g_free(context->name);
>
> connman_ipaddress_free(context->ipv4_address);
> g_free(context->ipv4_nameservers);
> @@ -1116,7 +1118,10 @@ static void add_network(struct modem_data *modem,
> connman_network_set_string(context->network, "Path",
> context->path);
>
> - if (modem->name)
> + /* we try first to use the context name as name, then the modem name */
> + if (context->name)
> + connman_network_set_name(context->network, context->name);
> + else if (modem->name)
> connman_network_set_name(context->network, modem->name);
> else
> connman_network_set_name(context->network, "");
> @@ -1152,6 +1157,23 @@ static void remove_network(struct modem_data *modem,
> context->network = NULL;
> }
>
> +static int set_context_name(struct network_context *context,
> + const char *name)
> +{
> + if (!context || !name)
> + return -EINVAL;
> +
> + g_free(context->name);
> + context->name = g_strdup(name);
> +
> + if(!context->name)
> + return -ENOMEM;
and you didn't fix this...
Thanks,
Daniel
------------------------------
Date: Thu, 5 Mar 2020 09:40:41 +0100
From: Daniel Wagner <[email protected]>
Subject: Re: [[PATCH v2 2/2] ofono: store context apn value
To: Nicola Lunghi <[email protected]>
Cc: connman <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Nicola,
On Wed, Mar 04, 2020 at 10:43:42AM +0000, Nicola Lunghi wrote:
> Storing the apn value will permit to expose this value via d-bus in
s/apn/APN/
s/d-bus/D-Bus/
> a later patch
No need to mention 'in a later patch'.
> ---
> plugins/ofono.c | 56 ++++++++++++++++++++++++++++++++-----------------
> 1 file changed, 37 insertions(+), 19 deletions(-)
>
> diff --git a/plugins/ofono.c b/plugins/ofono.c
> index bb08cfd..302ec57 100644
> --- a/plugins/ofono.c
> +++ b/plugins/ofono.c
> @@ -133,6 +133,7 @@ static GHashTable *context_hash;
> struct network_context {
> char *path;
> char *name;
> + char *apn;
> int index;
> struct connman_network *network;
>
> @@ -147,7 +148,6 @@ struct network_context {
> int refcount;
>
> bool active;
> - bool valid_apn; /* APN is 'valid' if length > 0 */
> };
>
> struct modem_data {
> @@ -295,6 +295,7 @@ static void network_context_unref(struct network_context
> *context)
>
> g_free(context->path);
> g_free(context->name);
> + g_free(context->apn);
>
> connman_ipaddress_free(context->ipv4_address);
> g_free(context->ipv4_nameservers);
> @@ -1174,6 +1175,27 @@ static int set_context_name(struct network_context
> *context,
> return 0;
> }
>
> +static context_apn_is_valid(struct network_context *context)
> +{
> + return ((context != NULL) &&
> + (context->apn != NULL) &&
> + (strlen(context->apn) > 0));
> +}
again from my last review:
return context && context->apn && strlen(context->apn);
> +
> +static int set_context_apn(struct network_context *context,
> + const char *apn_name)
If you don't check the return value, just make this funtion void.
> +{
> + if (!context || !apn_name)
> + return -EINVAL;
> +
> + g_free(context->apn);
> + context->apn = g_strdup(apn_name);
> +
> + DBG("%s Set context apn to %s", context->path, context->name);
> +
> + return 0;
> +}
> +
> static int set_context_ipconfig(struct network_context *context,
> const char *protocol)
> {
> @@ -1222,6 +1244,7 @@ static int add_cm_context(struct modem_data *modem,
> const char *context_path,
> dbus_bool_t active = FALSE;
> const char *ip_protocol = NULL;
> const char *ctx_name = NULL;
> + const char *apn_name = NULL;
>
> DBG("%s context path %s", modem->path, context_path);
>
> @@ -1262,16 +1285,11 @@ static int add_cm_context(struct modem_data *modem,
> const char *context_path,
> dbus_message_iter_get_basic(&value, &active);
>
> DBG("%s Active %d", modem->path, active);
> - } else if (g_str_equal(key, "AccessPointName")) {
> - const char *apn;
> -
> - dbus_message_iter_get_basic(&value, &apn);
> - if (apn && strlen(apn) > 0)
> - context->valid_apn = true;
> - else
> - context->valid_apn = false;
> -
> - DBG("%s AccessPointName '%s'", modem->path, apn);
> + } else if (g_str_equal(key, "AccessPointName") &&
> + dbus_message_iter_get_arg_type(&value) ==
> DBUS_TYPE_STRING)
> + {
Keep the bracket on the previous line.
> + dbus_message_iter_get_basic(&value, &apn_name);
empty line here.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 53, Issue 7
**************************************
