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: Unsalble cellular connection (Daniel Wagner)
2. Re: Propose patch for perpetual online check for connected
services (Daniel Wagner)
3. Re: [PATCH] vpn-provider: Do not add unsupported
configuration (Daniel Wagner)
4. Re: Alignment Trap Question (Daniel Wagner)
5. Re: DBus Unknown Method (connman & Qt) (Daniel Wagner)
6. Re: Waking from sleep, don't re-associate (Daniel Wagner)
7. Re: Sending DHCP release on incorrect iface when iface goes
down (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Thu, 15 Aug 2019 13:33:56 +0200
From: Daniel Wagner <[email protected]>
To: Jonas Bonn <[email protected]>, JH <[email protected]>
Cc: connman <[email protected]>, Giacinto Cifelli
<[email protected]>, "[email protected]" <[email protected]>
Subject: Re: Unsalble cellular connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
On 8/14/19 3:00 PM, Jonas Bonn wrote:
> Well, the log _seemed_ to indicate that connman does an NTP request to a
> server that isn't available and thereby decides to take the link down...
NTP lookup failures won't trigger a disconnect. As long oFono or the
kernel via RNTL changes the state ConnMan doesn't change the routing.
> off the top of my head I can't say whether that's something connman
> actually does so hopefully somebody else will jump in here.? Did ofono
> indicate the context as still established after that?
Mabye checking what monitor-ofono shows.
> Seeing the issue with complete logs would be useful.? I thought your
> previous logs indicated connman trying to deactivate the context when it
> took the link down, but the ofono logs didn't show any of that... what's
> going on there?
Yes, that is a good question. If oFono doesn't tell ConnMan anything,
then ConnMan reacts to a state change of the device.
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 15 Aug 2019 13:58:00 +0200
From: Daniel Wagner <[email protected]>
To: Aleksandar Mitev <[email protected]>
Cc: [email protected]
Subject: Re: Propose patch for perpetual online check for connected
services
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Aleksandar,
On 8/7/19 2:56 PM, Aleksandar Mitev wrote:
> I would like to propose adding an additional config option to the main
> config file of connman that would enable continuous recheck of the
> internet connectivity for the current default connection. It would solve
> the problem of losing internet connectivity after choosing the default
> connection, due to router malfunction etc., which may result in the
> system running connman in staying offline for indefinite time. The
> option defines interfaces on which such a recheck is enabled, because
> some of them may have too expensive data plans to permit for such
> regular checks.
I am bit lost, e.g. what do you mean with the last sentence. I read
checking for online connectivity is too expensive, so let's do regular
check. Can you elaborate a bit on your use case?
> The config option goes like this:
> # List of network interfaces that will continuously check
> # for online connectivity, separated by ",".
> # Services will check whether the interface they use is
> # into this list and if so will conduct online state check
> # regularly once Online state is reached. When in Online state
> # but due to lack of internet connectivity the service is
> # downgraded to a Ready state giving the chance of other
> # configured services to take over.
> # This feature depends on EnableOnlineCheck = true.
> # Default value is empty.
> # InterfacesPerpetualOnlineCheck = vmnet,vboxnet,virbr,ifb,ve-,vb-
Okay I might remember wrong. Currently we do only do the online check
when the link is setup, right? So adding the missing code which
constantly checks for online connectivity is just missing. With that we
would also get automatic downgrade (missing feature). IIRC this feature
is exists in Jolla version of ConnMan [1].
If possible I would like to avoid adding another config variable. Makes
it even more complex to handle it, let alone to test. It looks like I
need to understand first what you are trying to solve here.
[1] https://git.merproject.org/mer-core/connman
> Attached is the proposed patch (based on tag 1.37).
The patches were attached to this mail. Did you use git send-email to
send out the patches?
> Would be happy to read your feedback for this is my first proposal for
> change to connman :)
Welcome! I am sorry to response to many emails rather late. Not much
space between work and a lot of other hobbies :)
Thanks,
Daniel
------------------------------
Message: 3
Date: Thu, 15 Aug 2019 13:59:11 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Subject: Re: [PATCH] vpn-provider: Do not add unsupported
configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 8/8/19 8:41 AM, Daniel Wagner wrote:
> Remove provider from the hash table if provider_probe() fails.
>
> connman-vpn will crash when trying to add all connections to a D-Bus
> message in append_connection_structs(). The not fully initilized
> struct vpn_provider has no valid path for example.
>
> Avoid this by undoing what the vpn_provider_get() function does.
Patch applied.
------------------------------
Message: 4
Date: Thu, 15 Aug 2019 14:03:41 +0200
From: Daniel Wagner <[email protected]>
To: "Bair, Richard" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Alignment Trap Question
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Richard,
On 8/9/19 4:38 PM, Bair, Richard wrote:
> Hello and thanks for reading.
>
> We have an IMX-53 embedded system and we?re using connmand 1.35 as it
> comes in our BSP (yocto sumo using a variscite SOM).? We?re seeing an
> occasional alignment trap error as follows:
>
> ??? Aug ?6 01:51:54 var-som-mx6 daemon.warn connmand[506]: ipconfig
> state 3 ipconfig method 1
> ??? Aug ?6 01:51:54 var-som-mx6 user.err kernel: Alignment trap: not
> handling instruction e8532f00 at [<75ab4796>]
> ??? Aug ?6 01:51:54 var-som-mx6 user.alert kernel: Unhandled fault:
> alignment exception (0x011) at 0x5fc3fe07
> ??? Aug ?6 01:51:54 var-som-mx6 user.alert kernel: pgd = 86e34000
> ??? Aug ?6 01:51:54 var-som-mx6 user.alert kernel: [5fc3fe07]
> *pgd=179e6831, *pte=138be75f, *ppte=138bec7f
Urgh, it seems ConnMan should be tested on ARM. Do you know how to
reproduce this?
> Questions:
>
> 1. Does anyone know if this type of an issue was resolved in connmand
> 1.36 or 1.37?
Not likely.
> 2. As we have a release near-term and some BSPs use older libraries are
> any major distributions adoption 1.36 or 1.37 at this time?
From what I have seen most distro do update ConnMan normally. But maybe
due to our slow release cycle and the distro release dates they ship a
slightly older version.
Thanks,
Daniel
------------------------------
Message: 5
Date: Thu, 15 Aug 2019 14:07:32 +0200
From: Daniel Wagner <[email protected]>
To: "Bair, Richard" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: DBus Unknown Method (connman & Qt)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Richard,
On 8/9/19 4:47 PM, Bair, Richard wrote:
> Hello and thanks for reading.? I have an IMX53 embedded system using
> connman 1.3.5.? Occasionally I see this error:
>
> ??? Aug ?7 16:10:14 var-som-mx6 daemon.warn connmand[332]: ipconfig
> state 2 ipconfig method 1
> ??? Aug ?7 16:10:15 var-som-mx6 daemon.warn connmand[332]: ipconfig
> state 7 ipconfig method 1
>
> ? ??Aug ?7 16:10:15 var-som-mx6 auth.notice dbus-daemon[276]: [system]
> Rejected send message, 1 matched rules; type="error", sender=":1.12"
> (uid=0 pid=617 comm="Variscite -platform eglfs ") interface="(unset)"
> member="(unset)" error
>
> ????name="org.freedesktop.DBus.Error.UnknownMethod
>
> So we?re using Qt which leverages connman for the network manager.? The
> communications occur via DBus.? My hunch this is likely an issue on the
> Qt side whereby they are using a deprecated function of connman but not
> sure.? Any advice appreciated.
I would fingerpoint to the Qt binding. Is the pid the one of form you
application, right?
Thanks,
Daniel
------------------------------
Message: 6
Date: Thu, 15 Aug 2019 14:15:20 +0200
From: Daniel Wagner <[email protected]>
To: Christo Labuschagne <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Waking from sleep, don't re-associate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Christo,
On 8/13/19 9:00 AM, Christo Labuschagne wrote:
> Good day.
>
> We are using connman (1.37) on embedded linux (4.17) mobile platform
> with wpa_supplicant (2.6) even tried with IWD (0.19).? As it is a
> battery powered device, we would like to be asleep as much as possible.
> We would wake with an RTC timer to re-register on the server, but every
> time we wake, connman restarts the wifi connection which then takes the
> connection down, then up, then get new DHCP ip address.
Is this how
> something like android or iOS would do it when trying to maintain a push
> notification connection?
ConnMan was initially target to hand held devices, smartphones etc. So
it mimicks the behavior of the connection manager from iOS or Android.
> This process takes at least 5 seconds of
> valuable battery time every time I wake.
5 seconds is a long time for sure. Do you know why it takes so long? I
don't expect that ConnMan does a lot of work. Some state machine updates
but that doesn't take a long time. Have a close look on what happens
between ConnMan and wpa_supplicant.
> If I set up the connection from the command line and then assume we are
> connected in our application, we can wake, register and sleep again
> within less than 2 seconds, but then we are not relying on connman to
> handle the connection, which is then pointless.
Indeed.
> Some more info on the setup:
>
> ?We are listening on dbus.
>
> ?Waking and sleeping via wakelocks.
>
> ?Sleeping to s2idle state at this stage, but will be going to deeper
> state later.
>
> ?With iw we set wowlan pattern to wake us when a message from server
> comes in.
>
> ?For current testing we are stationary and waking every 30s.
Sounds like a reasonable setup. One thing you could do is to add time
stamps to the log entries from ConnMan. This should point to where it
takes so long (connmand -d 2>&1 | ts '[%H:%M:%.S]' | tee connman.log)
Thanks,
Daniel
------------------------------
Message: 7
Date: Thu, 15 Aug 2019 14:24:32 +0200
From: Daniel Wagner <[email protected]>
To: Joakim Lotseng?rd <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Sending DHCP release on incorrect iface when iface goes
down
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Joakim,
On 8/14/19 9:17 AM, Joakim Lotseng?rd wrote:
> Good morning!
>
> We have seen problems of a DHCP RELEASE packet being sent on incorrect
> interface (eth0) when another interface (mlan0) goes down. I have sadly
> not had time yet to completely debug this. I apologize in advance for
> not having time to test my theory properly. I would like to ask if
> someone else has observed this problem to aid my debugging.
>
> We have an embedded Linux device that has Ethernet (wired), WiFi and
> cellular uplink connections. (It also has wifi downlink/AP interfaces
> that are not controlled by connman.) This error can be reproduced by
> having just ethernet (eth0 in our case) and WiFi (mlan0 in our case)
> connected. It works with the cellular interface as well, instead of WiFi.
>
> Setup a running tcpdump on ethernet eth0 for DHCP packets. When down the
> mlan0 (wifi) interface. You will then see the DHCP release packet for
> the IP on mlan0 (wifi) interface goes out on eth0. To make matters
> worse, they are sent with the srcIP of eth0 (correct) but the dstIP is
> the DHCP-server what was on mlan0 (wifi). The srcIP is probably correct
> due to the SNAT-rule that connman added in iptables -t nat. If that rule
> is removed, the incorrect srcIP of the old mlan0's IP is used.
>
> My conclusion here is that connman kind of "correctly" detects the
> downed mlan0 interface and wants to cancel its DHCP lease. It creates
> the DHCP release packet correct, with correct srcIP (of the downed
> iface) and dstIP of the DHCP-server that leased us the IP. The bad part
> is that now the interface is down. Linux kernel will do its best to
> route out the packet. It takes the default path (eth0) and sends it out.
> In our case we do have ip_forward enabled due to internal NATing in the
> device.
>
> A small reservation here that we do have other complex routing setup in
> our device. We have for example downlink wifi interfaces as well and are
> routing/NAT in a non straight forward setup. I have not had the time yet
> to disable all those things and re-test.
>
> I will try to investigate this further but wanted to ask if someone else
> seen this issue. My guess is that a fix is to not send the DHCP release
> if the interface we want to release the IP for is down. It kind of makes
> sense. There must be very few cases where the DHCP release packet can be
> routed to the correct DHCP-server via another interface.
Without looking at the code I suspect, that the DHCP release is trigger
from the interface take down unconditionally.
That is when the interface goes down (user interaction) we send the DHCP
release. This works in the right order.
But when the interface goes down first we still try to send out the DCHP
release not checking if the interface is still up.
> connman version used is latest 1.37. However, we tested older of our
> firmwares and (at least) 1.36 has the problem as well.
Likely.
> Some debugging output:
> (I've hidden the true IP of eth0 due to privacy.)
>
> Run and wait for output in one terminal: (Dump ethernet)
> $ tcpdump -envvvs 0 -i eth0 "udp and (port 68 or port 67)"
>
> In another terminal run: (Take down a connected wifi interface)
> $ ip link set dev mlan0 down
>
> The first terminal gives us this:
> 10:32:14.802697 00:23:c1:1a:54:11 > 58:97:bd:24:bb:48, ethertype IPv4
> (0x0800), length 590: (tos 0x0, ttl 64, id 34388, offset 0, flags [DF],
> proto UDP (17), length 576)
> 172.X.Y.12.68 > 192.168.1.1.67: [bad udp cksum 0xe011 -> 0x3d80!]
> BOOTP/DHCP, Request from 24:c3:f9:00:08:89, length 548, xid 0x6eecdf95,
> Flags [none] (0x0000)
> Client-IP 192.168.1.100
> Client-Ethernet-Address 24:c3:f9:00:08:89
> Vendor-rfc1048 Extensions
> Magic Cookie 0x63825363
> DHCP-Message Option 53, length 1: Release
> Server-ID Option 54, length 4: 192.168.1.1
> END Option 255, length 0
> PAD Option 0, length 0, occurs 298
>
> IP 172.X.Y.12 is the IP of eth0. 192.168.1.0/24 is (was) the network of
> mlan0.
>
> If i run iptables -t nat -F (clear the nat tables) the dump is:
> root@lev-26F7A6CY:/usr/sbin# tcpdump -envvvs 0 -i eth0 "udp and (port 68
> or port 67)"
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
> 262144 bytes
> 11:45:13.316968 00:23:c1:1a:54:11 > 58:97:bd:24:bb:48, ethertype IPv4
> (0x0800), length 590: (tos 0x0, ttl 64, id 31652, offset 0, flags [DF],
> proto UDP (17), length 576)
> 192.168.1.100.68 > 192.168.1.1.67: [bad udp cksum 0x85f3 ->
> 0xf9f3!] BOOTP/DHCP, Request from 24:c3:f9:00:08:89, length 548, xid
> 0x36bfb56d, Flags [none] (0x0000)
> Client-IP 192.168.1.100
> Client-Ethernet-Address 24:c3:f9:00:08:89
> Vendor-rfc1048 Extensions
> Magic Cookie 0x63825363
> DHCP-Message Option 53, length 1: Release
> Server-ID Option 54, length 4: 192.168.1.1
> END Option 255, length 0
> PAD Option 0, length 0, occurs 298
>
> IP-addresses of the device when both eth0 and mlan0 was up:
> wwan0 and wwan1 are cellular, and not used in my test. uap0 is
> downlink/AP wifi interface, not handled by connman.
>
> root@lev-26F7A6CY:~# ip a s
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,DYNAMIC,UP,LOWER_UP> mtu 1500 qdisc mq
> state UP group default qlen 1000
> link/ether 00:23:c1:1a:54:11 brd ff:ff:ff:ff:ff:ff
> inet 172.X.Y.12/24 brd 172.X.Y.255 scope global eth0
> valid_lft forever preferred_lft forever
> 18: mlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> group default qlen 1000
> link/ether 24:c3:f9:00:08:89 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.100/24 brd 192.168.1.255 scope global mlan0
> valid_lft forever preferred_lft forever
> 19: uap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> group default qlen 1000
> link/ether 24:c3:f9:00:08:8a brd ff:ff:ff:ff:ff:ff
> inet 192.168.5.1/24 scope global uap0
> valid_lft forever preferred_lft forever
> 20: uap1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether 00:50:43:02:00:01 brd ff:ff:ff:ff:ff:ff
> 21: wwan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether fa:96:11:12:13:14 brd ff:ff:ff:ff:ff:ff
> 22: wwan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether fa:96:11:12:13:16 brd ff:ff:ff:ff:ff:ff
>
> I can easily get the full debug output of connman when I take the mlan0
> interface down, if needed. However it was a loooong output to post in a
> mail. I might also need to scrub the log from private data (IPs).
>
> Also, I have no idea why tcpdump thinks the UDP-packet has incorrect
> chksum. The error was discovered due to an ISP reacting to getting
> incorrect DHCP-releases from customers using our devices.
Maybe due to checksum offloading?
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 46, Issue 11
***************************************
