[Berlin-wireless] Seit Internet per ipb bestimmte Seiten nicht abrufbar
Sven-Ola Tuecke
sven-ola
Sa Jul 12 20:52:27 CEST 2014
Da feht das mss-clamping. Such mal "iptables forward mss-claming" und bau's ein
Gruß // Sven-Ola
On 12. Juli 2014 20:36:12 MESZ, Bastian <fly at d00m.org> wrote:
>Haben wir evtl. ein MTU-Problem?
>
>Auf einem OLSR-Knoten hinter bgp02 setzte ich den wget ab:
>
>root at ipb-west-5ghz:~# wget -O - http://cdn.sstatic.net
>Connecting to cdn.sstatic.net (190.93.246.58:80)
>[...] ewiges warten
>
>auf bgp01 lass ich einen tcpdump mit Filter auf diese CDN-IP laufen:
>vyatta at bgp01:~$ sudo tcpdump -i eth0 host 190.93.246.58
>[...]
>217.197.91.139 > 190.93.246.58: ICMP 77.87.48.197 unreachable - need to
>frag (mtu 1476), length 556
>[...]
>
>Die Anfrage wird bei bgp02 raus geschickt, das CDN antwortet über
>bgp01.
>Der GRE-Tunnel zwischen bgp01 und bgp02 hat eine MTU <1500 und anstatt
>zu fragmentieren fragt bpg01 wohl das CDN, ob es nicht kleinere Pakete
>schicken kann. Macht das CDN sicherlich dank sauberer Firewall nicht...
>
>Mal gucken wie man diese MTU-Path-Discovery oder MTU unter vyatta
>einstellt.
>
>@Daniel
>Any ideas?
>
>Gruß
>Bastian
>
>
>On 07/12/2014 07:55 PM, Sven-Ola Tuecke wrote:
>> Hi Bastian,
>>
>> Nope - nicht gelöst. Probier mal
>>
>> wget -4 -O - http://cdn.sstatic.net
>>
>> Das wird häufig verwendet und antwortet gar nicht. Sollte aber. Ping
>> geht, schau mal:
>>
>> [sven-ola at pcexo ~]$ wget -4 -O - http://cdn.sstatic.net
>> --2014-07-12 19:53:52-- http://cdn.sstatic.net/
>> Resolving cdn.sstatic.net (cdn.sstatic.net)... 141.101.114.59,
>190.93.245.58, 190.93.247.58, ...
>> Connecting to cdn.sstatic.net (cdn.sstatic.net)|141.101.114.59|:80...
>connected.
>> HTTP request sent, awaiting response... ^C
>> [sven-ola at pcexo ~]$ ping -c 1 141.101.114.59
>> PING 141.101.114.59 (141.101.114.59) 56(84) bytes of data.
>> 64 bytes from 141.101.114.59: icmp_seq=1 ttl=50 time=23.8 ms
>>
>> --- 141.101.114.59 ping statistics ---
>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>> rtt min/avg/max/mdev = 23.836/23.836/23.836/0.000 ms
>> [sven-ola at pcexo ~]$ tracepath -b 141.101.114.59
>> 1?: [LOCALHOST] pmtu 1500
>> 1: sven-ola-tp66.olsr (192.168.109.1) 0.837ms
>> 1: sven-ola-tp66.olsr (192.168.109.1) 0.770ms
>> 2: sven-ola-wap.olsr (104.198.65.97) 4.546ms
>> 3: GEK-Mod77-Arena.olsr (104.130.77.80) 5.146ms
>> 4: mid1.Mod77uplink.olsr (104.130.77.14) 8.623ms
>> 5: mid1.Zwingli-Core.olsr (104.130.10.21) 33.817ms
>> 6: mid10.rhxb-rt1.olsr (104.201.4.9) 40.938ms
>> 7: ipb-bgp02.olsr (104.201.4.18) 37.563ms
>> 8: cust-gw1.freifunk.ipberlin.com (185.27.157.169) 40.696ms
>asymm 11
>> 9: cr31.b5.xe-1-3-0.vl3001.ipberlin.com (194.29.243.2) 28.179ms
>asymm 12
>> 10: ^C
>>
>> Gruß // Sven-Ola
>>
>> Am 12.07.2014 15:33, schrieb Bastian:
>>> Hallo,
>>>
>>> Problem gelöst:
>>>
>>> Beim Wechseln von Ad-Hoc in Client-Modus, über das Webfrontend, mit
>>> einer alten pberg-168 Firmware, wird ein neues Interface-Stanza
>"wwan"
>>> angelegt. "wwan" holt IPs per DHCP und spricht kein OLSR. Firewall
>>> dürfte auch dieselbe wie bei "wan" sein.
>>>
>>> auto_ipv6 script ist in dieser Firmware-Version evtl. noch nicht
>ganz so
>>> rund, und weil der Knoten direkt am RHXB hängt ist jetzt auch ein
>>> statisches /56 vergeben.
>>>
>>> Gruß
>>> Bastian
>>
>>
>>
>>
>> _______________________________________________
>> Berlin mailing list
>> Berlin at berlin.freifunk.net
>> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>>
>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Berlin mailing list
>Berlin at berlin.freifunk.net
>http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140712/7f2b4dd8/attachment.html>
Mehr Informationen über die Mailingliste Berlin