Hallo,
ich habe ein kleines Problem mit meinem Freifunk Router. Ich kann nichtmehr auf Seiten wie web.de zugreifen wenn ich mich mit dem karlsruhe.freifunk.net Netz verbinde. Auf der Karte ist er als online angezeigt und auch ein verbundener client wird angezeigt.
Ich habe einen TP1043 v4 mit der aktuellen stable Firmware
per Lan ist dieser mit einer Fritzbox 6490 cable von Unitymedia verbunden (IPv4 über DS-Lite)
Knoten Name: ffka-bruchsal-bannweideweg
ich weiß grade nicht was ich noch dazu sagen kann, antworte aber gerne auf Fragen und kann auch sachen an dem Router direkt testen.
So, jetzt hab ich endlich mla wieder bisschen Zeit hier weiter zu basteln.
Also aus ifconfig:
inet Adresse:10.214.19.165 Bcast:10.214.31.255 Maske:255.255.224.0
ping 10.214.64.3
PING 10.214.64.3 (10.214.64.3) 56(84) bytes of data.
64 bytes from 10.214.64.3: icmp_seq=1 ttl=64 time=20.5 ms
64 bytes from 10.214.64.3: icmp_seq=2 ttl=64 time=17.8 ms
64 bytes from 10.214.64.3: icmp_seq=3 ttl=64 time=17.0 ms
64 bytes from 10.214.64.3: icmp_seq=4 ttl=64 time=61.0 ms
64 bytes from 10.214.64.3: icmp_seq=5 ttl=64 time=43.0 ms
64 bytes from 10.214.64.3: icmp_seq=6 ttl=64 time=65.6 ms
64 bytes from 10.214.64.3: icmp_seq=7 ttl=64 time=69.3 ms
^C
— 10.214.64.3 ping statistics —
8 packets transmitted, 7 received, 12% packet loss, time 7009ms
rtt min/avg/max/mdev = 17.027/42.060/69.312/21.834 ms
ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=48 time=33.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=48 time=36.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=48 time=35.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=48 time=30.4 ms
^C
— 8.8.8.8 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 30.466/33.906/36.139/2.131 ms
was aber sehr lustig ist, das ich google.de erreiche und auch suche kann, aber eine Seite wie web.de oder gmx.net nicht aufrufen kann.
Auch aus den google Suchergebnissen heraus kann ich keine Seite aufrufen.
ping -c 5 heise.de
PING heise.de (193.99.144.80) 56(84) bytes of data.
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=1 ttl=250 time=26.1 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=2 ttl=250 time=24.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=3 ttl=250 time=22.7 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=4 ttl=250 time=26.3 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_seq=5 ttl=250 time=23.9 ms
— heise.de ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 22.787/24.715/26.346/1.361 ms
das geht, aber im browser www.heise.de einzugeben geht nicht, da läd es ewig und führt dann zu einem Ladefehler. Gehe ich in mein eigenes Wlan kann ich wieder alles aufrufen ohne Probleme.
Interessant ist auch, wenn ich einen Torrentclient starte und dieser zum Verteilen übergeht, dann wird mein ganzer Internetzugang lahmgelegt und ich kann nichts mehr machen. Das hängt irgendwie mit Unitymedia zusammen und ist anscheinend ein Problem was mehrere Leute haben.
Ob du die Seite direkt im Browser eingibst oder bei Google auf den Link klickst ist egal, hat im Endeffekt beides das selbe Ergebnis: Dein Browser versucht die Adresse aufzulösen und anschließend den Inhalt vom Webserver anzufordern.
Das bringt mich auf eine andere Idee: Ich vermute, dass irgendwo die MTU falsch gesetzt ist. Dafür wäre einerseits die Ausgabe von ip a auf deinem Freifunkrouter interessant, andererseits könntest du den ping-Test nochmals mit unterschiedlich großen Paketen wiederholen:
ping -s <Paketgröße>
Wenn meine Vermutung stimmt, gehen Pakete bis zu einer gewissen Größe (vermutlich irgendwo um 1400 Byte) und größere nicht mehr. Das bedarf etwas Spielerei, fang am Besten mit 1000 Byte an und taste dich in 100er Schritten nach oben. Sobald Pakete nicht mehr beantwortet werden, kannst du dich in kleineren Schritten an die genaue Größe herantasten.
Jetzt konnte ich den Fehler die ganze Zeit nicht reproduzieren und dementsprechend auch wenig weiter machen, da ja alles die letzten Monate lief und ich auch nicht so viel Zeit hatte habe ich das jetzt mal auf sich beruhen lassen und es auf „später mal“ verschoben.
Heute habe ich wieder eine Kleinigkeit umgebaut, also FF-Router vom Strom und vom Netzwerk getrennt und ein Zimmer weiter wieder angeschlossen.
Ergebnis: nichts geht mehr, ich komme über beide Router nichtmehr ins Internet.
Dann ist mir aufgefallen, der 1043 ist schon die ganze zeit nichtmehr über seinen WAN Port ins Internet gegangen, sondern über die Mesh Funktion des anderen… … und jetzt stehe ich vor dem Problem, dass beide nicht mehr tun was sie sollen…
Falls jemand Anweisungen hat was ich machen soll/kann wäre ich dankbar.
Ich hab mich jetzt über den Konfigurationsmodus mit dem 1043 verbunden und ip a ergibt:
root@ffka-bruchsal-bannweideweg:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel qlen 1000
link/ether 98:de:d0:a8:cc:0c brd ff:ff:ff:ff:ff:ff
inet6 fe80::9ade:d0ff:fea8:cc0c/64 scope link
valid_lft forever preferred_lft forever
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 86:02:59:72:c4:90 brd ff:ff:ff:ff:ff:ff
4: teql0: mtu 1500 qdisc noop qlen 100
link/void
5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 98:de:d0:a8:cc:0c brd ff:ff:ff:ff:ff:ff
6: br-setup: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether 98:de:d0:a8:cc:0c brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-setup
valid_lft forever preferred_lft forever
inet6 fe80::9ade:d0ff:fea8:cc0c/64 scope link
valid_lft forever preferred_lft forever
7: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-setup
link/ether 98:de:d0:a8:cc:0c brd ff:ff:ff:ff:ff:ff
ach ja und das „ping -s 1342 web.de“ ist wirklich die grenze, 1342 geht, 1343 nicht mehr …
Ansonsten ist alles wie oben beschrieben, der FF-Gateway und alles andere reagiert auf den ping.
Bei beiden blinkt die Wlan LED, aber sind beide miteinander zu 100% über Wlan-Mesh verbunden und mit albufer2/albufer0 auch zu 90-100%