0

Sometimes Ubuntu 18.04 does not connect to the Network during start-up. I have to reboot 1 or 2 times for connecting properly. Wired Ethernet connection.

Any suggestion on how to resolve this problem without restart?


sudo lshw -C network
[sudo] password for user: 
  *-network                 
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:08:00.0
       logical name: enp8s0
       version: 07
       serial: 00:13:3b:2f:54:58
       size: 100Mbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=1xx.1xx.1.2 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s
       resources: irq:19 ioport:a000(size=256) memory:fe400000-fe400fff memory:d0000000-d0003fff

ifconfig
Command 'ifconfig' not found, but can be installed with:
sudo apt install net-tools 

cat /etc/netplan/*.yaml
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager

ip a
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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:13:3b:2f:54:58 brd ff:ff:ff:ff:ff:ff
    inet 1xx.1xx.1.2/24 brd 1xx.1xx.1.255 scope global dynamic noprefixroute enp8s0
       valid_lft 85762sec preferred_lft 85762sec
    inet6 2a02:2149:8671:6c00:95d5:5075:c66d:a36e/64 scope global temporary dynamic 
       valid_lft 70680sec preferred_lft 27480sec
    inet6 2a02:2149:8671:6c00:b5ed:32e1:2fd2:2ee/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 70680sec preferred_lft 27480sec
    inet6 fe80::c3c:4354:23e7:410f/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

tracepath www.google.com
 1?: [LOCALHOST]                        0.010ms pmtu 1492
 1:  2a02:2149:816a:5400:a6b1:e9ff:fe30:d40                1.069ms 
 1:  2a02:2149:816a:5400:a6b1:e9ff:fe30:d40                1.061ms 
 2:  bbras-llu-kln-15L500.forthnet.gr                     46.737ms 
 3:  Te-0-0-0-7.distr-kln-02.forthnet.gr                  24.145ms 
 4:  BE3.core-kln-03.forthnet.gr                          24.236ms 
 5:  Xe2-0-1.core-lsf-09.forthnet.gr                      32.092ms 
 6:  xgei0-2-0-5.core-tpn-01.forthnet.gr                  38.102ms 
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
     Too many hops: pmtu 1492
     Resume: pmtu 1492
  • This is not a common problem, so there is no common way to "resolve". – Pilot6 Mar 20 '19 at 11:42
  • I am in a dual boot system with Windows 7 64 bit. There is no problem of Ethernet in Windows. If that means anything to an expert... – Jomo Mar 20 '19 at 11:46
  • Edit your question to include the output of sudo lshw -C network and ifconfig and cat /etc/netplan/*.yaml. How are the ethernet cables connected in your network, from the computer to the switch/router/modem? Report back to @heynnema – heynnema Mar 20 '19 at 14:14
  • @heynnema I posted the info you asked. The Ethernet cables are connected from the computer to the router. Possibly a "hybrid" modem/router from ISP. – Jomo Mar 21 '19 at 16:33
  • Status please.. also show me ip a. – heynnema Mar 24 '19 at 14:10
1

I see three possible problems...

1. You've got a 1G network card that's only connecting at (speed=100Mbit/s). That's normally a cable problem, but it could be a problem with the router/modem (in your case).

Pull the POWER PLUG from BOTH the router/modem AND the PC. Count to 15. Plug the router/modem back into AC power. Count to 30. Plug the PC back into AC power. Issue the sudo lshw -C network command, and observe the speed value. It should be 1G (not 100Mbits/s). If it is 1G, retry your Internet and see if it works properly.

If that doesn't fix the problem, we'll need to try a DIFFERNET ethernet cable. Then power cycle everything again, and retest, as above.


2. Your MTU = 1500 which may be wrong for VDSL. First, contact your ISP and ask what they recommend for MTU settings. I'll also include the procedure so that you can determine for yourself... and you can match it with the ISP's information.

You'll want to test your connection by trying to reach various web sites, and also by running a network speed test (http://speedtest.net), before and after changing the MTU.


You may have a problem with the MTU setting for your VDSL connection.

There's a MTU setting in Ubuntu's network configuration, and a WAN MTU setting in your router.

For DSL, a common MTU setting is 1492. Just go ahead and try this value first and see if your web sites are now accessible.

To determine the correct setting, start with all MTU settings = 1500 and VPN = off. (VPN requires different testing).

In terminal:

ping [-c count] [-M do] [-s packet_size] [host]

The options used are:

  • c count: number of times to ping
  • M hint: Select Path MTU Discovery strategy. may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag).
  • s packet_size: Specifies the number of data bytes to be sent.

You should always start at 1472 and work your way down by 10 each time. Once you get a reply, go up by 1 until you get a fragmented packet. Take that value (last good value) and add 28 to the value to account for the various TCP/IP headers. Eg. let's say that 1452 was the proper packet size (where you first got an ICMP reply to your ping). The actual MTU size would be 1480, which is the optimum for the network we're working with.

ping -c 4 -M do -s 1472 8.8.8.8 # this will probably show fragmentation

ping -c 4 -M do -s 1462 8.8.8.8 # may show fragmentation

ping -c 4 -M do -s 1452 8.8.8.8 # no fragmentation?

ping -c 4 -M do -s 1453 8.8.8.8 # still no fragmentation?

reference: How to determine the proper MTU size with ICMP pings


3. You're using the r8169 driver (driver=r8169) and we may need to switch over to the r8168-dkms driver. More info pending results of step #1.

| improve this answer | |
  • I did the first part with the unplug of power from router and pc, the speed value remains the same: 100Mbit/s. I'll try the second part tomorrow with a different ethernet cable. I posted the ip a above. – Jomo Mar 24 '19 at 19:18
  • @Jomo please see the update in my answer. – heynnema Mar 24 '19 at 20:03
  • I check my router settings now and I don't see any option to change MTU. Also in "Broadband Connection" tab, there are 3 connections that are trying to connect: 1) Internet ADSL (connecting...), 2) Internet VDSL (connected), 3) Internet2 VDSL (connecting...). – Jomo Mar 25 '19 at 18:30
  • @Jomo Router MTU is normally on the WAN setup page. What was the outcome of Step #1 in my answer? Did you do Step #2 yet? In terminal type tracepath www.google.com and it may say that tracepath isn't installed... so go ahead and install it and try again. Report back. – heynnema Mar 25 '19 at 18:36
  • I posted above the results of tracepath www.google.com. I'll also contact my ISP for asking about MTU in the router. I am just a pc user, so I don't understand anything from all these tests, but I am trying to do my best. Thank you for the support! – Jomo Mar 26 '19 at 14:58
0

After a long negotiation with ISP, the conclusion is that the problem of the low speed is due to technical reasons from their side. The internet speed increased a bit, but it is still far from the optimal VDSL rate.

However, it remains the fact that Ubuntu 18.04.2 LTS does not reconnect automatically to the Network, in case the internet connection will dropout for various reasons. So, I found a workaround to avoid restarting when the internet disconnects. I open the menu at the top right of the screen and select "Wired connection". I click "Turn off", and then "Connect". This way the internet connection is back.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.