I am in the process of moving my computers to Ubuntu. Things are going pretty well on my first installation, but during the process I began to have serious internet connection problems. I know this problem has nothing to do with the O/S, because I have the problem with any PC on my network, regardless of which version of Linux I am using. Because all my efforts going forward will be on Ubuntu, I figured this was the best place to come.

I have a home network using DSL that has been working reliably for roughly 9 months. It started giving me connection problems 2 days ago, which was March 1st when I originally wrote this. Since first entering this, I obtained a new switch and that has improved the situation considerably.

The current status, as or March 5th, is that with the new switch in place, the original configurations mentioned, now labeled 'Route 1' and 'Route 2' are now both working.

I have considered closing this issue, but I am going to add 'Route 3', which is part of my network, but totally working. 'Route 3', daisy chaining switches off the main switch, has been part of the network since I set it up about 9 months ago. Physically, it is much more convenient than the alternative, the alternative being to run maybe an extra 6, 50-to-100 foot ethernet cables through my house. If the consensus is that I do that, I will close this issue.

The test I am using is: ping www.google.com

Below is 'Route 1' a configuration that works, where 'EL' is an ethernet link and 'SW' is a switch. With this configuration, I get normal results from the ping, with 64 byte messages being received back from www.google.com.

modem --> wired link --> router --> EL --> Ubuntu PC

Below is 'Route 2' which has an ethernet switch added. This configuration, shown below, now also passes.

modem --> wired link --> router --> EL --> SW --> EL --> Ubuntu PC

The final configuration, 'Route 3' is shown below.

modem --> wired link --> router --> EL --> SW1 --> EL --> SW2 --> EL --> Ubuntu PC

I currently have 4 ethernet links coming out of switch 'SW1'. One of those links fits the 'Route 2' diagram and works. The other 3 links are 'Route 3' links to the computers. Two of these links pass. The third link fails, with a slightly different error message, presumably because the are running different Linux distributions.

When I ping from the Ubuntu host, using the 'Route 3' configuration, the error message is:

ping: www.google.com: Name or service not known

When I ping from the non-Ubuntu host, again using the 'Route 3' configuration, the error message is:

ping: www.google.com: Temporary failure in name resolution

Both indicating that the name was being translated to an IP address.

From either computer I can ping the router, but not www.google.com.

When I run lshw using 'Route 3', I get the following:

lshw -C 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:01:00.0
       logical name: enp1s0
       version: 06
       serial: 00:30:67:cd:16:04
       size: 1Gbit/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= latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
       resources: irq:26 ioport:e000(size=256) memory:d0004000-d0004fff memory:d0000000-d0003fff

When I run tracepath using 'Route 2', I get:

tracepath www.google.com
 1?: [LOCALHOST]                      pmtu 1500
 1:  router                                                0.613ms 
 1:  router                                                0.566ms 
 2:  router                                                0.536ms pmtu 1492
 2:                                            18.574ms 
 3:                                         25.352ms 
 4:  no reply
 5:  no reply

and 'no reply' repeats until I break out of tracepath.

If I run tracepath using 'Route 3', then tracepath hangs with no output.

Jim A.

  • What happens when you bypass the Ethernet switch and connect directly to the DSL modem? – K7AAY Mar 4 at 20:00
  • 1
    When directly connected to the router, ping works as expected and I get back a series of 64 byte messages from www.google.com. (I have changed my post and added this information into the initial question). – Jim Mar 4 at 21:57
  • What's your MTU set for? Managed or unmanaged switches? Edit your question and show me sudo lshw -C network. – heynnema Mar 4 at 22:27
  • Install iputils-tracepath and edit your question and show me tracepath www.google.com with and without the switch. – heynnema Mar 4 at 22:32
  • @heynnema - I have largely rewritten my original post. Please be sure the read the 3rd and 4th paragraphs before going any further. In I have added results of running 'lshw' and 'tracepath' as you suggested. – Jim Mar 5 at 21:07

I have installed the r8168-dkms package.

In addition, I added the following to my /etc/network/interfaces file:

auto enp1s0
iface enp1s0 inet static
  mtu 1492

Note the interface is 'enp1s0', not 'eno1', because I'm using a debian host for the time being. Once I get the networking on the new Ubuntu PC, I will be using it.

With those changes, I now get a tracepath, using route:

router --> EL --> PC

tracepath www.google.com
 1?: [LOCALHOST]                      pmtu 1492
 1:  router                                                0.412ms 
 1:  router                                                0.353ms 
 2:                                            18.506ms 
 3:                                         34.332ms 
 4:  no reply

Using a route:

router --> EL --> switch --> EL --> PC

I get the following:

tracepath www.google.com
tracepath: www.google.com: Temporary failure in name resolution

NOTE: There is a delay of maybe 30 to 60 seconds before the 'Temporary failure' message is given.

With the switch in the route,

ping www.google.com


ping www.google.com
ping: www.google.com: Temporary failure in name resolution

One other thing worth noting is that during some of my testing with the switch in the path, when I did a ping and then broke it with cntl-C, the ping stats appeared and indicated there was a packet failure rate of 95%. I have not figured out why those stats show up sometimes, but not others.

With my configuration set up as:

router --> switch --> PC

I tried running 'ping -c xx -M do -s xxx' as heynnema suggessted. In all cases I got the same results. Below is an sample:

$ sudo ping -c 4 -M do -s 1400
PING ( 1400(1428) bytes of data. 
--- ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3079ms

With my configuration set up as:

router --> PC

I ran the pings once again and it looks like

$ ping -c 4 -M do -s 1464
PING ( 1464(1492) bytes of data.
76 bytes from icmp_seq=1 ttl=57 (truncated)
76 bytes from icmp_seq=2 ttl=57 (truncated)
76 bytes from icmp_seq=3 ttl=57 (truncated)
--- ping statistics --- 
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 21.980/23.742/25.505/1.444 ms
$ ping -c 4 -M do -s 1465
PING ( 1465(1493) bytes of data.
ping: local error: Message too long, mtu=1492
ping: local error: Message too long, mtu=1492
ping: local error: Message too long, mtu=1492

So, it looks like there is error at -s 1464.

But most important to me is that ping shows 100% packet loss when I am using the configuration:

router --> switch --> PC.

That is still the big mystery to me.

| improve this answer | |
  • Regarding your comment about cascading unmanaged switches - in theory there is no reason that cascaded switches should not work, and in fact, I have been doing that for the past 8 or 9 months. In practice, I have been reading a lot lately, and it is a bad idea to use cascading. I have reconfigured my network and I am not using any cascading now and plan to stay away from it. The network configuration that you mention is what I am using, and I think that translates into when I called, 'Route 1' and 'Route 2' in my post. My 'Route 3' definition uses cascading and I have eliminated that. – Jim Mar 7 at 19:23
  • Since you didn't notify me, I almost missed this "answer"... which really should be an edit to your original question. You've got a defective or misconfigured switch, and you didn't do the MTU thing correctly, and /etc/network/interfaces is kind of a dead file right now... the GUI should be used to do the same thing. Are you using cat 5e or cat 6 cables? Start comments to me with @heynnema or I may miss them. – heynnema Mar 8 at 0:50
  • Are these managed or unmanaged switches? What is EL? An ethernet cat 5e or cat 6 cable, or something else? – heynnema Mar 8 at 14:59
  • @heynnema - I'm sorry about the 'question' response that I gave. I have never used Stack Exchange before and I was a bit oblivious to the obvious. I won't do that again. Do you think I should remove my bogus 'answer' and insert the information in a comment? I am inclined to do that so that I don't confuse other potential readers. – Jim Mar 8 at 19:13
  • @heynnema - I don't think the switch is defective. I purchased it the past week to swap out the existing switch. Same results with both switches, both of which are unmanaged switches. The ethernet cables are cat 5e cables. – Jim Mar 8 at 19:15


I don't think that you can cascade unmanaged ethernet switches.

Your configuration should look more like this:

DSL modem-->router(1)-->switch(1-8)-->PCs(1-8)

To avoid long open cable runs, consider using PowerLine adapters.


For DSL, your MTU should not be 1500, but probably something like 1492.

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 the 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 # this will probably show fragmentation

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

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

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

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

Ethernet driver

The r8169 driver is buggy. Best to install r8168-dkms, reboot, and retest.

Update #1:

Replaced the router. It's all working now.

| 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.