Join Log in
Score:0
argus10q avatar Ubuntu

Network stops listening after some time Ubuntu 20.04 LTS

gw flag
argus10q

I am currently running on ubuntu 20.04 LTS

All packages are up to date.

Using Ping 8.8.8.8 does not work. Randomly stops after {some number}th ping and "Packet loss" occurs. However when I visit the actual server IP (numbers), it magically starts listening to return packets.

Visiting the server misc webpage does not work. However when I visit the actual server IP, it also magically starts to respond.

I tried to fix with every trick in the book (that I know of). I reconfigured netplan with DNS. I released and renewed for new IP, that did not solve the issue. I switched between google DNS and Cloudflare DNS, no luck.

I have tested it to not be a router issue as my windows machine can ping 8.8.8.8 and enjoy no "packet loss". And I am positive it is not a packet loss during transmission as I have changed out the eth cable to a known-good one.

The above also applies for apt-get, unless I visit my server IP and retry the apt-get process, it the ubuntu package servers will not be known for some reason.

I am getting desperate here as I have services to maintain, so any help would be very much appreciated.

Additional information at netbat's request: ip addr responds with the following:

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: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether b4:2e:99:93:b4:0b brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.3/24 brd 192.168.0.255 scope global dynamic enp4s0
       valid_lft 85891sec preferred_lft 85891sec
    inet6 2002:7076:ae9b:0:b62e:99ff:fe93:b40b/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2246sec preferred_lft 1646sec
    inet6 fe80::b62e:99ff:fe93:b40b/64 scope link 
       valid_lft forever preferred_lft forever
3: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: br-1f1b9a3082c0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:71:7d:6f:db brd ff:ff:ff:ff:ff:ff
    inet 172.22.0.1/16 brd 172.22.255.255 scope global br-1f1b9a3082c0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:71ff:fe7d:6fdb/64 scope link 
       valid_lft forever preferred_lft forever
5: br-3c0161ddec68: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:0d:93:4e:af brd ff:ff:ff:ff:ff:ff
    inet 172.23.0.1/16 brd 172.23.255.255 scope global br-3c0161ddec68
       valid_lft forever preferred_lft forever
    inet6 fe80::42:dff:fe93:4eaf/64 scope link 
       valid_lft forever preferred_lft forever
6: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:d0:b9:75:7a brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:d0ff:feb9:757a/64 scope link 
       valid_lft forever preferred_lft forever
7: br-7a5c6f0f89f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:c7:f0:51:bc brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-7a5c6f0f89f1
       valid_lft forever preferred_lft forever
8: br-f34cf0cbdd41: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:6b:10:be:6a brd ff:ff:ff:ff:ff:ff
    inet 172.21.0.1/16 brd 172.21.255.255 scope global br-f34cf0cbdd41
       valid_lft forever preferred_lft forever
    inet6 fe80::42:6bff:fe10:be6a/64 scope link 
       valid_lft forever preferred_lft forever
9: br-fe65b7ed9ee0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:02:84:1d:1c brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/20 brd 192.168.15.255 scope global br-fe65b7ed9ee0
       valid_lft forever preferred_lft forever
11: veth7153d2c@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default 
    link/ether ea:8b:11:af:8c:33 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::e88b:11ff:feaf:8c33/64 scope link 
       valid_lft forever preferred_lft forever
13: veth4c6a7c3@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-f34cf0cbdd41 state UP group default 
    link/ether 8a:f9:27:2c:e6:c9 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::88f9:27ff:fe2c:e6c9/64 scope link 
       valid_lft forever preferred_lft forever
15: veth925bf9a@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-1f1b9a3082c0 state UP group default 
    link/ether c6:3f:61:c2:e4:ad brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::c43f:61ff:fec2:e4ad/64 scope link 
       valid_lft forever preferred_lft forever

ip route returns the following:

default via 192.168.0.1 dev enp4s0 proto dhcp src 192.168.0.3 metric 100 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.18.0.0/16 dev br-7a5c6f0f89f1 proto kernel scope link src 172.18.0.1 linkdown 
172.21.0.0/16 dev br-f34cf0cbdd41 proto kernel scope link src 172.21.0.1 
172.22.0.0/16 dev br-1f1b9a3082c0 proto kernel scope link src 172.22.0.1 
172.23.0.0/16 dev br-3c0161ddec68 proto kernel scope link src 172.23.0.1 linkdown 
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.3 
192.168.0.0/20 dev br-fe65b7ed9ee0 proto kernel scope link src 192.168.0.1 linkdown 
192.168.0.1 dev enp4s0 proto dhcp scope link src 192.168.0.3 metric 100

ip neigh returns the follwing:

192.168.0.4 dev enp4s0 lladdr ee:8b:8b:69:64:85 STALE
172.22.0.2 dev br-1f1b9a3082c0 lladdr 02:42:ac:16:00:02 STALE
192.168.0.9 dev enp4s0 lladdr b2:e0:62:18:82:a1 STALE
192.168.0.6 dev enp4s0 lladdr 08:66:98:8c:c5:38 STALE
192.168.0.1 dev enp4s0 lladdr 34:98:b5:a0:74:7c REACHABLE
192.168.0.8 dev enp4s0 lladdr f0:18:98:2f:c5:c1 STALE
[REDACTED PUB IP] dev enp4s0 lladdr 34:98:b5:a0:74:7c STALE
192.168.0.2 dev enp4s0 lladdr 2c:f0:5d:e3:b2:28 REACHABLE
172.17.0.2 dev docker0 lladdr 02:42:ac:11:00:02 STALE
192.168.0.5 dev enp4s0 lladdr 9c:32:ce:7f:bf:09 STALE
172.17.0.3 dev docker0 lladdr 02:42:ac:11:00:03 STALE
172.21.0.2 dev br-f34cf0cbdd41 lladdr 02:42:ac:15:00:02 STALE
fe80::3698:b5ff:fea0:747c dev enp4s0 lladdr 34:98:b5:a0:74:7c router REACHABLE

I use ping 8.8.8.8 and let it run to test the connections.

64 bytes from 8.8.8.8: icmp_seq=36 ttl=118 time=3.56 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=118 time=4.09 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=118 time=4.17 ms
^C
--- 8.8.8.8 ping statistics ---
46 packets transmitted, 38 received, 17.3913% packet loss, time 45217ms
rtt min/avg/max/mdev = 3.504/25.263/814.588/129.764 ms

where the Control+C exit it used when it no longer and will never ping again. In this specific session the ping packets end at 38 and the rest are "lost".

Pings to the router gateway 192.168.0.1 are stable over the long term with 0% packet loss over 1202 packets. I have configured the router to reserve the IP address 192.168.0.3 to the MAC address, and there can be no conflicting addresses either.

However my other machine does not have this issue, so I am very firm with the thought of it being a Ubuntu configuration issue that I cannot solve on my own.

76
1 + 0
dns
Score:0
netbat avatar Ubuntu
br flag
netbat

You have given too little information for a thorough analysis of the problem. I would welcome a response to these commands:

ip addr
ip route
ip neigh

Enter the commands when Google DNS 8.8.8.8.8 responds to the ping and then again when the ping has no response. Comparing the two states will tell you a lot.

It is also important to check if the IP address of the default gateway (i.e. the router) is available and reliably responds to pings in the long term. You can find its address using the ip route command:

ip route | grep "default" | cut -f 3 -d " "

Is the router's ping response stable over the long term? If not, the problem must be in your local area network (LAN).

One possible explanation for the fault is that your Linux PC has an IP address collision with another device on the network. Perhaps your DHCP server does not check in advance whether there are free addresses it wants to allocate. Thus, a collision address allocation may occur. But this is just speculation, there could be more causes.

Edit

Please add the command responses for the state when the connection has already been broken, i.e. after 45 seconds. You only gave the responses for the normal state.

It is very unusual for the default network gateway (router) to still be available and yet the connection to external addresses is broken 45 seconds after the interface is activated. Either the gateway is lost and the connection to the outside of the network is broken at the same time, or the gateway is available and the connection to the outside persists.

I assume there is an address collision either on your network or directly on your Ubuntu system.

Take a look at your bridge interface br-fe65b7ed9ee0. It has an address of 192.168.0.1 that conflicts with the router address. In a state where the connection is working, the bridge interface is inactive. But should the system try to activate it after some time, the collision will occur and you will lose the connection out of the network. Your bridge interface will respond to the ping instead of the router, and therefore pinging the default gateway will seemingly work. But only seemingly.

+ 2
argus10q avatar
gw flag
argus10q
I have edited my post, hope these information can assist anybody reading
0
Reply
netbat avatar
br flag
netbat
I have added another comment and a request to complete the test. Please see the extended reply.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.