Treiberproblem e1000e [war: NIC-Hardwarefehler erkennen]

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
max123kl
Beiträge: 43
Registriert: 20.02.2006 22:33:39
Lizenz eigener Beiträge: MIT Lizenz

Treiberproblem e1000e [war: NIC-Hardwarefehler erkennen]

Beitrag von max123kl » 17.01.2018 11:03:02

Hallo,
in meinem Homeserver werkelt ein ASRock WS226M-Board. Onboard verbaut sind 2x GBit-NIC's (Intel i210 + Intel i217LM). OS ist Debian8, KVM/QEMU und libvirt.
Nach einem Bios-Update funktioniert eine der beiden NIC's nicht mehr. Auch ein Zurückspielen der vorherigen Bios-Version hilft nicht.
Wissentlich ist keine sonstige Änderung an der Konfiguration vorgenomen worden.

/etc/interfaces sieht wie folgt aus

Code: Alles auswählen

# The primary network interface + Bridge
#allow-hotplug eth0
#iface eth0 inet manual

#  bridge internet
iface br0 inet manual
	   bridge_ports eth0
	   bridge_stp on
	   bridge_fd 0
#  bridge intern	   
iface br1 inet static
   address 192.168.1.1
   netmask 255.255.255.0
   gateway 192.168.1.2
	   bridge_ports eth1
	   bridge_stp on
	   bridge_fd 0

Code: Alles auswählen

ip addr
: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether d0:50:99:64:d3:35 brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default 
    link/ether a2:5a:d8:13:fd:7c brd ff:ff:ff:ff:ff:ff
4: virbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 52:54:00:02:75:ad brd ff:ff:ff:ff:ff:ff
5: virbr1-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr1 state DOWN mode DEFAULT group default qlen 500
    link/ether 52:54:00:02:75:ad brd ff:ff:ff:ff:ff:ff
6: virbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 52:54:00:b7:74:68 brd ff:ff:ff:ff:ff:ff
7: virbr2-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr2 state DOWN mode DEFAULT group default qlen 500
    link/ether 52:54:00:b7:74:68 brd ff:ff:ff:ff:ff:ff
9: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr2 state UNKNOWN mode DEFAULT group default qlen 500
    link/ether fe:54:00:ce:0e:1c brd ff:ff:ff:ff:ff:ff
11: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr2 state UNKNOWN mode DEFAULT group default qlen 500
    link/ether fe:54:00:aa:11:f0 brd ff:ff:ff:ff:ff:ff
Es fehlt 'eth0' bzw 'br0' und 'eth1' ist down.
'ifup eth1' bringt "Ignoring unknown Device eth1=eth1"
Im syslog kann ich folgenses entdecken:

Code: Alles auswählen

Jan 17 07:40:29 host0 libvirtd[769]: Cannot get interface MTU on 'br0': Kein passendes Gerät gefunden
Jan 17 07:40:29 host0 kernel: [    4.682294] kvm: zapping shadow pages for mmio generation wraparound
Jan 17 07:40:29 host0 libvirtd[769]: Failed to autostart VM 'ipfire': Cannot get interface MTU on 'br0': Kein passendes Gerät gefunden
Über 'hwinfo' kann ich nur den Intel i217LM-Kontroller entdecken.
Wie kann ich feststellen ob wirklich ein Hardwaredefekt vorliegt. Die übliche Kabel- und Switch-Tauschaktion habe ich schon ohne Erfolg hinter mir. Oder ist es doch ein Konfigurationsfehler?
Gruß max
Zuletzt geändert von max123kl am 22.01.2018 19:41:04, insgesamt 1-mal geändert.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: NIC-Hardwarefehler erkennen

Beitrag von MSfree » 17.01.2018 11:22:51

max123kl hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 11:03:02
Nach einem Bios-Update funktioniert eine der beiden NIC's nicht mehr. Auch ein Zurückspielen der vorherigen Bios-Version hilft nicht.
Hat das eventuell die MAC-Adresse der zweiten Netzwerkschnittstelle geändert?
Dann würde eth1 nämlich zu eth2 umbenannt werden.

Was sagt ifconfig -a?

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von reox » 17.01.2018 11:38:58

eth2 scheint es ja auch nicht zu geben.

was sagt lspci? findest du im syslog was dazu? Evt ist das modul nicht geladen. Wobei vermutlich beide über E1000E laufen. Findest du zu e1000e was im kernel.log?

max123kl
Beiträge: 43
Registriert: 20.02.2006 22:33:39
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von max123kl » 17.01.2018 11:56:09

MSfree hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 11:22:51
Was sagt ifconfig -a?

Code: Alles auswählen

br0       Link encap:Ethernet  Hardware Adresse 8e:82:6e:9a:51:87  
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

br1       Link encap:Ethernet  Hardware Adresse d0:50:99:64:d3:35  
          inet Adresse:192.168.1.1  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6-Adresse: fe80::d250:99ff:fe64:d335/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:199 errors:0 dropped:0 overruns:0 frame:0
          TX packets:331 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:9991 (9.7 KiB)  TX bytes:14214 (13.8 KiB)

dummy0    Link encap:Ethernet  Hardware Adresse a2:5a:d8:13:fd:7c  
          BROADCAST NOARP  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth1      Link encap:Ethernet  Hardware Adresse d0:50:99:64:d3:35  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:212 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1178 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:18721 (18.2 KiB)  TX bytes:58258 (56.8 KiB)
          Speicher:efc00000-efc7ffff 
...
Kannst du hexen? :D
Ich hab die gestern die halbe Nacht damit zugebracht den Fehler zu finden.
Den ifconfig-Befehl natürlich auch auch abgesetzt - mit versch. 'interfaces' Versionen getestet, Live-CDs gestartet usw. — kein Erfolg.
Heute morgen dann wieder alles zurück auf Anfang um diesen Thread mit Code-Zeilen zu füttern — Status -kein 'br0'.

Nach deine schnellen Antwort nochmal 'ifconfig -a' abgesetzt — die fehlenden Interfaces sind da! :hail:
Auch 'ip addr' zeigt wieder alle Devices — "what a miracle"

Jetzt muss das Ganze nur noch einen Reboot überstehen.
:evil: Verdammt wieder keine 'br0' !
Was kann das nur sein?
Gruß max
Zuletzt geändert von max123kl am 17.01.2018 12:02:11, insgesamt 1-mal geändert.

BenutzerGa4gooPh

Re: NIC-Hardwarefehler erkennen

Beitrag von BenutzerGa4gooPh » 17.01.2018 11:57:42

Live-ISO booten, um andere Fehlerquellen auszuschließen. dmesg und journalctl -b prüfen. Direktanschluss eines 2. Rechners an fragliche Schnittstelle.
https://www.techrepublic.com/article/ho ... h-ethtool/
Wenn wirklich defekt, USB3.0-Ethernet-Adapter. Ich suche mal einen entsprechenden Thread ...
viewtopic.php?f=13&t=167590#p1159677

Edit: Lösung kam wohl schon. :mrgreen:
Nach deine schnellen Antwort nochmal 'ifconfig -a' abgesetzt — die fehlenden Interfaces sind da!
Zeigt alle Interfaces an, egal ob up oder down, konfiguriert oder nicht.

Edit2: Link nachgereicht.

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von reox » 17.01.2018 12:33:35

Jana66 hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 11:57:42
Nach deine schnellen Antwort nochmal 'ifconfig -a' abgesetzt — die fehlenden Interfaces sind da!
Zeigt alle Interfaces an, egal ob up oder down, konfiguriert oder nicht.
sollte doch das selbe tun wie

Code: Alles auswählen

ip link
oder nicht? Wer verwendet heute noch ifconfig ;)

max123kl
Beiträge: 43
Registriert: 20.02.2006 22:33:39
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von max123kl » 17.01.2018 12:35:47

reox hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 11:38:58
eth2 scheint es ja auch nicht zu geben.
eth2 ist auch nicht definiert.
was sagt lspci? findest du im syslog was dazu? Evt ist das modul nicht geladen. Wobei vermutlich beide über E1000E laufen. Findest du zu e1000e was im kernel.log?

Code: Alles auswählen

lspci
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
...
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 05)
...
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
im syslog steht:

Code: Alles auswählen

Jan 17 11:47:49 host0 libvirtd[765]: Cannot get interface MTU on 'br0': Kein passendes Gerät gefunden
Jan 17 11:47:49 host0 libvirtd[765]: Failed to autostart VM 'ipfire': Cannot get interface MTU on 'br0': Kein passendes Gerät gefunden
Wie du in meinem vorigen Post sehen kannst, hat die Konfiguration seltsamerweise bis zum Reboot wieder funktioniert. Dazu erschien im Syslog folgendes:

Code: Alles auswählen

Jan 17 11:32:36 host0 kernel: [ 7655.116840] br0: port 1(vnet2) entered learning state
Jan 17 11:32:36 host0 kernel: [ 7655.244652] br1: port 2(vnet3) entered learning state
Jan 17 11:32:51 host0 kernel: [ 7670.133350] br0: topology change detected, propagating
Jan 17 11:32:51 host0 kernel: [ 7670.133376] br0: port 1(vnet2) entered forwarding state
Jan 17 11:32:51 host0 kernel: [ 7670.133474] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
Jan 17 11:32:51 host0 kernel: [ 7670.261159] br1: topology change detected, propagating
Jan 17 11:32:51 host0 kernel: [ 7670.261177] br1: port 2(vnet3) entered forwarding state
Die eine Karte läuft mit dem e1000e- die andere mit dem igb-Treiber. Der e1000e wird über @modules.conf beim Booten geladen.
Gruß max

BenutzerGa4gooPh

Re: NIC-Hardwarefehler erkennen

Beitrag von BenutzerGa4gooPh » 17.01.2018 12:46:06

reox hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 12:33:35
Wer verwendet heute noch ifconfig :wink:
Die Ewiggestrigen wie MSFree. :mrgreen: :mrgreen: :mrgreen: (Der versteht Spaß.)
max123kl hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 12:35:47
Jan 17 11:47:49 host0 libvirtd[765]: Failed to autostart VM 'ipfire': Cannot get interface MTU on 'br0': Kein passendes Gerät gefunden
Läuft eine VM mit IPFire? Probeweise mal gebridgte VM abschalten, Interfaces neu konfigureren?!

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: NIC-Hardwarefehler erkennen

Beitrag von bluestar » 17.01.2018 13:41:55

Sofern ich nichts überlesen habe fehlen in deiner /etc/network/interfaces folgende Zeilen:

Code: Alles auswählen

auto br0
auto br1

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von reox » 17.01.2018 16:03:28

max123kl hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 12:35:47

Code: Alles auswählen

lspci
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
...
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 05)
...
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
Ok, also beide Karten werden am Bus erkannt. Wenn sie nicht per ip link auftaucht, dann liegt das vermutlich am Kernelmodul.
Im kern.log solltest du bei der e1000e karte sowas sehen:

Code: Alles auswählen

Jan 17 08:37:02 helios kernel: [    0.829864] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
Jan 17 08:37:02 helios kernel: [    0.829864] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
Jan 17 08:37:02 helios kernel: [    0.830965] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
Jan 17 08:37:02 helios kernel: [    0.977027] e1000e 0000:00:19.0 0000:00:19.0 (uninitialized): registered PHC clock
Jan 17 08:37:02 helios kernel: [    1.106963] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) e8:40:f2:3d:07:cb
Jan 17 08:37:02 helios kernel: [    1.106964] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
Jan 17 08:37:02 helios kernel: [    1.107003] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: FFFFFF-0FF
Jan 17 08:37:08 helios kernel: [   11.997757] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
was genau das andere Kernelmodul rausschreibt weiß ich nicht...
was sagt denn lsmod? sind beide module geladen? evt das modul entladen und neu laden und dabei den Kernel log beobachten.

Greppe doch mal nach e1000e und igb im kern.log.

Jedenfalls kann die Bridge nicht starten, solange kein interface eth0 da ist.
bluestar hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 13:41:55
Sofern ich nichts überlesen habe fehlen in deiner /etc/network/interfaces folgende Zeilen:

Code: Alles auswählen

auto br0
auto br1
das klingt sehr gut. nur laut der ausgabe von ipconfig -a gitb es keine andere karte außer eth1... Wieso da aber br0 auftaucht und kein eth0 weiß ich ehrlich gesagt auch nicht.

max123kl
Beiträge: 43
Registriert: 20.02.2006 22:33:39
Lizenz eigener Beiträge: MIT Lizenz

Re:Treiberproblem e1000e [was:NIC-Hardwarefehler erkennen]

Beitrag von max123kl » 18.01.2018 09:58:48

Hallo an alle, die helfen wollen.
Leider hatte ich gestern keine Zeit mehr zu antworten.
Deshalb versuche ich die bisher gemachten Vorschläge hier zusammenzufassen
reox hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 16:03:28
Ok, also beide Karten werden am Bus erkannt. Wenn sie nicht per ip link auftaucht, dann liegt das vermutlich am Kernelmodul.
Im kern.log solltest du bei der e1000e karte sowas sehen:

Code: Alles auswählen

Jan 17 08:37:02 helios kernel: [    0.829864] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
...
Jan 17 08:37:08 helios kernel: [   11.997757] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Im kern.log finde ich folgende Zeilen:

Code: Alles auswählen

Jan 18 07:17:51 host0 kernel: [    0.563001] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
Jan 18 07:17:51 host0 kernel: [    0.563003] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
Jan 18 07:17:51 host0 kernel: [    0.563032] usbcore: registered new device driver usb
Jan 18 07:17:51 host0 kernel: [    0.563082] SCSI subsystem initialized
Jan 18 07:17:51 host0 kernel: [    0.563292] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
Jan 18 07:17:51 host0 kernel: [    0.563308] e1000e 0000:00:19.0: irq 40 for MSI/MSI-X
Jan 18 07:17:51 host0 kernel: [    0.563370] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Jan 18 07:17:51 host0 kernel: [    0.563494] igb 0000:02:00.0: irq 41 for MSI/MSI-X
Jan 18 07:17:51 host0 kernel: [    0.563497] igb 0000:02:00.0: irq 42 for MSI/MSI-X
Jan 18 07:17:51 host0 kernel: [    0.563500] igb 0000:02:00.0: irq 43 for MSI/MSI-X
Jan 18 07:17:51 host0 kernel: [    0.563503] igb 0000:02:00.0: irq 44 for MSI/MSI-X
Jan 18 07:17:51 host0 kernel: [    0.563505] igb 0000:02:00.0: irq 45 for MSI/MSI-X
Jan 18 07:17:51 host0 kernel: [    0.563512] ehci-pci: EHCI PCI platform driver
Jan 18 07:17:51 host0 kernel: [    0.564040] libata version 3.00 loaded.
Jan 18 07:17:51 host0 kernel: [    0.595554] igb 0000:02:00.0: added PHC on eth0
Jan 18 07:17:51 host0 kernel: [    0.595556] igb 0000:02:00.0: Intel(R) Gigabit Ethernet Network Connection
Jan 18 07:17:51 host0 kernel: [    0.595558] igb 0000:02:00.0: eth0: (PCIe:2.5Gb/s:Width x1) d0:50:99:64:d3:35
Jan 18 07:17:51 host0 kernel: [    0.595611] igb 0000:02:00.0: eth0: PBA No: 001300-000
Jan 18 07:17:51 host0 kernel: [    0.595612] igb 0000:02:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
Jan 18 07:17:51 host0 kernel: [    0.646996] e1000e 0000:00:19.0: The NVM Checksum Is Not Valid
Jan 18 07:17:51 host0 kernel: [    0.682050] e1000e: probe of 0000:00:19.0 failed with error -5
Wobei die beiden letzten Zeilen vermutlich das Problem eingrenzen.
Wie kann ich das beheben?
reox hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 16:03:28
was genau das andere Kernelmodul rausschreibt weiß ich nicht...
was sagt denn lsmod? sind beide module geladen? evt das modul entladen und neu laden und dabei den Kernel log beobachten.
Greppe doch mal nach e1000e und igb im kern.log.

Code: Alles auswählen

lsmod | grep igb
igb                   171921  0 
i2c_algo_bit           12751  2 igb,i915
dca                    13168  1 igb
ptp                    17692  2 igb,e1000e
i2c_core               46012  10 drm,igb,i915,i2c_i801,snd_soc_rt5640,i2c_hid,i2c_designware_platform,regmap_i2c,drm_kms_helper,i2c_algo_bit

lsmod | grep e1000e
e1000e                212170  0 
ptp                    17692  2 igb,e1000e
Bedeutet die "0" nicht geladen? Wenn ja, warum werden die Interfaces jetzt mit 'ip link' angezeigt (siehe weiter unten)?
Jedenfalls kann die Bridge nicht starten, solange kein interface eth0 da ist.
bluestar hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 13:41:55
Sofern ich nichts überlesen habe fehlen in deiner /etc/network/interfaces folgende Zeilen:

Code: Alles auswählen

auto br0
auto br1
das klingt sehr gut. nur laut der ausgabe von ipconfig -a gitb es keine andere karte außer eth1... Wieso da aber br0 auftaucht und kein eth0 weiß ich ehrlich gesagt auch nicht.
@bluestar
Ich habe in die 'interfaces' mal auto br0 und auto br1 eingefügt. Sie sieht jetzt so aus:

Code: Alles auswählen

# The primary network interface + Bridge
#allow-hotplug eth0
#iface eth0 inet manual

#  bridge internet
auto br0
iface br0 inet manual
	   bridge_ports eth0
	   bridge_stp on
	   bridge_fd 0
# bridge intern
auto br1	   
iface br1 inet static
   address 192.168.1.1
   netmask 255.255.255.0
   gateway 192.168.1.2
	   bridge_ports eth1
	   bridge_stp on
	   bridge_fd 0
Beim booten erhalte ich eine Meldung, die vorher nicht auftauchte und die auf ein verzögertes Laden hindeutet. Was genau konnte ich nicht erkennen und in der 'syslog' nicht finden. Ich habe die kern.log http://zsitetst.bplaced.net/uploads/kern.log und syslog http://zsitetst.bplaced.net/uploads/syslog mal zum anschauen online gestellt.
Bei einem erneuten Reboot habe ich mir die Meldung notieren können:
"a start job is running for LSB. Raise network interfaces"
Danach hing der Bootprozess. Nach einem Hardreset kam der Rechner dann wieder hoch. Also kein Dauerzustand.

Was aber erfreulich ist, dass die Autostart-VMs auch booten. 'ip link' zeigt die bisher fehlenden Interfaces.

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br1 state UP mode DEFAULT group default qlen 1000
    link/ether d0:50:99:64:d3:35 brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default 
    link/ether ca:96:a8:fa:eb:d9 brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether fe:54:00:e3:f9:17 brd ff:ff:ff:ff:ff:ff
5: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether d0:50:99:64:d3:35 brd ff:ff:ff:ff:ff:ff
6: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 52:54:00:02:75:ad brd ff:ff:ff:ff:ff:ff
7: virbr1-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr1 state DOWN mode DEFAULT group default qlen 500
    link/ether 52:54:00:02:75:ad brd ff:ff:ff:ff:ff:ff
8: virbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 52:54:00:b7:74:68 brd ff:ff:ff:ff:ff:ff
9: virbr2-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr2 state DOWN mode DEFAULT group default qlen 500
    link/ether 52:54:00:b7:74:68 brd ff:ff:ff:ff:ff:ff
10: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr2 state UNKNOWN mode DEFAULT group default qlen 500
    link/ether fe:54:00:aa:11:f0 brd ff:ff:ff:ff:ff:ff
11: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr2 state UNKNOWN mode DEFAULT group default qlen 500
    link/ether fe:54:00:ce:0e:1c brd ff:ff:ff:ff:ff:ff
12: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN mode DEFAULT group default qlen 500
    link/ether fe:54:00:c8:d9:ff brd ff:ff:ff:ff:ff:ff
13: vnet3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT group default qlen 500
    link/ether fe:54:00:e3:f9:17 brd ff:ff:ff:ff:ff:ff
14: vnet4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN mode DEFAULT group default qlen 500
    link/ether fe:54:00:30:b3:d4 brd ff:ff:ff:ff:ff:ff
15: vnet5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr1 state UNKNOWN mode DEFAULT group default qlen 500
    link/ether fe:54:00:74:27:01 brd ff:ff:ff:ff:ff:ff
16: vnet6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr2 state UNKNOWN mode DEFAULT group default qlen 500
    link/ether fe:54:00:fd:e3:ef brd ff:ff:ff:ff:ff:ff
Da aber einige Interfaces den Status DOWN bzw. UNKNOWN haben muss ich erst prüfen ob die zu den nicht gestarteten VMs gehören. Aber zuerst muß das Problem mit dem 'e1000e' (siehe oben) gelöst werden.

Um hier posten zu können musste ich die ursprüngliche Verkabelung anpassen.
Jana66 hat geschrieben: ↑ zum Beitrag ↑
17.01.2018 12:46:06
Läuft eine VM mit IPFire? Probeweise mal gebridgte VM abschalten, Interfaces neu konfigureren?!
Ja, deshalb musste auch ein HW-Router ersatzweise her. Bis heute früh kam die IpFire-VM nicht mit hoch. Meinst du die Interfaces des IpFire oder des Hosts?

Gruß max

BenutzerGa4gooPh

Re: NIC-Hardwarefehler erkennen

Beitrag von BenutzerGa4gooPh » 18.01.2018 12:18:25

max123kl hat geschrieben: ↑ zum Beitrag ↑
18.01.2018 09:58:48
Jana66 hat geschrieben: ↑ zum Beitrag ↑
Mi 17. Jan 2018, 12:46
Läuft eine VM mit IPFire? Probeweise mal gebridgte VM abschalten, Interfaces neu konfigureren?!
Ja, deshalb musste auch ein HW-Router ersatzweise her. Bis heute früh kam die IpFire-VM nicht mit hoch. Meinst du die Interfaces des IpFire oder des Hosts?
Warum bridgest du die Interfaces auf dem Hostsystem???
Soweit mir bekannt ist (ausgehend von Vitualbox), wird eine virtuelle Firewall so "angeschlossen":
A) VM mit 2 Interfaces, jeweils auf 1 Host-Interface bridged, beide promiskuitiv -> FW wirksam für LAN
B) VM mit 2 Interfaces, 1 Interface bridged zum Host, 1 Interface "internal Networking", beide promiskuitiv -> FW nur wirksam für weitere VMs
https://www.thomas-krenn.com/de/wiki/Ne ... VirtualBox
Ob "promiskuitiv" (Rechercheergebnis) wirklich notwendig ist, wage ich zu bezweifeln: Mal ohne testen!
Die Bridge(s) werden also nicht im Hostsystem konfiguriert, sondern m. H. der Einstellungen der Virtualisierungslösung. In der VM erscheinen dann automatisch virtuelle Interfaces (zumindest bei und nach Installation eines Gastes). Das meinte ich mit meinem Beitrag, damit sollten sich deine Brückenprobleme des Hosts (Bridging zweier physischer NW-Adapter) gelöst haben: Bridging von IFs im Hostsystem m. E. unnötig, falsch.

Falls ein Provider MACs prüft, kann man diese m. H. der Virtualisierungseinstellungen (gebridgtes WAN-IF) ändern. Um das zu umgehen, wird vielleicht "promiskuitiv" vorgeschlagen?!

max123kl
Beiträge: 43
Registriert: 20.02.2006 22:33:39
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von max123kl » 18.01.2018 13:45:41

Jana66 hat geschrieben: ↑ zum Beitrag ↑
18.01.2018 12:18:25
Warum bridgest du die Interfaces auf dem Hostsystem???
Soweit mir bekannt ist (ausgehend von Vitualbox), wird eine virtuelle Firewall so "angeschlossen":
A) VM mit 2 Interfaces, jeweils auf 1 Host-Interface bridged, beide promiskuitiv -> FW wirksam für LAN
B) VM mit 2 Interfaces, 1 Interface bridged zum Host, 1 Interface "internal Networking", beide promiskuitiv -> FW nur wirksam für weitere VMs
https://www.thomas-krenn.com/de/wiki/Ne ... VirtualBox
VirtualBox setze ich auf meinem Desktop selbst ein, die unterschiedlichen Möglichkeiten dort virtuelle Netzwerkkarten einzusetzen waren mir schon bekannt.
In dem verlinkten Artikel wird nirgends "Firewall" erwähnt - mir fehlt deshalb der Bezug.
IpFire setze ich als Router-Firewall ein. Dort sind insgesamt 4 Interfaces definiert (je 1x für WAN, DMZ, WLAN und LAN)
Die Bridge(s) werden also nicht im Hostsystem konfiguriert, sondern m. H. der Einstellungen der Virtualisierungslösung. In der VM erscheinen dann automatisch virtuelle Interfaces (zumindest bei und nach Installation eines Gastes). Das meinte ich mit meinem Beitrag, damit sollten sich deine Brückenprobleme des Hosts (Bridging zweier physischer NW-Adapter) gelöst haben: Bridging von IFs im Hostsystem m. E. unnötig, falsch.
Derzeit stellt sich mir mein Problem mehr als Treiber- denn als Brückenproblem dar. Siehe:
max123kl hat geschrieben: ↑ zum Beitrag ↑
18.01.2018 09:58:48

Code: Alles auswählen

Jan 18 07:17:51 host0 kernel: [    0.646996] e1000e 0000:00:19.0: The NVM Checksum Is Not Valid
Jan 18 07:17:51 host0 kernel: [    0.682050] e1000e: probe of 0000:00:19.0 failed with error -5
Wobei die beiden letzten Zeilen vermutlich das Problem eingrenzen.
Wie kann ich das beheben?
Ich kann nicht sagen, dass ich mein Vorgehensweise technisch begründen kann, aber ich habe mich nach ausgiebigen Studien diverser Artikel zu diesem Modell entschieden. Falls dir dezdierte Gründe bekannt sind warum hier ein Fehler vorliegen könnte, immer her damit.

Wie ich im Ausgangspost schon geschrieben habe trat das Problem nach einem BIOS-Upgrade auf. Grund dafür war, dass das alte BIOS keine NVMe bot, die neue Version kann das. In dem Artikel https://superuser.com/questions/1104537 ... thernet-co ist ein ähnlicher Fall beschrieben. Demnach liegt ev. ein Bug im Treiber vor.
Nachinstallieren eines neueren Treibers (incl. kompilieren) scheint nicht zu helfen.

BenutzerGa4gooPh

Re: NIC-Hardwarefehler erkennen

Beitrag von BenutzerGa4gooPh » 18.01.2018 14:05:52

max123kl hat geschrieben: ↑ zum Beitrag ↑
18.01.2018 13:45:41
In dem verlinkten Artikel wird nirgends "Firewall" erwähnt - mir fehlt deshalb der Bezug.
Google mal nach "ipfire virtualbox" oder (mehr Treffer) "pfsense virtualbox". Prinzipiell (Virtualisierung einer FW) ist das ziemlich egal.
https://www.virtualbox.org/manual/ch06.html zeigt nirgendwo im Hostsystem manuell "anzufertigende" Bridges. Erledigt Virtualbox selber.
IpFire setze ich als Router-Firewall ein. Dort sind insgesamt 4 Interfaces definiert (je 1x für WAN, DMZ, WLAN und LAN)
Die Virtualisierung dessen könntest du mal schildern oder verlinken.

max123kl
Beiträge: 43
Registriert: 20.02.2006 22:33:39
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von max123kl » 19.01.2018 13:47:47

Jana66 hat geschrieben: ↑ zum Beitrag ↑
18.01.2018 14:05:52
max123kl hat geschrieben: ↑ zum Beitrag ↑
18.01.2018 13:45:41
In dem verlinkten Artikel wird nirgends "Firewall" erwähnt - mir fehlt deshalb der Bezug.
Google mal nach "ipfire virtualbox" oder (mehr Treffer) "pfsense virtualbox". Prinzipiell (Virtualisierung einer FW) ist das ziemlich egal.
https://www.virtualbox.org/manual/ch06.html zeigt nirgendwo im Hostsystem manuell "anzufertigende" Bridges. Erledigt Virtualbox selber.
Ist dir entgangen, dass ich auf dem Server nicht Virtualbox sondern KVM/Qemu einsetze, deshalb sind die verlinkten Anleitungen wenig hilfreich.
Ein Hauptgrund für die gewählte Netzwerkkonfiguration ist, dass es darüber unmöglich ist den Host aus dem WAN zu erreichen. Mit VirtualBox wäre das so nicht realisierbar, es benutzt nämlich immer die (konfigurierte) NIC des Hosts.
Entgegen deiner Ansicht wird eine Bridge durchaus auch im Wirtsystem eingerichtet z.B.: http://mywiki.bluelupo.net/mediawiki_1_ ... t_anpassen
IpFire setze ich als Router-Firewall ein. Dort sind insgesamt 4 Interfaces definiert (je 1x für WAN, DMZ, WLAN und LAN)
Die Virtualisierung dessen könntest du mal schildern oder verlinken.
Ich hatte im Vorfeld deshalb auch mit openvswitch experimentiert, was sich damals wegen fehlender Doku als nicht geeignet erwies.
Zum Plan:
  • a) Die erste physikalische NIC (nominal eth0, Treiber e1000e), vorgesehen für WAN wird über eine Bridge (br0) virtualisiert und ihr eine virtuelle NIC zugeordnet. Weder eth0 noch br0 erhalten eine IP-Adresse. Die virtNIC wird IpFire als WAN-Interface zugeordnet und erhält per DHCP vom Provider eine IP-Adresse.
  • b) Die zweite physikalische NIC (nominal eth1, Treiber igb), vorgesehen für LAN, DMZ und WLAN wird über eine Bridge (br1) virtualisiert und die virtNIC für LAN zugeordnet.
  • c) Die restlichen benötigten virtNICs werden über libvirt bzw. den virt-manager erzeugt und verwaltet.
Die ganze Diskussion ist aber hinfällig solange auch in einem Live-System wie Knoppix nur die zweite NIC (Treiber igb) startet und die erste NIC wg. eines Treiber-Fehlers (e1000e: probe of 0000:00:19.0 failed with error -5) nicht startet (s. auch meinen vorherigen Post).
Gruß max
[edit] Typo korrigiert, Link ergänzt

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: Re:Treiberproblem e1000e [was:NIC-Hardwarefehler erkennen]

Beitrag von reox » 19.01.2018 16:41:27

max123kl hat geschrieben: ↑ zum Beitrag ↑
18.01.2018 09:58:48

Code: Alles auswählen

Jan 18 07:17:51 host0 kernel: [    0.595558] igb 0000:02:00.0: eth0: (PCIe:2.5Gb/s:Width x1) d0:50:99:64:d3:35
Jan 18 07:17:51 host0 kernel: [    0.595611] igb 0000:02:00.0: eth0: PBA No: 001300-000
Jan 18 07:17:51 host0 kernel: [    0.595612] igb 0000:02:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
Jan 18 07:17:51 host0 kernel: [    0.646996] e1000e 0000:00:19.0: The NVM Checksum Is Not Valid
Jan 18 07:17:51 host0 kernel: [    0.682050] e1000e: probe of 0000:00:19.0 failed with error -5

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br1 state UP mode DEFAULT group default qlen 1000
    link/ether d0:50:99:64:d3:35 brd ff:ff:ff:ff:ff:ff

Da passt was nicht... die igb karte wird als eth0 erkannt, ist aber nachher eth1?

Die fehlermeldung von der e1000e könnte das hier sein: https://superuser.com/questions/1104537 ... thernet-co
Die erste Lösung klingt eher risky "irgendwas überschreiben", das hier klingt eher besser: https://superuser.com/a/1190558/90259

BenutzerGa4gooPh

Re: NIC-Hardwarefehler erkennen

Beitrag von BenutzerGa4gooPh » 20.01.2018 12:38:56

max123kl hat geschrieben: ↑ zum Beitrag ↑
19.01.2018 13:47:47
Ist dir entgangen, dass ich auf dem Server nicht Virtualbox sondern KVM/Qemu einsetze, deshalb sind die verlinkten Anleitungen wenig hilfreich.
Ein Hauptgrund für die gewählte Netzwerkkonfiguration ist, dass es darüber unmöglich ist den Host aus dem WAN zu erreichen. Mit VirtualBox wäre das so nicht realisierbar, es benutzt nämlich immer die (konfigurierte) NIC des Hosts.
Entgegen deiner Ansicht wird eine Bridge durchaus auch im Wirtsystem eingerichtet z.B.: http://mywiki.bluelupo.net/mediawiki_1_ ... t_anpassen
KVM/Qemu kenne ich nicht, deshalb meine "Parallelen" zu VBox. Die Nichtkonfiguration der WAN-NIC des Hostsystems (auch kein DHCP-Client *) und die (ausschließliche) Konfiguration der gebridgten WAN-NIC des Gastsystems (Firewall-Distributuion) ist wohl eine gute Idee für Sicherheit, wenn man iptables auf dem Host vermeiden will. Sollte doch mit VBox auch klappen, werde ich mal testen. Da ich KVM/Qemu nicht kenne und du einen Link auf Dritte gepostet hast, eine Frage: Ist die Bridge im Hostsystem (also "ausserhalb" Virtualisierungsloesung) ein Trick oder entspricht das der offiziellen Empfehlung/Doku von KVM/Quemu???
max123kl hat geschrieben: ↑ zum Beitrag ↑
19.01.2018 13:47:47
Die ganze Diskussion ist aber hinfällig solange auch in einem Live-System wie Knoppix nur die zweite NIC (Treiber igb) startet und die erste NIC wg. eines Treiber-Fehlers (e1000e: probe of 0000:00:19.0 failed with error -5) nicht startet (s. auch meinen vorherigen Post).
Gruß max
Da hast du wohl Recht. Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.

Edit: *)
Zuletzt geändert von BenutzerGa4gooPh am 20.01.2018 16:36:21, insgesamt 1-mal geändert.

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von reox » 20.01.2018 12:42:40

Wie in dem Superuser thread gezeigt, kann man diesen Checksum Check rauspatchen... Vllt ist der beim Kernel von den Live Distros nicht drin.
Ich würde mal dieses Tool von Intel probieren, auch wenn da steht das es nicht für OEM geht - dort hat es ja auch geklappt. So wie ich das verstehe besteht immer die Gefahr das irgendwas kaputt wird, also überleg es dir einfach. Ich möchte dir da nix empfehlen was deine Hardware potentiell mehr schädigt.
Da hast du wohl Recht. Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.
Nicht wenn du Gigabit WAN hast *scnr*

BenutzerGa4gooPh

Re: NIC-Hardwarefehler erkennen

Beitrag von BenutzerGa4gooPh » 20.01.2018 16:24:37

reox hat geschrieben: ↑ zum Beitrag ↑
20.01.2018 12:42:40
jana66 hat geschrieben: Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.
Nicht wenn du Gigabit WAN hast *scnr*
Funktionieren die nicht gut/angemessen? Also Adapter USB3.0->GBE.

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: NIC-Hardwarefehler erkennen

Beitrag von unitra » 22.01.2018 10:34:54

Jana66 hat geschrieben: ↑ zum Beitrag ↑
20.01.2018 16:24:37
reox hat geschrieben: ↑ zum Beitrag ↑
20.01.2018 12:42:40
jana66 hat geschrieben: Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.
Nicht wenn du Gigabit WAN hast *scnr*
Funktionieren die nicht gut/angemessen? Also Adapter USB3.0->GBE.
Als "Workaround" kann man diese Adapter zeitweise einsetzten, oder um Fehlerquellen auszuschliessen. Aber für professionellen Betrieb sind sie ungeeignet.
Von diesen "Adaptern" kann man nur abraten, die USB-to-Ethernet Adapter bieten nie Wirespeed/Linerate D.h. mit Gigabit unter Umständen z.B. maximal 60 MB/s Übertragungsrate (Linerate wäre 125MB/s bei Gigabit) . Die Treiber sind oft schlecht geschrieben, weil es z.B kein TCP offloading gibt, alles wird von der CPU berechnet, schlimstenfalls jedes IP Packet, jede TCP Session, jeder Ethernet Rahmen.

BenutzerGa4gooPh

Re: NIC-Hardwarefehler erkennen

Beitrag von BenutzerGa4gooPh » 22.01.2018 12:49:46

Nur zur Info: https://www.computerbase.de/forum/showt ... ?t=1474645
Notlösung, zu bevorzugen sind die natürlich nicht, besser aktive NICs: https://wiki.ipfire.org/hardware/passivenics

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von reox » 22.01.2018 13:07:30

Also es stimmt schon, mein APU Board hat auch noch die alten passiven Realtek Chips. Man merkt das bei 100% WAN auslastung (50MBit) die CPU schon so auf 10% geht. Liegt aber auch daran, dass da noch suricata rennt... Wo ich das Teil bekommen hab, hab ich ein paar Benchmarks gemacht und bei 100% Gigabit über 2 Ports waren das so ca 50% CPU auslastung auf einem Core.
Aber der Benchmark ist auch nicht ganz so gut geeignet, da er nicht auf maximale Paketanzahl pro Sekunde abziehlt sondern auf maximalen Durchsatz. maximale Anzahl der Pakete ist aber eigentlich wichtiger.

max123kl
Beiträge: 43
Registriert: 20.02.2006 22:33:39
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von max123kl » 22.01.2018 16:15:40

Hallo und vielen Dank für die bisherige Beteiligung am Thread.
reox hat geschrieben: ↑ zum Beitrag ↑
19.01.2018 16:41:27
Da passt was nicht... die igb karte wird als eth0 erkannt, ist aber nachher eth1?
Sehr aufmerksam! ;)
Aber das hat seine Richtigkeit. Defaultmäßig wird/wurde der i217LM-Chip als eth0 und der i210-Chip als eth1 erkannt. Per udev-Regel habe ich die Schnittstellen in der Server-Installation vertauscht.
Die fehlermeldung von der e1000e könnte das hier sein: https://superuser.com/questions/1104537 ... thernet-co
Die erste Lösung klingt eher risky "irgendwas überschreiben", das hier klingt eher besser: https://superuser.com/a/1190558/90259
Genau diese Links und ein paar parallele Threads hatte ich gelesen. Weshalb ich denke, dass mein Problem treiberbasiert ist.
Mir ist aber unbehaglich bei dem Geanken einen Treiber zu patchen.
a) habe ich so etwas noch hie gemacht und b) bin ich unsicher ob die Lösung Upgrade-fest ist. Im UP hatte ich ja schon geschrieben, dass das OS Debian8 ist, da steht irgendwann der Wechsel zu stretch an.
reox hat geschrieben: ↑ zum Beitrag ↑
20.01.2018 12:42:40
Wie in dem Superuser thread gezeigt, kann man diesen Checksum Check rauspatchen... Vllt ist der beim Kernel von den Live Distros nicht drin.
Ich würde mal dieses Tool von Intel probieren, auch wenn da steht das es nicht für OEM geht - dort hat es ja auch geklappt. So wie ich das verstehe besteht immer die Gefahr das irgendwas kaputt wird, also überleg es dir einfach. Ich möchte dir da nix empfehlen was deine Hardware potentiell mehr schädigt.
Das ist ein weiterer Grund weshalb ich noch am Überlegen bin.
Jana66 hat geschrieben: ↑ zum Beitrag ↑
20.01.2018 12:38:56
Da ich KVM/Qemu nicht kenne und du einen Link auf Dritte gepostet hast, eine Frage: Ist die Bridge im Hostsystem (also "ausserhalb" Virtualisierungsloesung) ein Trick oder entspricht das der offiziellen Empfehlung/Doku von KVM/Quemu???
Siehe hier: https://www.linux-kvm.org/page/Networking#Public_Bridge
oder hier: https://wiki.qemu.org/Documentation/Networking
oder hier: https://wiki.ubuntu.com/KvmWithBridge
im Wesentlichen habe ich mich hieran orientiert: https://www.linuxmuster.net/wiki/anwend ... -netzwerk
Da hast du wohl Recht. Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.
Zu deinem Vorschlag sind ja schon ein paar Kommentare gekommen, die dir zeigen sollten, dass er nur als Notlösung in Betracht käme.
Der betreffende Rechner ist ein (Eigenbau-) Server, deshalb habe ich bei der Auswahl des MB's darauf geachtet habe, dass Server-Chips für die NICs verbaut sind. Ursprünglich hätte ich auch einen zusätzlichen Dual-Port NIC-Kontroller einsetzen können, auf den ich jetzt notgedrungen zurückgreifen muss.
Da ich aber weder Broadcom- noch Realtek-Chips im Server einsetzen will, bleibt eigentlich nur Intel übrig und damit auch das Treiberproblem bestehen.
Gut lt. Intel unterstützt 'bootutil' die Karten im Gegensatz zu den OnBoard-Kontrollern, aber ein Restrisiko bleibt.

Gruß max
Edit: weiterer Link hinzugefügt

max123kl
Beiträge: 43
Registriert: 20.02.2006 22:33:39
Lizenz eigener Beiträge: MIT Lizenz

Re: NIC-Hardwarefehler erkennen

Beitrag von max123kl » 23.01.2018 06:53:28

max123kl hat geschrieben: ↑ zum Beitrag ↑
22.01.2018 16:15:40
Hallo und vielen Dank für die bisherige Beteiligung am Thread.
reox hat geschrieben: ↑ zum Beitrag ↑
19.01.2018 16:41:27
Da passt was nicht... die igb karte wird als eth0 erkannt, ist aber nachher eth1?
Sehr aufmerksam! ;)
Aber das hat seine Richtigkeit. Defaultmäßig wird/wurde der i217LM-Chip als eth0 und der i210-Chip als eth1 erkannt. Per udev-Regel habe ich die Schnittstellen in der Server-Installation vertauscht.
Die fehlermeldung von der e1000e könnte das hier sein: https://superuser.com/questions/1104537 ... thernet-co
Die erste Lösung klingt eher risky "irgendwas überschreiben", das hier klingt eher besser: https://superuser.com/a/1190558/90259
Genau diese Links und ein paar parallele Threads hatte ich gelesen. Weshalb ich denke, dass mein Problem treiberbasiert ist.
Mir ist aber unbehaglich bei dem Geanken einen Treiber zu patchen.
a) habe ich so etwas noch hie gemacht und b) bin ich unsicher ob die Lösung Upgrade-fest ist. Im UP hatte ich ja schon geschrieben, dass das OS Debian8 ist, da steht irgendwann der Wechsel zu stretch an.
reox hat geschrieben: ↑ zum Beitrag ↑
20.01.2018 12:42:40
Wie in dem Superuser thread gezeigt, kann man diesen Checksum Check rauspatchen... Vllt ist der beim Kernel von den Live Distros nicht drin.
Ich würde mal dieses Tool von Intel probieren, auch wenn da steht das es nicht für OEM geht - dort hat es ja auch geklappt. So wie ich das verstehe besteht immer die Gefahr das irgendwas kaputt wird, also überleg es dir einfach. Ich möchte dir da nix empfehlen was deine Hardware potentiell mehr schädigt.
Das ist ein weiterer Grund weshalb ich noch am Überlegen bin.
Jana66 hat geschrieben: ↑ zum Beitrag ↑
20.01.2018 12:38:56
Da ich KVM/Qemu nicht kenne und du einen Link auf Dritte gepostet hast, eine Frage: Ist die Bridge im Hostsystem (also "ausserhalb" Virtualisierungsloesung) ein Trick oder entspricht das der offiziellen Empfehlung/Doku von KVM/Quemu???
Siehe hier: https://www.linux-kvm.org/page/Networking#Public_Bridge
oder hier: https://wiki.qemu.org/Documentation/Networking
oder hier: https://wiki.ubuntu.com/KvmWithBridge
im Wesentlichen habe ich mich hieran orientiert: https://www.linuxmuster.net/wiki/anwend ... -netzwerk
Da hast du wohl Recht. Wenn nichts hilft, ich hatte oben einen USB-GBE-Adapter verlinkt. Für WAN sicher einsetzbar, für LAN mit VLANs unsicher.
Zu deinem Vorschlag sind ja schon ein paar Kommentare gekommen, die dir zeigen sollten, dass er nur als Notlösung in Betracht käme.
Der betreffende Rechner ist ein (Eigenbau-) Server, deshalb habe ich bei der Auswahl des MB's darauf geachtet habe, dass Server-Chips für die NICs verbaut sind. Ursprünglich hätte ich auch einen zusätzlichen Dual-Port NIC-Kontroller einsetzen können, auf den ich jetzt notgedrungen zurückgreifen muss.
Da ich aber weder Broadcom- noch Realtek-Chips im Server einsetzen will, bleibt eigentlich nur Intel übrig und damit auch das Treiberproblem bestehen.
Gut, lt. Intel unterstützt 'bootutil' die Karten im Gegensatz zu den OnBoard-Kontrollern, aber ein Restrisiko bleibt.

Gruß max
Edit: weiterer Link hinzugefügt

Antworten