2

On my Ubuntu 17.04 Dell Latitude laptop I use docking station. This station has dedicated connection.

  1. When I dock My laptop into station, It indefinitely shows "connecting" state icon. Like it tries to connect, then resets, then trying to connect again.
  2. When I unplug cable, wait a bit and connect again the connection is up instantly.

It probably happens more often when resuming from sleep. But tried changing BIOS power options to no avail.

It was working fine on Ubuntu 16.10, but I'm not sure if problem arised after 17.04, as other factors changed too.

There is rather old 10/100Mbit switch between laptop and router, maybe connection negotiation takes too long? But network printer connects without problem.

Update: Tried reloading ethernet driver with modprobe -r -v tg3, modprobe -v rg3 and restarting network service too.

running dmesg shows a lot of link up/link down messages:

[92580.119745] tg3 0000:09:00.0 eth0: Link is up at 100 Mbps, full duplex
[92580.119768] tg3 0000:09:00.0 eth0: Flow control is on for TX and on for RX
[92580.774047] tg3 0000:09:00.0 eth0: Link is down
[92582.426348] tg3 0000:09:00.0 eth0: Link is up at 100 Mbps, full duplex
[92582.426351] tg3 0000:09:00.0 eth0: Flow control is on for TX and on for RX
[92583.368441] tg3 0000:09:00.0 eth0: Link is down
[92585.047635] tg3 0000:09:00.0 eth0: Link is up at 100 Mbps, full duplex
[92585.047662] tg3 0000:09:00.0 eth0: Flow control is on for TX and on for RX
[92585.562763] tg3 0000:09:00.0 eth0: Link is down
[92587.207396] tg3 0000:09:00.0 eth0: Link is up at 100 Mbps, full duplex
[92587.207418] tg3 0000:09:00.0 eth0: Flow control is on for TX and on for RX
[92588.085716] tg3 0000:09:00.0 eth0: Link is down
[92589.744788] tg3 0000:09:00.0 eth0: Link is up at 100 Mbps, full duplex
[92589.744816] tg3 0000:09:00.0 eth0: Flow control is on for TX and on for RX
[92590.706366] tg3 0000:09:00.0 eth0: Link is down
[92592.296863] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[92592.365857] tg3 0000:09:00.0 eth0: Link is up at 100 Mbps, full duplex
[92592.365860] tg3 0000:09:00.0 eth0: Flow control is on for TX and on for RX
[92592.365876] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[92593.326975] tg3 0000:09:00.0 eth0: Link is down
[92594.987186] tg3 0000:09:00.0 eth0: Link is up at 100 Mbps, full duplex
[92594.987212] tg3 0000:09:00.0 eth0: Flow control is on for TX and on for RX
[92595.947772] tg3 0000:09:00.0 eth0: Link is down
[92597.608392] tg3 0000:09:00.0 eth0: Link is up at 100 Mbps, full duplex
[92597.608416] tg3 0000:09:00.0 eth0: Flow control is on for TX and on for RX
[92598.568514] tg3 0000:09:00.0 eth0: Link is down
[92600.229535] tg3 0000:09:00.0 eth0: Link is up at 100 Mbps, full duplex
[92600.229548] tg3 0000:09:00.0 eth0: Flow control is on for TX and on for RX

Wireshark logs when connection is stalled:

No.     Time           Source                Destination           Protocol Length Info
      7 2.660584149    0.0.0.0               255.255.255.255       DHCP     342    DHCP Request  - Transaction ID 0xde0c185d

Frame 7: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Dell_39:4b:6e (d0:67:e5:39:4b:6e), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Request)

No.     Time           Source                Destination           Protocol Length Info
     12 5.401359750    0.0.0.0               255.255.255.255       DHCP     342    DHCP Request  - Transaction ID 0xde0c185d

Frame 12: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Dell_39:4b:6e (d0:67:e5:39:4b:6e), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Request)

No.     Time           Source                Destination           Protocol Length Info
     35 13.832656290   0.0.0.0               255.255.255.255       DHCP     342    DHCP Discover - Transaction ID 0xb9200f10

Frame 35: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Dell_39:4b:6e (d0:67:e5:39:4b:6e), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)

Wireshark logs just after reconnecting cable:

No.     Time           Source                Destination           Protocol Length Info
     13 12.440180322   0.0.0.0               255.255.255.255       DHCP     342    DHCP Request  - Transaction ID 0xc06e5459

Frame 13: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Dell_39:4b:6e (d0:67:e5:39:4b:6e), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Request)

No.     Time           Source                Destination           Protocol Length Info
     14 12.444870618   192.168.1.254         192.168.1.5           DHCP     358    DHCP ACK      - Transaction ID 0xc06e5459

Frame 14: 358 bytes on wire (2864 bits), 358 bytes captured (2864 bits) on interface 0
Ethernet II, Src: VtechTel_55:61:31 (00:12:2a:55:61:31), Dst: Dell_39:4b:6e (d0:67:e5:39:4b:6e)
Internet Protocol Version 4, Src: 192.168.1.254, Dst: 192.168.1.5
User Datagram Protocol, Src Port: 67, Dst Port: 68
Bootstrap Protocol (ACK)

No.     Time           Source                Destination           Protocol Length Info
     15 12.463981621   192.168.1.5           224.0.0.22            IGMPv3   62     Membership Report / Join group 224.0.0.252 for any sources / Join group 224.0.0.251 for any sources

Frame 15: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface 0
Ethernet II, Src: Dell_39:4b:6e (d0:67:e5:39:4b:6e), Dst: IPv4mcast_16 (01:00:5e:00:00:16)
Internet Protocol Version 4, Src: 192.168.1.5, Dst: 224.0.0.22
Internet Group Management Protocol
3
  • Can you use Wireshark to see what happens when it is trying to connect (If it can see traffic and if it is asking for an getting an IP)
    – jrtapsell
    Oct 4, 2017 at 22:06
  • @jrtapsell I've added wireshark logs
    – PeterM
    Oct 10, 2017 at 11:46
  • Have you ruled out an intermittent short in the Ethernet cable? If the issue is hard to replicate it may be only occurring when the cable is disturbed. You might try replacing the cable with a known good one. This seems especially feasible since restarting the network service isn't working for you.
    – Elder Geek
    Oct 10, 2017 at 22:44

1 Answer 1

2
+25

A few months ago an automatic update broke my Ethernet suspend/resume after it was working perfectly for 6 months or so. It happened to a few other users here around the same time.

The solution for me was to create a script that gets executed when resuming from suspend:

#!/bin/bash

# NAME: r8169-reset
# PATH: /lib/systemd/system-sleep
# DESC: Reset Ethernet card after suspend, not working automatically
# DATE: Feb ?? 2017. Modified: Apr 30, 2017.

MYNAME=$0

restart_ethernet() {
   /usr/bin/logger $MYNAME 'restart_ethernet(r8169) BEGIN'
   /sbin/modprobe -v -r r8169
   # /sbin/modprobe -v -r mii
   /sbin/modprobe -v r8169
   /usr/bin/logger 'systemctl restart NetworkManager.service (SUPPRESED)'
   /usr/bin/logger $MYNAME 'restart_ethernet(r8169) END'
}

/usr/bin/logger $MYNAME 'case=[' ${1}' ]'
case "${1}/${2}" in
   hibernate|suspend|pre*)
      ;;
   resume|thaw|post*)
      restart_ethernet;;
esac

Save the script to /lib/systemd/system-sleep/r8169-reset. Of course change this script name to your actual driver name. Also change the driver kernel module name within the script.

Note the line:

/usr/bin/logger 'systemctl restart NetworkManager.service (SUPPRESED)'

Sometimes simply restarting the network manager is all that is needed and you can try that too.

You'll need sudo powers to save the file. For good measure I always mark these scripts as executable using:

sudo chmod a+x /lib/systemd/system-sleep/r8169-reset

You can check /var/log/syslog to see output from the script.

Hope this works for you.

2
  • Thank You for Your answer which seems to be reasonable, but unfortunately it didn't work. I've tried to reload network module (tg3 in my case) as in Your script and tried to restart network manager.
    – PeterM
    Oct 10, 2017 at 11:53
  • @PeterM When you tried to reload the drivers, were there any error messages in /var/log/syslog? Oct 10, 2017 at 23:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .