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

Reply via email to