14
PfSense RX Error auf WAN
Hallo,
seit ein bis zwei Wochen einem Problem auf der Spur, das noch länger zu bestehen scheint, aber ich mit meiner Fehlersuche nicht mehr weiter komme:
Die letzten Tage wurde es besonders schlimm, auf der WAN-Schnittstelle passierten immer wieder RX Errors. Es gehen also eingehend immer wieder Pakete verloren.
Ich hatte natürlich als erstes die Schnittstellen der pfSense-Kiste im Verdacht. Es handelt sich um ein Board von Supermicro (X11SDV-4C-TP8F), die 1Gbit- Schnittstellen werden von einem Intel I350-AM4 Controller gesteuert und intern als igb erkannt. Firmware ist aktuell. pfSense Version ist 2.4.5-p1. Aber selbst ein Wechsel der NIC brachte nichts und außerdem wären dann dort nicht auch ausgehend Paket-Verlust aufgetreten?
Ich habe das bestehende Problem erst relativ spät mitbekommen, weil ansich alles ohne Probleme lief und auch die Anwender nichts meldeten, nur in den letzten Tagen häuften sich dann wohl die Paket-Verluste. Das es aber schon mehrere Wochen bestehen muss, zeigt dieses Bild:
Das ist die Aufzeichnung der Paketverluste per SNMP. Das Problem scheint nicht immer in der gleichen Intensität vorzuliegen und stark zu variieren. In der Woche 53 von 2020 wurde dieses Logging erst gestartet. Deshalb ist davor nichts vermerkt.
Der Provider (lokaler Anbieter) sieht selbst keine Fehler auf seiner Leitung und meint die Werte wären "hervorragend". Die Box oder das Modem, in Wirklichkeit nur ein LWL-Medienconverter (Genexis Hybrid FTTH Gateway), habe ich schon neugestartet und die Patchkabel getauscht. Es sind dadurch vorerst gefühlt weniger Fehler, ob es tatsächlich so ist wird das Logging mit der Zeit zeigen.
Aber gäbe es noch eine andere Möglichkeit solch einem Problem auf die Schliche zu kommen? Um wirklich zweifelsfrei zu lokalisieren wo das Problem liegt?
Wäre sehr dankbar für paar Tipps.
Gruß
seit ein bis zwei Wochen einem Problem auf der Spur, das noch länger zu bestehen scheint, aber ich mit meiner Fehlersuche nicht mehr weiter komme:
Die letzten Tage wurde es besonders schlimm, auf der WAN-Schnittstelle passierten immer wieder RX Errors. Es gehen also eingehend immer wieder Pakete verloren.
Ich hatte natürlich als erstes die Schnittstellen der pfSense-Kiste im Verdacht. Es handelt sich um ein Board von Supermicro (X11SDV-4C-TP8F), die 1Gbit- Schnittstellen werden von einem Intel I350-AM4 Controller gesteuert und intern als igb erkannt. Firmware ist aktuell. pfSense Version ist 2.4.5-p1. Aber selbst ein Wechsel der NIC brachte nichts und außerdem wären dann dort nicht auch ausgehend Paket-Verlust aufgetreten?
Ich habe das bestehende Problem erst relativ spät mitbekommen, weil ansich alles ohne Probleme lief und auch die Anwender nichts meldeten, nur in den letzten Tagen häuften sich dann wohl die Paket-Verluste. Das es aber schon mehrere Wochen bestehen muss, zeigt dieses Bild:
Das ist die Aufzeichnung der Paketverluste per SNMP. Das Problem scheint nicht immer in der gleichen Intensität vorzuliegen und stark zu variieren. In der Woche 53 von 2020 wurde dieses Logging erst gestartet. Deshalb ist davor nichts vermerkt.
Der Provider (lokaler Anbieter) sieht selbst keine Fehler auf seiner Leitung und meint die Werte wären "hervorragend". Die Box oder das Modem, in Wirklichkeit nur ein LWL-Medienconverter (Genexis Hybrid FTTH Gateway), habe ich schon neugestartet und die Patchkabel getauscht. Es sind dadurch vorerst gefühlt weniger Fehler, ob es tatsächlich so ist wird das Logging mit der Zeit zeigen.
Aber gäbe es noch eine andere Möglichkeit solch einem Problem auf die Schliche zu kommen? Um wirklich zweifelsfrei zu lokalisieren wo das Problem liegt?
Wäre sehr dankbar für paar Tipps.
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 658827
Url: https://administrator.de/contentid/658827
Ausgedruckt am: 24.11.2024 um 22:11 Uhr
14 Kommentare
Neuester Kommentar
Das Problem scheint nicht immer in der gleichen Intensität vorzuliegen und stark zu variieren.
Riecht etwas nach einem Autonegotiation Problem, denn diese zeigen oft so ein Verhalten besonders wenn der Duplex Mode nicht richtig ausgehandelt wurde. Mit steigendem Traffic steigen dann auch die Fehler.Bei einem Duplex Mismatch sind das in erster Linie aber immer Collisions die hier primär ja nicht zu sehen sind.
Trotzdem macht es ggf. Sinn mal einen doofen L2 Switch zw. der FW und dem Übergabepunkt zu hängen um zu sehen ob das ggf. verschwindet. Wenn ja, wäre es dann ein Indiz für ein Autonegotiation Problem.
Sinnvoll wäre es auch einmal die Genexis Hybrid FTTH Gateway Box zu tauschen. Der Fehler muss ja nicht zwingend auf deiner Seite sein...
Alternativ bei Glasfaser wäre es spannend den Provider mal zu fragen ob das durchgängig ist. Es gibt Szenarien wo Provider auf Zwischenlinks gebündelte xDSL Leitungen nutzen wenn sie eine Versorgungslücke schliessen müssen. Dann gibt es aber einen Bruch in der MTU wegen der xDSL Encapsulation und zu grosse Frames machen dann Probleme. Allerdings so das die dann gedropt werden und eher keine Error Counter hochzählen. Das wäre dann eher nicht das Problem aber könnte man mit einer Verkleinerung der MTU am WAN Port fixen.
Interessant wäre es auch einmal die Interface Statistiken aus der Genexis Hybrid FTTH Gateway sehen zu können ob die Errors denen deiner Seite entsprechen, was sie eigentlich sollten.
Wichtig wäre auch zu wissen was genau den Error Counter triggert ob das nicht nur Ethernet Runts oder Giant Frames sind und nicht auch welche mit VLAN ID Tag z.B. die das Interface nicht lesen kann was dann wieder Fragen der Provider Konfig am Übergabepunkt aufwirft.
Habe jetzt nochmal weiter gegraben:
Die Statistiken zeigen das es wirklich nur unter Last passiert. In der Nacht, wo wenig los ist, kein einziger dokumentierter Fehler. An den meisten Tagen gehen die Fehler ab etwa 16-17 Uhr zurück. Gearbeitet wird aber bis etwa 22 Uhr.
Beispiel:
Unter "Last" ist auch relativ zu sehen. Der Traffic hält sich auf der WAN-Seite in Grenzen. Die bestellte Geschwindigkeit der LWL-Anbindung ist 100/100Mbit. Bei normalen Betrieb wird die Bandbreite über den Tag vielleicht zu 30-40% ausgenutzt.
Da komme ich leider nicht drauf und muss mich da auf die Aussagen des Providers verlassen. Dieser sagt, das keine Fehler drauf sind.
Dazu habe ich folgendes auf der pfsense per sysctl gefunden:
Es scheint sich also doch direkt um CRC-Fehler zu handeln.
Den Trick mit dem kleinen Switch (Cisco SG110) dazwischen hatte ich ebenfalls schon vor paar Wochen probiert, der war scheinbar gänzlich mit der Situation überfordert. Die Fehler nahmen zu und die LEDs an den Ports haben sich gar nicht mehr einbekommen, trotz relativ wenig Traffic. Für mich meist ein Zeichen, das hier irgendwas nicht stimmt.
Die Statistiken zeigen das es wirklich nur unter Last passiert. In der Nacht, wo wenig los ist, kein einziger dokumentierter Fehler. An den meisten Tagen gehen die Fehler ab etwa 16-17 Uhr zurück. Gearbeitet wird aber bis etwa 22 Uhr.
Beispiel:
Unter "Last" ist auch relativ zu sehen. Der Traffic hält sich auf der WAN-Seite in Grenzen. Die bestellte Geschwindigkeit der LWL-Anbindung ist 100/100Mbit. Bei normalen Betrieb wird die Bandbreite über den Tag vielleicht zu 30-40% ausgenutzt.
Interessant wäre es auch einmal die Interface Statistiken aus der Genexis Hybrid FTTH Gateway sehen zu können ob die Errors denen deiner Seite entsprechen, was sie eigentlich sollten.
Da komme ich leider nicht drauf und muss mich da auf die Aussagen des Providers verlassen. Dieser sagt, das keine Fehler drauf sind.
Wichtig wäre auch zu wissen was genau den Error Counter triggert ob das nicht nur Ethernet Runts oder Giant Frames sind und nicht auch welche mit VLAN ID Tag z.B. die das Interface nicht lesen kann was dann wieder Fragen der Provider Konfig am Übergabepunkt aufwirft.
Dazu habe ich folgendes auf der pfsense per sysctl gefunden:
dev.igb.1.mac_stats.coll_ext_errs: 0
dev.igb.1.mac_stats.alignment_errs: 0
dev.igb.1.mac_stats.crc_errs: 460
dev.igb.1.mac_stats.recv_errs: 222Es scheint sich also doch direkt um CRC-Fehler zu handeln.
Den Trick mit dem kleinen Switch (Cisco SG110) dazwischen hatte ich ebenfalls schon vor paar Wochen probiert, der war scheinbar gänzlich mit der Situation überfordert. Die Fehler nahmen zu und die LEDs an den Ports haben sich gar nicht mehr einbekommen, trotz relativ wenig Traffic. Für mich meist ein Zeichen, das hier irgendwas nicht stimmt.
Dieser sagt, das keine Fehler drauf sind.
Darauf solltest du dich natürlich nie verlassen. Bitte ihn darum einen Screenshot der Port Statistiken zu schicken und zwar mit einer Laufzeit Info. Nicht das er vorher die Statistiken löscht. Kannst du aber ja auch an der Menge sehen die mit deinen Paket und Trafficzahlen korrelieren sollte.Übliches Verhalten von Providern das sie erstmal alles abwimmeln auf die Kunden. Im Rahmen eures Vertrages haben die aber die Pflicht zur Auskunft.
CRC Fehler sind Checksummen Fehler könnte was mit der Negotiation zu tun haben. Verdächtig ist die Lastabhängigkeit was dafür sprechen würde.
Der Test mit dem Zwischenswitch ist also deshalb sehr wichtig. Das der scheinbar auch nicht richtig Auto negotiaten konnte erhärtet zudem den Verdacht.
Vielleicht hast du irgendwo noch einen ungemanagten 100Mbit China 5 Port Plasteswitch in der Schublade. Die eigenen sich ganz gut dafür. Ein managebarer wäre aber erheblich besser weil du an dem wieder sowohl den Provider Port als auch deinen FW Port in den Port Statistiken genau beobachten kannst.
Dein Verdacht ist schon richtig wenn schon bei sehr geringen Trafficraten sowas passiert. 50% Last auf dem Port sollten niemals die Fehlercounter hochzählen lassen. Eine geringe Menge ist Prinzip bedingt zwar normal im Ethernet aber niemals in der Größenordnung wie bei dir.
https://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/t ...
Also der Techniker den ich am Telefon hatte, wollte nur eine mündliche Aussage machen. Er meinte: Gestern ab 14 Uhr das Protokoll gestartet und über Nacht etwas über 60000 Pakete protokolliert, von denen etwa 200 nicht durchgingen. Was sich in etwa mit meinen Werten deckt. Er sagte das sei völlig in Ordnung und unter 1%.
Da war ich gegenteiliger Meinung: Wenn das ein Wert von einer Woche gewesen wäre, dann hätte ich gesagt OK. Aber nicht bei weniger als 20 Stunden. Auf eine Woche hoch gerechnet sind das immerhin 1680 Pakete, eher weit über 2000 wenn ich die hohe Varianz mit einbeziehe. die hier scheinbar spurlos verschwinden. Da reichen schon paar wenige verlorene Fehler, das eine VPN-Verbindung abreißt und sich der User zu Recht beschwert.
Aber, ich glaube einen schuldigen gefunden zu haben: EEE oder auch "Green Ethernet".
Was auch sonst. Durch Zufall drauf gestoßen. Man kann es direkt auf der CLI pro NIC deaktivieren:
Das von allen beteiligten Netzwerkschnittstellen unterstützt werden muss. Da ich bei der Genexis Brotdose nicht damit rechne, sollte ich das vielleicht deaktivieren.
Will man es Reboot-fest haben, dann unter "System > Advanced > System Tunables" einen neuen Eintrag erzeugen. Seit etwa drei Stunden kein Fehler. Gestern im selben Zeitraum hatte ich schon mindestens 80 verlorene Pakete. Ich freue mich mal noch nicht zu früh, aber vorerst sieht es gut aus, gefühlt auch Performance besser geworden.
Aber die Zeit wird es zeigen.
Da war ich gegenteiliger Meinung: Wenn das ein Wert von einer Woche gewesen wäre, dann hätte ich gesagt OK. Aber nicht bei weniger als 20 Stunden. Auf eine Woche hoch gerechnet sind das immerhin 1680 Pakete, eher weit über 2000 wenn ich die hohe Varianz mit einbeziehe. die hier scheinbar spurlos verschwinden. Da reichen schon paar wenige verlorene Fehler, das eine VPN-Verbindung abreißt und sich der User zu Recht beschwert.
Aber, ich glaube einen schuldigen gefunden zu haben: EEE oder auch "Green Ethernet".
Was auch sonst. Durch Zufall drauf gestoßen. Man kann es direkt auf der CLI pro NIC deaktivieren:
sysctl dev.igb.0.eee_disabled:1Das von allen beteiligten Netzwerkschnittstellen unterstützt werden muss. Da ich bei der Genexis Brotdose nicht damit rechne, sollte ich das vielleicht deaktivieren.
Will man es Reboot-fest haben, dann unter "System > Advanced > System Tunables" einen neuen Eintrag erzeugen. Seit etwa drei Stunden kein Fehler. Gestern im selben Zeitraum hatte ich schon mindestens 80 verlorene Pakete. Ich freue mich mal noch nicht zu früh, aber vorerst sieht es gut aus, gefühlt auch Performance besser geworden.
Aber die Zeit wird es zeigen.
👍 Hört sich gut an !
Das wäre mal spannend wie der Counter nach einer Woche aussieht ! Feedback wäre mal interessant.
Was sehr verwunderlich ist ist die Tatsache das diese Feature auf einer Firewall aktiviert ist ?! Eigentlich völliger Unsinn bei einem Device was always on sein muss. EEE für Router oder Firewall ist generell eigentlich netztechnischer Unsinn.
Das wäre mal spannend wie der Counter nach einer Woche aussieht ! Feedback wäre mal interessant.
Was sehr verwunderlich ist ist die Tatsache das diese Feature auf einer Firewall aktiviert ist ?! Eigentlich völliger Unsinn bei einem Device was always on sein muss. EEE für Router oder Firewall ist generell eigentlich netztechnischer Unsinn.
Das musste mal Netgate/pfSense-Leute fragen: Die haben es in über zwei Jahren nicht hinbekommen aktuelle Treiber z.B. für ixl (X710/Intel Xeon D-2100) zu implementieren. Die meisten 10Gbit-Schnittstellen die man zum Beispiel im LAGG laufen lassen wöllte, würden nicht funktioneren. Im normalen Betrieb kann es zu einer Kernel Panic kommen. Die darf man sich dann selbst kompilieren.
Ich weiß nicht ob die es mal hinbekommen haben, das in in 2.5 zu fixen. Bin da noch skeptisch. Privat habe ich jedenfalls schon mal festgestellt, das in 2.5 die Registrierung von DHCP im DNS Resolver nicht funktioniert. Bin mal gespannt wie das in Zuknuft mit dem neuen Pfsense Plus und Community laufen wird. Wird wohl so werden, das ich zu OPNsense wechsel. Schade drum.
Warum soetwas standardmäßig aktiviert ist und man sich erst durch diverse pfSense-Foren/Intel-Dokus schlängeln darf, ist mir darüber hinaus auch völlig schleierhaft.
Ich weiß nicht ob die es mal hinbekommen haben, das in in 2.5 zu fixen. Bin da noch skeptisch. Privat habe ich jedenfalls schon mal festgestellt, das in 2.5 die Registrierung von DHCP im DNS Resolver nicht funktioniert. Bin mal gespannt wie das in Zuknuft mit dem neuen Pfsense Plus und Community laufen wird. Wird wohl so werden, das ich zu OPNsense wechsel. Schade drum.
Warum soetwas standardmäßig aktiviert ist und man sich erst durch diverse pfSense-Foren/Intel-Dokus schlängeln darf, ist mir darüber hinaus auch völlig schleierhaft.
Für mich hat es sich bestätigt. Es ist definitiv so das hier EEE oder 802.3az Probleme gemacht hat. Entweder ist es am FTTH Gateway deaktiviert, fehlerhaft oder nicht implementiert. Seit fast 4 Tagen kein einziger Fehler. Im gleichen Zeitraum eine Woche vorher, sah es schon sehr düster aus.
Nun erklärt sich auch warum mein SG110 solche Probleme gemacht hat: Bei dem ist dauerhaft standardmäßig EEE aktiv. Der ist unmanaged, da kann man auch nichts konfigurieren.
pfSense kann man eigentlich nur vorwerfen, das diese veraltete Treiber verwenden und für Optimierung von NIC nur wenig dokumentiert haben. Ein Button oder ein Profil mit der Einstellung oder irgendeinen Hinweis das man das deaktivieren kann oder es zu Problemen führen könnte, hätte ich mir schon gewünscht. Ob man es dann aktiviert ist dann die Sache des Anwenders. Ansich ist das EEE ja im Inter-Treiber implementiert.
Lustigerweise ist mir bei anderen Standorten solche Probleme nie untergekommen, da verwende ich unter anderem Debian mit iptables als Firewall und da sind teilweise die selben Treiber im Einsatz. Da sind dann meist auch etwas bessere Modems oder Router vorgeschalten, aber wenn es dort ebenfalls EEE inaktiv ist, müsste es ja zu ähnlichen Problemen kommen. Bisher aber nichts.
Nun erklärt sich auch warum mein SG110 solche Probleme gemacht hat: Bei dem ist dauerhaft standardmäßig EEE aktiv. Der ist unmanaged, da kann man auch nichts konfigurieren.
pfSense kann man eigentlich nur vorwerfen, das diese veraltete Treiber verwenden und für Optimierung von NIC nur wenig dokumentiert haben. Ein Button oder ein Profil mit der Einstellung oder irgendeinen Hinweis das man das deaktivieren kann oder es zu Problemen führen könnte, hätte ich mir schon gewünscht. Ob man es dann aktiviert ist dann die Sache des Anwenders. Ansich ist das EEE ja im Inter-Treiber implementiert.
Lustigerweise ist mir bei anderen Standorten solche Probleme nie untergekommen, da verwende ich unter anderem Debian mit iptables als Firewall und da sind teilweise die selben Treiber im Einsatz. Da sind dann meist auch etwas bessere Modems oder Router vorgeschalten, aber wenn es dort ebenfalls EEE inaktiv ist, müsste es ja zu ähnlichen Problemen kommen. Bisher aber nichts.
Sehr interessantes Feedback !
Ich habe gerade mal mehrere APUs gecheckt mit der 2.5er. Dort scheint das kein Problem zu sein
Die stecken meist direkt an einem LWL Switch eines Providers der der Übergabepunkt ist. Diverse Hersteller Alcatel, Cisco usw. Keiner der APUs zeigt irgendwelche Errors auf dem WAN. Wie gesagt...nur APU Hardware.
Eine Frage noch zum Kommando sysctl dev.igb.0.eee_disabled:1. In den Advanced Settings unter "System Tunables" taucht der Parameter nicht auf. Er kann dann vermutlich nur über den Shell Zugang konfiguriert werden, richtig ?
Bei APUs z.B. deren Interfaces "re0" usw. heissen müsste das dann entsprechend vermutlich sysctl dev.re.0.eee_disabled:1 lauten wenn man das deaktivieren möchte. Bzw. man sollte vorher in die Interface Statistiken sehen um die Systembezeichnung seiner Interfaces zu verifizieren.
Ich habe gerade mal mehrere APUs gecheckt mit der 2.5er. Dort scheint das kein Problem zu sein
Eine Frage noch zum Kommando sysctl dev.igb.0.eee_disabled:1. In den Advanced Settings unter "System Tunables" taucht der Parameter nicht auf. Er kann dann vermutlich nur über den Shell Zugang konfiguriert werden, richtig ?
Bei APUs z.B. deren Interfaces "re0" usw. heissen müsste das dann entsprechend vermutlich sysctl dev.re.0.eee_disabled:1 lauten wenn man das deaktivieren möchte. Bzw. man sollte vorher in die Interface Statistiken sehen um die Systembezeichnung seiner Interfaces zu verifizieren.
Also, erstmal: Die Option muss im Treiber sein, bei re0 Schnittstellen weiß ich nicht wie das ist.
Prüfen kann man es auf der CLI mit:
Wenn da nichts auftaucht, kannst du den Wert auch nicht setzen. Kann auch sein das er anders heißt bei anderen Treibern von anderen Herstellern. Bei mir ist das ja explizit Intel igb, also alle NIC vom Typ 82575/6, 82580, i350, I354 und Interstate 210/I211.
Auf der CLI kann man den Wert akut setzen mit:
Einfach so reindonnern. Dann quittiert dir das Interface sogar was der vorherige Wert war. Das ist aber nicht rebootfest. Normalerweise würde man in der /boot/loader.conf entsprechend etwas hinterlegen. Aber dort hat die Option nach reboot keinen Effekt. Keine Ahnung warum.
Stattdessen muss man unter "System > Advanced > System Tunables" wie folgt einen neuen Eintrag erzeugen:
Wenn du den Eintrag nicht erzeugst, kannst du da auch keinen finden. ;)
Grüße
Prüfen kann man es auf der CLI mit:
sysctl dev.re.0 | grep eeeWenn da nichts auftaucht, kannst du den Wert auch nicht setzen. Kann auch sein das er anders heißt bei anderen Treibern von anderen Herstellern. Bei mir ist das ja explizit Intel igb, also alle NIC vom Typ 82575/6, 82580, i350, I354 und Interstate 210/I211.
Auf der CLI kann man den Wert akut setzen mit:
sysctl dev.igb.0.eee_disabled:1Einfach so reindonnern. Dann quittiert dir das Interface sogar was der vorherige Wert war. Das ist aber nicht rebootfest. Normalerweise würde man in der /boot/loader.conf entsprechend etwas hinterlegen. Aber dort hat die Option nach reboot keinen Effekt. Keine Ahnung warum.
Stattdessen muss man unter "System > Advanced > System Tunables" wie folgt einen neuen Eintrag erzeugen:
Wenn du den Eintrag nicht erzeugst, kannst du da auch keinen finden. ;)
Grüße
Nope, der Realtek Treiber kann das (vermutlich) nicht. Bestätigt dann auch indirekt warum die Error Counter dort vermutlich alle auf 0 sind ! 
[2.5.0-RELEASE][admin@firewall.de]/root: sysctl dev.re.0
dev.re.0.int_rx_mod: 65
dev.re.0.stats: -1
dev.re.0.%parent: pci1
dev.re.0.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123 class=0x020000
dev.re.0.%location: slot=0 function=0 dbsf=pci0:1:0:0
dev.re.0.%driver: re
dev.re.0.%desc: RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet
[2.5.0-RELEASE][admin@firewall.de]/root:
Dann besteht zumindestens bei den APUs wohl kein Handlungsbedarf in Sachen EEE.
[2.5.0-RELEASE][admin@firewall.de]/root: sysctl dev.re.0
dev.re.0.int_rx_mod: 65
dev.re.0.stats: -1
dev.re.0.%parent: pci1
dev.re.0.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123 class=0x020000
dev.re.0.%location: slot=0 function=0 dbsf=pci0:1:0:0
dev.re.0.%driver: re
dev.re.0.%desc: RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet
[2.5.0-RELEASE][admin@firewall.de]/root:
Dann besteht zumindestens bei den APUs wohl kein Handlungsbedarf in Sachen EEE.
Offensichtlich nicht. Mich würde aber dennoch stark interessieren ob es dann bei Realtek überhaupt EEE gibt oder ob die darauf komplett von vorne herein verzichtet haben. Scheint wieder so ein Intel-Ding zu sein.
Habe hier auch eine APU4 in einer kleiner Inhouse-Lösung, an einem Zyxel Modem dran, dort ebenfalls keine Probleme.
Habe hier auch eine APU4 in einer kleiner Inhouse-Lösung, an einem Zyxel Modem dran, dort ebenfalls keine Probleme.
Laut Realtek Datenblatt kann er (der RTL8168 Chip) das:
https://www.realtek.com/en/products/communications-network-ics/item/rtl8 ...
https://www.realtek.com/en/products/communications-network-ics/item/rtl8 ...
Dann scheint es besser implementiert zu sein, auch schon in älteren Treibern, als bei Intel. Nicht zum ersten Mal das man von Intel enttäuscht wird.
Obwohl Intel LAN Chipsätze oder die von Broadcom ja durch die Bank einen sehr guten Ruf haben. Ebenso die Linux oder FreeBSD Treiber Unterstützung an der Intel ja aktiv mitarbeitet.
