|
|
Das Toturial ist nicht mehr aktuell bitte diesen Link benutzen um das aktuelle zu bekommen!
Toturial für die OLSR Firmware für den Asus Accesspointer.
So wies aussieht ist wohl die Betatesterei nun zu ende! Der 19.05.2005 war der U-Day! Also der berühmte umstellungs Tag. Im moment sind die AP's 6, 14, 15, 16, 20 und 38 mit der Firmware ausgestattet! Alle AP's von opennet müssen nun umgestellt werden!
Habe alles davon aus diesem Post. Wenn irgendwas falsch ist oder ihr ergänzungen habt einfach posten. Ich ändere es dann.
Ich übernehme keinerlei Verantwortung für das was hier im folgenden steht. Bitte überdenkt jede Aktion, die ihr macht selbst und macht mich bitte nicht verantwortlich. Ich sitz daran jetzt schon 2-3 Stunden und habe meinen AP mindestens 20 mal neu geflasht, weil das mit dem DHCP auf dem Lan nicht funzt. Und so wies aussieht auch bei der Firmware nicht vorgesehen ist. Das ganze ist auch noch nicht vollständig! Naja jetzt gehts los.
Also mal vorne weg alles was ihr dazu downloaden müsst ist:
OLSR Firmware
Firmware Restoration Tool von Asus
Putty
1. Wenn ihr eure alte Firmware für den Asus schon für opennet eingestellt habt, würde ich ein Reset durchführen, wenn ihr es nicht macht könnte es später Probleme geben euren AP im Lan wiederzufinden.
2. Beim AP Netzstecker ziehen, Resetknopf drücken und gedrückt halten, Netzstecker wieder einstöpzeln, Resetknopf loslassen wenn die Power LED blinkt. TCP/IP alles auf automatisch beziehen einstellen. 2 min warten. Dann Überprüfen ob die IP adresse eine 169.254.xx.xx Nummer ist. Wenn nicht dann start>ausführen>cmd>ipconfig /renew und 2 min warten.
3.Firmware Restoration Tool von Asus runterladen, entpacken, installieren, starten und bei durchsuchen die OLSR Firmware auswählen. Dann Hochladen(U), warten bis er fertig ist dann schließen. Danach noch mal den Netzstecker vom AP abziehen, kurz warten und wieder einstöpseln. (Sonst bekahm ich keine Verbindung zum AP.)
4.Gucken ob ihr jetzt eine 172.16.0.X Adresse bekommen habt sonst start>ausführen>cmd>ipconfig /renew und 2 min warten. Falls ihr keine bekommen solltet ihr TCP/IP manuell einstellen:
5.Putty öffnen, 172.16.0.1 und SSH eingeben, dann open. Als Benutzernamen root und als Passwort admin eingeben.
Dann das eingeben:
nvram set wl0_mode=sta
nvram set wl0_infra=0
nvram set wl0_channel=1
nvram set wl0_ssid=olsr.opennet-forum.de
nvram set wl0_wds=
nvram set wl0_lazywds=0
nvram set wl0_wep=on
nvram set wl0_wep_bit=128
nvram set wl0_key1=<on-key>
nvram set wl0_key2=<on-key>
nvram set wl0_key3=<on-key>
nvram set wl0_key4=<on-key>
nvram commit
Danach wieder schließen. <on-key> = der Schlüssel den ihr von opennet bekommen habt
(Komisch ohne das hab ich auf der HTML-Seite keinen zugriff)
6.Browser öffnen, 172.16.0.1, auf admin clicken, benutzer root; pass admin, dann auf wireless. (X Steht für die Zahl die ihr von Opennet bekommen habt)
Apply, restart, normaler restart
7.Um die Verbindung zu testen
start>ausführen>cmd
tracert 192.168.1.254
um die Anzahl der Hops zwischen euch und gateway zu zählen
ping 192.168.1.254 -n 1000
je nachdem wieviele Hops zwischen euch sind wird der Ping pro Hop im besten Fall um nur 2ms steigen
Beispiel:
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
|
tracert 192.168.1.254
Routenverfolgung zu 192.168.1.254 über maximal 30 Abschnitte
1 1 ms <1 ms <1 ms 172.16.0.1
2 3 ms 2 ms 2 ms 192.168.1.38
3 7 ms 4 ms 4 ms 192.168.1.15
4 8 ms 6 ms 8 ms 192.168.1.254
Ablaufverfolgung beendet. |
|
Ich zähle 2 Hobs (der erste und letzte zählt nicht da die Strecken über Lan gehen), dann sollte der durchschnittliche Perfekte Ping 4ms (2*2ms) zu 192.168.1.254 betragen. Falls die Werte irgend wo extrem höher sind also über 50 oder 100ms oder gar * (timeout) dann "hingt" bei dem AP eure Verbindung.
| code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
|
ping 192.168.1.254 -n 1000
Ping wird ausgeführt für 192.168.1.254 mit 32 Bytes Daten:
Antwort von 192.168.1.254: Bytes=32 Zeit=17ms TTL=61
Antwort von 192.168.1.254: Bytes=32 Zeit=5ms TTL=61
Antwort von 192.168.1.254: Bytes=32 Zeit=11ms TTL=61
Antwort von 192.168.1.254: Bytes=32 Zeit=4ms TTL=61
...
...
...
Ping-Statistik für 192.168.1.254:
Pakete: Gesendet = 1000, Empfangen = 829, Verloren = 171 (17% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 4ms, Maximum = 151ms, Mittelwert = 9ms
|
|
Am besten ist es natürlich wenn ihr 0% Packetloss und im meinen Fall einen Ping Mittelwert von 4ms habt Je mehr Packetloss ihr habt desto schlechter ist die Verbindung. Ich hab im durchschnitt ca. 17% Packetloss damit kann man schon surfen, aber manchemal muss man schon 2, 3 mal auf die Seite clicken bis sie sich öffnet. Je nachdem wann ihr am Tag das macht können die Werte varieieren und das surfen ist dann besser oder schlechter.
So das wars erst mal! Jetzt bitte alles Posten was falsch oder verändert werden sollte und das was ich noch vergessen hab.
Falls es zu Problemen kommen sollte:
Beim AP Netzstecker ziehen, Resetknopf drücken und gedrückt halten, Netzstecker wieder einstöpzeln, Resetknopf loslassen wenn die Power LED blinkt. TCP/IP alles auf automatisch beziehen einstellen. Dann Überprüfen ob die IP adresse eine 169.254.xx.xx Nummer ist. Wenn nicht dann start>ausführen>cmd>ipconfig /renew und 2 min warten.
Firmware Restoration Tool von Asus starten und bei durchsuchen die alte Firmware(WL500g-1.8.1.9.) (Datei muss noch entpackt werden) auswählen. Dann Hochladen(U), schließen.
Bei TCP/IP 192.168.1.215; 255.255.255.0 einstellen, dann im Browser 192.168.1.X oder 192.168.1.1 eingeben und hoffen das die Seite geöffnett wird. Wenn nicht das Prog Device Discovery öffnen (ist beim Asus prog dabei) und hoffen das das Prog den AP findet. Wenn ja die IP im browser eingeben und ein Frimware Reset durch führen (siehe Punkt 1).
Wenn das nicht hilft bei TCP/IP 192.168.2.215; 255.255.255.0 einstellen, dann im Browser 192.168.2.X oder 192.168.2.1 eingeben und hoffen das die Seite geöffnett wird. Wenn nicht das Prog Device Discovery öffnen und hoffen, dass das Prog den AP findet. Wenn ja die IP im browser eingeben und ein Frimware Reset durch führen (siehe Punkt 1). Wenn das nicht funzt siehts schlecht aus. Es hilft manchmal den PC neu zu starten oder einfach mal 1-2 min zu warten zwischen den Schritten. Falls es doch funzt was es bei mir zum glück jedesmal hat, dann könnt ihr ab jetzt wieder mit dem Toturial anfangen.
edit1: Post2
edit2+3: kleine Änderungen
edit4-6: IP änderungen + es funktioniert jetzt
edit7: nochmal etwas "vereinfacht"
edit8: U-DAY
edit9:AP's
edit10: 172.16.0.1
edit11: Punkt4 geändert
edit12+13: Verbindungstest, alte Firmware
__________________
Dieser Beitrag wurde 14 mal editiert, zum letzten Mal von Oconnor am 03.08.2005 14:38.
|
|
09.05.2005 18:04 |
|
|
|
|
Möglich, deaktiviert dann aber SNAT vom lan zum wlan; für die meisten end-user ist das eher nicht das Richtige. Ich gebe der firmware in ein par Tagen ein upgrade mit einem sinnvolleren default.
| Zitat: |
8.Putty starten, einloggen und das eingeben:
wl0_mode=sta
wl0_infra=0
wl0_channel=1
wl0_ssid=olsr.opennet-forum.de
wl0_wds=
wl0_lazywds=0
wl0_wep=on
wl0_wep_bit=128
wl0_key1=XXXXXXXXXXXXXXXXXXXXXXXXX
wl0_key2=XXXXXXXXXXXXXXXXXXXXXXXXX
wl0_key3=XXXXXXXXXXXXXXXXXXXXXXXXX
wl0_key4=XXXXXXXXXXXXXXXXXXXXXXXXX |
Nope. In c&p-Format ist das eher:
nvram set wl0_mode=sta
nvram set wl0_infra=0
nvram set wl0_channel=1
nvram set wl0_ssid=olsr.opennet-forum.de
nvram set wl0_wds=
nvram set wl0_lazywds=0
nvram set wl0_wep=on
nvram set wl0_wep_bit=128
nvram set wl0_key1=<on-key>
nvram set wl0_key2=<on-key>
nvram set wl0_key3=<on-key>
nvram set wl0_key4=<on-key>
nvram commit
Den Großteil davon sollte die firmware beim ersten boot des APs selbst setzen, die keys aber definitiv nicht. Ausserdem werden die geänderten settings erst nach einem ap-reboot genutzt.
| Zitat: |
| Wie funzt das mit dem DHCP auf Lan? |
Afaict mit dieser firmware gar nicht. Die aktuelle FFF scheint per default keinen funktionsbereiten dhcpd (eventuell hat busybox dafür benutzbaren code...) dabei zu haben (und ich habe für diese Version auch keinen dazugelegt); u.U. gibt es dafür ein separates Package. Ich schaue in ein par Tagen mal.
Grundsätzlich ist diese Version noch nicht für den Großteil der eigentlichen user ausgelegt, sondern für Feldtests bei experimentierfreudigen Einzelpersonen mit Erfahrung auf den relevanten Gebieten.
|
|
|
09.05.2005 18:34 |
|
|
thm
Administrator
 |
|
Warum überhaupt Managed Client - er sollte lieber im Ad-Hoc Mode sein!
|
|
|
11.05.2005 17:38 |
|
|
thm
Administrator
|
|
Jetzt hat er es geändert.
|
|
|
12.05.2005 08:30 |
|
|
Oconnor
Forenmitglied
Themenstarter 
|
|
Ja, ich wusste auch nicht so genau was dahin sollte. Dachte eigentlich, das sich der AP im AD-Hoc Modus so verhält wie 2 wlankarten, d.h. die übertragung ist unverschlüsselt und es können sich nur 2 verbinden und nicht mehr.
__________________
|
|
|
12.05.2005 11:12 |
|
|
thm
Administrator
|
|
Hallo,
damit NAT funktioniert müsste das LAN Interface (eth0 auf Asus) noch eine IP-Nummer außerhalb des Subnetzes für das WLAN bekommen.
Thomas
|
|
|
14.05.2005 08:38 |
|
|
Oconnor
Forenmitglied
Themenstarter
|
|
Mit ifconfig eth0 192.168.3.20 funzt das, aber nach einem neustart ist das wiederweg. Wenn ich es in den nvram reinschreibe mit:
nvram ifconfig eth0 192.168.3.20
nvram commit
passiert nix auch nach einem neustart nicht. Also wie kann man denn das dauerhaft dem Asus beibringen?
__________________
|
|
|
16.05.2005 23:51 |
|
|
|
|
| Zitat: |
| Mit ifconfig eth0 192.168.3.20 funzt das |
Nein, wird es nicht. Die IP ist Teil des 192.168.0.0/16 Netzwerks. Etwas aus einer ganz anderen privaten ip-range wäre dafür besser...z.B. 172.16.0.0/12 oder 10.0.0.0/8 (wir werden aber wohl Teile der letztgenannten für VPN-ips nutzen - das wäre daher auch nicht optimal).
| Zitat: |
| Also wie kann man denn das dauerhaft dem Asus beibringen? |
"nvram set lan_ipaddr=a.b.c.d ; nvram commit"
|
|
|
17.05.2005 00:06 |
|
|
|
|
| Zitat: |
| mit dem Befehl "nvram set lan_ipaddr ... " wird nicht die Schnittstelle eth0 verändert sondern br0. |
Die Variable konfiguriert das durch lan_ifname bestimmte interface. Normalerweise sollte das auf der Asus-hardware für diese firmware 'eth0' sein; 'br0' ginge wohl auch, dann sollte aber lan_ifnames (sic) nur 'eth0' sein - und die Nutzung der Bridge wäre in dem Fall sinnlos.
For the complete explanation see the OpenWrt wiki.
|
|
|
17.05.2005 01:54 |
|
|
Oconnor
Forenmitglied
Themenstarter
|
|
Ok, bei mir wars nicht eth0 sondern br0! Also müsste ich das so ins nvram schreiben:?
nvram set lan_ifname=eth0
nvram set lan_ipaddr=172.16.0.X
nvram commit
oder einfacher bei WAN (da eth0=Wan ist) auf der internen Webseite die IP Adresse 172.16.0.X eingeben?
Eins versteh ich jetzt aber noch nicht warum kann ich den AP jetzt nicht über Wan erreichen sondern immer nur noch über lan?
Ich dachte eigentlich wenn ich bei eth0 was verändere dann verändere ich alles was am Wan port hängt, bei eth1 alles was am Lan port und eth2 alles was wireless ist.
__________________
|
|
|
17.05.2005 15:40 |
|
|
|
|
| Zitat: |
Also müsste ich das so ins nvram schreiben:?
nvram set lan_ifname=eth0
nvram set lan_ipaddr=172.16.0.X
nvram commit |
Looks good.
| Zitat: |
| oder einfacher bei WAN (da eth0=Wan ist) auf der internen Webseite die IP Adresse 172.16.0.X eingeben? |
Du kannst es versuchen, aber empfehlen würde ich es nicht. Ein Teil des ff-codes geht davon aus, dass lan_* wirklich das LAN-if betrifft; ka was du eventuell für Probleme bekommst, wenn du versuchst, das umzubiegen.
| Zitat: |
| Ich dachte eigentlich wenn ich bei eth0 was verändere dann verändere ich alles was am Wan port hängt, bei eth1 alles was am Lan port |
Nope; wie auf http://openwrt.org/OpenWrtDocs/Configura...db0dd23a7b6acab beschrieben ist auf dem Asus wl-500g: LAN => eth0 ; WAN => eth1 ; WLAN => eth2.
|
|
|
17.05.2005 16:25 |
|
|
|
|
Ich hoffe mal mir ist das Thema nicht entgangen...
Da jetzt unser Zugang morgen umgestellt wird, sollten auch wir uns mal Gedanken machen...
Die Konfiguration des Linksys sollte eigentlich anhand des Asus Tuts machbar sein, jedoch wie sieht es mit der Firmware aus?
Hatte ebend mal im der Rubrik geschaut, aber nichts konkretes gefunden...
__________________
Ap 39
|
|
|
18.05.2005 20:46 |
|
|
|
|
Schreib meine Probleme wohl besser hier in den Thread.
Wenn ich meinen AP jetzt mit OriginalFirmware stehen habe und Stecker ziehe, Teset gedrückt halte, Stecker wieder rin ...
Dann bekomme ich keine Verbindung mehr, bzw. nur noch limeted. Er sendet, aber empfängt nischts. Sollte in dem Recovery Modus ja auch ok sein. Ich hab dann jedenfalls diese 169.254.xx.xx IP.
Dann ziehe ich mit dem Recoverytool die neue Software rauf und warte bis er fertig ist. Dann erzählt er ja immer, dass man warten soll, bis er neugestartet hat. Beim Flashen mit Asus-Firmware sehe ich das immer daran, dass die AIR-LED wieder blinkt. Bei dem neuen Zeug tut sich da aber gar nichts. WIe lange muss man da warten?
Wenn ich dann trotz aller widrigkeiten fortfahre, sehe ich schon, dass nicht wirklich VErbindung zwischen AP und PC besteht und das führt dann eben dazu, dass Putty einen Network Connection Error meldet.
Wo ist das Problem? Liegt es vielleicht daran dass ich einen Asus-Deluxe habe?
Bitte helft mir!
__________________
|
|
|
20.05.2005 17:55 |
|
|
Oconnor
Forenmitglied
Themenstarter
|
|
Ok deine neue Firmware ist drauf. Jetzt habe ich Punkt 4 verändern bekommst du nun eine 172.16.0.X IP zugewiesen? Wenn nicht würde ich von dem AP noch mal den Netzstecker ziehen, kurz warten und noch mal neu einstecken. Wenn nicht weis dir 172.16.0.X Nummer zu. Dann guck mal ob das Prog Device Discovery (von Asus) den AP findet.
Wenn du Putty startest musst auch SSH anclicken. Hast du mal versucht auf die Webseite vom AP zu kommen? entweder 172.16.0.1 dann muss deine LAn ip eine 172.16.0.X sein oder 192.168.0.1 dann muss deine LAN IP eine 192.168.0.X sein. Ich weis nicht ob diese Firmware Version für die Deluxe geht oder nicht. Vielleicht weis da ja sh01 bescheid.
__________________
|
|
|
20.05.2005 19:49 |
|
|
|
|
Mit der neuesten Version der Firmeware hat jetzt auch die Umstellung des Linksys ohne weiteres geklappt. Also: gute Arbeit!
Die Verbindung ist zwar nicht mehr so gut wie zuvor, aber das wird wohl andere Ursachen haben...
Jedoch nun doch noch eine Frage. Der DHCP funktioniert für's LAN wunderbar und sollte wohl auch für's WLAN ebenso funktionieren. Allerdings bekommen wir (Daniel (AP43) und ich) keine IP zugewiesen. Muss man dort irgendetwas besonderes beachten? Kann man nicht auch eine IP manuell zuweisen?
Es wäre schön wenn es so auch funktionieren würde, ansonsten müssen wir die APs wohl immer mit in den Garten nehmen...
Gruß,
Christian
__________________
Ap 39
|
|
|
20.05.2005 20:20 |
|
|
|
|
|
  |
|
