The onboard nic is a 82579LM Gigabit Network Connection (Lewisville)        vendor: Intel Corporation The driver is e1000e. When this nic began acting up a few months ago, I started using the usb adapter.  When it started acting up, I removed it and went back to the onboard nic. ip link showed : 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 so ip neighbor showed nothing.  ip address: 1: lo: 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 tcpdump did nothing. Joseph Sinclair asked if I upgraded or downgraded the kernel. I hadn't upgraded the kernel unless it did that when I upgraded to Kubuntu 22.04. I ran journalctl -xe after it booted up without the network and with it.  I wouldn't know what to look for.  If anyone else wants to have a look, I've put version on google drive. without network https://drive.google.com/file/d/1tPf-2wzsAdN9YL1fbIt0gbJu082YCqUU/view?usp=sharing with network https://drive.google.com/file/d/1_dc12Loro0D4dCe8_kodqIj3GKTQOspf/view?usp=sharing On 9/23/22 14:00, Michael Butash via PLUG-discuss wrote: > I've used a lot of usb-based devices, and still do technically with a > thunderbolt dock for like the past 5 years, and not really run into > this on either ubuntu or arch.  I've run into some weirdness before > though with wired or wireless nics. Basic linux network 101 applies... > test it like a network engineer, layer 1-7. > > use "ip link" to see the state of of the physical nic, or verify layer 1 > use "ip neighbor" to verify you see mac forwarding ala arp table, or > layer 2/3 > use "ip address" to verify exactly that, verifying dhcp or static > configs take place for layer 3 > use "iftop" or "tcpdump" to see what traffic is sending, and if any is > coming back assuming your nic has link for layer 2-7 > > Aside from that probably a kernel/firmware thing.  Use journalctl -xe > or -b options to show you boot and logs (as root) of what happens > around the events with your nic.  It could be some firmware bug, > realtek's used to be terrible cursed names, but really haven't a > problem for me in the past 5-10 years I'd say, and you're hard pressed > to find a usb nic that *isn't* a realtek. > > You can probably rmmod and insmod the realtek driver too as long as > something isn't using it.  If it's busted, it should not be used, but > stranger things happen, especially if firmware is hung in a funky way, > which is usually what would always happen with them. > > -mb > > > On Fri, Sep 23, 2022 at 12:04 PM T Zack Crawford via PLUG-discuss > wrote: > > I am very interested in the answer because my desktop does the > same thing if I tell it to hibernate, boot into my windows dual > boot, and reboot back into linux. I can regain network access > again by hibernating again and booting back into linux directly > (no windows). Pretty annoying because it takes a solid 2-5 minutes > to shut down when hibernating. At least it still does the job, > just with delay. > > This only happens if I try hibernating and then boot into windows > (not full shutdown, not hibernate and boot directly to linux). It > has always happened since I enabled hibernation (arch wiki > instructions). Having Systemd restart NetworkManager does nothing. > Setting up a new network configuration with networkmanager does > not solve it. This is with my motherboard ethernet and my wireless > USB adapter. I spent some good energy trying to figure it out, but > never did. > > > Did you update kernels today? What if you downgrade? > > Put the solution as a boot script. Or at least bash profile > instead of run commands (otherwise it will run every time you > spawn a terminal shell) > > Sep 23, 2022 11:14:35 Jim via PLUG-discuss > : > > > A few months ago my Dell Optiplex 7010 running Ubuntu 20.04 > started booting up without the network.  I'd reboot the machine > and  the network was there.  If I shut down the machine and turned > it on again, no network.  I thought something was wrong with the > built in ethernet adapter, so I bought a usb adapter, disabled the > built in one and the problem went away until today.  Now it's > happening with the usb ethernet adapter.  Rebooting the machine > fixes the problem gets the network up and running.  If I start > with a cold boot and reboot at the grub screen, I get the > network.  I have 3 SSDs and 2 HDDs.  I have the same video card > that I had before this problem first showed itself.  It's a > GeForce GT 710. > > > > I looked online and found something telling of other people who > have had this problem.  They disconnected video cards and went > back to the built in video (display port), and removed hard drives > that had been added later and this fixed the problem.  The > ultimate solution was to replace the power supply.  I disconnected > one SSD and the 2 HDDs.  I don't have anything that can use a > display port, so I left the video card in place.  All I had > connected were  2 SSDs.  One it boots from and my home directory > is on the other.  The problem still showed itself when I booted > the machine, so I shut down and plugged in everything again.  This > thing has a 240 watt power supply.  Do power supplies go band in > such a way they don't produce the amount of power they used to? > > > > Any ideas what it might be?  Is there a command that would tell > the system to set up the network again?  If there is, I could put > it in the .bashrc until I get this fixed. > > > > Thanks > > > > --------------------------------------------------- > > PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org > > To subscribe, unsubscribe, or to change your mail settings: > > https://lists.phxlinux.org/mailman/listinfo/plug-discuss > --------------------------------------------------- > PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org > To subscribe, unsubscribe, or to change your mail settings: > https://lists.phxlinux.org/mailman/listinfo/plug-discuss > > > --------------------------------------------------- > PLUG-discuss mailing list:PLUG-discuss@lists.phxlinux.org > To subscribe, unsubscribe, or to change your mail settings: > https://lists.phxlinux.org/mailman/listinfo/plug-discuss