Why can't connman automatically enable and connect to cellular network interface?
by JH
Hi,
I installed oFono plugin to an embedded system where the cellular is
used, I suppose that the connman should automatically enable and
connect to cellular when it first time boot up, it didn't, I have to
manually run the connmanctl command to enable and to connect it. In a
product due to limited Flash storage size, I'll not install connmanctl
and there will be no manual interactive process, how can I set up
connman to automatically enable and connect to cellular network
interface?
Thank you.
Kind regards,
- jupiter
7 months
Sending DHCP release on incorrect iface when iface goes down
by Joakim Lotsengård
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.
connman version used is latest 1.37. However, we tested older of our
firmwares and (at least) 1.36 has the problem as well.
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.
Best regards,
Joakim Lotsengård
10 months, 3 weeks
[PATCH 0/6] Re: Propose patch for perpetual online check for connected services
by aleksandar＠analyticsfire.com
From: Aleksandar Mitev <shondll(a)yahoo.com>
Hi Daniel,
So nice to hear from you :)
Ok, let me describe our use case that led me to come up with the proposed change:
We have a setup with Ethernet, Wifi and Cellular and want to have Internet access
in any case. This would mean that if an interface fails or doesn't have Internet
reachability, a switchover should be made to the next one. Of course, Ethernet
is the most preferred, falling back to Wifi, and if Wifi is not reliable source
of Internet, then go to the last resort of Cellular.
Everything is running fine with the current version of connman, except that, if,
for example, Ethernet is the current default source of Internet, and the router
we are connected to, stops routing packets for some reason, then we lose Internet
connectivity and our connection the device is no longer active.
But connman would not react and continue using the Ethernet connecion. I have seen
this on my Android phone as well: when I am connected with Wifi and the ISP
decides to cut my router's Internet access, then the phone would not switch to cellular
and no application would recieve notifications for indefinite time.
So my proposed change is to monitor the internet reachability at regular intervals,
using the same technique that connman uses now at the connecting phase. However,
since this checking will eat some data inevitably, we would not want to run it
on the cellular connection, at least (which is last resort anyway and no fallback
can be made). That is why the config option I added is based on network interfaces,
allowing you to choose only those devices that would make sence to continuously
check for Internet reachability.
*************
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?
I hope the above info is descriptive enough. I am avaialable for more
details if needed.
>> 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
I was not familiar with this fork of connman. Did not test it but looked
at the code and I did not find the continuous check after the service goes to
ONLINE state. I may be missing smth here, though.
As for the config option - sure, it could be removed (meaning that all
interfaces would be treated as enabled for checks) or reduces to a
simple global switch that would enable continuous online check after
going to the ONLINE state. However, please consider the usefulness of
our use case here.
>> 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?
No, I just used my email client. Now using the git send mail. Hope this
is the right way to send patch proposals along.
>> 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 :)
Thank you!
No problem, since it is holiday season, anyway. My response comes a bit
late as well, so sorry abot that as well.
Thanks again for starting the discusstion on the proposed change.
Best,
Aleksnadar
******
Aleksandar Mitev (6):
Added a config option for perpetual online check
Added check if the device is in InterfacesPerpetualOnlineCheck
Exported device getter for the network object
Added flag in service object to determinte perpetual online check
Added logic to perform perpetual online checks
Added timeout to socket connections
gweb/gweb.c | 32 +++++++++++++++++
include/device.h | 1 +
src/connman.h | 1 +
src/device.c | 27 +++++++++++++++
src/main.c | 26 ++++++++++++++
src/main.conf | 12 +++++++
src/network.c | 5 +++
src/service.c | 90 +++++++++++++++++++++++++++++++++++++++++++++---
8 files changed, 190 insertions(+), 4 deletions(-)
--
2.17.1
11 months
[PATCH] gresolv: fix ASAN runtime error.
by Mickael GARDET
../git/gweb/gresolv.c:331:7: runtime error: left shift of 169 by 24
places cannot be represented in type 'int'
connmand2[3417]: eth0 {add} route 192.168.2.0 gw 0.0.0.0 scope 253 <LINK>
---
gweb/gresolv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gweb/gresolv.c b/gweb/gresolv.c
index 38a554e0..02f2df91 100644
--- a/gweb/gresolv.c
+++ b/gweb/gresolv.c
@@ -315,7 +315,7 @@ static int match_gai_table(struct sockaddr *sa,
const struct gai_table *tbl)
}
}
-#define DQUAD(_a,_b,_c,_d) ( ((_a)<<24) | ((_b)<<16) | ((_c)<<8) | (_d) )
+#define DQUAD(_a,_b,_c,_d) ( (((guint32)_a)<<24) | ((_b)<<16) |
((_c)<<8) | (_d) )
#define V4MATCH(addr, a,b,c,d, m) ( ((addr) ^ DQUAD(a,b,c,d)) >> (32 -
(m)) )
#define RFC3484_SCOPE_LINK 2
--
2.21.0
11 months, 1 week
Set up wifi.config
by JH
Hi,
In wifi.config set up, how can the WiFi name with white space, using
quotes? Also, the Passphrase is clear text, can the connman accepts
Passphrase be hashed or some encypted method?
Name = My Home Wifi
Thank you.
Kind regards,
- jh
11 months, 1 week
[PATCH] tethering: fix use after free.
by Mickael GARDET
methods of reproducing:
in loop
1) connmanctl tether wifi on my_ssid my_pasword
2) connecting client
3) connmanctl tether wifi off
con[14819.539062] tether: port 1(wlan0) entered disabled state
nmand2[3831]: ../git/src/technology.c:set_property() property Tethering
connmand2[3831]: ../git/plugins/wifi.c:tech_set_tethering()
connmand2[3831]:
../git/src/technology.c:connman_technology_tethering_notify() technology
0xb57006e0 enabled 0
connmand2[3831]:
../git/src/tethering.c:__connman_tethering_set_disabled() enabled 0
=================================================================
==3831==ERROR: AddressSanitizer: heap-use-after-free on address
0xb490c370 at pc 0x41c2e9c0 bp 0xbedf7494 sp 0xbedf7060
READ of size 2 at 0xb490c370 thread T0
#0 0x41c2e9bf (/usr/lib/libasan.so.5+0x41c2e9bf)
0xb490c370 is located 0 bytes inside of 18-byte region
[0xb490c370,0xb490c382)
freed by thread T0 here:
#0 0x41c73ee7 in free (/usr/lib/libasan.so.5+0x41c73ee7)
#1 0x42877473 (/usr/lib/libglib-2.0.so.0+0x42877473)
previously allocated by thread T0 here:
#0 0x41c7421b in malloc (/usr/lib/libasan.so.5+0x41c7421b)
#1 0x42890b8b in g_malloc (/usr/lib/libglib-2.0.so.0+0x42890b8b)
#2 0x9d3a7 in sta_authorized ../git/plugins/wifi.c:3004
#3 0xa79eb in callback_sta_authorized
../git/gsupplicant/supplicant.c:626
#4 0xc3dd7 in signal_sta_authorized ../git/gsupplicant/supplicant.c:2779
#5 0xceb2f in g_supplicant_filter ../git/gsupplicant/supplicant.c:3620
#6 0x419fb123 in dbus_connection_dispatch
(/usr/lib/libdbus-1.so.3+0x419fb123)
#7 0xb2501d17 (<unknown module>)
SUMMARY: AddressSanitizer: heap-use-after-free
(/usr/lib/libasan.so.5+0x41c2e9bf)
Shadow bytes around the buggy address:
0x36921810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36921820: fa fa fa fa fa fa fa fa fa fa fa fa fd fd fd fd
0x36921830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36921840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36921850: fa fa fa fa fa fa 00 00 00 fa fa fa fa fa fa fa
=>0x36921860: fa fa 00 00 00 00 fa fa fa fa fa fa fa fa[fd]fd
0x36921870: fd fa fa fa 00 00 00 00 fa fa fa fa fa fa fa fa
0x36921880: fa fa fa fa fa fa 00 00 00 04 fa fa fa fa fa fa
0x36921890: fa fa fa fa fa fa fa fa fd fd fd fd fa fa fa fa
0x369218a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x369218b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==3831==ABORTING
---
src/tethering.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/tethering.c b/src/tethering.c
index e04756ff..8386ec90 100644
--- a/src/tethering.c
+++ b/src/tethering.c
@@ -637,8 +637,8 @@ void __connman_tethering_client_register(const char
*addr)
void __connman_tethering_client_unregister(const char *addr)
{
- g_hash_table_remove(clients_table, addr);
client_removed(addr);
+ g_hash_table_remove(clients_table, addr);
}
int __connman_tethering_init(void)
@@ -682,6 +682,7 @@ void __connman_tethering_cleanup(void)
g_hash_table_destroy(pn_hash);
g_hash_table_destroy(clients_notify->remove);
+ clients_notify->remove = NULL;
g_free(clients_notify);
clients_notify = NULL;
--
2.21.0
11 months, 3 weeks
Re: Unsalble cellular connection
by JH
Hi Jonas,
On 8/14/19, Jonas Bonn <jonas(a)norrbonn.se> wrote:
> So you have no traffic over the LTE link? How do you know that it goes
> down after 1-2 hours... maybe it went down after 5 minutes?
I logged link status every 10 minutes.
> Cloud messages are as good as a ping... a packet's a packet.
> The link is configured by connman, not ofono. ofono just publishes the
> address details so that connman can set it up.
So, it is back to connman?
>>> No Address? No Interface? Running ofono with debug output will
>>> probably shed some light on what's going on here.
>>
>> I think that could be because I only ran it once, if I ran
>> list-contexts 4 times consecutively, every time it displayed different
>> results included address and interface, is it the normal behaviour of
>> list-contexts?
>
> Sounds broken...???
Which one is broken, ofono or connman or something else? There is not
much configurations for both ofono and connman,
Can the defect hardware particularly the system power supply caused
the link down? I have only one test device, I cannot prove it. The
SATA chip has a pin for power up, During the boot, a command to set
the power up before ofono is running. When the link is down, either I
restart the ofonod or I called the command to turn the power up again,
both can bring the link back. I cannot image the chip could lose
power, but if the system power supply is not stable in some stage too
low to support the SARA chip, will it trig the power down? I talked to
the hardware engineer who rejected that it did not make sense because
WiFi was running fine, he is pointing the figure to the modem manager
and connection manager.
Thank you.
Kind regards,
- jh
11 months, 3 weeks
Re: Unsalble cellular connection
by Jonas Bonn
Hi Michael,
Re-adding JH and mailing lists to conversation...
On 19/08/2019 10:00, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Mon, Aug 19, 2019 at 9:51 AM Jonas Bonn <jonas(a)norrbonn.se> wrote:
>>
>>
>>
>> On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:
>>> Can be chattering and rush current? Even are you sure that you don't have
>>> some reset our of the ofono service that send an at command that
>>> restart the modem?
>>
>> Just to try to prevent us from going down the wrong rabbit hole here:
>> i) The modem is a QMI device so there are no AT commands being sent
>
> Ok, so the uart used as ttyUSB0 and ttyUSB1 they don't support any AT command?
> Is qmi part only the network interface?
ttyUSB0 and ttyUSB1 _do_ support AT commands, but are complementary to
the QMI interface which is a complete communication channel to the modem
in itself. The network interface is _only_ for the QMI channel: the
network packets are carried on a dedicated endpoint of the USB interface
supporting QMI.
I think the question of QMI vs AT is moot here. Internally the modem
does pretty much the same thing; it's just the interface that looks a
bit different.
In JH's case, only the 'qmimisc' device and the 'network' interface are
in play via ofono. These are separate endpoints on a single USB
interface, all managed by the qmi-wwan driver in the kernel.
/Jonas
11 months, 3 weeks
[PATCH] rtnl: Allow watch callback to remove itself
by Slava Monich
---
src/rtnl.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/rtnl.c b/src/rtnl.c
index cba5ef7..dfe6bb6 100644
--- a/src/rtnl.c
+++ b/src/rtnl.c
@@ -494,14 +494,15 @@ static void process_newlink(unsigned short type, int index, unsigned flags,
__connman_technology_add_interface(interface->service_type,
interface->index, interface->ident);
- for (list = watch_list; list; list = list->next) {
+ list = watch_list;
+ while (list) {
+ GSList *next = list->next;
struct watch_data *watch = list->data;
- if (watch->index != index)
- continue;
-
- if (watch->newlink)
+ if (watch->index == index && watch->newlink)
watch->newlink(flags, change, watch->user_data);
+
+ list = next;
}
}
--
1.9.1
11 months, 3 weeks
Race condition on too fast stop&&start resulting in Error /net/connman/technology/wifi: Not supported that does not recovery without another restart
by KARBOWSKI Piotr
Hi,
I am facing issue with connman-1.37 regarding the wireless network
access. If I restart connman that was already running, I will get not
working wireless connection
# connmanctl scan wifi
Error /net/connman/technology/wifi: Not supported
I can reproduce it on two separated Gentoo ~amd64 systems. One has Intel
9462 and the other with Intel 8265. The wireless connection never
recovery unless I restart connman one more time.
If I not use restart, but stop && start with sleep 3 in between for
example, everything works.
It looks to me like a race condition with whatever connman does to
iwlwifi device upon stopping, that is still 'on going' after connmand
exited, and when new one starts, it lacks code to retry bringing device
up after a delay when it fails for the first time, unless it silently
fails inside, somewhere.
Steps to reproduce:
While connman is running, run /etc/init.d/connman stop &&
/etc/init.d/connman start
The `connmanctl scan wifi` will not work regardless of how long one will
wait. The init script is the most basic one, all it does is
starts/terminates /usr/sbin/connmand.
Steps to reproduce with a workaround:
While connman is running, run /etc/init.d/connman stop && sleep 3 &&
/etc/init.d/connman start
The `connmanctl scan wifi` will work after a few seconds.
-- Piotr.
11 months, 3 weeks
