Is independent control of rfkill possible?
by Messer, David
Hi,
I have a device with two wi-fi interfaces, one for AP mode and the other for STA mode. I would like to control the device so one could operate AP or STA individually. The first interface is running hostapd. On the second interface, I would like to run connman. The problem I'm running into has to do with rfkill. If I unblock the wi-fi radio for AP mode, connman sees this event and powers up the wi-fi (STA) technology. Likewise, if I turn off STA mode, connman powers down wi-fi technology which then blocks the radio for AP mode. Is there any way to get around this?
Thank you,
David
1 year, 7 months
[PATCH 0/2] Fix connections to VPN servers on local network
by Santtu Lakkala
When VPN server resides on local network, a route via default gateway
must not be added for it to remain reachale.
Add a check using existing IPv4 helper, and introduce a new helper for
IPv6.
Santtu Lakkala (2):
inet: Add connman_inet_compare_ipv6_subnet()
connection: Fix connections to local VPN servers
include/inet.h | 1 +
src/connection.c | 13 +++++++++++
src/inet.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 73 insertions(+)
--
2.20.1
1 year, 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
1 year, 7 months
[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
1 year, 8 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
1 year, 8 months
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
1 year, 8 months
