OpenWRT auf dem "Horst" der HorstBox

jumptonjoy

Neuer User
Mitglied seit
12 Sep 2008
Beiträge
19
Punkte für Reaktionen
0
Punkte
0
Hallo,

gibt es hier noch jemanden der OpenWRT auf der Horst zu laufen gebracht hat?

Ich arbeite schon seit ein paar Wochen dran und könnte ein bisschien Hilfe gebrauchen.

Es wäre nett wenn jemand mal ein paar Tips für mich hat.
 
Config_mtd_redboot_directory_block = 127

Jau, mehr oder weniger erfolgreich kämpfe ich mich seit zwei Wochen millimeterweise durch Herta und Horst.

Inzwischen läuft mit OpenWrt auf Herta (MIPS-Prozessor TI-AR7 im LSB/Little-Endian-Modus):
  • Ok: Flashspeicher
  • Ok: Serielle Konsole (0/3.3V-Pegel) mit umgebautem Handy/USB-Kabel.
  • Ok: Ethernet
  • Ok: Ethernet-Switch (braucht keine Treiber, außer wenn man seine Zusatzfeatures benutzen will; siehe Datenblatt)
  • Ok: ADSL2+-Modem. Da lassen sich jetzt zwei PPPoE-Verbindungen zu meinem Provider aufbauen: VCI 1/32 für normales Internet und VCI 1/35 für bevorzugten VoIP-Verkehr.
  • Nein: WLAN. Da gabs wohl ein Gezerre, ob der ACX111-WLAN-Treiber offiziell in den Kernel kommt. Habs in der Kürze mit dem Treiber bei OpenWrt nicht hingekriegt. Aber die scheiben auch, dass er fehlerhaft sei.
  • Nein: Leuchtdiodenansteuerung (ist wohl das GPIO-Gedöhns). Habs nicht untersucht.
  • Nein: Resettaster (der Taster auf Horst ist wohl tatsächlich an Herta ansgeschlossen). Habs nicht untersucht.

Und auf Horst (ARM-Prozessor IXP425, MSB/Big-Endian-Modus):
  • Ok: Flashspeicher
  • Ok: Serielle Konsole (<-3/>+3V-Pegel) mit umgebautem PC-Seriellanschluss-Flachbandkabel.
  • Nein: Ethernet
  • Nein: ISDN. Habs noch nicht untersucht.
  • Nein: Telefonanschlüsse FXO und FXS. Habs nicht untersucht.
  • Nein: Leuchtdiodenansteuerung (ist wohl das GPIO-Gedöhns). Habs nicht untersucht.

Besondere Schwierigkeiten bisher:
  • Konsolkabel an Horst. Bis ich da die richtige Verdrahtung herausgefunden hatte, war der serielle Anschluss an der Dockingstation abgeraucht.
  • Nochmals Konsolkabel an Horst. Mein schrottiges Nullmodemkabel funktioniert nur bis 57600bps halbwegs ok. RedBoot und OpenWrt mussten zu der niedrigen Geschwindigkeit überredet werden.
  • An Ethernet auf Horst bin ich grad dran. OpenWrt will unbedingt Phy5 und Phy4 verwenden (was immer das auch genau ist), wobei der RedBoot-Lader allerdings was von Phy1 meldet.

Spezielle Verweise:
  • Flashen von Herta: hier. Da wirt eine kombiniertes zImage/rootfs-Datei geflashed. Herta ist effektiv ein DLINK DSL-G684T (Annex B) was fast dasselbe ist wie ein DSL-G624T (ADSL Annex A).
  • Flashen eines neuen RedBoot-Loaders bei Horst, der TFTP übers Ethernet kann: hier.
  • Flashen von zImage- und squashfs-Partitionen bei Horst ungefähr so wie hier beschrieben.
  • Redboot-Kommandozeile zum Starten des Openwrt-Kernels:
    exec -c "init=/etc/preinit rootfstype=squashfs root=/dev/mtdblock3 console=ttyS0,57600n8"
    Oder aber bei den MTD-Parametern die Option angeben(geht bei OpenWrt mit "make kernel_menuconfig"), dass er eine Flash-Partition "rootfs" suchen und als Wurzel mounten soll. Dieser Punkt wird allerdings erst dann angeboten, wenn OpenWrt einmal durchkompiliert worden ist. Dann später aber beim Flashen mittels dem RedBoot/FIS-Kommandos die Squashfs-Partition bitte "rootfs" nennen. Dann gehts bei mir mit:
    exec -c "init=/etc/preinit rootfstype=squashfs console=ttyS0,57600n8"
    Wer die Standardgeschwindigleit 115200kbps verwenden kann, läßt natürlich das "console=ttyS0,57600n8" weg.
  • Achja, ganz Wichtig: damit der OpenWrt-Kernel die RedBoot-Partitionstabelle im Flash findet, musste ich bei OpenWrt nach dem "make menuconfig" nochmals "make kernel_menuconfig" aufrufen. Dann beim MTD-Parameter
    Code:
    Drivers
      Memory Technology Device (MTD) support
        MTD partitioning support 
          RedBoot partition table parsing
            Location of RedBoot partition table
    den Wert 127 angeben. Das hab ich übrigens aus der Horstbox-Entwicklungsumgebung von D-Link abgeschaut. Hier findet sich auch nach dem ersten Durchkompilieren der oben erwähnte Punkt "Automatically set 'rootfs' partition to be root filesystem".
 
Zuletzt bearbeitet:
Na Klasse!
Es gibt doch noch jemanden der an den Thema arbeitet.

OpenWRT auf der Herta läuft bei mir inzwischen. Wlan funktionier auch fast. DSL hab ich nocht nicht getestet.
Ein HowTo für die Herta bin ich grad noch am verfassen.


Nur beim Horst habe ich noch ein kleines Problem.

Die Horstbox Bootet zwar vollständig allerdings kann ich nicht aufs main-fs schreiben. Klappt das bei dir?
Netzwerk funktioniert bei mir auch soweit. Allerdings nur mit der Version 7.09.
Welche versionen verwendest du denn?
 
> Es gibt doch noch jemanden der an den Thema arbeitet.
Leider muss ich da jetzt etwas kürzer treten. Das richtige Leben kommt mit seinen Anforderungen...

> Wlan funktionier auch fast.
Benutzt Du den ACX-Treiber von OpenWrt? Bei mir hat der zwar die Karte erkannt und ich konnte das wlan hochfahren, aber irgendwie schafft er es nicht, eine Verbindung aufzubauen.

> Ein HowTo für die Herta bin ich grad noch am verfassen.
Super.

> Die Horstbox bootet zwar vollständig allerdings kann ich nicht aufs main-fs schreiben.
Hmm, falls bei Dir das main-fs vom Typ SquashFs ist: SquashFs ist wohl grundsätzlich ein Readonly-Dateisystem.

Also OpenWrt richtet bei mir nach dem Flashen beim ersten Starten automatisch ein neues leeres JFFS2-Dateisystem ein; ich glaub in den freien Platz in der rootfs-Partition (Du nennst die wohl main-fs) hinter dem darin befindlichen SquashFs. Das SquashFs wird dann über ein virtuelles Dateisystem "mini_fo" überlagert mit dem JFFS2. Schreiboperationen gehen dann automatisch nach JFFS2; das funktioniert ähnlich wie bei Knoppix.

Ich hab dann also folgende gemountete Dateisysteme:
Code:
root@OpenWrt:/# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root /rom squashfs ro 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev 0 0
tmpfs /dev tmpfs rw 0 0
devpts /dev/pts devpts rw,mode=600 0 0
/dev/mtdblock4 /jffs jffs2 rw 0 0
mini_fo:/jffs / mini_fo rw 0 0

Das ursprüngliche RootFs (SqashFS) läßt sich damit über /rom ansprechen. Auf das beschreibbare JFFS2 komme ich direkt mit /jffs, und die Wurzel / selbst ist die mini_fo-Zusammenführung von beiden. Schlau gemach von den OpenWrt-Leuten!

Wenn SqashFs-Dateien gelöscht werden, dann werden die nicht wirklich gelöscht, sonder das mini_fo legt im JFFS2 im entsprechenden Ordner eine Textdatei META_dAfFgHE39ktF3HD2sr an, in welcher die Namen der als gelöscht anzusehenden SuqashFs-Dateien stehen.

Dieses Einrichten von/Schreiben ins JFFS2 und auch das Anlegen und Löschen von Dateien durch mich hat geklappt.

Ich habe den Eindruck (i.e. noch nicht genauer untersucht), dass die RedBoot-Flash-Partitionen mit fester Größe an fester Stelle stehen. Und dass die Linux-Kernel Partition (mtd3) viel größer ist, als sie sein müsste. Wenn man die Kernel-Partition verkleiner (geht das mit RedBoot?) und dafuer die Rootfs-Partition vergrößert, dann hat man später ein größeres JFFS2.

> Netzwerk funktioniert bei mir auch soweit. Allerdings nur mit der Version 7.09.
Automatisch erkannt? Musstest Du irgendwas machen?

> Welche versionen verwendest du denn?
Bleeding Edge aus dem SVN. Das war jetzt "Kamikaze (r13186)"
 
Sobald OpenWRT auf der Herta läuft sag ich bescheid.

Welchen Imagetyp und welches Image benutzt du denn vom OpenWRT?
Das erzeugen des jffs und des mini_fo macht er aus irgendeinen Grund nicht.

Netzwerk funktioniert auch nur mit der 7.09. Ich habs auch mal mit 8.09_rc1 probiert aber das hatte nicht funktioniert. Ich denke mal, dass liegt daran das im SVN und in der 8.09 der Intel Sourcecode nicht verwendet wird.
Wenn ich die 7.09 compilieren will, verlangt er den Download von der Intel Seite.
 
Zuletzt bearbeitet:
Welchen Imagetyp und welches Image benutzt du denn vom OpenWRT?
kernel: openwrt-ixp4xx-zImage
rootfs: openwrt-ixp4xx-squashfs.img

Aber ich glaube, openwrt-ixp425-Image hat auch schon bei mir funktioniert. Die Horst-CPU ist wohl sogar eine ixp425.

Zum Flashen des Kernels und des Root-Fs verwende ich:
Code:
load -r -b %{FREEMEMLO} -h 192.168.0.x openwrt-ixp4xx-zImage
fis create linux
load -r -b %{FREEMEMLO} -h 192.168.0.x openwrt-ixp4xx-squashfs.img
fis create rootfs

Anschließend sieht das RedBoot-Partitionlayout so aus:
Code:
RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
<Not a string: 0x3FFF300>                 0x28011301  0x00696E66  0x6F5F636F  0x6E736F6C
RedBoot           0x50000000  0x0013A400  0x00080000  0x0013A400
nvram             0x50080000  0x50080000  0x00040000  0xFFFFFFFF
linux             0x500C0000  0x00026400  0x00100000  0x00026400
rootfs            0x501C0000  0x00026400  0x000E0000  0x00026400
update-fs         0x50EC0000  0x50EC0000  0x00100000  0xFFFFFFFF
RedBoot config    0x50FC0000  0x50FC0000  0x00001000  0x00000000
FIS directory     0x50FE0000  0x50FE0000  0x00020000  0x00000000
                  0x5F736372  0x69707400  0x00000000  0x0411010C
RedBoot>
 
Bie mir lief bis jetzt immer nur das avila image.
Ich werde heute abend aber mal deine Vorschläge umsetzen und dann mal berichten.
 
Ich habe den Eindruck (i.e. noch nicht genauer untersucht), dass die RedBoot-Flash-Partitionen mit fester Größe an fester Stelle stehen. Und dass die Linux-Kernel Partition (mtd3) viel größer ist, als sie sein müsste. Wenn man die Kernel-Partition verkleiner (geht das mit RedBoot?) und dafuer die Rootfs-Partition vergrößert, dann hat man später ein größeres JFFS2.

Falscher Eindruck. Der RedBoot/Fis legt doch die Partitionen dynamisch an. Es geht nix verloren.
 
Ethernet funzt

Auf die Kernelparameterzeile zum Booten des Openwrt-Kernels bei Horst muss noch "init=/etc/preinit" rauf. Sorry, das muss ich bei meinem ersten Posting verschwitzt haben (ist inzwischen dort korrigiert)

Und Ethernet tutet jetzt auch, nachdem ich über diverse Forenbeiträge hier und bei OpenWrt gerätselt hatte, habe ich jetzt mal aufs Geratewohl mein Glück versucht.

In Datei build_dir/linux-ixp4xx_generic/linux-2.6.27/arch/arm/mach-ixp4xx/coyote-setup.c
Code:
static struct eth_plat_info ixdpg425_plat_eth[] = {
        {
                .phy            = 5,  // Hier 1 draus machen
                .rxq            = 3,
                .txreadyq       = 20,
        }, {
                .phy            = 4,  // Hier 0 draus machen
                .rxq            = 4,
                .txreadyq       = 21,
        }
};

Ne 5 zu 'ner 1 und ne 4 zu 'ner 0 bewirkt Wunder.
 
Das hört sich ja ganz gut an.

Ich hab gestern abend leider nicht so viel geschafft.

Bei der Herta hab ich nur festgestellt das ich mich zwar per WLAN verbinden kann (erstmal ohne verschlüsselung) ich allerdings keine Paket ins normale Netz bekommen. Ich bekommen zwar eine IP von meinen DHCP Server (also muss zumindestens UDP Broadcast Pakete durchgehen) aber das wars. Auch ein Ping auf die Herta selbst funktioniert zwar aber nur mit viel Paketverlusst.
Da muss ich wohl nochmal ein tcpdump dazu machen...

Das man im build_dir Patchen muss ist ja nicht so toll. Irgendwo vorher muss ja diese option definiert sein.

Per grep findet man folgende Datei:

target/linux/ixp4xx/patches-2.6.26/170-ixdpg425_mac_plat_info.patch

Hier stehen diese Informationen drin:
Code:
+/* Built-in 10/100 Ethernet MAC interfaces */
+static struct eth_plat_info ixdpg425_plat_eth[] = {
+        {
+                .phy            = 5,
+                .rxq            = 3,
+                .txreadyq       = 20,
+        }, {
+                .phy            = 4,
+                .rxq            = 4,
+                .txreadyq       = 21,
+        }
+};

Ich denke mal es reicht volkommen aus diesen Patch einfach zu löschen.

Dieser Patch ist in der 7.09er Version noch nicht enthalten.

Gruß

PS: Wie in den Patch zu sehen ist trifft das nur auf die ixdpg425 Prozessoren zu. Und genau diesen Prozessor hat die Horstbox.
 
Zuletzt bearbeitet:
IMHO gab es (als ich mir das zuletzt angeschaut habe) keinen Code, der den Switch auf Herta ansteuern konnte. Somit war zwar OpenWRT auf Herta möglich, aber keine Kommunikation mit Horst.
 
Ich denk mal nicht das es etwas mit den Switch auf der Herta zu tun hat.
Auf die Horstbox komm ich ja auch (hat eine IP im selben Netz bekommen, also kein NAT mehr).

Was mir aber aufgefallen ist, ist das wlan0 und br0 die selbe MAC-Adresse haben. Bei der original Herta ist das nicht der Fall.
 
komisch...

Bevor ich WLAN aktiviere habe ich folgende Mac Adresse:

Code:
br-lan    Link encap:Ethernet  HWaddr 00:17:9A:13:1E:EB
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:416 errors:0 dropped:0 overruns:0 frame:0
          TX packets:339 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:49418 (48.2 KiB)  TX bytes:99074 (96.7 KiB)

eth0      Link encap:Ethernet  HWaddr 00:17:9A:13:1E:EB
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:416 errors:0 dropped:0 overruns:0 frame:0
          TX packets:339 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:55242 (53.9 KiB)  TX bytes:99074 (96.7 KiB)
          Interrupt:41

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Danach sieht es dann so aus

Code:
br-lan    Link encap:Ethernet  HWaddr 00:17:9A:10:D7:15
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3206 (3.1 KiB)  TX bytes:7650 (7.4 KiB)

eth0      Link encap:Ethernet  HWaddr 00:17:9A:13:1E:EB
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1679 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1540 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:164176 (160.3 KiB)  TX bytes:313992 (306.6 KiB)
          Interrupt:41

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
wlan0     Link encap:Ethernet  HWaddr 00:17:9A:10:D7:15
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:80
 
In meinem Verständnis ist eine Bridge von der Funktionalität her dasselbe wie ein Switch und braucht eigentlich keine eigene MAC-Adresse.

Aussnahme: wenn Bridge/Switch sich von Aussen her über irgendwelche Protokolle speziell konfigurieren lassen sollen (z.B. VLAN-Port-Zuweisungen, QoS/Priorisierung).

Habs ausgetestet: sowohl Win-XP als auch Linux behandeln eine Bridge jedoch wie ein Netzwerkinterface, mit einer MAC-Adresse.

Auch ausgetestet: bei Linux sind die beteilgten "überbrückten" Interfaces selbst nicht mehr konfigurierbar (z.B. IP-Adresszuweisung mittels ifconfig). Und die Bridge bekommt immer die MAC-Adresse des jeweils letzten zu ihr hinzugefügten Interfaces.
 
IMHO gab es (als ich mir das zuletzt angeschaut habe) keinen Code, der den Switch auf Herta ansteuern konnte. Somit war zwar OpenWRT auf Herta möglich, aber keine Kommunikation mit Horst.

Ich denk mal nicht das es etwas mit den Switch auf der Herta zu tun hat.

Ja, ich hab auf beiden jetzt OpenWrt laufen, und da komm ich munter vom einem zum anderen, und natürlich auch rein und raus über die blauen Ethernetbuchsen.

Ich vermute mal, dass so ein Switch-Baustein einen Standardmodus hat, in dem er einfach läuft. Nur wenn man seine eingebauten Zusatzfeatures nutzen will, müssen die eingestellt werden über irgendeine Schnittstelle, welche einen Treiber erfordert. Siehe hier für Beispiele, was es da gibt.
 
Ja, ich hab auf beiden jetzt OpenWrt laufen, und da komm ich munter vom einem zum anderen, und natürlich auch rein und raus über die blauen Ethernetbuchsen.

Ich vermute mal, dass so ein Switch-Baustein einen Standardmodus hat, in dem er einfach läuft. Nur wenn man seine eingebauten Zusatzfeatures nutzen will, müssen die eingestellt werden über irgendeine Schnittstelle, welche einen Treiber erfordert. Siehe hier für Beispiele, was es da gibt.

Genauso sehe ich das auch.
Das komische ist ja auch, dass ein Teil von Paketen durchgehen.
Ich werde das nochmal genauer analysieren.


Bei der Horst hab ich auch eine Lösung für mein Problem mit der schreibbaren Root Partition gefunden.

Original auf der Horstbox hat die Root Partition den namen "main-fs". Damit kann OpenWRT leider nichts anfangen. Nennt man diese Partition in "rootfs" um dann funktioniert es auf einmal.
 
Hi jumptonjoy

Das passiert bei anderen Installatinen mit OpenWRT auch.
Dies liegt an der Verteilung der Ports bzw. Erkennung von OpenWRT.
Da vertauscht OpenWRT schon gerne mal WAN,LAN und DMZ auf einem Router.

Das Gleiche sollte es auch hier sein. Das kann man aber im NVRam einstellen. Dann sollten die Ports nach einem reboot sauber sein.

Lg
Christian
 
Hast du eine Info oder ne Idee wie ich das machen kann?

Ich hab leider mit OpenWrt noch nicht so viel Erfahrung.
 
Ich habe das Wochenende nochmal geforscht.

Es scheint wirklich so zu sein das OpenWRT auf der Herta nicht wirklich gut mit WLAN funktioniert. Es ist bei OpenWRT auch bekannt das der acx Treiber nicht so gut funktioniert.
Ich bekommen zwar ein WLAN hin. Allerdings hat es keine gute Qualität. Pakete gehen verloren und die Ping Zeiten sind auch nicht ganz konstant. Auserdem wird momentan auch kein WPA/WPA2 von den Treiber unterstützt.

Schade...
 
Fallstrick: OpenWrt verhindert Zugriff übers Ethernet

Eine Sache noch, an der ich länger gesucht hatte:

Openwrt schaltet wohl standardmäßig aus, dass es auf Arp-Anfragen reagiert. Dann kann man u.U. nicht via Ethernet von außen drauf zugreifen.

Ein externer PC beispielsweise kann dann nicht die MAC-Adresse des OpenWrt-Systems herausfinden, weil das ja über das Arp-Protokoll geschieht.

Wenn aber OpenWrt einmal selbst den PC kontaktiert hat (z.B. man macht manuell von der OpenWrt-Konsole einen Ping auf den PC), dann lernt der PC die MAC-Adresse und hält sie im Arp-Cache. Dann funktioniert der Zugriff plötzlich.

Der Inhalt des Arp-Caches auf dem PC läßt sich übrigens sowohl unter Windows als auch unter Linux mit "arp -a" anzeigen.

Lösung: In der OpenWrt-Box in /etc/sysctl.conf diese Zeilen auskommentieren, wie z.B. hier dargestellt:

# net.ipv4.conf.default.arp_ignore=1
# net.ipv4.conf.all.arp_ignore=1
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.