Beaglebone network reconnection

[David Lambert]

What is the correct way to ensure that the network connection is restored on replugging the Ethernet cable. I have tried manually restarting connman.service using systemctl, and this appears to work. However, adding the following to connman.service does not appear to work. I am a newbie to systemd, so please excuse if this is a naive question.



[Unit]
Description=Connection service
After=syslog.target

[Service]
Type=dbus
BusName=net.connman
ExecStart=/usr/sbin/connmand -n
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

[Koen Kooi]

Op 31 jan. 2012, om 02:09 heeft David Lambert het volgende geschreven:

> What is the correct way to ensure that the network connection is restored on replugging the Ethernet cable.

Nothing, just a router that hands out dhcp when it gets a request.

[David Lambert]

My problem is that the connman.service dies when I unplug the Ethernet
cable. When I re-plug nothing happens until I manually restart
connman.service:

systemctl status connman.service
connman.service - Connection service
Loaded: loaded (/lib/systemd/system/connman.service; enabled)
Active: failed since Tue, 31 Jan 2012 13:40:16 +0000; 3s ago
Process: 29148 ExecStart=/usr/sbin/connmand -n (code=exited,
status=1/FAILURE)
CGroup: name=systemd:/system/connman.service

Jan 31 13:31:49 argus2 connmand[29148]: connmand[29148]: Enabling DNS
server...8
Jan 31 13:31:49 argus2 connmand[29148]: connmand[29148]: Enabling DNS
server...6
Jan 31 13:40:15 argus2 connmand[29148]: connmand[29148]: eth0 {RX} 77795
pac...s
Jan 31 13:40:15 argus2 connmand[29148]: connmand[29148]: eth0 {TX} 717
packe...s
Jan 31 13:40:15 argus2 connmand[29148]: connmand[29148]: eth0 {update}
flags...>
Jan 31 13:40:16 argus2 connmand[29148]: connmand[29148]:
connman_inet_clear_...t
Jan 31 13:40:16 argus2 connmand[29148]: connmand[29148]: eth0 {newlink}
inde...0
Jan 31 13:40:16 argus2 connmand[29148]: connmand[29148]: eth0 {newlink}
inde...>
Jan 31 13:40:16 argus2 connmand[29148]: connmand[29148]: Removing DNS
server...6
Jan 31 13:40:16 argus2 connmand[29148]: connmand[29148]: Adding DNS
server 6...6

[David Lambert]

On 01/31/2012 07:42 AM, David Lambert wrote:
> My problem is that the connman.service dies when I unplug the Ethernet
> cable. When I re-plug nothing happens until I manually restart
> connman.service:
>
>

I seem to have fixed my problem, by the following. If it is deemed
correct by the Beaglebone gurus, maybe it should be incorporated into
/lib/systemd/system/connman.service?

~# systemctl disable connman.service

~# cat > /etc/systemd/system/connman.service

[Unit]
Description=Connection service
After=syslog.target

[Service]
Type=dbus
BusName=net.connman
ExecStart=/usr/sbin/connmand -n
Restart=on-failure

RestartSec=5

[Install]
WantedBy=multi-user.target

^D

~# systemctl enable connman.service

~# systemctl start connman.service

[eskimobob]

David, did you get any further with this?

I have the same problem - If I unplug the LAN then it will not reconnect automatically when I plug it back in.  I added your RestartSec=5 and Restart=on-failure as shown below and then providing I plug the LAN back in within 5 seconds, it will indeed reconnect.  If however I leave it unplugged for longer and then plug it back in, connman will not reconnect the LAN.

What I want it to do is reconnect whenever it sees the LAN cable is attached.

Martin

On Tuesday, 31 January 2012 15:53:40 UTC, David wrote:

Restart=on-failure
RestartSec=5

[David Lambert]

On 13-06-18 04:25 AM, eskimobob wrote:

David, did you get any further with this?

Unfortunately the situation appears to have changed, but arguably not for the better with the 3.8.x kernel releases. The good news is that connmand appears not to crash (time will tell). However, I have a simple network watchdog that restarts the connman service when network connectivity appears to be lost (cannot ping a know server). Unfortunately restarting connman now appears to break the connection. Only a reboot will reestablish the connection although connmand appears to restart successfully, but fails to set the default route:


root@trax:~# ping google.com
PING google.com (74.125.225.174): 56 data bytes
64 bytes from 74.125.225.174: seq=0 ttl=47 time=64.170 ms
64 bytes from 74.125.225.174: seq=1 ttl=47 time=60.273 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 2 packets received, 33% packet loss
round-trip min/avg/max = 60.273/62.221/64.170 ms

root@trax:~# systemctl restart connman.service

[   28.854950] Bridge firewalling registered
root@trax:~# [   29.273575] net eth0: initializing cpsw version 1.12 (0)
[   29.299452] net eth0: phy found : id is : 0x7c0f1
[   29.314430] libphy: PHY 4a101000.mdio:01 not found
[   29.319574] net eth0: phy 4a101000.mdio:01 not found on slave 1
[   29.335780] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   31.307162] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[   31.318616] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
root@trax:~# ping google.com
ping: bad address 'google.com'

root@trax:~# systemctl status connman

connman.service - Connection service
          Loaded: loaded (/lib/systemd/system/connman.service; enabled)

          Active: active (running) since Fri 2026-12-04 08:56:24 UTC; 1min 20s ago
        Main PID: 345 (connmand)
          CGroup: name=systemd:/system/connman.service
                  `-345 /usr/sbin/connmand -n

Dec 04 08:56:27 trax connmand[345]: eth0 {add} route fe80:: gw :: scope 0 <...E>
Dec 04 08:56:27 trax connmand[345]: connmand[345]: eth0 {add} route fe80:: ...E>
Dec 04 08:57:07 trax connmand[345]: connmand[345]: eth0 {add} address 169.2... 2
Dec 04 08:57:07 trax connmand[345]: connmand[345]: eth0 {add} route 169.254...K>
Dec 04 08:57:07 trax connmand[345]: eth0 {add} address 169.254.87.118/16 la... 2
Dec 04 08:57:07 trax connmand[345]: eth0 {add} route 169.254.0.0 gw 0.0.0.0...K>
Dec 04 08:57:07 trax connmand[345]: eth0 {add} route 0.0.0.0 gw 0.0.0.0 sco...K>
Dec 04 08:57:07 trax connmand[345]: Setting default interface route failed ...s)
Dec 04 08:57:07 trax connmand[345]: connmand[345]: eth0 {add} route 0.0.0.0...K>
Dec 04 08:57:07 trax connmand[345]: connmand[345]: Setting default interfac...s)

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[eskimobob]

Hmmm - I get something similar on three boards I have here (2 x A5B and 1 x A5A).  I was in the process of adding more info when you posted.

If I connect via serial debug cable then I can get more info:

So I start from scratch and boot normally then unplug LAN for just a few seconds, I get this via dmesg:

[ 99.785921] libphy: 4a101000.mdio:00 - Link is Down
[ 101.324323] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 101.859369] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[ 101.859425] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

and you can see it is working again - presumably after the 5 seconds restart.  I can do this multiple times providing I do not exceed 5 seconds.

If however I unplug for more than a few seconds (i.e. longer than the 5 sec restart time), dmesg then gives:

[ 142.098320] libphy: 4a101000.mdio:00 - Link is Down
[ 144.529396] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

and I cannot use LAN again.

If I then do:

systemctl restart connman.service

I get a message appear as follows:

[ 212.282752] libphy: PHY 4a101000.mdio:01 not found
[ 212.287820] net eth0: phy 4a101000.mdio:01 not found on slave 1

and if I then do dmesg I get something similar to you:

[ 212.068744] Bridge firewalling registered
[ 212.279445] net eth0: initializing cpsw version 1.12 (0)
[ 212.282723] net eth0: phy found : id is : 0x7c0f1
[ 212.282752] libphy: PHY 4a101000.mdio:01 not found
[ 212.287820] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 212.303499] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

I wonder if it has got something to do with the firewalling it mentions? - I am not connecting via USB although I am powering via USB.

if I do:

systemctl status connman.service

I get:

connman.service - Connection service

\0x09 Loaded: loaded (/lib/systemd/system/connman.service; enabled)
\0x09 Active: \0x1b[1;32mactive (running)\0x1b[0m since Tue 2013-06-18 14:06:46 BST; 9min ago
\0x09Main PID: 379 (connmand)
\0x09 CGroup: name=systemd:/system/connman.service
\0x09\0x09 `-379 /usr/sbin/connmand -n

Jun 18 14:06:46 beaglebone connmand[379]: connmand[379]: usb0 {update} flags...>
Jun 18 14:06:46 beaglebone connmand[379]: connmand[379]: usb0 {newlink} inde...0
Jun 18 14:06:46 beaglebone connmand[379]: connmand[379]: usb0 {newlink} inde...>
Jun 18 14:06:46 beaglebone connmand[379]: connmand[379]: Adding interface us...]
Jun 18 14:06:46 beaglebone connmand[379]: connmand[379]: eth0 {RX} 195 packe...s
Jun 18 14:06:46 beaglebone connmand[379]: connmand[379]: eth0 {TX} 114 packe...s
Jun 18 14:06:46 beaglebone connmand[379]: connmand[379]: eth0 {update} flags...>
Jun 18 14:06:46 beaglebone connmand[379]: connmand[379]: eth0 {newlink} inde...0
Jun 18 14:06:46 beaglebone connmand[379]: connmand[379]: eth0 {newlink} inde...>

Jun 18 14:06:46 beaglebone connmand[379]: connmand[379]: usb0 {add} address ...2

I thought about compiling the latest connman from source but it started throwing out DBus error messages during coompilation.

[eskimobob]

Another clue perhaps? - 47 minutes later the LAN LEDs light up again and dmesg reports:

[ 3042.054311] libphy: 4a101000.mdio:00 - Link is Up - 100/Full

[ 3042.054435] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

The service now reports:

connman.service - Connection service
\0x09 Loaded: loaded (/lib/systemd/system/connman.service; enabled)

\0x09 Active: \0x1b[1;32mactive (running)\0x1b[0m since Tue 2013-06-18 14:06:46 BST; 1h 47min ago

\0x09Main PID: 379 (connmand)
\0x09 CGroup: name=systemd:/system/connman.service
\0x09\0x09 `-379 /usr/sbin/connmand -n

Jun 18 14:53:56 beaglebone connmand[379]: connmand[379]: Skipping disconnect....
Jun 18 14:53:56 beaglebone connmand[379]: connmand[379]: eth0 {add} route fe...>
Jun 18 14:54:38 beaglebone connmand[379]: connmand[379]: eth0 {add} address ...2
Jun 18 14:54:38 beaglebone connmand[379]: connmand[379]: eth0 {add} route 16...>
Jun 18 14:54:38 beaglebone connmand[379]: connmand[379]: eth0 {add} route 0....>
Jun 18 14:54:38 beaglebone connmand[379]: connmand[379]: Setting default int...)
Jun 18 14:54:38 beaglebone connmand[379]: eth0 {add} address 169.254.123.55/...2
Jun 18 14:54:38 beaglebone connmand[379]: eth0 {add} route 169.254.0.0 gw 0....>
Jun 18 14:54:38 beaglebone connmand[379]: eth0 {add} route 0.0.0.0 gw 0.0.0....>
Jun 18 14:54:38 beaglebone connmand[379]: \0x1b[1;31mSetting default interface route fa...)\0x1b[0m

and if I do ifconfig -a

if shows:

eth0 Link encap:Ethernet HWaddr C8:A0:30:AB:E4:40
inet addr:169.254.123.55 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::caa0:30ff:feab:e440/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:195 errors:0 dropped:63 overruns:0 frame:0
TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:23401 (22.8 KiB) TX bytes:12670 (12.3 KiB)
Interrupt:56

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:272 errors:0 dropped:0 overruns:0 frame:0
TX packets:272 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21258 (20.7 KiB) TX bytes:21258 (20.7 KiB)

usb0 Link encap:Ethernet HWaddr AA:D0:B5:41:F5:3D
inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

so the interface eventually came back up but as you noticed, it didn't get an address from my dhcp server but rather picked another (169.254.123.55).

now if I try 

systemctl restart connman.service

it still comes back with 169.254.123.55

How frustrating to have no idea what is going on... :-(

[David Lambert]

On 13-06-18 10:01 AM, eskimobob wrote:
>
>
> and if I do ifconfig -a
> if shows:
>
> eth0 Link encap:Ethernet HWaddr C8:A0:30:AB:E4:40
> inet addr:169.254.123.55 Bcast:169.254.255.255 Mask:255.255.0.0
> inet6 addr: fe80::caa0:30ff:feab:e440/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:195 errors:0 dropped:63 overruns:0 frame:0
> TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:23401 (22.8 KiB) TX bytes:12670 (12.3 KiB)
> Interrupt:56
>
>

> so the interface eventually came back up but as you noticed, it didn't
> get an address from my dhcp server but rather picked another
> (169.254.123.55).
>
> now if I try
>
> systemctl restart connman.service
>
> it still comes back with 169.254.123.55
>
>

This looks like a link local address maybe served/negotiated by avahi?
My guess it is a fallback due to DHCP failing.

My 2c

Dave.

[eskimobob]

Thanks Dave.  I have previously disabled avahi service so I'm not convinced it is that.

I've been googling a while - it seems it is not only apparent in Angstrom but Arch too (see here).  The chap there describes how he cannot use LAN unless he boots with LAN connected - I get exactly the same thing.  If I boot without LAN connected then even when I plug LAN in and restart connman.service, I cannot access the LAN.

I'm surprised more people are not noticing that if they unplug the LAN then they have to reboot in order to reconnect.  The lack of others asking the same question makes me worry that I am doing something stupid...

[David Lambert]

On 13-06-18 10:38 AM, eskimobob wrote:

Thanks Dave.  I have previously disabled avahi service so I'm not convinced it is that.

I agree, avahi-autoip does not seem to be used in any case. Maybe connmand is responsible for link local addresses?

I've been googling a while - it seems it is not only apparent in Angstrom but Arch too (see here).  The chap there describes how he cannot use LAN unless he boots with LAN connected - I get exactly the same thing.  If I boot without LAN connected then even when I plug LAN in and restart connman.service, I cannot access the LAN.

I'm surprised more people are not noticing that if they unplug the LAN then they have to reboot in order to reconnect.  The lack of others asking the same question makes me worry that I am doing something stupid...

Well at least you have my company in stupidity ;-)

In any case I notice that connmand seems to be much more stable in the 3.8 kernel release, but restarting it wrecks the system.

On Tuesday, 18 June 2013 16:07:27 UTC+1, David wrote:

This looks like a link local address maybe served/negotiated by avahi?  
My guess it is a fallback due to DHCP failing.

--

[eskimobob]

I thought I'd go back and try to compile connman from source again.  Currently version 1.4 is used.  The latest version is 1.15 but I thought I'd play it safe and try compiling version 1.5 so that there were minimal changes.  I can get .configure to complete but when I run make, it initially looks good but then:

CCLD src/connmand
gsupplicant/supplicant.o: In function `interface_scan_result':
supplicant.c:(.text+0x1402): undefined reference to `g_slist_free_full'

<snip>

Looking in supplicant.c, it does not mention g_slist_free_full so I am confused as to why that error is happening.

I thought I'd try compiling version 1.15 again but it complains of the same problem...

Stuck.

[eskimobob]

There is another separate discussion on this group about the same thing but based on comments in that thread, this is not a connman problem but something more fundamental.

See thread here