Missing default route after boot
Hi,
I have both ethernet and WIFI connection configured as autoconnect.
Further connman is configured with SingleConnectedTechnology = true.
Today after boot the ethernet connection was setup with a correct IP
address (DHCP) but a missing default route. After a restart of connman
it was ok again. I wasn't able to reproduce this behaviour a second time
by rebooting or restarting connman.
Could there be a timing issue when ethernet and WIFI come up at the same
time when SingleConnectedTechnology is enabled?
I'm using the current master (c1b9fc4) of connman.
Best regards
Tobias
My /etc/connman/main.conf:
[General]
PreferredTechnologies = ethernet,wifi
SingleConnectedTechnology = true
Routing table:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
192.168.0.254 0.0.0.0 255.255.255.255 UH0 0 0 eth0
Routing table after connman restart:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
default 192.168.0.254 0.0.0.0 UG0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
192.168.0.254 0.0.0.0 255.255.255.255 UH0 0 0 eth0
Connman log:
Jul 24 08:14:50 duffman.bmw-carit.intra connmand[851]: Connection
Manager version 1.24
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Checking loopback
interface settings
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: System hostname
is
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: lo {newlink}
index 1 address 00:00:00:00:00:00 mtu 65536
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: lo {newlink}
index 1 operstate 0 UNKNOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {create}
index 2 type 1 ETHER
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {update}
flags 4098 DOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink}
index 2 address 10:60:4B:49:47:2E mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink}
index 2 operstate 2 DOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Adding interface
eth0 [ ethernet ]
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {create}
index 3 type 1 ETHER
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update}
flags 4098 DOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink}
index 3 address 6C:88:14:6E:65:60 mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink}
index 3 operstate 2 DOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Adding interface
wlo1 [ wifi ]
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {update}
flags 36867 UP
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink}
index 2 address 10:60:4B:49:47:2E mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink}
index 2 operstate 2 DOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Method
ListAdapters with signature on interface org.bluez.Manager
doesn't exist
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update}
flags 4163 UP,RUNNING
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink}
index 3 address 6C:88:14:6E:65:60 mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink}
index 3 operstate 0 UNKNOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update}
flags 4099 UP
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink}
index 3 address 6C:88:14:6E:65:60 mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink}
index 3 operstate 5 DORMANT
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink}
index 3 address 6C:88:14:6E:65:60 mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink}
index 3 operstate 2 DOWN
Jul 24 08:14:52 duffman.bmw-carit.intra connmand[851]: Skipping
disconnect of 4349543032_managed_psk, network is connecting.
Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: eth0 {add} route
fe80:: gw :: scope 0 UNIVERSE
Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: eth0 {update}
flags 102467 UP,RUNNING,LOWER_UP
Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: eth0 {newlink}
index 2 address 10:60:4B:49:47:2E mtu 1500
Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: eth0 {newlink}
index 2 operstate 6 UP
Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: wlo1 {add} route
fe80:: gw :: scope 0 UNIVERSE
Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: wlo1 {update}
flags 69635 UP,LOWER_UP
Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink}
index 3 address 6C:88:14:6E:65:60 mtu 1500
Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink}
index 3 operstate 5 DORMANT
Jul 24 08:14:54
[PATCH 2/2] Let dhcp_server_unref stop dhcp_server
P2P peer was explicit stopping dhcp_server besides dhcp_server_unref,
which already takes care of server stopping.
---
src/peer.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/peer.c b/src/peer.c
index 39877ec..3107f0a 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -62,7 +62,6 @@ static void stop_dhcp_server(struct connman_peer *peer)
DBG();
if (peer-dhcp_server) {
- g_dhcp_server_stop(peer-dhcp_server);
g_dhcp_server_unref(peer-dhcp_server);
}
peer-dhcp_server = NULL;
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 2/2] Let dhcp_server_unref stop dhcp_server
Hi Eduardo,
if (peer-dhcp_server) {
- g_dhcp_server_stop(peer-dhcp_server);
g_dhcp_server_unref(peer-dhcp_server);
}
peer-dhcp_server = NULL;
You can remove the { ... } then. Just resend that one.
Thanks,
Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 1/2] Check wifi plugin exists before removing peer
Hi Eduardo, @@ -2291,6 +2291,9 @@ static void peer_lost(GSupplicantPeer *peer) struct connman_peer *connman_peer; const char *identifier; + if (!wifi) + return; + identifier = g_supplicant_peer_get_identifier(peer); Good catch! ACK Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/2] Check wifi plugin exists before removing peer
Do sanity check before using wifi pointer on peer_lost. --- plugins/wifi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/plugins/wifi.c b/plugins/wifi.c index eb1fad0..ce6d7e7 100644 --- a/plugins/wifi.c +++ b/plugins/wifi.c @@ -2291,6 +2291,9 @@ static void peer_lost(GSupplicantPeer *peer) struct connman_peer *connman_peer; const char *identifier; + if (!wifi) + return; + identifier = g_supplicant_peer_get_identifier(peer); DBG(ident: %s, identifier); -- 1.9.1 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 2/2] Let dhcp_server_unref stop dhcp_server
P2P peer was explicit stopping dhcp_server besides dhcp_server_unref,
which already takes care of server stopping.
---
src/peer.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/peer.c b/src/peer.c
index 39877ec..d627487 100644
--- a/src/peer.c
+++ b/src/peer.c
@@ -61,10 +61,9 @@ static void stop_dhcp_server(struct connman_peer *peer)
{
DBG();
- if (peer-dhcp_server) {
- g_dhcp_server_stop(peer-dhcp_server);
+ if (peer-dhcp_server)
g_dhcp_server_unref(peer-dhcp_server);
- }
+
peer-dhcp_server = NULL;
if (peer-ip_pool)
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 0/2 v2] Avoid segfault on connman deinitialization
Applied change Tomasz has requested on this patchset v2. Eduardo Abinader (2): Check wifi plugin exists before removing peer Let dhcp_server_unref stop dhcp_server plugins/wifi.c | 3 +++ src/peer.c | 5 ++--- 2 files changed, 5 insertions(+), 3 deletions(-) -- 1.9.1 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 0/2 v2] Avoid segfault on connman deinitialization
Hi Eduardo, ACK on this patchset. Thanks, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 0/2 v2] Avoid segfault on connman deinitialization
On 07/24/2014 02:55 PM, Tomasz Bursztyka wrote: Hi Eduardo, ACK on this patchset. Patches applied. Thanks, Daniel ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Missing default route after boot
Hi Tobias,
On 24 July 2014 12:44, Tobias Henkel tobias.hen...@oss.bmw-carit.de wrote:
Hi,
I have both ethernet and WIFI connection configured as autoconnect. Further
connman is configured with SingleConnectedTechnology = true.
The use of SingleConnectedTechnology should be avoided if possible. It
just works too strongly and disconnects the other service even if
someone is using the connection.
Have you tried just to set PreferredTechnologies=ethernet? At least
that setting works in my laptop and only ethernet is normally
connected. I can still manually connect other wifi services and the
ethernet connection would not be disconnected in this case (because I
have SingleConnectedTechnology=false in my conf file).
Today after boot the ethernet connection was setup with a correct IP address
(DHCP) but a missing default route. After a restart of connman it was ok
again. I wasn't able to reproduce this behaviour a second time by rebooting
or restarting connman.
I have not really seen this behaviour.
Could there be a timing issue when ethernet and WIFI come up at the same
time when SingleConnectedTechnology is enabled?
Are your ethernet and wifi in the same subnet i.e., are they both in
192.168.0.0/16? If so, that might explain this behaviour.
I'm using the current master (c1b9fc4) of connman.
Best regards
Tobias
My /etc/connman/main.conf:
[General]
PreferredTechnologies = ethernet,wifi
SingleConnectedTechnology = true
Routing table:
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
192.168.0.254 0.0.0.0 255.255.255.255 UH0 0 0 eth0
Routing table after connman restart:
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
default 192.168.0.254 0.0.0.0 UG0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
192.168.0.254 0.0.0.0 255.255.255.255 UH0 0 0 eth0
Connman log:
Jul 24 08:14:50 duffman.bmw-carit.intra connmand[851]: Connection Manager
version 1.24
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Checking loopback
interface settings
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: System hostname is
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: lo {newlink} index 1
address 00:00:00:00:00:00 mtu 65536
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: lo {newlink} index 1
operstate 0 UNKNOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {create} index 2
type 1 ETHER
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {update} flags
4098 DOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink} index
2 address 10:60:4B:49:47:2E mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink} index
2 operstate 2 DOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Adding interface eth0
[ ethernet ]
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {create} index 3
type 1 ETHER
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags
4098 DOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
3 address 6C:88:14:6E:65:60 mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
3 operstate 2 DOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Adding interface wlo1
[ wifi ]
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {update} flags
36867 UP
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink} index
2 address 10:60:4B:49:47:2E mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {newlink} index
2 operstate 2 DOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: Method ListAdapters
with signature on interface org.bluez.Manager doesn't exist
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags
4163 UP,RUNNING
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
3 address 6C:88:14:6E:65:60 mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
3 operstate 0 UNKNOWN
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags
4099 UP
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
3 address 6C:88:14:6E:65:60 mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
3 operstate 5 DORMANT
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
3 address 6C:88:14:6E:65:60 mtu 1500
Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {newlink} index
3 operstate 2 DOWN
Jul 24 08:14:52 duffman.bmw-carit.intra connmand[851]: Skipping disconnect
of 4349543032_managed_psk, network is connecting.
Jul 24 08:14:54 duffman.bmw-carit.intra
Re: Routing problem
Hi, On 24 July 2014 10:21, G i...@asidev.com wrote: Hi folks, I have a strange bahaviour using connman 1.20 If possible try to upgrade to latest release (1.24), it fixes lot of bugs, although probably does not fix your issue. I have a device with an ethernet card and a wifi card Both card are with dhcp and are connected to the same network (I know this is not good, but I can't do in a different way). Furthermore the ethernet card got a static IP on a different subnet So my routing table looks like this root@razor:~# ip route 192.168.10.100 via 192.168.10.100 dev eth0 192.168.10.100 dev eth0 scope link 192.168.10.100 dev wlan0 scope link metric 10 10.189.189.0/24 dev eth0 proto kernel scope link src 10.189.189.1 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.109 192.168.10.0/24 dev wlan0 proto kernel scope link src 192.168.10.107 metric 10 224.0.0.0/24 dev eth0 scope link default via 192.168.10.100 dev eth0 192.168.10.100 is the dhcp server / default gateway (simply a wireless router); 10.189.189.0/24 is a control subnet used to reach other devives through a switch (no VLAN) You can see that the route via eth0 is preferred because of a lower metric root@razor:~# ip route get 192.168.10.100 192.168.10.100 dev eth0 src 192.168.10.109 cache ipid 0x34b2 mtu 1500 advmss 1460 hoplimit 64 The problem arise when I disconnect the ethernet cable, because the routing table doesn't change at all and if I check the previous route I obtain root@razor:~# ip route get 192.168.10.100 192.168.10.100 dev eth0 src 10.189.189.1 cache mtu 1500 advmss 1460 hoplimit 64 So the route goes via eth0, using the static configured ip The interface looks like this root@razor:~# ip link 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: NO-CARRIER,BROADCAST,MULTICAST,DYNAMIC,UP mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:21:84:30:03:78 brd ff:ff:ff:ff:ff:ff 3: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:21:84:26:01:84 brd ff:ff:ff:ff:ff:ff Is this the expected behaviour under these conditions? I tried this setup with my laptop and did not see exacly similar issue (although my ethernet was reconnected to same subnet as wifi). My ethernet got always the default route after toggling ethernet cable. So both ethernet and wifi connected at the same time the routing table looked like this Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.178.1 0.0.0.0 UG0 0 0 em1 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 em1 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp3s0 192.168.178.1 0.0.0.0 255.255.255.255 UH0 0 0 wlp3s0 192.168.178.1 0.0.0.0 255.255.255.255 UH0 0 0 em1 Then after disconnecting ethernet and reconnecting it again I got Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.178.1 0.0.0.0 UG0 0 0 em1 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 wlp3s0 192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 em1 192.168.178.1 0.0.0.0 255.255.255.255 UH0 0 0 em1 192.168.178.1 0.0.0.0 255.255.255.255 UH0 0 0 wlp3s0 So the routes are in slightly different order but that does not matter in this case. Why routes through eth0 (which is down) aren't removed from routing table? The removal of the eth route seem to have failed (probably because they are in the same subnet as wifi). We should already remove all the routes via some interface when that interface is taken down but this seems to not have happened. I wonder if this could be related to your static IP address for ethernet. Could you try whether the situation changes if you use always dhcp addresses? Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
