Über uns
Know-how
FAQ
Projektverlauf
Technikbereich
Ip-Vergabe
Organisation / Termine
Community
Forum
Karte
Gästebuch
Partner
Sonstiges
Downloads
Gallery
Spenden-Topf
Forum Startseite Wiki Karte Forum
WLanhsh & WLanwse Foren-Übersicht WLanhsh & WLanwse
Forum des WLan Hohenschönhausen und des WLan Weißensee
wlanhsh.freifunk.net
 
 FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen   RegistrierenRegistrieren 
 ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin 

33<>scharping stottert
Gehe zu Seite 1, 2  Weiter
 
Dieses Forum ist gesperrt, du kannst keine Beiträge editieren, schreiben oder beantworten.   Dieses Thema ist gesperrt, du kannst keine Beiträge editieren oder beantworten.    WLanhsh & WLanwse Foren-Übersicht -> WLanwse
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 07.08.2006, 15:36    Titel: 33<>scharping stottert Antworten mit Zitat

kleine voaraberläuterung:

für eine vernünftige verbindung zu scharping hängt an der neuen 33 anscheinend die antenne deutlich zu tief ... ergebnis ist ein mittelmäßiger link. ich hab da treibermäßig schon versucht alles rauszuholen, was sich in folgenden aufrufen zeigt:

Code:
iwconfig $BB_WSE_SCHARPING essid "wlanwse.de repKV<>scharping"
iwconfig $BB_WSE_SCHARPING key [i][ausgeblendet][/i]
iwconfig $BB_WSE_SCHARPING rate 11M
iwpriv $BB_WSE_SCHARPING pureg 1
iwpriv $BB_WSE_SCHARPING bgscan 0
iwpriv $BB_WSE_SCHARPING burst 0
athctrl -i wifi2 -d 1700
ifconfig $BB_WSE_SCHARPING 104.0.200.5 netmask 255.255.255.252 broadcast 104.0.200.7


es wird also verschlüsselt um fremd-clienten auszuschließen, mit pureg nichtmehr nach vermeintlichen 11b-clients gelausch, nichtmehr im hintergrund zu roamingzwecken gescant, nichtmehr geburstet (wodurch im frameverlustfall alle nocheinmal gesendet werden werden müssten), die ACK-timings für maximalen durchsatz getuned und die übertragungsrate auf 11MBit fest eingestellt (wobei ich eher das gefühl habe, dass er darauf gar nciht reagiert). also eigtl alles für punkt-zu-punkt-links rausgekitzelt. und trotzdem gibts packetloss. und zwar so schlimm, dass die 33 angeblich nur die hälfte aller olsr-pakete vom apscharping empfängt. da die route deswegen häufiger über die rundstrahler bedient wurde, habe ich LQ-faktoren auf beiden seiten gesetzt.

wenn ich mir aber diese routingabsurdität anschaue, dann fehlt mir jede idee, was da schief läuft:

(104.0.200.1/104.13.3.105 ist Nico
104.0.200.2/104.0.200.5/104.13.3.33 ist die "neue 33"
104.0.200.6/104.12.0.20 ist APscharping)

Code:
root@repeaterKV:~# ping -R 104.0.200.6 |grep -v "(same route)"
PING 104.0.200.6 (104.0.200.6) 56(124) bytes of data.
64 bytes from 104.0.200.6: icmp_seq=1 ttl=64 time=1.22 ms
RR:     104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.5

64 bytes from 104.0.200.6: icmp_seq=85 ttl=64 time=4.28 ms
RR:     104.13.3.33
        104.12.0.46
        104.0.200.6
        104.0.200.6
        104.13.3.33

64 bytes from 104.0.200.6: icmp_seq=103 ttl=64 time=192 ms
RR:     104.13.3.33
        104.12.0.19
        104.0.200.6
        104.0.200.6
        104.13.3.33

64 bytes from 104.0.200.6: icmp_seq=108 ttl=64 time=5.44 ms
RR:     104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.5

64 bytes from 104.0.200.6: icmp_seq=185 ttl=64 time=275 ms
RR:     104.13.3.33
        104.12.0.19
        104.0.200.6
        104.0.200.6
        104.13.3.33

64 bytes from 104.0.200.6: icmp_seq=191 ttl=64 time=5.99 ms
RR:     104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.5

64 bytes from 104.0.200.6: icmp_seq=215 ttl=64 time=27.7 ms
RR:     104.13.3.33
        104.12.0.19
        104.0.200.6
        104.0.200.6
        104.13.3.33

64 bytes from 104.0.200.6: icmp_seq=219 ttl=64 time=1.07 ms
RR:     104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.5

64 bytes from 104.0.200.6: icmp_seq=243 ttl=64 time=45.7 ms
RR:     104.13.3.33
        104.12.0.19
        104.0.200.6
        104.0.200.6
        104.13.3.33

64 bytes from 104.0.200.6: icmp_seq=247 ttl=62 time=993 ms
RR:     104.0.200.2
        104.13.3.105
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1
        104.0.200.2

64 bytes from 104.0.200.6: icmp_seq=249 ttl=62 time=886 ms
RR:     104.0.200.2
        104.0.200.1
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1
        104.0.200.2

64 bytes from 104.0.200.6: icmp_seq=251 ttl=62 time=5.57 ms
RR:     104.0.200.2
        104.0.200.1
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1
        104.0.200.2

64 bytes from 104.0.200.6: icmp_seq=250 ttl=62 time=1086 ms
RR:     104.0.200.2
        104.0.200.1
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1
        104.0.200.2

64 bytes from 104.0.200.6: icmp_seq=252 ttl=64 time=1.10 ms
RR:     104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.5

64 bytes from 104.0.200.6: icmp_seq=404 ttl=62 time=93.9 ms
RR:     104.0.200.2
        104.13.3.105
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1
        104.0.200.2

64 bytes from 104.0.200.6: icmp_seq=408 ttl=64 time=2.13 ms
RR:     104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.5

64 bytes from 104.0.200.6: icmp_seq=492 ttl=62 time=79.5 ms
RR:     104.0.200.2
        104.13.3.105
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1
        104.0.200.2

64 bytes from 104.0.200.6: icmp_seq=507 ttl=64 time=1.17 ms
RR:     104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.5

64 bytes from 104.0.200.6: icmp_seq=539 ttl=62 time=15.9 ms
RR:     104.0.200.2
        104.13.3.105
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1
        104.0.200.2

64 bytes from 104.0.200.6: icmp_seq=543 ttl=62 time=13.6 ms
RR:     104.0.200.2
        104.0.200.1
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1
        104.0.200.2

64 bytes from 104.0.200.6: icmp_seq=544 ttl=64 time=1.74 ms
RR:     104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.5

From 104.13.3.33 icmp_seq=656 Destination Host Unreachable
64 bytes from 104.0.200.6: icmp_seq=657 ttl=64 time=198 ms
RR:     104.13.3.33
        104.12.0.19
        104.0.200.6
        104.0.200.6
        104.13.3.33


was hier aufgelistet ist, ist ein ping, der mit jedem durchlauf die route ermittelt und eine routenänderung incl neuer route anzeigt. aus der ausgabe habe ich die erfolgreichen pings ohne routenänderung ausgeschlossen, damit nur die routenänderungen selbst zu sehen sind. die icmp_seq-Nummer zeigt die zeit seit dem ausführen des kommandos an, da eine sequanz eine sekunde dauert. dazu sei noch gesagt, dass in der angegebenen route hin und rückweg drin ist.(vlt ließe sich damit auch ein script zu statistischen ermittlung von routenwechseln pro zeit bauen).

am kuriosesten finde ist ja, dass der ping für scharping manchmal zu nico(!!) gesendet wird und *trommelwirbel* durch den backbone direkt zum apscharping ?!?!? ... das geht nicht ... die wlankarte mit der 104.0.200.1 kann der wlankarte mit der 104.0.200.6 nicht direkt senden ... mal ganz abgesehen davon, das sie sich nichtmal empfangen, muss zwischen ihenen immer die 33 routen ... *verwirrtsei*
und die ETX-werte zwischen den rundstrahler nico und scharping sind derart mies, dass sie niemals besser sein können, als ein ETX ~1 plus eine ETX ~2 verbindung. also wie kommt das zustande.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ali



Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.

BeitragVerfasst am: 07.08.2006, 15:58    Titel: Antworten mit Zitat

glockman hat Folgendes geschrieben:

Code:

64 bytes from 104.0.200.6: icmp_seq=247 ttl=62 time=993 ms
RR:     104.0.200.2
        104.13.3.105
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1
        104.0.200.2


Was ist denn das? Die Antwort nimmt rückwärts einen Abstecher über nico (104.0.200.1), nachdem sie schon bei der "33" angelangt war?

Keine Idee, was hier los ist. Ist ScharpingAP der Master auf dieser Verbindung? Mir fiel vorgestern bei ihm auf, daß iwconfig keine ESSID auf dem i/f zur 33 anzeigte (und die Verbindung ins Internet ruckelte). Habe sie dann von Hand neu gesetzt. Ob er zyklisch die ESSID verliert und sich die "33" dann de-assoziiert?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 07.08.2006, 16:09    Titel: Antworten mit Zitat

das log auf dem APscharping schweigt sich wegen einem linkverlust aus ... ich weiß aber nicht, ob es überhaupt eine message geben müsste ... der olsrd schmeißt ein interface erst nach einer weile raus

ich will vlt noch anmerken, dass ich seit dem umbau zur neuen 33 erst anch dem treibertuning des links eine anständige ssh-session zu APscharping hinbekommen habe.
da muss also etwas passieren.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ali



Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.

BeitragVerfasst am: 07.08.2006, 22:22    Titel: Antworten mit Zitat

glockman hat Folgendes geschrieben:
das log auf dem APscharping schweigt sich wegen einem linkverlust aus ... ich weiß aber nicht, ob es überhaupt eine message geben müsste ... der olsrd schmeißt ein interface erst nach einer weile raus


Wer soll den Linkverlust ins Log melden?

Gerade nachgesehen - die ESSID ist wieder weg und iwlist behauptet, keinen Peer zu haben. Zudem zählt der "Rx invalid nwid" Zähler ständig hoch.

Code:

root@scharpingap:~# iwconfig ath1
ath1      IEEE 802.11g  ESSID:""  Nickname:"scharpingap"
          Mode:Master  Frequency:2.432 GHz  Access Point: 00:03:2F:2D:8F:18   
          Bit Rate=5 Mb/s   Tx-Power:16 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:XXXX Security mode: restricted
          Link Quality=11/94  Signal level=-84 dBm  Noise level=-95 dBm
          Rx invalid nwid:61476  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

root@scharpingap:~# iwlist ath1 peers
ath1      No Peers/Access-Point in range


EDIT: Andererseits sieht der Mitte-Link (ath0) den Master mit der korrekten ESSID:
Code:

root@scharpingap:~# iwlist ath0 scan
ath0      Scan completed :
          Cell 01 - Address: 00:03:2F:2D:8F:18
                    ESSID:"wlanwse.de repKV<>scharping"
                    Mode:Master
                    Frequency:2.432 GHz (Channel 5)
                    Quality=43/94  Signal level=-52 dBm  Noise level=-95 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
ali



Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.

BeitragVerfasst am: 07.08.2006, 23:01    Titel: Antworten mit Zitat

Der Scan auf ath0 (dem Mitte-Link, ja, ich weiß, der zeigt ganz woanders hin) zeigt einige Aktivität um den Kanal 5 herum. Ist das die Ursache? Aber wieviel davon kommt bei ath1 an. "iwlist ath1 scan" zeigt gar nichts, liegt das am Master Mode?

Code:
iwlist ath0 scan - Auszüge Kanal 5+/-2
          Cell 01 - Address: 00:03:2F:2D:8F:18
                    ESSID:"wlanwse.de repKV<>scharping"
                    Mode:Master
                    Frequency:2.432 GHz (Channel 5)
                    Quality=43/94  Signal level=-52 dBm  Noise level=-95 dBm
 
          Cell 03 - Address: 00:15:0C:1D:F3:39
                    ESSID:"FRITZ!Box Fon WLAN 7050"
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Quality=13/94  Signal level=-82 dBm  Noise level=-95 dBm

           Cell 06 - Address: 00:14:78:75:4B:FC
                    ESSID:"BBB Mitte<>BrehmeAP"
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Quality=8/94  Signal level=-87 dBm  Noise level=-95 dBm

          Cell 07 - Address: 02:DE:AD:BE:EF:02
                    ESSID:"alis_testnetz"
                    Mode:Ad-Hoc
                    Frequency:2.422 GHz (Channel 3)
                    Quality=14/94  Signal level=-81 dBm  Noise level=-95 dBm

          Cell 09 - Address: 00:40:96:58:D5:59
                    ESSID:""
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Quality=13/94  Signal level=-82 dBm  Noise level=-95 dBm

          Cell 14 - Address: 00:13:49:4B:EE:62
                    ESSID:"ArcorWirelessLAN"
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Quality=6/94  Signal level=-89 dBm  Noise level=-95 dBm

          Cell 16 - Address: 00:15:0C:2F:44:E7
                    ESSID:""
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Quality=7/94  Signal level=-88 dBm  Noise level=-95 dBm

          Cell 17 - Address: 00:13:46:49:AA:BE
                    ESSID:"MaxundMoritz"
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Quality=8/94  Signal level=-87 dBm  Noise level=-95 dBm
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
ropf



Anmeldedatum: 25.04.2006
Beiträge: 582

BeitragVerfasst am: 08.08.2006, 00:27    Titel: Antworten mit Zitat

letzten Beitrag gelöscht - war Blödsinn
/ropf
_________________
jabber: ropf at dernico.no-ip.org
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 08.08.2006, 10:35    Titel: Antworten mit Zitat

jau .. ich kann auf keinem master-interface scannen ... hm ... war der meinung, dass das mal ging. ick mach det mitte-interface am besten mal wieder aus.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 09.08.2006, 16:09    Titel: Antworten mit Zitat

nachdem das ip_conntrack-modul draußen ist, siehts folgendermaßen aus:

Code:
root@nicoap:~# ping -R 104.0.200.6|grep -v "(same route)"
PING 104.0.200.6 (104.0.200.6) 56(124) bytes of data.
64 bytes from 104.0.200.6: icmp_seq=1 ttl=63 time=2.07 ms
RR:     104.0.200.1
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1

64 bytes from 104.0.200.6: icmp_seq=33 ttl=63 time=148 ms
RR:     104.13.3.105
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.13.3.105

64 bytes from 104.0.200.6: icmp_seq=38 ttl=63 time=4.79 ms
RR:     104.0.200.1
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1

64 bytes from 104.0.200.6: icmp_seq=121 ttl=64 time=18.5 ms
RR:     104.0.200.1
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.1

64 bytes from 104.0.200.6: icmp_seq=125 ttl=63 time=2.29 ms
RR:     104.0.200.1
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1

64 bytes from 104.0.200.6: icmp_seq=175 ttl=63 time=2.31 ms
RR:     104.0.200.1
        104.0.200.2
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1

64 bytes from 104.0.200.6: icmp_seq=182 ttl=63 time=1.89 ms
RR:     104.0.200.1
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1

64 bytes from 104.0.200.6: icmp_seq=216 ttl=63 time=1.71 ms
RR:     104.0.200.1
        104.0.200.2
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1

64 bytes from 104.0.200.6: icmp_seq=220 ttl=63 time=163 ms
RR:     104.13.3.105
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.13.3.105

64 bytes from 104.0.200.6: icmp_seq=225 ttl=63 time=2.15 ms
RR:     104.0.200.1
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1

64 bytes from 104.0.200.6: icmp_seq=243 ttl=63 time=23.8 ms
RR:     104.13.3.105
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.13.3.105

64 bytes from 104.0.200.6: icmp_seq=248 ttl=63 time=11.3 ms
RR:     104.0.200.1
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1

64 bytes from 104.0.200.6: icmp_seq=254 ttl=63 time=94.3 ms
RR:     104.13.3.105
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.13.3.105

64 bytes from 104.0.200.6: icmp_seq=262 ttl=63 time=1.92 ms
RR:     104.0.200.1
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1

64 bytes from 104.0.200.6: icmp_seq=456 ttl=63 time=1464 ms
RR:     104.13.3.105
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.13.3.105

64 bytes from 104.0.200.6: icmp_seq=460 ttl=63 time=1.64 ms
RR:     104.0.200.1
        104.0.200.5
        104.0.200.6
        104.0.200.6
        104.0.200.2
        104.0.200.1


zwar keine unlogischen routen mehr, aber auf dem interface, das zu nico zeigt, gibt sich die 33 anscheind hin und wieder als 104.0.200.5, anstatt 104.0.200.2, aus. da die 104.0.200.5 aber außerhalb des subnetzes auf dem punkt-zu-punkt-link nico-33 liegt, wird das nächste paket auf dem rundstrahler rausgeblasen. also bin ich der ursache schonmal auf der spur ... aber der lösung kein bisschen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 10.08.2006, 13:46    Titel: Antworten mit Zitat

die lösung ist manchmal VIEL einfacher, als man denkt ...

im cron-script für den rundstrahler habe ich damals folgende zeilen reingeschrieben:

Code:
if [ -z "` route -n | grep 0.0.0.0 | grep $IFACE | grep -v 104.0.0.0 `" -a "$MYBSSID" == "$BSSID" ]
then
        logger "no routes on $IFACE in spite of correct BSSID, restarting olsrd"
               killall olsrd
               olsrd
fi


nun hat der rundstrahler bie nico aber in letzt zeit häufiger mal die angewohnheit, trotz richtiger bssid nicht mehr mit dem netz zu sprechen ... nunja ... die folge ist ein ständig neu startender olsrd ...

es war also nicht die verbindung 33-scharping, sondern nicos ap ... nunja ... wenn einem die blickwinkel zur diagnose fehlen ...

schaue ich mir aber an, was die routen machen, kann man das immer noch nicht als stabil bezeichnen ... *Grmpf*
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ali



Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.

BeitragVerfasst am: 13.08.2006, 14:43    Titel: Antworten mit Zitat

Ich habe mal auf dem ScharpingAP in /etc/olsrd.conf für das Interface ath1 (BB zum KV33) die Zeile

Code:

        Ip4Broadcast            104.0.200.5

hinzugefügt, also als Zieladresse der OLSR Pakete die IP-Adresse der "33" und siehe da,
die Routen waren in den letzten 5 Minuten stabil und wir haben ETX-Werte von 1.01 und 1.04 Sehr glücklich

Hintergrund: Der 802.11-Standard definiert, daß bei Broadcast-Paketen nur dann ACKs auf Linklevel-Ebene geschickt werden, wenn das ToDS-Bit gesetzt ist (Kapitel 9.2.7 in 802.11-1999), also das Paket zum AP geht. Auf dem Backbone ScharpingAP<->33 ist der ScharpingAP der AP (aka Master). Also wurden nur die OLSR-Pakete zum ScharpingAP geACKT und beim Ausbleiben sofort vom Sender wiederholt.

Mit obiger Änderung sind OLSR-Pakete zur 33 keine Broadcast-Pakete und werden geACKt.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
ropf



Anmeldedatum: 25.04.2006
Beiträge: 582

BeitragVerfasst am: 13.08.2006, 15:06    Titel: Antworten mit Zitat

Bravo!
_________________
jabber: ropf at dernico.no-ip.org
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ali



Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.

BeitragVerfasst am: 13.08.2006, 16:08    Titel: Antworten mit Zitat

Tja, die Frage ist jetzt: Merkt jemand, der mit am ScharpingAP hängt, eine Verbesserung?

Aber manchmal wackelt die Route ScharpingAP -> 33 immer noch, und es geht, statt über den Backbone, über den Rundstrahler und Nico zur 33:

Code:

Sun Aug 13 15:27:59 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
Sun Aug 13 15:28:01 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
Sun Aug 13 15:30:57 CEST 2006
104.0.200.5 104.13.3.33 255.255.255.255 UGH 1 0 0 eth1
Sun Aug 13 15:30:59 CEST 2006
104.0.200.5 104.13.3.33 255.255.255.255 UGH 1 0 0 eth1
Sun Aug 13 15:32:08 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
Sun Aug 13 15:32:10 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
Sun Aug 13 15:34:52 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
Sun Aug 13 15:34:54 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
Sun Aug 13 15:43:49 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
Sun Aug 13 15:43:51 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
Sun Aug 13 15:53:35 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
Sun Aug 13 15:53:37 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
Sun Aug 13 15:53:39 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1

Das ist die Ausgabe von /root/trace_route_kv33.sh:
Code:

#!/bin/bash
# check every 2 seconds if the route to 104.0.200.5 is direct
# if not, print it out
while true; do
        ROUTE=`route -n | grep ^104.0.200.5`
        if echo $ROUTE | fgrep -v 0.0.0.0 > /dev/null; then
                date
                echo $ROUTE
        fi
        sleep 2
done


Ich werde mal versuchen, die aktuellen LQ-Werte mit aufzuzeichnen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
scharping



Anmeldedatum: 07.09.2005
Beiträge: 216
Wohnort: 13086 lehderstrasse 11 (104.12.0.20)

BeitragVerfasst am: 13.08.2006, 16:43    Titel: Antworten mit Zitat

scharping hängt auch am scharpingap.
meine messung:
Die Messung wurde durchgeführt:
Sonntag, 13.08.2006 um 16:41:35 Uhr (CEST).

Download-Geschwindigkeit: 2.185 kbit/s (273 kByte/s)
Upload-Geschwindigkeit: 418 kbit/s (52 kByte/s)

Das Ergebnis entspricht folgendem Anschlusstyp: DSL 3.000

ist doch super !!!!!!!
und deutlich stabiler
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
ali



Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.

BeitragVerfasst am: 13.08.2006, 19:26    Titel: Antworten mit Zitat

Hmm, so ganz zufrieden bin ich noch nicht.
Ich habe auf dem ScharpingAP ein Skript laufen (/root/trace_route_kv33.sh), das alle zwei Sekunden nachsieht, ob die Route zu KV33 (104.0.200.5) noch direkt ist. Wenn nicht, loggt es die Route und die Zeilen für 104.0.200.5 und das neue Gateway aus http://localhost:8080/nodes:

Code:

tracking the route to 104.0.200.5 every 2 seconds
Sun Aug 13 17:56:07 CEST 2006
############################
Sun Aug 13 18:20:46 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
  104.12.0.20  104.13.3.105  0.00  0.42  58  100  0.10  24.29 
  104.0.200.6  104.0.200.5  0.00  0.99  1  100  0.00  0.00 
Sun Aug 13 18:20:48 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
  104.12.0.20  104.13.3.105  0.00  0.40  60  100  0.09  28.98 
  104.0.200.6  104.0.200.5  0.00  0.99  1  100  0.97  1.04 
Sun Aug 13 18:36:09 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
  104.12.0.20  104.13.3.105  0.00  0.49  51  100  0.05  43.37 
  104.0.200.6  104.0.200.5  0.00  0.79  21  100  0.99  1.28 
Sun Aug 13 18:36:12 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
  104.12.0.20  104.13.3.105  0.00  0.52  48  100  0.05  40.87 
  104.0.200.6  104.0.200.5  0.00  0.77  23  100  0.99  1.31 
Sun Aug 13 18:38:29 CEST 2006
104.0.200.5 104.13.3.105 255.255.255.255 UGH 2 0 0 eth1
  104.12.0.20  104.13.3.105  0.00  0.40  60  100  0.09  28.98 
  104.0.200.6  104.0.200.5  0.00  1.00  0  100  0.99  1.01 
...

Um 18:36:09 verläuft die Route zur KV33 (104.0.200.5) plötzlich (zwei Sekunden zuvor war sie noch direkt) über NicoAPs Rundstrahler, obwohl der ETX-Wert dorthin 43.37 und der zwischen 104.0.200.6 und 104.0.200.5 1.28 war... ? Zwei Sekunden später dasselbe Bild, aber vier Sekunden später ist die Route zur KV33 wieder direkt.
Hat jemand eine Ahnung, was die Ursache sein könnte?
Ich dachte immer, ETX und LQ Werte ändern sich allmählich.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
ali



Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.

BeitragVerfasst am: 13.08.2006, 22:38    Titel: Antworten mit Zitat

Ich habe jetzt mal den olsrd mit Debuglevel 1 parallel zum Skript laufen lassen.
Die indirekte Route entsteht mit voller Absicht:
Code:

--- 19:58:14.25 ---------------------------------------------------- LINKS
IP address       hyst   LQ     lost   total  NLQ    ETX
104.13.3.105     0.000  0.420  58     100    0.169  14.12
104.0.200.5      0.000  1.000  0      100    1.000  1.00
...
--- 19:58:14.25 ------------------------------------------------ NEIGHBORS
IP address       LQ     NLQ    SYM   MPR   MPRS  will
104.0.200.1      0.420  0.169  YES   YES   YES   7
104.0.200.2      1.000  1.000  YES   YES   YES   7
(die 104.0.200.5  kommt hier nicht vor, aber olsrd weiß, daß die 200.2 ein Alias für die 200.5 ist)
...
(ioctl)Adding route with metric 2 to 104.0.200.5/255.255.255.255 via 104.13.3.105/eth1.
(ioctl)Adding route with metric 2 to 104.0.200.2/255.255.255.255 via 104.13.3.105/eth1.


Wer das ganze File sehen will: auf ScharpingAP in
Code:
/root/problem_route_to_kv33.tgz


EDIT: War ein Denkfehler, im olsr Log kommen anscheinend zuerst die ioctl, danach die Tabellen, also:
Code:

(ioctl)Adding route with metric 2 to 104.0.200.5/255.255.255.255 via 104.13.3.105/eth1.
(ioctl)Adding route with metric 2 to 104.0.200.2/255.255.255.255 via 104.13.3.105/eth1.
...
--- 19:58:18.98 ---------------------------------------------------- LINKS
IP address       hyst   LQ     lost   total  NLQ    ETX
104.0.200.5      0.000  1.000  0      100    0.000  0.00
...
--- 19:58:18.98 ------------------------------------------------ NEIGHBORS
IP address       LQ     NLQ    SYM   MPR   MPRS  will
104.0.200.1      0.440  0.157  YES   YES   YES   7
104.0.200.2      0.093  0.043  YES   YES   YES   7


Kurz zuvor hatten wir noch NLQ=1.00 (siehe oben). Wie kann das passieren?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
Beiträge der letzten Zeit anzeigen:   
Dieses Forum ist gesperrt, du kannst keine Beiträge editieren, schreiben oder beantworten.   Dieses Thema ist gesperrt, du kannst keine Beiträge editieren oder beantworten.    WLanhsh & WLanwse Foren-Übersicht -> WLanwse Alle Zeiten sind GMT + 2 Stunden
Gehe zu Seite 1, 2  Weiter
Seite 1 von 2

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.


Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de