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: The role of connection manager (Robert Tiemann)
2. Re: The role of connection manager (Robert Tiemann)
3. Re: The role of connection manager (JH)
4. Re: The role of connection manager (Julien Massot)
5. Stale Wifi service and network not being destroyed?
(Henrik Persson)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Feb 2019 09:38:45 +0100
From: Robert Tiemann <[email protected]>
To: JH <[email protected]>, connman <[email protected]>
Subject: Re: The role of connection manager
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 2/26/19 8:21 PM, JH wrote:
> Hi,
Hi!
> I am currently debating with my colleague about if it is necessary to
> use connection manager in a small embedded Linux device with network
> interfaces of LTE, WiFi and BLE.
Short answer: don't try implementing it your own way.
We are successfully using Connman in an embedded product with WiFi and
Ethernet. Connman does a good job at managing these two interfaces and
switches between them automatically without any issues. You should
also know that wpa_supplicant is pretty messy to deal with directly
(consider using iwd instead), and Connman does it already for you. So
that's a big time saver for your development. Also, Connman is not at
all restricted for use on the desktop; it's quite the other way
around: Connman can help you a lot with dealing with the complex
dynamics of network connectivity experienced on mobile devices which
are typically not an issue on the desktop computer. Desktops are
usually much simpler in this respect.
On the downside, you *have* to talk to Connman via D-Bus. There is no
C API for Connman. Your D-Bus options for C are libdbus (bugs, bugs,
bugs), GDBus (pulls GLib into your application, which is what we do
and hate), and sd-bus. For C++ there are a few other libraries and
wrappers around the C libraries, but we haven't tried any of them yet.
You could also try messing around with connmanctl (the command line
interface to Connman which uses D-Bus) or D-Bus command line tools
such as dbus-send or busctl to send your configuration to Connman. For
simple things this should work pretty well, but monitoring of changes
would be a bit challenging.
Anyway, we are quite satisfied with Connman. We had discussions about
using a network manager vs doing it by hand here as well (and
sometimes these discussions come up again when something goes wrong).
In retrospect, however, I'd say going with Connman was the right
decision. I wouldn't try to implement my own way of network
management, especially if there are multiple networking interfaces
involved. It can get really complex, and you would just end up
reimplementing parts of Connman, but with your own set of bugs which
you would have to solve all by yourself.
Whatever you do, however, do not try to mix Connman with manual
management. If you go with Connman, then you should use it exclusively
and avoid using external tools for network configuration.
> Thank you.
>
> JH
Best regards,
Robert
------------------------------
Message: 2
Date: Thu, 28 Feb 2019 09:50:03 +0100
From: Robert Tiemann <[email protected]>
To: JH <[email protected]>
Cc: connman <[email protected]>
Subject: Re: The role of connection manager
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 2/27/19 1:03 AM, JH wrote:
>> What connman gets you, primarily, is sane routing depending on
>> availability of the various types of connection. If WiFi isn't
>> available, connman can ask ofono to bring up the LTE connection and set
>> that up as the primary route. When WiFi becomes available, it can move
>> the default route to that. And so on... depending on your requirements.
>
> That is actually a key requirement for our application I am straggling
> to achieve it. My colleague argued we should do it manually using
> scripts, I think that is more than just networking interface scripts.
I like to stress at this point that scripting like in the good old
days will simply not work for your case. Scripts are fine for static
setups (servers, maybe desktops), but your case is highly dynamic.
There are way too many things to consider and things that could go
wrong to handle in a bunch of scripts. You have to *manage* your
networking in a proper, coordinated way.
Robert
------------------------------
Message: 3
Date: Thu, 28 Feb 2019 20:53:34 +1100
From: JH <[email protected]>
To: Robert Tiemann <[email protected]>
Cc: connman <[email protected]>
Subject: Re: The role of connection manager
Message-ID:
<CAA=hcWRQWnfeDmN0LQceVXAw=dajzfwubftndtbx4sjx_tj...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Robert,
Thanks for sharing your insight experience about connection manager
and ConnMan, the DBus was my original concern, it was designed for
desktop, but I hope that the ConnMan can manage the network interface
switching, we don't have to interact too much after setting up the
configure file in main.conf.
Are you able to set up WiFi SSID and Password via ConnMan C API? I was
using the wap_supplicant shell commands in C++ program, that was a
little bit mess, I wish I can change to use ConnMan API in my C++
program.
Thank you very much and appreciate your comments.
Kind regards,
- jupiter
> Short answer: don't try implementing it your own way.
> On the downside, you *have* to talk to Connman via D-Bus. There is no
> C API for Connman. Your D-Bus options for C are libdbus (bugs, bugs,
> bugs), GDBus (pulls GLib into your application, which is what we do
> and hate), and sd-bus. For C++ there are a few other libraries and
> wrappers around the C libraries, but we haven't tried any of them yet.
------------------------------
Message: 4
Date: Thu, 28 Feb 2019 11:18:01 +0100
From: Julien Massot <[email protected]>
To: JH <[email protected]>
Cc: Robert Tiemann <[email protected]>, connman <[email protected]>
Subject: Re: The role of connection manager
Message-ID:
<CADGp=qegzat365cnsgyy60cd-cjs3bfb-m9dkamrs8o1pyb...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Jupiter,
10 years ago I did an api/library to generate wpa_s conf, just don't
do that, it will not
match your customer requirements, and I was saved by connman project.
I totally agree with Robert comment, configuring wpa_s is time consuming,
but having a wifi connection "which just works" imply more than just writing
a wpa_s configuration file.
You will have to deal with dhcp most likely and route management,
having script for that is
not my recommended way.
ConnMan does that nicely.
Dbus is no longer a desktop only bus, i don't know how small is your
embedded system,
but it should not be a big deal to add it.
I personnaly use glib GIO for dbus communication that's not a big deal
but surely it will take you weeks,
to implement things correctly.
If you are familar with python, I suggest you to do a first draft
using it since communication with dbus is really easy,
and there is example in ConnMan source code which will help you.
About why using a connection manager for an embedded system, then you
know ConnMan never take his place
on desktop distro AFAIK, so it's mostly used in embedded system and
firstly designed for.
After all, you are on ConnMan mailing list:
Who will say that ConnMan is not the way to go,
and you can do what people did here in 10 year using shell script :) ?
Julien
--
*This email and any attachment thereto are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, please be advised that disclosing,
copying, distributing or taking any action in reliance on the contents of
this email is strictly prohibited. In such case, please immediately advise
the sender, and delete all copies and attachment from your system.
This
email shall not be construed and is not tantamount to an offer, an
acceptance of offer, or an agreement by SoftBank Robotics Europe on any
discussion or contractual document whatsoever. No employee or agent is
authorized to represent or bind SoftBank Robotics Europe to third parties
by email, or act on behalf of SoftBank Robotics Europe by email, without
express written confirmation by SoftBank Robotics Europe? duly authorized
representatives.
*
*Ce message ?lectronique et ?ventuelles pi?ces
jointes sont confidentiels, et exclusivement destin?s ? la personne ou
l'entit? ? qui ils sont adress?s.
Si vous n'?tes pas le destinataire vis?,
vous ?tes pri? de ne pas divulguer, copier, distribuer ou prendre toute
d?cision sur la foi de ce message ?lectronique. Merci d'en aviser
imm?diatement l'exp?diteur et de supprimer toutes les copies et ?ventuelles
pi?ces jointes de votre syst?me.
Ce message ?lectronique n'?quivaut pas ?
une offre, ? une acceptation d?offre, ou ? un accord de SoftBank Robotics
Europe sur toute discussion ou document contractuel quel qu?il soit, et ne
peut ?tre interpr?t? comme tel. Aucun employ? ou agent de SoftBank Robotics
Europe n'est autoris? ? repr?senter ou ? engager la soci?t? par email, ou ?
agir au nom et pour le compte de la soci?t? par email, sans qu?une
confirmation ?crite soit donn?e par le repr?sentant l?gal de SoftBank
Robotics Europe ou par toute autre personne ayant re?u d?l?gation de
pouvoir appropri?e.
*
**
------------------------------
Message: 5
Date: Thu, 28 Feb 2019 11:17:12 +0000
From: Henrik Persson <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Stale Wifi service and network not being destroyed?
Message-ID:
<he1pr1001mb1226b2b0f521165e015d5200f7...@he1pr1001mb1226.eurprd10.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I'm doing some post mortem of a connman process which started to behave
strangely and didn't manage to connect to the Wifi network it should have
connected to for a week (before I forced?a core dump and restarted it,?which
made everything work again). The error returned to the other process over
DBus after calling service.Connect() was -EIO, which after some investigation
into the source code seems to indicate that the error originates from
service_complete().
Digging into the core dump I found some things that could explain the error:
(gdb) print ((struct connman_service *)(service_list->next->next->data))->name
$157 = 0x1714f38 "B<snip>-2G"
(gdb) print ((struct connman_service
*)(service_list->next->next->data))->network
$158 = (struct connman_network *) 0x1722588
(gdb) print ((struct connman_service
*)(service_list->next->next->data))->network->device
$159 = (struct connman_device *) 0x0
(gdb) print ((struct connman_service
*)(service_list->next->next->data))->network->driver
$160 = (struct connman_network_driver *) 0x0
(gdb) print ((struct connman_service
*)(service_list->next->next->data))->network->name
$161 = 0x17224b8 "B<snip>-2G"
network->{driver,device} being NULL explains why -EIO is returned. I'm thinking
that should not happen. I also found another connman_network when digging
into what the supplicant interface was seeing, and that's not the same network
that the service holds a reference to..
(gdb) print ((struct connman_network *)((struct wifi_data
*)((GSupplicantInterface
*)interface_table->values[1])->data)->networks[0]->next->next->next->next->next->next->next->next->next->next->next->data)->name
$168 = 0x173cc30 "B<snip>-2G"
(gdb) print ((struct connman_network *)((struct wifi_data
*)((GSupplicantInterface
*)interface_table->values[1])->data)->networks[0]->next->next->next->next->next->next->next->next->next->next->next->data)
$169 = (struct connman_network *) 0x172d310
So, I don't have any logs that tells me anything useful since debugging was not
enabled, but I do have the core dump. It sort of feels like a missing deref on
that
service somewhere.
Monitoring dbus during a connection attempt:
? Type=method_call Endian=l Flags=0 Version=1 Priority=0 Cookie=239369
Sender=:1.12 Destination=net.connman
Path=/net/connman/service/wifi_24[..snip..]3247_managed_psk
Interface=net.connman.Service Member=Connect
UniqueName=:1.12
MESSAGE "" {
};
? Type=signal Endian=l Flags=1 Version=1 Priority=0 Cookie=530610
Sender=:1.10 Path=/net/connman/service/wifi_24[..snip..]3247_managed_psk
Interface=net.connman.Service Member=PropertyChanged
UniqueName=:1.10
MESSAGE "sv" {
STRING "State";
VARIANT "s" {
STRING "idle";
};
};
? Type=method_call Endian=l Flags=0 Version=1 Priority=0 Cookie=530611
Sender=:1.10 Destination=:1.12 Path=/ Interface=net.connman.Agent
Member=RequestInput
UniqueName=:1.10
MESSAGE "oa{sv}" {
OBJECT_PATH "/net/connman/service/wifi_24[..snip..]3247_managed_psk";
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "Passphrase";
VARIANT "a{sv}" {
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "Type";
VARIANT "s" {
STRING "psk";
};
};
DICT_ENTRY "sv" {
STRING "Requirement";
VARIANT "s" {
STRING "mandatory";
};
};
DICT_ENTRY "sv" {
STRING "Alternates";
VARIANT "as" {
ARRAY "s" {
STRING "WPS";
};
};
};
};
};
};
DICT_ENTRY "sv" {
STRING "WPS";
VARIANT "a{sv}" {
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "Type";
VARIANT "s" {
STRING "wpspin";
};
};
DICT_ENTRY "sv" {
STRING "Requirement";
VARIANT "s" {
STRING "alternate";
};
};
};
};
};
};
};
? Type=method_return Endian=l Flags=1 Version=1 Priority=0 Cookie=239370
ReplyCookie=530611
Sender=:1.12 Destination=:1.10
UniqueName=:1.12
MESSAGE "a{sv}" {
ARRAY "{sv}" {
DICT_ENTRY "sv" {
STRING "Passphrase";
VARIANT "s" {
STRING <redacted>;
};
};
};
};
? Type=signal Endian=l Flags=1 Version=1 Priority=0 Cookie=530612
Sender=:1.10 Path=/net/connman/service/wifi_24[..snip..]3247_managed_psk
Interface=net.connman.Service Member=PropertyChanged
UniqueName=:1.10
MESSAGE "sv" {
STRING "State";
VARIANT "s" {
STRING "failure";
};
};
? Type=error Endian=l Flags=1 Version=1 Priority=0 Cookie=530613
ReplyCookie=239369
Sender=:1.10 Destination=:1.12
ErrorName=net.connman.Error.Failed ErrorMessage="Input/output error"
UniqueName=:1.10
MESSAGE "s" {
STRING "Input/output error";
};
? Type=method_call Endian=l Flags=0 Version=1 Priority=0 Cookie=239371
Sender=:1.12 Destination=net.connman
Path=/net/connman/service/wifi_24[..snip..]3247_managed_psk
Interface=net.connman.Service Member=Remove
UniqueName=:1.12
MESSAGE "" {
};
? Type=method_return Endian=l Flags=1 Version=1 Priority=0 Cookie=530614
ReplyCookie=239371
Sender=:1.10 Destination=:1.12
UniqueName=:1.10
MESSAGE "" {
};
And that's about all I got so far, but it was stuck in this state for at least
a week and a new wifi scan was triggered periodically during that time.
Any pointers, suggestions, comments, etc that could either tell me that
I'm doing something wrong interacting with connman, or where to look
further?
I'm on connman 1.35 btw because of reasons, but I didn't find anything
in the connman history since that point that should have fixed this. But
I'm gladly proven wrong.
Thanks,
--
Henrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 40, Issue 15
***************************************
