[Berlin-wireless] pings rund um das ND

Mo Mär 20 11:31:05 CET 2006

Na -- dann sollte ich vielleicht mal ein Plakat zumindest für das  
Studentenwohnheim malen (in englisch, chinesich, koreanisch,  
japanisch, ....) mit der Bitte, dass alle Freifunkler , die hier  
wohnen  , bitte updaten... bzw.. sollte die Idee mit der Freifunk  
Party dort und dem Versuch einen oder zwei Ansprechpartner dort  
auszugucken doch mal voran getrieben werden.

mehr dazu am Mittwoch.. vielleicht sollte auch ab und zu mal ein  
english newsletter raus gehen, mit dem Hinweis zum updaten., oder  
passiert das schon ?
  Gruss Dagmar

Dagmar Albrecht
albrechtdagmar at web.de

On 20.03.2006, at 07:06, Sven-Ola Tuecke wrote:

> Hi,
>
> jupp. ND laeuft immer noch nicht so wie gewohnt. Das ist (wie oft) ein
> mehrstufiges Problem. Die Situation ist wie folgt:
>
> - ND2 (104.129.0.1, Rundstrahler) ist blind und stumm. Der  
> Rundtrahler war
> sonst z.B. von mir aus (Alex) gerade so zu erreichen. Jetzt laeuft  
> da gar nix
> mehr. Liegt leider auch nicht an der fehlenden TxPwr-Einstellung fuer
> Senao-Prism2-Karte im aktuellen Nylon/stable. Ist ein HF-Problem  
> mit der
> Antenne (Regenwurm in der Leitung?). Manuelle Versuche mit "alc  
> 0;writemif
> 62" bringen fast nix.
>
> - Als Notmassnahme ist ND1 (104.0.4.1, gerichtet auf Zwingli) im Ad- 
> Hoc. Damit
> kann z.B. der WRT 104.129.1.71 gerade so erreicht werden.  
> 104.129.1.71 hat zu
> Zeit eine MTU von 250, damit da wenigstens EMail abgefragt werden  
> kann.
>
> - Die Testweise eingebauten Atheros/Madwifi-Karten fuehrten zu  
> haeufigen
> Abstuerzen. Da dann immer jemand (Cven) 'rauf muss, sind jetzt  
> wieder die
> alten Senao/Prism2-Karten drin. Bei denen kann man die BSSID aber  
> nicht fest
> einstellen. Immer wenn einer der (vielen) WRTs rund um das ND eine  
> der Senaos
> von einer anderen BSSID ueberzeugt, wird es hakeln. Das geht  
> solange, bis
> alle rund um diesen Standord das FFF-Update durchgezogen haben.  
> Kanditat waer
> z.B. 104.130.1.73 (jemand Namens "Alex"!?).
>
> - Und weils so schoen ist, ist natuerlich auch die Boche weg.
>
> HTH Sven-Ola
>
> Am Montag 20 März 2006 02:02 schrieb Peter Lazarev:
>> es ist mir auch aufgefallen, der war heute  mal als BBB_ND_FHAIN  
>> da mal
>> als 2cafebabe/olsr.freifunknet.net/adhoc mal als zufällige ssid  
>> und dann
>> ganz weg,
>> dann war der wieder da und ist seit null uhr wieder ganz weg.
>> ich glaube es kann gut mit dem 2cafebabe-zwang-mechanismus zu tun  
>> haben,
>> da scheintdas  BBB_ND_FHAIN gegen 2cafebabe anzutreten, und nach  
>> einigen
>> hin und her verabschiedet sich der cube ganz.
>>
>> gruss Peter
>>
>> David Weese wrote:
>>> nabend,
>>>
>>> mir ist grad was komisches aufgefallen. Wir hatten Mitte letzte  
>>> Woche
>>> ja mal die Internetprobleme am Neuen Deutschland untersucht.  
>>> Anpingen
>>> der 104.129.0.1 - nd2 war ja möglich, surfen leider nicht. Das  
>>> gleiche
>>> Problem seh ich grad wieder, nur dass nun die 104.0.4.1 - nd1 auf
>>> "olsr.freifunk.net" funkt.
>>> Ich hab ein bisschen mit den ping-Paketgrößen rumprobiert.  
>>> Paketgröße
>>> 186 hat bei mir 0% und Paketgröße 187 hat 100%! paket loss. Wie  
>>> kommt
>>> denn so was? Hat der Franz-Mehring-Äther ne MTU von 228 Bytes? Kann
>>> vielleicht einer der Anwohner rund um das ND das Phänomen  
>>> bestätigen?
>>>
>>> Unter Windows *ping -l 186 -t 104.0.4.1* bzw. *ping -l 187 -t  
>>> 104.0.4.1*
>>> oder unter Linux *ping -s 186 104.0.4.1* bzw. *ping -s 187  
>>> 104.0.4.1*
>>>
>>> und mal den paket loss vergleichen. Bei mir siehts da so aus:
>>>
>>>
>>> root at kommune31:~# traceroute 104.0.4.1
>>> traceroute to 104.0.4.1 (104.0.4.1), 30 hops max, 40 byte packets
>>>  1  104.0.4.1 (104.0.4.1)  162.742 ms  264.769 ms  249.016 ms
>>> root at kommune31:~# ping -s 186 104.0.4.1
>>> PING 104.0.4.1 (104.0.4.1): 186 data bytes
>>> 194 bytes from 104.0.4.1: icmp_seq=0 ttl=63 time=65.9 ms
>>> 194 bytes from 104.0.4.1: icmp_seq=1 ttl=63 time=54.3 ms
>>> 194 bytes from 104.0.4.1: icmp_seq=2 ttl=63 time=21.6 ms
>>> 194 bytes from 104.0.4.1: icmp_seq=3 ttl=63 time=14.1 ms
>>> 194 bytes from 104.0.4.1: icmp_seq=4 ttl=63 time=26.0 ms
>>> 194 bytes from 104.0.4.1: icmp_seq=5 ttl=63 time=13.9 ms
>>> 194 bytes from 104.0.4.1: icmp_seq=6 ttl=63 time=13.7 ms
>>> 194 bytes from 104.0.4.1: icmp_seq=7 ttl=63 time=17.7 ms
>>> 194 bytes from 104.0.4.1: icmp_seq=8 ttl=63 time=31.9 ms
>>> 194 bytes from 104.0.4.1: icmp_seq=9 ttl=63 time=14.0 ms
>>> 194 bytes from 104.0.4.1: icmp_seq=10 ttl=63 time=13.7 ms
>>>
>>> --- 104.0.4.1 ping statistics ---
>>> 11 packets transmitted, 11 packets received, 0% packet loss
>>> round-trip min/avg/max = 13.7/26.0/65.9 ms
>>> root at kommune31:~# ping -s 187 104.0.4.1
>>> PING 104.0.4.1 (104.0.4.1): 187 data bytes
>>>
>>> --- 104.0.4.1 ping statistics ---
>>> 27 packets transmitted, 0 packets received, 100% packet loss
>>>
>>>
>>>
>>> Das würde schonmal erklären, warum pingen (mit Standard- 
>>> Paketgröße 56)
>>> funktioniert, alle Routen vorhanden sind, der Browser aber trotzdem
>>> leer bleibt.
>>>
>>> Gruß
>>> Dave
>>> -------------------------------------------------------------------- 
>>> ----
>>>
>>> _______________________________________________
>>> Berlin mailing list
>>> Berlin at olsrexperiment.de
>>> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin
>
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin

_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin