Routing problem
Hi folks, I have a strange bahaviour using connman 1.20 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: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: 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: 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? Why routes through eth0 (which is down) aren't removed from routing table? Thanks you all G ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
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 Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {create} index 2 type 1 Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {update} flags 4098 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 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 Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags 4098 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 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 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 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 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 Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags 4099 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 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 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 Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: eth0 {update} flags 102467 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 Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: wlo1 {add} route fe80:: gw :: scope 0 Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags 69635 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 Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]: wlo1 {RX} 2 packets 328 bytes Jul 24 08:14:54 duffman.bmw-carit.intra connmand[851]
[PATCH 0/2] Avoid segfault on connman deinitialization
This patchset fixes 2 segmentation faults found on connman finalization, after doing p2p discovery. The following procedures has been done: 1) Scan p2p 2) peers found 3) ctrl+c Eduardo Abinader (2): Check wifi plugin exists before removing peer Let dhcp_server_unref stop dhcp_server plugins/wifi.c | 3 +++ src/peer.c | 1 - 2 files changed, 3 insertions(+), 1 deletion(-) -- 1.9.1 ___ 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 | 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 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 > Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {create} index 2 > type 1 > Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: eth0 {update} flags > 4098 > 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 > 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 > Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags > 4098 > 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 > 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 > 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 > 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 > 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 > Jul 24 08:14:51 duffman.bmw-carit.intra connmand[851]: wlo1 {update} flags > 4099 > 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 > 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 > 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 conn
Re: Routing problem
Hi, On 24 July 2014 10:21, G 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: mtu 16436 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > 2: eth0: 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: 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
Re: Routing problem
2014-07-24 23:22 GMT+02:00 Jukka Rissanen : > Hi, > > Hi Jukka > On 24 July 2014 10:21, G 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. > Tried, with no luck > 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? > If I have only the dhcp addresses everything goes well, so I suppose you are right In which file I can search for the problem? -- G ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman