(Insbesondere) Linux ist immer wieder für eine Überraschung gut. Jaja, ich hätte es mir denken können, daß dieses nicht ganz standardkonforme Verhalten bei solcher Hardware Probleme macht; aber, hey, warum eigentlich? Wegen 4 Bytes?
Worum geht es? Wie schon geschrieben habe ich, mehr so notgedrungen, einen meiner Dockstars zum T-VDSL-Anbindungsrouter umfunktioniert — und das zweite Ethernet via USB-Ethernet-Adapter realisiert. Soweit, so erfolgreich.
Allerdings liegt die Geschwindigkeit über den OpenVPN-Tunnel ungleich höher als über die T-VDSL-IP direkt; http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.35.7.tar.bz2 per OpenVPN-Tunnel:
100%[======================================>] 69.255.636 946K/s in 68s
Im Vergleich dazu, direkt über die T-VDSL-IP:
100%[======================================>] 69,255,636 366K/s in 3m 30s
Schon ein Unterschied, und der liegt, wie auch im Netz nachzulesen, an:
Oct 19 12:00:10 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:10 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:10 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:12 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:14 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:14 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:21 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:22 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:22 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:25 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:25 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:26 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:26 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518 Oct 19 12:00:28 nslug-1 kernel: eth1: asix_rx_fixup() Bad RX Length 1518
Hintergrund: die Deutsche Telekom nutzt bei T-Entertain-Anschlüssen (mittlerweile IIRC auch bei ADSL2+ (»16plus«), nicht nur an VDSL-Anschlüssen wie meinem) ein Setup mit zwei VLANs, die aus dem xDSL-Modem kommen: VLAN7 für den Internet-Verkehr, VLAN8 für das Entertain-Produkt inkl. Multicasting für Live-TV.
Mit anderen Worten, aus dem Ethernet-Interface meines VDSL-Modems Speedport 300 HS »fallen« getaggte Ethernetframes raus, die statt 1518 max. 1522 Bytes groß sind. Das ist für meinen Switch kein Problem, das ist für Linux kein grundsätzliches Problem — aber leider unterstützt entweder die Hardware sowohl des »asix«-getriebenen GBit/sec-Adapters von Belkin noch die MosChip-MCS7830-basierten Logilink-Adapter oder deren (Linux-?) Treiber keine Ethernetframes mit >1518 Bytes. Die Folge sind Paketverluste, der asix-Treiber loggt diese zumindest, und damit einhergehend massiver Durchsatzeinbruch.
Evtl. läßt sich das Problem mittels einer kleineren MTU umschiffen, alternativ böte es sich an, den Switch das Tagging erledigen zu lassen und die VLANs 7 und 8 auf getrennten Ports ungetagged dem Dockstar über dann zwei USB-Ethernet-Adapter zuzuführen. Oder alles auf einen Port, ggf. das Heimnetz in ein VLAN verfrachten?
Hrmpft. All das wäre unnötig, wäre der GuruPlug der versprochene Rechner statt eines Brandbeschleunigers :(