Routing - Verbindungsabbrüche

[dufty2]

Man sollte sich nicht zu sehr auf die Namensauslösung versteifen, sie scheint zu funktionieren,
da eine (sogar mehrere) Verbindungen zum Webserver stattfinden.
Viel interessanter wäre die Frage, warum die Verbindung (dauernd) abbricht.

[mat6937]

Man sollte sich nicht zu sehr auf die Namensauslösung versteifen, sie scheint zu funktionieren,

Ja, aber es könnte sein, dass hier diese permanente Anfrage an Port 53 (Namensauflösung) eine "Voraussetzung" für den funktionierenden Download ist. Evtl. sollte man loggen, ob der Download evtl. dann aufhört/aussetzt wenn keine Antwort mehr vom DNS-Server/-Resolver (vom src-Port 53) kommt.

[dufty2]

Es scheint eine Eigenheit dieses "axel"-Programms zu sein, für jeden Verbindungsaufbau eine DNS-Auflösung zu machen. Nimmt man "-n 1" sind es 2, nimmt man als Parameter "-n 9" sind es 10.
Und da der Download (resp. die 10 parallelen Downloads) ständig abbrechen, wird von axel scheinbar für jeden neuen Verbindungsaufbau das DNS erneut bemüht.

Wie auch immer, DNS funktioniert, und wenn die Verbindung erst einmal aufgebaut ist, braucht man auch kein DNS mehr, da dann alles weitere über IPs geht.

[mat6937]

..., wird von axel scheinbar für jeden neuen Verbindungsaufbau das DNS erneut bemüht.

Naja, da der lokale DNS-Cache hier nicht funktioniert, ist jede neue Verbindung zum Port 53 (betr. Namensauflösung für "leaseweb") ein Hinweis für eine Unterbrechung im Download bzw. für einen neuen Verbindungsaufbau.

EDIT:

@Keinerfari
Schau mal auf deinem Router und auf deinem Laptop, ob die "Query time" nach 4 bis 5 Abfragen in der Folge, 0 msec wird:

Code: Alles auswählen

dig mirror.de.leaseweb.net | grep -i time

Betr. WLAN evtl. auf dem Router und auf dem Laptop, die Ausgabe von:

Code: Alles auswählen

iwevent

beobachten.

[Keinerfari]

So, ich bin noch einmal alles durchgegangen:

Code: Alles auswählen

$ dig mirror.de.leaseweb.net | grep -i time
;; Query time: 18 msec

;; Query time: 1 msec

;; Query time: 8 msec

;; Query time: 6 msec

;; Query time: 1 msec

;; Query time: 1 msec

Das sind die verschiedenen Ausgaben, wenn ich den Befehl mehrmals eingebe. Auf 0 msec sinkt die Zeit nicht.

Die Eingabe von iwevent zeigt mir (auch bei Nutzung des WLAN-Moduls) sowohl auf dem Client, also auch auf dem Router nichts an:

Code: Alles auswählen

$ iwevent 
Waiting for Wireless Events from interfaces...

Außerdem zur Namensauflösung:

Code: Alles auswählen

$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 127.0.0.1

(auf einem anderen Client wird als nameserver 192.168.1.1 angezeigt)

Code: Alles auswählen

# netstat -tulpen | grep -iE 'dnsmasq|:53'
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      0          10448       1571/dnsmasq    
udp        0      0 127.0.0.1:53            0.0.0.0:*                           0          10447       1571/dnsmasq    

Auf einem anderen ebenfalls betroffenen Clients ist die Ausgabe abweichend:

Code: Alles auswählen

udp        0      0 0.0.0.0:5353            0.0.0.0:*                           106        12980       630/avahi-daemon: r
udp6       0      0 :::5353                 :::*                                106        12981       630/avahi-daemon: r

Code: Alles auswählen

$ nm-tool | grep -i dns
    DNS:             192.168.1.1

Code: Alles auswählen

ps aux | grep -i [d]ns
nobody    1571  0.0  0.0   6884  1376 ?        S    Dec09   0:01 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus --conf-dir=/etc/NetworkManager/dnsmasq.d

@dufty2:

Ich habe nun auch einmal während des stockenden Downloads mit tcpdump sowohl die WLAN- also auch die Ethernet-Schnittstelle des Routers aufgezeichnet.
In Wireshark sehe ich, dass die Abbrüche der Verbindung offenbar vor den erneuten DNS-Anfragen auftreten.
Abbrüche der TCP-Verbindung sind auf beiden Interfaces ersichtlich.

Hier einmal ein Bild davon: http://www.abload.de/img/wiresharkgzj9b.jpg
(Aus den dump des Ethernet-Interface)
Wie habe ich das zu lesen? Online finde ich einiges zu Wireshark, aber so ganz blicke ich noch nicht durch.

[mat6937]

Code: Alles auswählen

$ dig mirror.de.leaseweb.net | grep -i time
;; Query time: 18 msec

;; Query time: 1 msec

;; Query time: 8 msec

;; Query time: 6 msec

;; Query time: 1 msec

;; Query time: 1 msec

Das sind die verschiedenen Ausgaben, wenn ich den Befehl mehrmals eingebe. Auf 0 msec sinkt die Zeit nicht.

OK, eine query time von 1 msec deutet schon auf die Nutzung eines dns-cache, aber nicht den lokalen dns-cache auf dem Client (... evtl. den vom Router/AP oder den vom TC7200-Kabel-Router).

Code: Alles auswählen

ps aux | grep -i [d]ns
nobody    1571  0.0  0.0   6884  1376 ?        S    Dec09   0:01 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec --enable-dbus --conf-dir=/etc/NetworkManager/dnsmasq.d

Konfiguriere mal den dnsmasq auf dem WLAN-Client, statt "--cache-size=0" mit z. B.: "--cache-size=500".

Die Eingabe von iwevent zeigt mir (auch bei Nutzung des WLAN-Moduls) sowohl auf dem Client, also auch auf dem Router nichts an:

Code: Alles auswählen

$ iwevent 
Waiting for Wireless Events from interfaces...

Das ist gut, denn das bedeutet, dass es hier keine Unterbrechungen in der WLAN-Verbindung zwischen WLAN-Router und WLAN-Client gibt.

EDIT:

Schau mal auf dem WLAN-Router und auch auf dem WLAN-Client, für das WLAN-Interface mit z. B.:

Code: Alles auswählen

modinfo <Treiber/Modul> | grep -iE 'depends|parm'

was Du evtl. zusätzlich konfigurieren/optimieren könntest.

[dufty2]

In Wireshark sehe ich, dass die Abbrüche der Verbindung offenbar vor den erneuten DNS-Anfragen auftreten.
Abbrüche der TCP-Verbindung sind auf beiden Interfaces ersichtlich.

Hier einmal ein Bild davon: http://www.abload.de/img/wiresharkgzj9b.jpg
(Aus den dump des Ethernet-Interface)

Mmmh, Deine NATerei verwirrt mich etwas, denn Du hattest doch gar kein masquerade in Deinen iptables-Regeln (?)

Desweiteren hätt' ich jetzt erwartet, das bei z. B. "-n 10" pro neue Verbindung auch der Source-Port hochgezählt wird, also 42634, 42635, 42636, bis 42643.
Aber vielleicht kommt die noch im weiteren Teil des dumps?

[mat6937]

Betroffen sind außerdem nur die WLAN-Clients.

Betroffen sind die WLAN-Clients an deinem Laptop-WLAN-Router. Das TC7200-Kabel-Router-Modem hat ja auch WLAN. Hast Du dieses WLAN evtl. von UM (für 30 EUR) aktivieren lassen? Hast Du evtl. auch einen "richtigen" WLAN-Router (z. B. FritzBox oder gleichwertig) mit dem Du als AP an deinem TC7200 testen könntest? UM und/oder KabelBW behaupten ja auch, dass man am TC7200 keinen WLAN-Router als AP betreiben kann. Ob das stimmt weiß ich nicht.

[Keinerfari]

Mmmh, Deine NATerei verwirrt mich etwas, denn Du hattest doch gar kein masquerade in Deinen iptables-Regeln (?)

Masquerade ist eingeschaltet.

Code: Alles auswählen

# iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE

...der Source-Port hochgezählt wird...

Das ist auch der Fall. Der Port wurde sogar von 42613 bis 42663 hochgezählt.
Lässt sich daraus der Fehler finden?

@mat6937:
modinfo gibt folgendes aus - Router:

Code: Alles auswählen

# modinfo ath9k_htc | grep -iE 'depends|parm'
depends:        ath9k_hw,ath9k_common,mac80211,ath,cfg80211,usbcore
parm:           debug:Debugging mask (uint)
parm:           nohwcrypt:Disable hardware encryption (int)
parm:           btcoex_enable:Enable wifi-BT coexistence (int)
parm:           ps_enable:Enable WLAN PowerSave (int)

Client:

Code: Alles auswählen

# modinfo ath5k | grep -iE 'depends|parm'
depends:        mac80211,cfg80211,ath
parm:           nohwcrypt:Disable hardware encryption. (bool)
parm:           all_channels:Expose all channels the device can use. (bool)
parm:           fastchanswitch:Enable fast channel switching for AR2413/AR5413 radios. (bool)

Das WLAN vom Kabel-Modem-Router habe ich nicht aktivieren lassen. Für die Aktivierung der schon vorhandenen Funktion wollte ich aus Prinzip nicht blechen. Eine ältere FritzBox habe ich noch hier, die werde ich morgen einmal am UM-Gerät testen. Das ist eine tolle Idee!

[mat6937]

modinfo gibt folgendes aus - Router:

Code: Alles auswählen

# modinfo ath9k_htc | grep -iE 'depends|parm'
depends:        ath9k_hw,ath9k_common,mac80211,ath,cfg80211,usbcore
parm:           debug:Debugging mask (uint)
parm:           nohwcrypt:Disable hardware encryption (int)
parm:           btcoex_enable:Enable wifi-BT coexistence (int)
parm:           ps_enable:Enable WLAN PowerSave (int)

Versuch mal mit (... wenn Du Kabelverbindung zum Router hast):

Code: Alles auswählen

sudo modprobe -rfv ath9k_htc && sudo modprobe -v ath9k_htc nohwcrypt=1
sudo depmod -a

Wenn es was bringt, dann kannst Du es permanent machen, mit:

Code: Alles auswählen

echo "options ath9k_htc nohwcrypt=1" | sudo tee -a /etc/modprobe.d/ath9k_htc.conf

Client:

Code: Alles auswählen

# modinfo ath5k | grep -iE 'depends|parm'
depends:        mac80211,cfg80211,ath
parm:           nohwcrypt:Disable hardware encryption. (bool)
parm:           all_channels:Expose all channels the device can use. (bool)
parm:           fastchanswitch:Enable fast channel switching for AR2413/AR5413 radios. (bool)

Auf dem Client:

Code: Alles auswählen

sudo modprobe -rfv ath5k
sudo modprobe -v ath5k nohwcrypt=Y
sudo depmod -a

Wenn es was bringt, dann kannst Du es permanent machen, mit:

Code: Alles auswählen

echo "options ath5k nohwcrypt=Y" | sudo tee -a /etc/modprobe.d/ath5k.conf

Poste auch die parm der depends, für den Router und den Client.

EDIT:

Evtl. auch nur als Test und temporär, auf dem Router-Laptop mit deaktiviertem IPv6 versuchen.

[wanne]

Cih möchte ausdrücklich von den Vorschlägen von mat6937 abraten. Dein Wlan funktioniert.
Die Ausgabe von Wieshark zeigt eindeutig, dass das Problemschon auf eth0 besteht. Die rumkofiguriererei am WLAN kann dir eigentlich nur was kaputt machen.
@mat6937: Oder habe ich da irgend was übersehen?

Mmmh, Deine NATerei verwirrt mich etwas, denn Du hattest doch gar kein masquerade in Deinen iptables-Regeln (?)

Doch:

Code: Alles auswählen

# iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE

Desweiteren hätt' ich jetzt erwartet, das bei z. B. "-n 10" pro neue Verbindung auch der Source-Port hochgezählt wird, also 42634, 42635, 42636, bis 42643.Aber vielleicht kommt die noch im weiteren Teil des dumps?

Im dump ist offensichtlichnur eine Verbindung zu sehen. (Siehe auch die immer gleich Sequenznummer. (Die sind unter Linux pro Verbindung randomisiert.))

Wie habe ich das zu lesen? Online finde ich einiges zu Wireshark, aber so ganz blicke ich noch nicht durch.

Ohne dir zu nahe zu treten zu wollen glaube ich dass dir zum lesen einfach die Kentnisse über TCP fehlen. Wenn's dich wirklich interessiert, vielleicht mal den Artikel der englischen Wikipdia durchlesen. Ich glaube der ist vergelichsweise verständlich. Es gibt da wenn ich mich richtig erinnere auch irgend wo gute Slides von CISCO. Finde ich im Moment aber nicht.

Was aber ganz nett wäre, ist wenn du uns mal den Dump abspeichest, statt nen Screenshot herzugeben.
Am besten machst du zuerstamal den Filter rein (Dann dürfte da großartig auch nichts mehr datenschutzkritisches drin sein.)
(ip.proto == ICMP)||ip.src==37.58.58.140||ip.dst==37.58.58.140
Und dann File->export Specified Packets->Displayed.
(Wenn du dir sicher bist dass da nichts geheimes unverschlüsselt über die Leitung geht, währe einfach Captured angenemer.)

PS: Warum hast du nicht einfach den Wireshark aus den Quellen genmmen?

[mat6937]

Cih möchte ausdrücklich von den Vorschlägen von mat6937 abraten. Dein Wlan funktioniert.
Die Ausgabe von Wieshark zeigt eindeutig, dass das Problemschon auf eth0 besteht. Die rumkofiguriererei am WLAN kann dir eigentlich nur was kaputt machen.
@mat6937: Oder habe ich da irgend was übersehen?

Wlan funktioniert, aber es könnte sein, dass die "hardware encryption" der WLAN-Interfaces evtl. einen "Einfluss" auf die Daten die von eth0 kommen, hat. Ich denke nicht, dass man was kaputt machen kann, denn die Konfiguration (Optionen) der Treiber ist ja nicht permanent. D. h. nach einem reboot werden die Treiber mit den Standardoptionen geladen.

[dufty2]

PS: Warum hast du nicht einfach den Wireshark aus den Quellen genmmen?

?
Das Bild zeigt genau den Aufbau eines aktuellen wireshark 1.12.1+g01b65bf-2 aus jessie und jener hat auch dieses
Version 1.12.1 (Git Rev Unknown from unknown)
auf das Du vermutlich anspielst.
Ansonsten sollten sich die Unterschiede zum offiziellen 1.12.2 von http://www.wireshark.org in Grenzen halten.

[Keinerfari]

Hier habe ich einmal - wie von wanne beschrieben - den Mitschnitt von tcpdump hochgeladen: Link
Den Wireshark habe ich normal mit apt aus den Debian Paketquellen installiert.

Ohne dir zu nahe zu treten zu wollen glaube ich dass dir zum lesen einfach die Kentnisse über TCP fehlen.

Da hast du mehr als recht. Ich habe mir vor wenigen Tagen Harald Zisler, Computer-Netzwerke aus dem Galileo Verlag besorgt um ein paar Grundkentnisse zu gewinnen.

Danke für die rege Beteiligung hier im Thread und die vielen Versuche zu helfen.

[dufty2]

Man sieht (z.B. per "tcp.stream == 19"), dass der NAT-Router kurz vor dem Webserver ein paar RST schickt (und danach der webserver erst dicht macht). Fragt sich nur warum