[SOLVED] Jessie: Sporadische Netzwerkunterbrechungen

[silverSliDE]

Hallo zusammen,

Ich hab nun seit monaten ein kleines Problem, dass zwar nicht dramatisch ist, aber mich nun nach monaten langsam aber sicher in den Wahnsinn treibt.

seit etwa Anfang/Frühjahr diesen Jahres kommt es immer wieder zu kurzen Netzwerkunterbrechungen, dabei ist es egal ob es eth0, wlan0 oder eth1(usb<=>eth Konverter) (!X!-6sec) ist.
Die Unterbrechungen kommen höchst unregelmäßig, und bestehen unterschiedlich lange, meistens jedoch unterhalb des TCP-Timeoutfensters, so dass die Übertragung anschließend fortgesetzt und Remotesessions wieder weiter fortgeführt werden. Ganz selten kommt es auch vor, dass die Unterbrechung über den Timeout hinaus dauert und die Verbindungen gecanceled werden.
Am gravierensten merkt man es unter Verwendung von synergy: Teilen von Maus, Tastatur und Zwischenablage über das Netzwerk. (!X!-9sec)

(!X!-7sec)
Synergyaufbau:
[links: Asus eeePC, aktuelles Deb/Jessie x86; LXDE; Synergy-Client] --- [mitte: Desktop Win7 SP1 x64, Synergy-Server, Maus + Tastatur owner] --- [rechts: Fujitsu Lifebook S762; aktuelles Deb/Jessie multiarch, bis vor kurzem noch amd64 machte aber keinen unterschied, KDE 4.14.2; Synergy Client]

Es äußert sich folgender maßen:
Alles läuft wunderbar. Tritt die Netzwerkunterbrechung auf, friert Maus + Tastatur ein (logisch), (!X!-5sec) tippt man dennoch weiter, (Synergyserver läuft ja auf der Windows-Kiste und cached) werden die eingaben nachträglich "nachgeholt". Beim Browsen ist ähnlich: (!X!-4sec) ruft (!X!-6sec) (!X!-10sec)man (!X!-7sec) eine Seite auf, wird diese verzögert geladen, oder kann gar nicht geladen werden.

Das abgefahrene: Auf dem EeePC Läuft alles absolut problemfrei, keine unterbrechungen, nichts. Alles super. Auf dem Fujitsu mit KDE4 dagegen dieser Mist! und das Beste: zuhause auf dem Alienware M14x R2 mit KDE4 und aktuellem Deb/Jessie/amd64 jab ich das gleiche Problem obwohl ich den Alienware diesen Monat neu aufgesetzt habe und alles frisch installiert hab.

Gemeinsamkeiten der Problemlaptops (AW und Fuji): KDE4, Ivy-Bridge i7 CPU.

Anhaltspunkte:

Code: Alles auswählen

# tail /var/log/syslog 
Nov 28 11:56:33 LF01 Synergy 1.5.0: INFO: entering screen
Nov 28 11:56:40 LF01 Synergy 1.5.0: INFO: leaving screen
Nov 28 11:57:34 LF01 freshclam[1052]: Received signal: wake up
Nov 28 11:57:34 LF01 freshclam[1052]: ClamAV update process started at Fri Nov 28 11:57:34 2014
Nov 28 11:57:34 LF01 freshclam[1052]: main.cld is up to date (version: 55, sigs: 2424225, f-level: 60, builder: neo)
Nov 28 11:57:34 LF01 freshclam[1052]: daily.cld is up to date (version: 19691, sigs: 1276765, f-level: 63, builder: neo)
Nov 28 11:57:34 LF01 freshclam[1052]: bytecode.cld is up to date (version: 242, sigs: 46, f-level: 63, builder: dgoddard)
Nov 28 12:00:57 LF01 Synergy 1.5.0: INFO: entering screen
Nov 28 12:00:58 LF01 Synergy 1.5.0: INFO: leaving screen
Nov 28 12:03:38 LF01 Synergy 1.5.0: INFO: entering screen

Code: Alles auswählen

# tail /var/log/dmesg
[    5.778079] vboxdrv: Found 8 processor cores.
[    5.778312] vboxdrv: fAsync=0 offMin=0xda offMax=0x100b
[    5.778386] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
[    5.778387] vboxdrv: Successfully loaded version 4.3.6 (interface 0x001a0007).
[    5.818147] e1000e 0000:00:19.0: irq 40 for MSI/MSI-X
[    5.818230] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    5.819343] ax88179_178a 3-4.2:1.0 eth1: register 'ax88179_178a' at usb-0000:00:14.0-4.2, ASIX AX88179 USB 3.0 Gigabit Ethernet, 50:3f:56:00:24:3c
[    5.819370] usbcore: registered new interface driver ax88179_178a
[    5.834228] systemd-udevd[257]: renamed network interface eth1 to eth4
[    5.998060] vboxpci: IOMMU not found (not registered)

Code: Alles auswählen

# tail /var/log/kern.log
Nov 28 07:56:43 LF01 kernel: [    6.243470] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Nov 28 07:56:44 LF01 kernel: [    7.416685] floppy0: no floppy controllers found
Nov 28 07:56:45 LF01 kernel: [    7.685523] vboxdrv: Found 8 processor cores.
Nov 28 07:56:45 LF01 kernel: [    7.685739] vboxdrv: fAsync=0 offMin=0x129 offMax=0x577f
Nov 28 07:56:45 LF01 kernel: [    7.685822] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
Nov 28 07:56:45 LF01 kernel: [    7.685824] vboxdrv: Successfully loaded version 4.3.14 (interface 0x001a0007).
Nov 28 07:56:45 LF01 kernel: [    7.886248] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
Nov 28 07:56:45 LF01 kernel: [    7.886257] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
Nov 28 07:56:45 LF01 kernel: [    7.886296] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Nov 28 07:56:45 LF01 kernel: [    7.906843] vboxpci: IOMMU not found (not registered)

Code: Alles auswählen

# lsusb
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 004: ID 0489:e052 Foxconn / Hon Hai 
Bus 003 Device 005: ID 0b97:7772 O2 Micro, Inc. OZ776 CCID Smartcard Reader
Bus 003 Device 003: ID 0b97:7761 O2 Micro, Inc. Oz776 1.1 Hub
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c05b Logitech, Inc. M-U0004 810-001317 [B110 Optical USB Mouse]
Bus 001 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Code: Alles auswählen

# lspci
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series Chipset Family KT Controller (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
00:1c.7 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 8 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QM77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
0a:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)
0b:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader (rev 01)

(!X!-23sec)
(!X!-18sec)
lspci -vv
38132

lsusb -vv
38131

Kann mir da jemand weiterhelfen, das Netzwerk in den Griff zu bekommen?



PS: Die "(!X!-7sec)" sind die punkte wo währen des Schreibens dieses Posts ich Verbindungsunterbrechungen hatte und wie lange.

[rendegast]

Die Interfaces werden über ein Desktop-Tool (network-manager o.ä.) konfiguriert oder über /etc/network/interfaces ?
Der Kontrolle durch dieses Tool mal entziehen durch Eintragung in genannte Datei.

Mal systemd(init) durch sysv ersetzen

Code: Alles auswählen

apt-get install sysvinit-core systemd-shim
apt-get install --reinstall sysvinit

#Evtl. Neuerstellen der initrd?
update-initramfs -u -kall
<REBOOT>

(Zurück zum systemd(init) per 'apt-get install systemd-sysv')

Den Turbo-Modus des i7 im BIOS deaktivieren?
IOMMU im BIOS deaktivieren? oder per Kernel-Commandline?
BIOS-Upgrade?

intel-microcode versuchen?
kernel 3.17 aus experimental?

[dufty2]

oder eth1(usb<=>eth Konverter)

Bin kein großer Freund von Convertern (egal ob Kupfer/Glas oder USB/Ethernet).
Für ~ 20 Euronen gibt es nette 5 port Gigabit/s-Switche, dann hat Dein eepc 100 Mbps und Dein schleppi & desktop jeweils ein 1 gig.

[silverSliDE]

Die Interfaces werden über ein Desktop-Tool (network-manager o.ä.) konfiguriert oder über /etc/network/interfaces ?
Der Kontrolle durch dieses Tool mal entziehen durch Eintragung in genannte Datei.

Mal systemd(init) durch sysv ersetzen

Code: Alles auswählen

apt-get install sysvinit-core systemd-shim
apt-get install --reinstall sysvinit

#Evtl. Neuerstellen der initrd?
update-initramfs -u -kall
<REBOOT>

(Zurück zum systemd(init) per 'apt-get install systemd-sysv')

Den Turbo-Modus des i7 im BIOS deaktivieren?
IOMMU im BIOS deaktivieren? oder per Kernel-Commandline?
BIOS-Upgrade?

intel-microcode versuchen?
kernel 3.17 aus experimental?

Hatte beides versucht:
konfiguration über /etc/network/interfaces und den Network-Manager inkl. plasma-nm purgen (Blacklisten von NM brachte nichts), Alles komplett über den NM laufen zu lassen und network/Interfaces außen vor zu lassen (inkl Neustart der Deamons später Reboot um falsche Deamon restart Reihenfolge auszuschließen), keine Änderung.

sysv gerade installiert, werde jetzt rebooten un die nächsten tage beobachten, bevor ich dann zu den CPU/BIOS-settings übergehe
eins steht fest: sollte das Problem wirklich drch sysv gelöst sein, wäre das schonmal ein großes pro für Devuan, aber das ist ein anderes Thema.

Bin kein großer Freund von Convertern (egal ob Kupfer/Glas oder USB/Ethernet).
Für ~ 20 Euronen gibt es nette 5 port Gigabit/s-Switche, dann hat Dein eepc 100 Mbps und Dein schleppi & desktop jeweils ein 1 gig.

Da bin ich ganz bei dir, nur muss ich geräte in 6 VLANs administrieren. eth0 ist im default-netz während der USB-LAN Adapter bei bedarf mit dem benötigten VLAN verbunden und in den Laptop eingesteckt wird. Es mach übrigens keinen unterschied ob der Adapter steck oderr nicht.

[silverSliDE]

switch zu sysv hat nichts gebracht ==> wieder zurück bei systemd
versuche es nun mit intel-microcode

[mutetella]

Hab' dasselbe Problem, nach unspezifischen Intervallen verlier' ich die Verbindung zum Internet, genauer gesagt: Die Route zum Gateway verschwindet. So sieht die Routingtabelle aus, wenn alles in Ordnung ist:

Code: Alles auswählen

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 wlan0
192.168.0.0     *               255.255.255.0   U     0      0        0 wlan0

Und so, wenn es wieder soweit ist:

Code: Alles auswählen

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 wlan0

Wenn ich die Route neu setze ...

Code: Alles auswählen

# route add default gw 192.168.0.1 dev wlan0

... kann ich wieder auf's Internet zugreifen.

Kann mangels Ahnung nicht beurteilen, ob das mit Deinem Problem zu tun haben könnte. Vielleicht bringt's Dich (und damit dann auch mich *grins*) weiter...

Gruß
mutetella

[silverSliDE]

interessanter ansatz, werde ich beobachten.
PS: intel-microcode hat nichts gebracht

[silverSliDE]

nope hab keine änderung an der Route beim verbindungsabbruch...

[silverSliDE]

Sooooo! Problem gelöst!

Hier ein kleiner Bericht für die Nachwelt:
Nachdem ich heute morgens wieder teilweise 3-4 abbrüche pro Minute hatte, und meinen Tisch zum Xten mal umgeworfen habe, nahm ich mir nun die zeit alles vernünftig zu analysieren.
nachdem nun ja alle logs sauber waren und die maschine ansonsten sauber läuft, hatte ich bei jedem ausfall angefangen wild ins blaue zu pingen.
erstmal nach extern ==> nix
eine stufe zurück, Gateway ==> nix
eine stufe zurück, DNS ==> GEHT!
OK beim nächsten ausfall schnell einige internen IPs aus dem eigenen subnet gepingt ==> geht
also auf den Gateway aufgewählt und angefangen die regeln zu durchforsten.
Regeln, netzwerklogs: alles sauber.
iwann hab ich aus neugierde die internen systemlogs des GW mal überflogen und da fiel es auf:

Code: Alles auswählen

Dec 11 12:03:53 	kernel: arp: aaa.bbb.ccc.129 moved from e0:18:77:aa:aa:aa to 00:0d:65:aa:aa:aa on lagg0
Dec 11 12:03:53 	kernel: arp: aaa.bbb.ccc.129 moved from 00:0d:65:aa:aa:aa to e0:18:77:aa:aa:aa on lagg0
Dec 11 12:03:52 	kernel: arp: aaa.bbb.ccc.129 moved from e0:18:77:aa:aa:aa to 00:0d:65:aa:aa:aa on lagg0
Dec 11 12:03:51 	kernel: arp: aaa.bbb.ccc.129 moved from 00:0d:65:aa:aa:aa to e0:18:77:aa:aa:aa on lagg0
Dec 11 12:03:50 	kernel: arp: aaa.bbb.ccc.129 moved from e0:18:77:aa:aa:aa to 00:0d:65:aa:aa:aa on lagg0

dieses eine logfile war VOLL davon.

somit war relativ schnell klar: irgendwo hängt eine kiste mit Cisco-MAC und "meiner" IP statisch im Netz, denn auf allen Servern ist nur meine MAC zu der IP zugeordnet.
also fix meiner kiste eine andere Ip zuweisen lassen, die SICHER noch nicht besetzt war. jetzt kam der entscheidende Punkt. keiner der Kollegen konnte nun die alte IP pingen. keiner außer mir. Als ich meine ARP-Tabelle überprüfte, war bei mir diese alte IP mit der fremden MAC eingetragen. Nachdem ich die Netzeinstellungen unserer Rechner verglich fiel uns auf, dass ich der einzige aus dem "hinteren" teil unseres 23er Netzes war. alle hatten eine "aaa.bbb.110.ccc" IP nur ich hatte die "aaa.bbb.111.129". somit lag nahe, dass das gerät statisch auf die aaa.bbb.111.129/24 konfiguriert war und die anfragen aus dem 110er bereich ins Nirvana liefen.
Ein schneller nmap auf die aaa.bbb.111.129 ergab schnell dass es kein rechner war, da bis auf 3nötige ausnahmen ALLE ports dicht waren. Anhand der Ports war es rel klar dass es tatsächlich ein Cisco Switch sein musste. Ich schloss mich mit den Kollegen von anderen Standorten kurz und folgendes kam raus:

zu urzeiten, als es noch "das" 24er netz gab, war DIESER adressbereich ein abgeschottetes 26er Netz für sondergeräte. im Laufe der Jahre wurde es abgeschafft und es entstand ein "großes" 23er Netz. Der Switch für die 4 26er Netze wurde allerdings nie vom Netz genommen und ist mit den Jahren in Vergessenheit geraten. was auch kein thema war, da er eh nur vor sich hin dümpelte und keiner aufgabe nachging. bis ich iwan DIESE Adresse zugewiesen bekommen hab, die zufällig dieser UR-Switch auch hat.
Die Vermutung liegt nun nahe, dass es bei dem 2ten System mit den gleichen Problemen um das gleiche Phänomen handelt. Wer weiß, was an irgend einem Standort noch aus den 90ern undokumentiert am netz gammelt.
somit kann ich nun plasma-nm wieder ordentlich konfigurieren und wieder zufrieden der Arbeit nachgehen.

Vielen Dank an alle Beteiligten für die Hilfe, Mühe und Denkanstöße

Viele Grüße
silverSl!DE

PS: WOW kein einziger Abbruch währen dem Schreiben!


TL;DR
Anderes System(MAC) mit selber IP im Netz