Probleme: Unterschied zwischen den Versionen

Aus Weimarnetz Wiki
Zur Navigation springen Zur Suche springen
K
Zeile 1: Zeile 1:
Auf dieser Seite werden Probleme mit dem Wireless (sowie deren Lösung) dokumentiert. '''Vor dem Eintragen neuer Probleme bitte unbedingt [[Hilfe:Probleme_melden]] lesen!'''
+
Auf dieser Seite werden Probleme mit dem Wireless (sowie deren ) dokumentiert. '''Vor dem Eintragen neuer Probleme bitte unbedingt [[Hilfe:Probleme_melden]] lesen!'''
  
 
===Staendiger Wechsel des gewaehlten Internet-Zugangs, Verbindungsabbrueche===
 
===Staendiger Wechsel des gewaehlten Internet-Zugangs, Verbindungsabbrueche===
Zeile 11: Zeile 11:
 
'''technische Infos'''
 
'''technische Infos'''
 
:Dieses Verhalten ist fast eine Art grundsaetzliches Problem von OLSR. Zwar ist das wechseln von Routen im Internet vorgesehen,aber nicht wenn zwischendurch geNATet wird. (DSL-Zugang) Vorhandene Verbindungen muessten gehalten oder beim Wechsel am neuen Gateway "angemeldet" werden.  
 
:Dieses Verhalten ist fast eine Art grundsaetzliches Problem von OLSR. Zwar ist das wechseln von Routen im Internet vorgesehen,aber nicht wenn zwischendurch geNATet wird. (DSL-Zugang) Vorhandene Verbindungen muessten gehalten oder beim Wechsel am neuen Gateway "angemeldet" werden.  
'''Lösung?'''
+
'''?'''
*Workaround-1: analog zu 0. linkqualitäten (bewertung nicht die quali an sich) zu nicht bevorzugten verbindung künstlich verschlechtern, das gibt die neue 1.0.2 firmware her. siehe [[wechselnderdslzugang]]  
+
*Workaround-1: analog zu 0. (bewertung nicht die quali an sich) zu nicht bevorzugten verbindung verschlechtern, das gibt die neue 1.0.2 firmware her. siehe [[wechselnderdslzugang]]  
 
*Workaround0: Linkqualitaeten zur bevorzugten Verbindung deutlich verbessern. -  richtantennen  
 
*Workaround0: Linkqualitaeten zur bevorzugten Verbindung deutlich verbessern. -  richtantennen  
 
*Workaround1: unerwuenschten Knoten auf dem WEB-Interface unter OLSR/OLSR-Filter eintragen.  
 
*Workaround1: unerwuenschten Knoten auf dem WEB-Interface unter OLSR/OLSR-Filter eintragen.  
Zeile 22: Zeile 22:
 
**Nachteil: hoher Konfigurationsaufwand auf beiden Seiten. 8-)
 
**Nachteil: hoher Konfigurationsaufwand auf beiden Seiten. 8-)
 
**Nachteil2: die dynamik des routings geht verloren, bei ausfall des benutzten dslers muss ein neuer vpn tunnel benutz werden - handarbeit
 
**Nachteil2: die dynamik des routings geht verloren, bei ausfall des benutzten dslers muss ein neuer vpn tunnel benutz werden - handarbeit
*Workaround4: LQ- Window size vergrössern
+
*Workaround4: LQ- Window size
 
**Vorteil: ein paar wenige verlorene packete haben einen nicht so grossen einfluss auf die linkquali -> routen werden stabiler  
 
**Vorteil: ein paar wenige verlorene packete haben einen nicht so grossen einfluss auf die linkquali -> routen werden stabiler  
**Nachteil: tote links bleiben dadurch auch länger in der routingtabelle -> gibt es so oft tote links?
+
**Nachteil: tote links bleiben dadurch auch in der routingtabelle -> gibt es so oft tote links?
  
 
===Ebay und Onlinebanking/https geht nicht===
 
===Ebay und Onlinebanking/https geht nicht===
 
'''Status'''
 
'''Status'''
: Das Problem ist in der Budapesterstr. gel�st auf Nodes anderer Nutzer des WN ist es nur teilweise gel�st.
+
: Das Problem ist in der Budapesterstr. auf Nodes anderer Nutzer des WN ist es nur teilweise .
  
  
 
:Hay hier ist mein Beitrag zum Problem!!!     
 
:Hay hier ist mein Beitrag zum Problem!!!     
:Habe das Problem wie folgt gel�st: Als erstes habe ich meine Einstellung wie Christian empfohlen auf MTU 1400 eingestellt. als n�chstes habe ich meinen Netzknoten auf 172.16.6.8 eingestellt resultat gleich null. (no connect)
+
:Habe das Problem wie folgt : Als erstes habe ich meine Einstellung wie Christian empfohlen auf MTU 1400 eingestellt. als habe ich meinen Netzknoten auf 172.16.6.8 eingestellt resultat gleich null. (no connect)
kurzer R�ckruf bei Christian MTU auf 1500 resultat gleich null. (no connect)
+
kurzer bei Christian MTU auf 1500 resultat gleich null. (no connect)
Die Ratschl�ge Christian waren zwar sehr interessant aber blieben ohne Erfolg
+
Die Christian waren zwar sehr interessant aber blieben ohne Erfolg
:Habe nach der ganzen Aktion meine Einstellungen wie folgt belassen: MTU 1492,  RTS 500, IP:172.16.4.8  habe mein Node danach am gleichen Tag aus gemacht und am n�chsten Tag wieder eingeschaltet und habe nocheinmal versucht bei Ebay rein zu kommen. Und siehe da eine Selbstheilung hat den erfolg �ber Nacht gebracht.
+
:Habe nach der ganzen Aktion meine Einstellungen wie folgt belassen: MTU 1492,  RTS 500, IP:172.16.4.8  habe mein Node danach am gleichen Tag aus gemacht und am Tag wieder eingeschaltet und habe nocheinmal versucht bei Ebay rein zu kommen. Und siehe da eine Selbstheilung hat den erfolg Nacht gebracht.
  
 
'''technische Infos'''
 
'''technische Infos'''
Zeile 42: Zeile 42:
  
 
'''Beschreibung'''
 
'''Beschreibung'''
:Vom Internet-Einwahlpunkt weit entfernte Knoten koennen nicht auf Ebay drauf bzw. koennen keinerlei per HTTPS verschl�sselte WEB-Seiten aufrufen.
+
:Vom Internet-Einwahlpunkt weit entfernte Knoten koennen nicht auf Ebay drauf bzw. koennen keinerlei per HTTPS WEB-Seiten aufrufen.
 
'''Submitter'''
 
'''Submitter'''
 
:[[Benutzer:Fries43|fries43]] 21:45, 24. Jul 2005 (CEST)
 
:[[Benutzer:Fries43|fries43]] 21:45, 24. Jul 2005 (CEST)
Zeile 48: Zeile 48:
 
:hab das problem reproduziert. siehe: '''[[mtu_prob]]'''
 
:hab das problem reproduziert. siehe: '''[[mtu_prob]]'''
 
:[[Benutzer:Storchi|Storchi]] 17:05, 18. Aug 2005 (CEST)
 
:[[Benutzer:Storchi|Storchi]] 17:05, 18. Aug 2005 (CEST)
'''L�sung?'''
+
'''?'''
 
:Ich glaube das haengt irgendwie mit den MTU-Einstellungen zusammen. Original-Wert 1500. Telekom-ADSL brauch irgendwie 1492
 
:Ich glaube das haengt irgendwie mit den MTU-Einstellungen zusammen. Original-Wert 1500. Telekom-ADSL brauch irgendwie 1492
 
::Auch das aendern der MTU auf dem Linksys des betroffenen Netzknotens bringt keinen Erfolg. Konkret: Liszt18<->Budapester8
 
::Auch das aendern der MTU auf dem Linksys des betroffenen Netzknotens bringt keinen Erfolg. Konkret: Liszt18<->Budapester8
 
:
 
:
  
===WEP-Verschlüsselung unter MacOSX/Nokia Communicator funktioniert nicht===
+
===WEP-unter MacOSX/Nokia Communicator funktioniert nicht===
 
'''Status'''
 
'''Status'''
 
:Geloest!
 
:Geloest!
 
'''Beschreibung'''
 
'''Beschreibung'''
:Wenn versucht wird sich mit dem weimarnetz.de zu verbinden, fragt MacOSX nach dem WEP-Schlüssel. Nachdem dieser eingegeben ist, wird zwar angezeigt das eine Verbindung zum Netz besteht, allerdings ist kein ping oder sonstiger Netzverkehr möglich. Dabei ist es egal ob der WEP-Schlüssel als Passphrase (ascii-text) oder 26-Stellen HEX eingegeben wird.
+
:Wenn versucht wird sich mit dem weimarnetz.de zu verbinden, fragt MacOSX nach dem WEP-. Nachdem dieser eingegeben ist, wird zwar angezeigt das eine Verbindung zum Netz besteht, allerdings ist kein ping oder sonstiger Netzverkehr . Dabei ist es egal ob der WEP-als Passphrase (ascii-text) oder 26-Stellen HEX eingegeben wird.
 
'''Submitter'''
 
'''Submitter'''
 
:[[Benutzer:Lars|Lars]] 14:37, 11. Mai 2005 (CEST)
 
:[[Benutzer:Lars|Lars]] 14:37, 11. Mai 2005 (CEST)
 
'''technische Infos'''
 
'''technische Infos'''
 
:Mac OS X 10.2, Powerbook G4
 
:Mac OS X 10.2, Powerbook G4
'''Lösung'''
+
''''''
 
:Den ersten WEP-Key vom Linksys als "WEP 40/128-Bit Hex" eingeben.
 
:Den ersten WEP-Key vom Linksys als "WEP 40/128-Bit Hex" eingeben.
 
:In der ESSID darf KEIN "-" oder komische Zeichen vorkommen.
 
:In der ESSID darf KEIN "-" oder komische Zeichen vorkommen.
'''2. Lösung'''
+
'''2. '''
:Wer einen Nokia Communicator 9500 oder 9300 hat, wird dieses Problem mit den Sonderzeichen los, wenn er das neue Nokia update was seit 03.06.2005 als Version 05.22(01) RA-2 in einem Service Point (bsp.:Erfurt) updaten lässt.
+
:Wer einen Nokia Communicator 9500 oder 9300 hat, wird dieses Problem mit den Sonderzeichen los, wenn er das neue Nokia update was seit 03.06.2005 als Version 05.22(01) RA-2 in einem Service Point (bsp.:Erfurt) updaten .
  
Beim Nokia Communicator 9500 gibt es unter Systemsteuerung/Verbindungen/WLAN-Option/Verbindung/ einen punkt an der rechten Seite da steht erweiterte Optionen dort kann man einstellen die RTS -Schwelle auf 500 eingestellt läuft der 9500 im Weimarnetz viel besser.  
+
Beim Nokia Communicator 9500 gibt es unter Systemsteuerung/Verbindungen/WLAN-Option/Verbindung/ einen punkt an der rechten Seite da steht erweiterte Optionen dort kann man einstellen die RTS -Schwelle auf 500 eingestellt der 9500 im Weimarnetz viel besser.  
  
 
MfG Jens M 18 Aug. 2005
 
MfG Jens M 18 Aug. 2005
  
===fall back des netzes auf 802.11b übertragungsraten - 11mbit problem ===
+
===fall back des netzes auf 802.11b - 11mbit problem ===
 
'''Status'''
 
'''Status'''
 
:offen
 
:offen
 
'''Beschreibung'''
 
'''Beschreibung'''
:nach tagen oder wochen mit 802.11g -raten (bis 54 mbit) entschliesst sich das netz auf b raten zurückzugehen
+
:nach tagen oder wochen mit 802.11g -raten (bis 54 mbit) entschliesst sich das netz auf b raten
 
'''Submitter'''
 
'''Submitter'''
 
:storch - muentzer 24 - weimarnetz.de auf 11 mbit
 
:storch - muentzer 24 - weimarnetz.de auf 11 mbit
 
'''technische Infos'''
 
'''technische Infos'''
:b und g netze senden zwar auf den gleichen frequenzen aber in verschieden modulationen(sprachen), auf deutsch: ein g node kann den verkehr der b-nodes hören, ein b node hört nur b - verkehr und der g verkehr wird als rauschen (noise) interpretiert. weiterhin muss man wissen das die luft ein sogenanntes shared medium ist, d.h. es kann zur gleichen zeit nur einer senden. da die b-nodes den g-verkehr nicht mitbekommen senden sie zur falschen zeit -> es kommt zu kollisionen -> daten müssen en: um kollisionen zu vermeiden werden alle nodes auf b-raten gesenkt -> kein kollisionen mehr und diese "lösung" wird über sogenannte beacons propagiert. diese beacons werden im netz verteilt und ein node mit richtigen einstellungen der zurück ins netz geht erhält die falschen raten(11 mbit)     
+
:b und g netze senden zwar auf den gleichen frequenzen aber in verschieden modulationen(sprachen), auf deutsch: ein g node kann den verkehr der b-nodes , ein b node nur b - verkehr und der g verkehr wird als rauschen (noise) interpretiert. weiterhin muss man wissen das die luft ein sogenanntes shared medium ist, d.h. es kann zur gleichen zeit nur einer senden. da die b-nodes den g-verkehr nicht mitbekommen senden sie zur falschen zeit -> es kommt zu kollisionen -> daten Ÿen: um kollisionen zu vermeiden werden alle nodes auf b-raten gesenkt -> kein kollisionen mehr und diese "" wird sogenannte beacons propagiert. diese beacons werden im netz verteilt und ein node mit richtigen einstellungen der ins netz geht die falschen raten(11 mbit)     
'''Lösung?'''
+
'''?'''
:rts/cts einschalten (mit entsprechender rts -schwelle von 500), das sollte bewirken dass g-nodes vor dem senden ein von b-nodes zu verstehendes signal senden, dass die anderen nodes davon abhält das medium zu besetzen -> keine kollisionen mehr. wie es zur zeit ausschaut entschliesst sich das netz nicht von alleine auf g-raten zurück zu wechseln -> wir müssen es zwingen
+
:rts/cts einschalten (mit entsprechender rts -schwelle von 500), das sollte bewirken dass g-nodes vor dem senden ein von b-nodes zu verstehendes signal senden, dass die anderen nodes davon das medium zu besetzen -> keine kollisionen mehr. wie es zur zeit ausschaut entschliesst sich das netz nicht von alleine auf g-raten zu wechseln -> wir es zwingen
ebenso müssen alle anderen g geräte wie laptops etc den rts mechanismus benutzen
+
ebenso alle anderen g wie laptops etc den rts mechanismus benutzen

Version vom 27. September 2005, 15:03 Uhr