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: <LOOPBACK,UP,LOWER_UP> 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: <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
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
> <plug-discuss@lists.phxlinux.org> 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
> <plug-discuss@lists.phxlinux.org>:
>
> > 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---------------------------------------------------
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
(text/plain)