Beiträge von sunnygerald

    Die folgende udev Regeln hat bei mir das Problem gelöst


    Code
    ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0b95", ATTR{idProduct}=="1790", ATTR{bConfigurationValue}!="1", ATTR{bConfigurationValue}="1"

    Nun wird ax88179_178a wie beabsichtigt geladen:

    Installiere dir mal einen älteren Kernel und schau damit, ob es geht.

    Habe jetzt den 5.14.21-150500.55.39-default im Einsatz. Erfolglos probiert hatte ich ja zuvor schon die zwei Versionen vor dem *52 (*44 und *49).

    Jetzt, also mit *39, erkennt und startet der Network Manager das Ethernet Device auch direkt nach dem Start :)


    Problem ist offenbar der Treiber. Jetzt wird anstatt dem cdc_ncm Treiber der ax88179_178a genutzt:


    Code
     triton:~ # inxi -xxN
    Network:
      Device-1: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter
        vendor: Rivet Networks Killer Wireless-n/a/ac 1535 driver: ath10k_pci
        v: kernel pcie: speed: 2.5 GT/s lanes: 1 bus-ID: 3b:00.0
        chip-ID: 168c:003e temp: 54.0 C
      Device-2: ASIX AX88179 Gigabit Ethernet type: USB driver: ax88179_178a
        bus-ID: 2-2.2:6 chip-ID: 0b95:1790
      Device-3: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152
        bus-ID: 4-1.2:3 chip-ID: 0bda:8153

    Wie könnte ich denn bei dem aktuellen Kernel (*52) erzwingen, dass der ax88179_178a genutzt wird?


    Code
    triton:~ # inxi -xxN
    Network:
      Device-1: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter
        vendor: Rivet Networks Killer Wireless-n/a/ac 1535 driver: ath10k_pci
        v: kernel pcie: speed: 2.5 GT/s lanes: 1 bus-ID: 3b:00.0
        chip-ID: 168c:003e temp: 54.0 C
      Device-2: ASIX AX88179 Gigabit Ethernet type: USB driver: cdc_ncm
        bus-ID: 2-2.2:4 chip-ID: 0b95:1790
      Device-3: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152
        bus-ID: 4-1.2:3 chip-ID: 0bda:8153

    Du hast aber auch schon gateway und DNS auf die IP von deinem Router gesetzt?

    Ja, die IP Adresse meiner Fritzbox hatte ich als Gateway und DNS gesetzt.


    Installieren:

    Code
    zypper in -f r8152-kmp-default

    Das ist der original Realtek Treiber als rpm gebaut.

    Es wird nur noch zusätzlich ein ueficert.rpm installiert, das ist bei secure boot notwendig.

    Falls du secure boot eingeschaltet hast, beim restart nach der Installation (wichtig):

    Mok Example


    Secure-Boot wird nicht benutzt.


    Der Realtek Treiber bzw. der NIC r8152 ist gar nicht das Problem: der ist zwar im Thunderbolt Dock vorhanden, wird aber gar nicht benutzt, dh. hat kein Kabel angeschlossen.

    Die Probleme macht der USB-GbE Controller AX88179A, der über einen USB-Hub direkt am Laptop angeschlossen ist. Das System lädt den Treiber cdc_ncm für das Device direkt nach dem Start.

    Was ist mit dem ältesten Kernel???

    Einen Kernel älter als 5.14.21-150500.55.44 wollte ich aus Sicherheitsgründen nicht mehr installieren.
    Wie erwähnt, bei 5.14.21-150500.55.44 friert das System wegen dem bekannten Bug ein. Kernel 14.21-150500.55.49 zeigt das gleiche verhalten.

    Kannst du nicht wicked benutzen?

    An einem Laptop würde dies nur sehr ungern tun, ist aber sicherlich eine valide Umgehungsmaßnahme, wenn man das Problem nicht lösen kann.


    Oder mal mit fester IP statt dhcp?

    Habe ich probiert: Device ist nach dem Start im State "disconnected". Erst ein Restart des NetworkManager Services bringt dann das Device (enp0s20f0u2u2c2) in den State "connected"

    Nach einem der letzten Online-Updates von OpenSuse 15.5 wird die Netzwerk-Verbindung "Kabelgebundene Verbindung 1" nach dem Start nicht mehr aktiviert bzw. ist im status DOWN. Erst eine manueller Restart von NetworkManager behebt das Problem

    Code
    triton:~ # ip a
    ....
    4: enp0s20f0u2u2c2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
        link/ether a0:ce:c8:6c:09:ae brd ff:ff:ff:ff:ff:ff
        inet 192.168.5.33/24 brd 192.168.5.255 scope global dynamic noprefixroute enp0s20f0u2u2c2
           valid_lft 863069sec preferred_lft 863069sec
        inet6 fe80::42b9:d104:ac4b:bbcf/64 scope link noprefixroute 
           valid_lft forever preferred_lft forever


    Bei dem Netzwerkdevice handelt es sich um einen Gigabit Ethernet NIC (AX88179A), der an einem USB Port hängt:


    Hier die (hoffentlich) relevanten Stellen aus dem Systemlog nach dem Boot, welches das Device enp0s20f0u2u3c2 im status "unmanaged" hinterlässt:


    Nach dem Restart über systemctl restart NetworkManager steht folgendes im Log (journalctl -b 0 -u NetworkManager):



    Das ganze funktionierte noch im Dezember... Im Rahmen der letzten (zwei?) Online-Updates kam irgendeine Veränderung rein, die das Verhalten veränderte.