|
|
|
 |
WLanhsh & WLanwse
Forum des WLan Hohenschönhausen und des WLan Weißensee
wlanhsh.freifunk.net
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
glockman
Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP
|
 Verfasst am: 07.08.2006, 15:36 Titel: 33<>scharping stottert |
 |
|
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 |
|
|
ali
Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.
|
| Verfasst am: 07.08.2006, 15:58 Titel: |
|
|
| 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 |
|
|
glockman
Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP
|
| Verfasst am: 07.08.2006, 16:09 Titel: |
|
|
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 |
|
|
ali
Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.
|
| Verfasst am: 07.08.2006, 22:22 Titel: |
|
|
| 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 |
|
|
ali
Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.
|
| Verfasst am: 07.08.2006, 23:01 Titel: |
|
|
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 |
|
|
ropf
Anmeldedatum: 25.04.2006
Beiträge: 582
|
| Verfasst am: 08.08.2006, 00:27 Titel: |
|
|
letzten Beitrag gelöscht - war Blödsinn
/ropf
_________________
jabber: ropf at dernico.no-ip.org |
|
| Nach oben |
|
|
glockman
Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP
|
| Verfasst am: 08.08.2006, 10:35 Titel: |
|
|
| 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 |
|
|
glockman
Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP
|
| Verfasst am: 09.08.2006, 16:09 Titel: |
|
|
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 |
|
|
glockman
Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP
|
| Verfasst am: 10.08.2006, 13:46 Titel: |
|
|
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 |
|
|
ali
Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.
|
| Verfasst am: 13.08.2006, 14:43 Titel: |
|
|
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 
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 |
|
|
ropf
Anmeldedatum: 25.04.2006
Beiträge: 582
|
| Verfasst am: 13.08.2006, 15:06 Titel: |
|
|
Bravo!
_________________
jabber: ropf at dernico.no-ip.org |
|
| Nach oben |
|
|
ali
Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.
|
| Verfasst am: 13.08.2006, 16:08 Titel: |
|
|
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 |
|
|
scharping
Anmeldedatum: 07.09.2005
Beiträge: 216
Wohnort: 13086 lehderstrasse 11 (104.12.0.20)
|
| Verfasst am: 13.08.2006, 16:43 Titel: |
|
|
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 |
|
|
ali
Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.
|
| Verfasst am: 13.08.2006, 19:26 Titel: |
|
|
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 |
|
|
ali
Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.
|
| Verfasst am: 13.08.2006, 22:38 Titel: |
|
|
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 |
|
|
|
|
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 |
| |
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
