Send connman mailing list submissions to
connman@lists.01.org
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
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. RE: ConnMan sometimes shutting down, sometimes not restarting
(Craig McQueen)
2. Re: [PATCH] fixed Connect OperationAborted if it was issued
during some moment of autoscan (Daniel Wagner)
3. Re: [PATCH] reduce noisy error when we try to provision
hidden service from config file (Daniel Wagner)
4. Re: Default Gateway (Daniel Wagner)
5. Re: Ofono LTE modems and connman services (Daniel Wagner)
6. Re: connman does not see any wifi carriers after cycling
hardware rfkill button (Daniel Wagner)
7. Re: [PATCH v3] build: Add --disable-stats option (Daniel Wagner)
8. Re: DBus Signal for Address Conflict Detection (Daniel Wagner)
9. Re: Static Address for Ethernet interface (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Mar 2018 04:21:07 +0000
From: Craig McQueen <craig.mcqu...@innerrange.com.au>
To: Daniel Wagner <w...@monom.org>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Subject: RE: ConnMan sometimes shutting down, sometimes not restarting
Message-ID: <aaf6fb76b4594ed59dd3ec9b68c36...@innerrange.com.au>
Content-Type: text/plain; charset="utf-8"
Daniel Wagner wrote:
> Hi Craig,
> >
> > Jan 29 17:25:34 wt000043 daemon.err connmand[19746]: Inconsistent
> > IP pool management (start not found)
> >
> > Shortly after that message, ConnMan shuts down. Usually it restarts,
> > and everything is fine. But occasionally, ConnMan never restarts, and
> > the system has no network connectivity.
>
> If ConnMan crashes, something like systemd will probably restart.
> ConnMan can't restart itself.
Thanks for explaining. You are right, it turns out it is a system initscript
that was restarting ConnMan (due to a network configuration occurring shortly
after power-up). (I am using initscripts, not system.)
The initscript restart was doing a stop, then a sleep for 1 second, then a
start (this is an initscript from the Yocto project). But, the stop wasn't
actually waiting for connmand to shutdown, so when the start occurred, it
failed due to the not-yet-fully-stopped connmand that was still running.
I have improved the initscript so that the stop operation waits until connmand
really has stopped.
I should also mention, that with ConnMan 1.32, I simply never saw it restart.
With ConnMan 1.35, I saw the new instance of ConnMan SEGFAULT. Perhaps the
SEGFAULT is worth investigating.
> > Jan 29 17:25:34 wt000043 daemon.err connmand[19746]: Inconsistent
> > IP pool management (start not found)
>
> The error message indicates, that we have a problem finding a empty IP
> range in the private address space (192.168.0.0/16, ...).
>
> So we either have a bug in the code trying to find an empty block or the
> current network configuration is covering all the private address ranges and
> the logic can't find any block.
It seems that this error message was a red herring in my problem.
> > What might be a cause for this error? I see in the source code, function
> __connman_ippool_deladdr() contains:
> >
> > info = lookup_info(index, start);
> > if (!info) {
> > /* In theory this should never happen */
> > connman_error("Inconsistent IP pool management (start not
> found)");
> > return;
>
> Hard to tell without the log. Can you post the log output of ConnMan (or a
> post a link the log)? Also the output of 'ip addr' and 'ip route'
> would be handy.
My immediate problem is solved I think, but I would still be happy to provide
logs if you wish to diagnose the "Inconsistent IP pool management (start not
found)" error message. Would you like me to send logs?
--
Craig McQueen
------------------------------
Message: 2
Date: Thu, 8 Mar 2018 06:24:27 +0100
From: Daniel Wagner <w...@monom.org>
To: Vasyl Vavrychuk <vvavryc...@gmail.com>
Cc: connman@lists.01.org
Subject: Re: [PATCH] fixed Connect OperationAborted if it was issued
during some moment of autoscan
Message-ID: <c2cfeb94-1373-5314-a7b7-4680abfe1...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Vasyl,
On 03/02/2018 04:58 PM, Vasyl Vavrychuk wrote:
> Suppose there is Wi-Fi network X that is saved in connman. Consider
> the following scenario:
>
> 1. Autoscan is started by connman.
> 2. Network X will be marked as unavailable as result of
> connman_device_set_scanning(true).
> 3. Application issue connect to network X.
> 4. Connect to X starts and
> interface_state(G_SUPPLICANT_STATE_AUTHENTICATING) is received.
> 5. As result of this stop_autoscan >
> connman_device_set_scanning(false) > __connman_device_cleanup_networks
> is issued that free_network X because it was marked as unavailable.
> 6. It leads to network_remove > __connman_service_remove_from_network
>> connman_service_unref_debug > __connman_service_disconnect > ...
> reply_pending(ECONNABORTED)
Patch applied.
Thanks,
Daniel
------------------------------
Message: 3
Date: Thu, 8 Mar 2018 06:26:13 +0100
From: Daniel Wagner <w...@monom.org>
To: Vasyl Vavrychuk <vvavryc...@gmail.com>, connman@lists.01.org
Subject: Re: [PATCH] reduce noisy error when we try to provision
hidden service from config file
Message-ID: <0ba089c0-1fe5-2c98-79e0-80df06ef8...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Vasyl,
On 03/02/2018 04:58 PM, Vasyl Vavrychuk wrote:
> Before this change upon every scan of the hidden service we got
> "Network SSID not set" error in logs. This is because hidden services
> have no WiFi.SSID set.
>
> Changed function is try_provision_service from config file and of course
> we can not do this for hidden services without SSID so we can report
> ENOENT for them.
Patch applied.
Thanks,
Daniel
------------------------------
Message: 4
Date: Thu, 8 Mar 2018 06:43:29 +0100
From: Daniel Wagner <w...@monom.org>
To: Vasiu Alexandru <alexandru.va...@cnglsibiu.ro>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Subject: Re: Default Gateway
Message-ID: <752df88d-f019-b0b1-980c-b4e89912d...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Vasiu,
On 02/26/2018 03:18 PM, Vasiu Alexandru wrote:
> Hi,
>
> I have *2 PCs *with the following set-up:
> - both have 2 interfaces: eth0 and eth1
> *PC 1: *
>
> * Not connected to network
> * Has a *DHCP* Server with gives private IPs from 192.168.2.0/24
> <http://192.168.2.0/24>
> * Is connected to *PC 2 *through eth0 (eth0 PC 1 to eth0 PC 2)
>
> *PC? 2:*
>
> * eth0 has?IP from *DHCP* Server from *PC 1*
> * eth1 has IP from an intern network (also private, 10. ...)
>
> If I run "ip route show" on PC 2, it shows *2 default gateways* (one for
> eth0 and one for eth1) on *Ubuntu* and on a distribution with *connman*,
> it shows just *one default gateway *(eth 1).
>
> Questions:
>
> 1. Which is the normal behavior?
Obviously, having two default routes doesn't really make sense.
Basically, a default route means if any other routing rule doesn't match
take the default route. Though the kernel has some ways to differentiate
between two routing matching routing entries. There some metrics which
are used to decided which route it is to be used per frame. See [1] for
more information on this topic.
Although it is possible to have two default routes, it is rather
confusing and not intuitive from an user perspective. ConnMan clears the
routing table on startup. So any left overs from a previous setup or
ConnMan crash is removed first. Maybe you see a left over in the two
default route scenario.
> 2. If both interfaces have different?IPs from the same network there
> should be only one default gateway or one for each interface (with
> the same value)?
I would say there should only be one default route. In case you have
several different networks on the same computer (one or more interfaces)
you should have a routing entry per network.
For example I have connected via Ethernet and WiFi to my home network:
? ip r
default via 192.168.154.1 dev wlp2s0b1
192.168.154.0/24 dev wlp2s0b1 proto kernel scope link src 192.168.154.54
192.168.154.0/24 dev eth0 proto kernel scope link src 192.168.154.61
192.168.154.1 dev eth0 scope link
192.168.154.1 dev wlp2s0b1 scope link
So I have one default route which is over the WiFi interface and I have
a routing entry for each network per device.
Thanks,
Daniel
[1] http://linux-ip.net/html/routing-selection.html
------------------------------
Message: 5
Date: Thu, 8 Mar 2018 06:49:35 +0100
From: Daniel Wagner <w...@monom.org>
To: Denis Kenzior <denk...@gmail.com>, Marcel Holtmann
<mar...@holtmann.org>
Cc: Jonas Bonn <jo...@southpole.se>, of...@ofono.org,
"connman@lists.01.org" <connman@lists.01.org>
Subject: Re: Ofono LTE modems and connman services
Message-ID: <1c5b7a2b-b916-a896-3c6e-48969d9af...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 03/02/2018 06:15 PM, Denis Kenzior wrote:
>> A lot of the above comes from my understanding of what connman is trying
>> to do:? if it sees the state as Attached and has no Active contexts then
>> it starts trying to activate the first context.? Ideally, it would never
>> see an inactive context for LTE, at least not in the Attached state.
>> However, I may be missing something in my understanding of how this is
>> intended to work, so any clarification would be appreciated.
>
> Or it should give up if it sees the InProgress error, but yes it might
> be that re-ordering messages is the right approach. Daniel, Marcel?
I must admit, I am slightly confused. So we have a different behavior
pattern between UMTS/GSM and LTE networks which expresses itself in the
non ordering of Active and Attached?
Anyway, I don't have anything against ordering the events. Shouldn't be
to hard to update the plugin.
Thanks,
Daniel
------------------------------
Message: 6
Date: Thu, 8 Mar 2018 06:51:30 +0100
From: Daniel Wagner <w...@monom.org>
To: KARBOWSKI Piotr <piotr.karbow...@gmail.com>
Cc: Vasyl Vavrychuk <vvavryc...@gmail.com>, "connman@lists.01.org"
<connman@lists.01.org>
Subject: Re: connman does not see any wifi carriers after cycling
hardware rfkill button
Message-ID: <93e58e4f-bd60-35ff-8725-49cacd475...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Piotr,
On 03/03/2018 08:22 AM, Vasyl Vavrychuk wrote:
> try 'enable wifi' from connmanctl
>
> On Sat, Mar 3, 2018 at 9:07 AM, KARBOWSKI Piotr
> <piotr.karbow...@gmail.com> wrote:
>> On 2018-02-19 18:16, KARBOWSKI Piotr wrote:
>>>
>>> Hi,
>>>
>>> It appears that the momment I double tap fn+print screen (rfkill) hotkey
>>> (so, block followed by unblock), connman looses wifi support until restart.
>>> If I try to force scan via `scan wifi`, I get:
>>>
>>> connmanctl> scan wifi
>>> Error /net/connman/technology/wifi: No carrier
>>>
>>> I can confirm that `rfkill` reports all as unblocked.
>>>
>>> Any suggestion how can I make connman recovery after such event?
It is hard to give you feedback just from your description. The logs
from ConnMan would help a lot.
Thanks,
Daniel
------------------------------
Message: 7
Date: Thu, 8 Mar 2018 06:56:10 +0100
From: Daniel Wagner <w...@monom.org>
To: Chris Novakovic <ch...@chrisn.me.uk>
Cc: connman@lists.01.org
Subject: Re: [PATCH v3] build: Add --disable-stats option
Message-ID: <e08e42d7-4a5b-559d-e8b7-c16805bd8...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Chris,
On 03/04/2018 06:59 PM, Chris Novakovic wrote:
> Generation of interface statistics files can now be controlled at
> compile-time using the --{enable,disable}-stats configure options.
> Statistics files remain enabled by default.
>
> Based on an idea by Feng Wang <wan...@nestlabs.com>.
Patch applied.
Thanks,
Daniel
------------------------------
Message: 8
Date: Thu, 8 Mar 2018 07:03:48 +0100
From: Daniel Wagner <w...@monom.org>
To: Christian Spielberger <christian.spielber...@gmail.com>
Cc: connman@lists.01.org
Subject: Re: DBus Signal for Address Conflict Detection
Message-ID: <d7fc60ef-5b5f-4791-80bd-e3ca78439...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Chris,
On 03/06/2018 12:09 PM, Christian Spielberger wrote:
> Hello,
>
> I am currently working on address conflict detection. (Code will follow soon.)
> One task is to add a notification to application or user. Maybe a dbus signal
> would be an adequate form of notification for other processes, right?
>
> Maybe like connman_dbus_property_changed_basic in service.c?
That is a good question. The obvious way is to add a new property with a
good name (hard thing :)) to the Service API. Though I wonder what would
it tell me as user.
I see two cases (correct me please if I am wrong)
1) device is offline and we try to connect (static IP)
2) device is online and someone starts to use our IP
For 1) would say the return code of Connect() should be something
like 'boooh IP conflict, try again'. For 2) I am not sure what you want
to do. Just inform the user or disconnect the device?
If we just disconnect for 2) no new property is needed. But I expect you
tell me you don't want that :)
Thanks,
Daniel
------------------------------
Message: 9
Date: Thu, 8 Mar 2018 07:17:57 +0100
From: Daniel Wagner <w...@monom.org>
To: "Eswaran Vinothkumar (BEG/PJ-IOT-EL)"
<vinothkumar.eswa...@de.bosch.com>
Cc: "connman@lists.01.org" <connman@lists.01.org>
Subject: Re: Static Address for Ethernet interface
Message-ID: <fbcd52db-d970-a78b-2dca-85dc3ab6e...@monom.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Vinothkumar,
On 03/06/2018 01:13 PM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:
> Hi,
>
> I am using Connman in one of our internal IOT project. ?Connman version:1.35
>
> The hardware I am using has two Ethernet interfaces. To set up the
> static IP I run the following commands:
>
> ?connmanctl config ethernet_0001c01e6612_cable --ipv4 manual
> 192.168.1.40 255.255.255.0 192.168.0.1 --ipv6 off?
>
> ?connmanctl config ethernet_0001c01e6621_cable --ipv4 manual
> 192.168.1.45 255.255.255.0 192.168.0.1 --ipv6 off?
>
> This works without any problems and I can see the IP addresses being set
> as requested.
That is good to hear that something works ;)
> For the project I will be using 50 or more hardwares and manually
> setting IP for every hardware is bit annoying. It becomes more
> complicated when I use over the air software updates. Manual
> interruption is required everytime after software update to set up the
> static IP. Is there any config available within connman to set up the
> static IP for Ethernet inerfaces?
>
> I have looked into the connman-config documents and found out that I can
> set up the static IP by using a config file.
There are two ways to configure ConnMan. One way is via D-Bus (that is
would you use with connmanctl) and the second one is via the config files.
> [service_ethernet]
>
> Type = ethernet
>
> IPv4 = 192.168.1.40/255.255.255.0/192.168.1.1
>
> IPv6 = off
>
> I purposefully omitted the MAC address because the addresses will be
> unique for each hardware. But using this sets up the same IP address for
> both the Ethernet interfaces.
ConnMan tries to match the config entry to the hardware. The only real
'unique' identifier is the MAC. The next weaker match is the type
(ethernet).
If you want to stick to the config file approach you need to add the MAC
address to the entries.
> Is there any way to setup static IP
> without using MAC address in Connman? Any other proposal to solve the
> problem will also be helpful.
Obviously I am missing the big picture why you decided to configure each
device directly.
At work, we are using hawkbit [1] in combination with SWupdate [2] for
fleed and software updates management. Basically we don't care too much
about network configuration (using just DHCP for IPv4) and let the
devices fetch the software itself.
Daniel
[1] https://www.eclipse.org/hawkbit/
[2] https://github.com/sbabic/swupdate
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 29, Issue 8
**************************************
