1

I am using USB wired modem to connect internet(over eth0 interface) in Debian Bullseye (uname -a >> Linux styx 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux). Sometimes, my ethernet interface suddenly stops. Interestingly :

  1. I can ping to gateway(success),
  2. I can ping to 8.8.8.8(success),
  3. Interface seems up (I checked ip addr show)
  4. I restart interface by ifdown first, and then by ifup, nothing happened, ethernet interface name changed from eth0 to enxMACADDRESS, but still no internet connection.
  5. I checked the output of ip route, it was the same configuration as with eth0 when it was working.

I checked the previous question&answers (such as no connection, etc.). I can ping to 8.8.8.8 but there is not internet(No ping to other IPs, such as openDNS's servers).

There is no error about interface and it is up. Only I have to unplug and replug USB cable and then connection re-established. [ EDIT BEGIN ] After comments and answer, I checked the /var/log/syslog as Felicia stated as answer and I found that :

Feb 21 11:40:30 localhost kernel: [ 3936.163162] usb-storage 3-5.4:1.2: USB Mass Storage device detected
Feb 21 11:40:30 localhost kernel: [ 3936.167079] scsi host10: usb-storage 3-5.4:1.2
Feb 21 11:40:30 localhost mtp-probe: checking bus 3, device 18: "/sys/devices/pci0000:00/0000:00:1d.7/usb3/3-5/3-5.x"
Feb 21 11:40:30 localhost mtp-probe: bus: 3, device: 18 was not an MTP device
Feb 21 11:40:30 localhost systemd-udevd[5898]: Using default interface naming scheme 'v247'.
Feb 21 11:40:30 localhost systemd-udevd[5898]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Feb 21 11:40:30 localhost kernel: [ 3936.225574] cdc_ether 3-5.x:1.0 enxXXXXXXXXXXXX: renamed from eth0
Feb 21 11:40:30 localhost mtp-probe: checking bus 3, device 18: "/sys/devices/pci0000:00/0000:00:1d.7/usb3/3-5/3-5.x"
Feb 21 11:40:30 localhost mtp-probe: bus: 3, device: 18 was not an MTP device
Feb 21 11:40:30 localhost systemd-udevd[5903]: Using default interface naming scheme 'v247'.
Feb 21 11:40:30 localhost systemd-udevd[5903]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Feb 21 11:40:30 localhost systemd[1]: Found device 1024.
Feb 21 11:40:30 localhost systemd[1]: Started ifup for enxXXXXXXXXXXXX.
Feb 21 11:40:30 localhost dhclient[5931]: Internet Systems Consortium DHCP Client 4.4.1
Feb 21 11:40:30 localhost sh[5931]: Internet Systems Consortium DHCP Client 4.4.1
Feb 21 11:40:30 localhost dhclient[5931]: Copyright 2004-2018 Internet Systems Consortium.
Feb 21 11:40:30 localhost sh[5931]: Copyright 2004-2018 Internet Systems Consortium.
Feb 21 11:40:30 localhost dhclient[5931]: All rights reserved.
Feb 21 11:40:30 localhost dhclient[5931]: For info, please visit https://www.isc.org/software/dhcp/
Feb 21 11:40:30 localhost sh[5931]: All rights reserved.
Feb 21 11:40:30 localhost sh[5931]: For info, please visit https://www.isc.org/software/dhcp/
Feb 21 11:40:30 localhost dhclient[5931]: 
Feb 21 11:40:30 localhost dhclient[5931]: Listening on LPF/enxXXXXXXXXXXXX/X:X:X:X:X:X
Feb 21 11:40:30 localhost sh[5931]: Listening on LPF/enxXXXXXXXXXXXX/X:X:X:X:X:X
Feb 21 11:40:30 localhost sh[5931]: Sending on   LPF/enxXXXXXXXXXXXX/X:X:X:X:X:X
Feb 21 11:40:30 localhost sh[5931]: Sending on   Socket/fallback
Feb 21 11:40:30 localhost sh[5931]: DHCPREQUEST for 192.168.x.100 on enxXXXXXXXXXXXX to 255.255.255.255 port 67
Feb 21 11:40:30 localhost dhclient[5931]: Sending on   LPF/enxXXXXXXXXXXXX/X:X:X:X:X:X
Feb 21 11:40:30 localhost dhclient[5931]: Sending on   Socket/fallback
Feb 21 11:40:30 localhost dhclient[5931]: DHCPREQUEST for 192.168.9.100 on enxXXXXXXXXXXXX to 255.255.255.255 port 67
Feb 21 11:40:30 localhost dhclient[5931]: DHCPNAK from 192.168.x.1
Feb 21 11:40:30 localhost sh[5931]: DHCPNAK from 192.168.x.1
Feb 21 11:40:30 localhost avahi-autoipd(enxXXXXXXXXXXXX)[5947]: Found user 'avahi-autoipd' (UID 108) and group 'avahi-autoipd' (GID 116).
Feb 21 11:40:30 localhost avahi-autoipd(enxXXXXXXXXXXXX)[5947]: Successfully called chroot().
Feb 21 11:40:30 localhost avahi-autoipd(enxXXXXXXXXXXXX)[5947]: Successfully dropped root privileges.
Feb 21 11:40:30 localhost avahi-autoipd(enxXXXXXXXXXXXX)[5947]: Starting with address 169.254.4.147

Also I have found that there is a file in /run/ called /run/dhclient.enxXXXXXXXXXXXX.pid which includes 5931 which is the same number stated in above log. But, What I understood is that, the problem is due to error was that it changed my address to 169.254.4.147**, which means it kicks me that IP and I do not see network anymore. [ END OF EDIT]

[SECOND EDIT] Ok, again failure occured this time I am ready to analyse it(I think :D). So, what I found this time are :

  1. I checked whether I can pinging to another IP other than 8.8.8.8 and but no success, 8.8.8.8 is still successful.
  2. I can not ping 169.254.4.147 (which seem an private IP I dropped to) too! Strange.
  3. I checked that /sys/clas/net/enxXXXXXXXXXXXX/carrier file to have a network or not, it said 1, so it gives me I am online.
  4. However, until unplug, I can not see none of the interface or network errors in /var/log/syslog(i.e. system logs). When I unplug and replugger USB cable, all of them revealed.
  5. I checked that /etc/resolv.conf is the same as before, i.e not changed after failure.
  6. I can still ping to 8.8.8.8 only, not to other addresses.
  7. I am trying ; restarting networking service,ifup-down interfaces, IP release/renwe by dhclient -r and dhclient -4 etc. but during all those processes I can still ping to 8.8.8.8. Is there something stucked socket etc. to 8.8.8.8?

[ END OF SECOND EDIT]

  1. Is there other ways/commands to check what is the root cause of the problem?

  2. How can I solve it without unplugging/replugging the cable?

[EDIT] I found the answer in answer. Thanks to mcdizzle's answer. Problem was tcp packages's timestamps, when I closed and add a openDNS as nameserver, those solved my problems.

Jim L.
  • 7,188
  • 1
  • 13
  • 25
  • 1
    8.8.8.8 *is* on the internet, so if you get a response from that address you have an Internet connection. Maybe you have a name server problem? Have you tried pinging other IP addresses? – Johan Myréen Feb 21 '22 at 11:39
  • Perhaps your `/etc/resolv.conf` file is getting overwritten or removed periodically. – Bib Feb 21 '22 at 12:10
  • 1
    You've stated what still works, but not what does not work. Please add this information also. – gerhard d. Feb 21 '22 at 12:10
  • @Bib: this has nothing to do with basic routing, though. I would suspect some kind of firewall-rule kicking in here... – gerhard d. Feb 21 '22 at 12:11
  • @gerhard if it works, then stops, it is unlikely to be firewall issues. I have seen `/etc/resolv.conf` being deleted sometime after an interface has come up, hence it should be checked, – Bib Feb 21 '22 at 12:21
  • Just cat it out and check for server and search entries, it's not huge. – Bib Feb 21 '22 at 12:28
  • Other logs show a DHCP renew failing and IPv4LL getting used. But then ping to 8.8.8.8 (or even the gateway) should not work anymore. As nothing is clear, you should show the output of this before the failure and after the failure: `ip -br link; ip -br address; ip route` and as already asked, state exactly what did work before and doesn't work after (not just "Internet", since 8.8.8.8 is part of Internet and is working). Yet, still also give the resolv.conf before and after the problem. – A.B Feb 21 '22 at 12:43

2 Answers2

1

This

Feb 21 11:40:30 localhost sh[5931]: DHCPREQUEST for 192.168.x.100 on enxXXXXXXXXXXXX to 255.255.255.255 port 67
Feb 21 11:40:30 localhost dhclient[5931]: Sending on   LPF/enxXXXXXXXXXXXX/X:X:X:X:X:X
Feb 21 11:40:30 localhost dhclient[5931]: Sending on   Socket/fallback
Feb 21 11:40:30 localhost dhclient[5931]: DHCPREQUEST for 192.168.9.100 on enxXXXXXXXXXXXX to 255.255.255.255 port 67
Feb 21 11:40:30 localhost dhclient[5931]: DHCPNAK from 192.168.x.1

says you are trying to get an IP address from the DHCP server, for an existing IP address, but that is denied. As a consequence, you are probably loosing the IP address on that interface (check with ip addr).

So configure your DHCP server correctly. Or stop your interface from changing the MAC address. Or whatever causes the DHCPNAK.

(BTW, you don't need to x the 192.168 addresses; these are private IP addresses, and won't be used outside your private network).

dirkt
  • 31,679
  • 3
  • 40
  • 73
  • This information really belongs into the question ... if the DHCP server is running on the usb-modem, or in your ISPs network, then you cannot configure it, as you don't own it. So then you need to figure out why your system insists on a DHCP for an existing address, and if you cannot configure it to just get a new address if that interface goes down (or whatever triggers that request). Assuming you use systemd for networking, this is going to be "fun". – dirkt Mar 09 '22 at 07:18
0

Check the syslog to see if there are any errors related to the interface:

sudo tail -f /var/log/syslog

If you see errors related to the interface, a kernel upgrade might help. For example, you could set up bullseye backports and install a more recent backport kernel which might solve the issue.

Felicia
  • 19
  • 3