FB Emulation (qemu) - suche helfende Hand

[patphone]

Dazu müsstest du das flashimage.bin von einer FritzBox auslesen, nachdem du sie auf Werkseinstellungen zurückgesetzt hast. Wobei dann deine MAC-Adresse immer noch drin ist. Aber die Passwörter sind nicht in dem Bereich den du mit kernel und filesystem tauscht.
Wobei man den adam2 und die beiden tffs Partitionen auch tauschen kann...

MfG Oliver

Hm - eine Partitionstabelle bzw. die Partition sollte man auch von 'außerhalb' erstellen koennen - genauso wie den bootloader zu 'frickeln' - ich versteh nach wie vor nicht genau, wieso man eine Fritzbox brauch um eine zu emulieren - schließlich bootet sie auch nur von einem FW-Image - der Rest sollte doch auch 'selber erstellbar' sein!?

 

[olistudent]

Wenn du weißt wie man einen Bootloader erstellt, dann sollte das gehen. Da bin ich mal gespannt wie du den ohne Sourcecode hinbekommst. ;-)

MfG Oliver

 

[patphone]

Wenn du weißt wie man einen Bootloader erstellt, dann sollte das gehen. Da bin ich mal gespannt wie du den ohne Sourcecode hinbekommst. ;-)

MfG Oliver

Hm okay - das ist ein Argument

 

[RalfFriedl]

ich versteh nach wie vor nicht genau, wieso man eine Fritzbox brauch um eine zu emulieren

Braucht man denn eine Fritzbox, oder braucht man nur den Speicherinhalt einer Fritzbox?

 

[olistudent]

Man braucht die FritzBox nur zum Auslesen des Speichers. Wenn du ein flashimage.bin hast, dann brauchst du keine Box mehr.

MfG Oliver

 

[MaxMuster]

Zum Thema "Spanning Tree": Grundsätzlich, sofern nicht allseits bekannt, ist der im Ethernet dazu da, Schleifen zu erkennen. Dazu werden Spezielle Pakete versandt mit denen sich jede Bridge ein "Bild" vom Netz macht. Knapp zusammengefasst wird ein Interface, was eine Schleife verursacht, "ausgeschaltet". Dieser Algorithmus "läuft los", wenn sich die Topologie ändert, deshalb vermutete ich das mit dem "topology changed".

Merkwürdig sind hier zwei Dinge: Zum einen ist dieser Status dann "blocked", nicht "disabled", zum anderen behauptet brctl es sei zumindest in der Bridge "lan" kein SpanningTree aktiv. Wenn, so passiert das also im Ethernet-Treiber selbst. Vielleicht liege ich ja auch daneben, und es ist "andersrum": Das Interface eth0 "steigt aus", und das ist natürlich ein "topology change"...

Letzlich zeigt ein ifconfig, dass der Zustand von eth0 dann zwischendurch immer mal kurz zu "RUNNING" wechselt. Es werden, wenn ich auf die "umgeleiteten Adressen" (z.B. localhost 2323) zugreife Pakete "empfangen", aber alles als "ERRORS"...

Weiter bin ich noch nicht gekommen...

Jörg

 

[RalfFriedl]

Hier handelt es sich doch nicht um einen echten Switch, sondern um den, der von qemu emuliert wird, oder?
Ich vermute nicht, daß sich qemu die Mühe macht, an einem virtuellen Switch mit "Spanning Tree" nach Schleifen zu suchen.
Eher ist etwas an der Emulation von qemu nicht genau so wie auf der echten Hardware.

 

[MaxMuster]

Vollkommen ack! Ein brctl behauptet ja wie gesagt auch, gar kein STP zu fahren. Dennoch, alle Meldungen kommen mit großer Wahrscheinlichkeit vom STP der Bridge (im Kernel-Source unter "net/bridge/*stp*"...) und die scheint dann das "Interface" auch zu "deaktivieren")

Jörg

 

[MaxMuster]

@Oliver:
Probier doch mal den multid zu killen (der fiel mir so ein ;-)). Die Session lief danach mehrere Minuten ohne Probleme, die nächste läuft jetzt auch seit über 5 Minuten mit multid (Allerdings habe ich dann jetzt im WebIF die IP-Einstellungen auf 10.0.2.15 vorgenommen )?!?

Jörg
EDIT: ...und läuft und läuft nun schon seit 30 Minuten (naja, die qemu Uhr geht wohl etwas schnell ;-))

 

[RalfFriedl]

Mal eine Frage zur Geschwindigkeit:
Läuft auf einem aktuellen Rechner eine emulierte Fritzbox eher schneller oder eher langsamer als eine echte?

 

[MaxMuster]

Hättest du einen sinnvollen Test ("lange laufend" mit nicht allzuviel Speicherbedarf)? Vielleicht was aus dem "Fax-Projekt", womit man die Zeiten mal vergleichen kann? Dass ich im Webif keine großen Differenzen "fühle" hilft ja nix.

Jörg

 

[RalfFriedl]

Anbei eine Datei time_test. Es enthält eine doppelte Schleife und ist ohne Optimierung übersetzt. Der Quelltext ist auch dabei. Der Speicherbedarf sollte minimal sein.

Aufruf mit zwei Werten für die jeweiligen Schleifen.

time ./time_test 100000 1000
real    0m 13.09s
user    0m 12.44s
sys     0m 0.66s

für einen echten Vergleich ist das etwas wenig, aber es zeigt schon einmal die Größenordnung. Mit einer Null mehr hinten sollte die Laufzeit etwas über zwei Minuten sein. Für den Test in der Emulation wäre eine externe Uhr sinnvoll, wenn dort die Zeit nicht zuverlässig läuft.

PS: Du hast recht, es geht mir dabei um das Fax-Programm.

 

[MaxMuster]

Das Braucht bei mir auf einem Athlon x2 3800, 2GB :
2min 49 Sekunden (169 Sekunden), handgestoppt.

Ausgabe (ohne nervige Consolemeldungen):

/var/tmp $ time ./time_test 100000 10000
real    3m 45.12s
user    3m 41.36s
sys     0m 0.02s

Nachtrag der "realen HW" Eumex 300IP mit ds26-15.2, kein Unterschied der Anzeige zur "externen Uhr":

/var/tmp $ time ./time_test 100000 10000
real    2m 59.00s
user    2m 56.28s
sys     0m 0.25s
/var/tmp $

Also für mich kein "echter" Vorteil der emulierten Box (in dieser Beziehnung!).


@Oliver zum Thema Netz: Das mit dem multid ist zumindest nicht im "Nachhinein" anwendbar. Wenns einmal micht (mehr) läuft, ist es weg. Bei mir klappt es scheinbar auch nur jedes 3. mal in etwa. Nach dem Ändern der IP im WebIF scheint die Verbindung nicht mehr wegzufliegen (wenn sie denn "hochkommt") die Eingestellte IP-Änderung ist "Soft-Reset-Fest" und überlebt ein Reload aber keinen kompletten Neustart.
Ich habe nun cpmac-Fehler, der Status geht aber in "forwarding" über:

[cpmac] cpphy_if_tx_complete, 55 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 1514 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 1078 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 54 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 222 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 1514 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 1514 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 1514 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 1260 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 1514 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 1260 bytes dropped (9)
[cpmac] cpphy_if_tx_complete, 1260 bytes dropped (9)
lan: port 1(eth0) entering disabled state
lan: port 1(eth0) entering learning state
lan: topology change detected, propagating
lan: port 1(eth0) entering forwarding state
lan: port 1(eth0) entering disabled state
lan: port 1(eth0) entering learning state
lan: topology change detected, propagating
lan: port 1(eth0) entering forwarding state
lan: port 1(eth0) entering disabled state
lan: port 1(eth0) entering learning state
lan: topology change detected, propagating
lan: port 1(eth0) entering forwarding state

Jörg

 

[olistudent]

Hm, dann werd ich mal die ar7.cfg editieren. Im Moment sieht es so aus:

# ifconfig eth0 down
lan: port 1(eth0) entering disabled state
# ifconfig eth0 up
[setup_irq]: irq 27 irqaction->handler 0x940e6c4c (cpmac_main_isr+0x0/0x78 )
[ar7int_ctrl_irq_pacing_register] IRQ 27 already registered!
[ar7int_ctrl_irq_pacing_set] Handle 4294967295 is invalid!
lan: port 1(eth0) entering learning state
lan: topology change detected, propagating
lan: port 1(eth0) entering forwarding state
# lan: port 1(eth0) entering disabled state

MfG Oliver

edit: Nachdem ich die 10.0.2.15 jetzt in der ar7.cfg eingetragen hab gehts auch mit dem Netzwerk. Der telnet-Zugriff funktioniert. Nur beim Zugriff auf das Webinterface stockt es etwas.

Nachtrag:

/ $ time time_test 100000 10000
real    1m 25.00s
user    1m 25.01s
sys     0m 0.00s

Handgestoppt: 1m 05s

 

[MaxMuster]

AUf meinem "Arbeits-PC" (P4 3GHZ) ist das time-test (wie auch bei Oliver) deutlich schneller (1:42). Vielleicht sollte ich das qemu Binary mal selbst kompilieren...
Wenn ich nun noch die "Firmware ändern" könnte, ich warte da gespannt auf das mkfirm. Oder ist es das von berlios?

Da ergeben sich zumindest ganz neue Möglichkeiten des Testens von "tiefen" Änderungen, die man ansonsten ohne Serielle Konsole (oder sogar EJTAG) nicht tun sollte.

Jörg

 

[RalfFriedl]

Danke für die Infos. Auf dem W900V braucht das Programm 2:10 Minuten. Da ich auch einen Athlon habe, bringt es vermutlich nichts. Anscheinend sind beim qemu die Pentiums deutlich schneller.
Bei Euch beiden geht die Systemzeit im qenu einiges schneller als die reale Zeit. Aber vielleicht hängt das ähnlich wie bei VMWare mit der Takt-Umschaltung zusammen.

Vielleicht versuche ich es trotzdem noch mit qemu, unabhängig von der Geschwindigkeit. Die Emulation hört sich interessant an.

 

[olistudent]

Anbei mal mein Patch für mkfirm.rb. Ich war zu faul die unnötigen Änderungen wieder rauszunehmen. Wichtig sind nur die im unteren Teil.
Anleitung:

flashimage.bin nach qemu/boot kopieren
kernel.image aus ds26-15.2/build/modified/firmware/var/tmp nach qemu/boot kopieren
qemu/mkfirm.rb load-kernel boot/kernel.image

Für 8mb Firmwares muss die 4 in eine 8 geändert werden.

FLASHIMAGE = "boot/flashimage.bin"
FLASHSIZE = [COLOR=red]8[/COLOR] * MiB
if FLASHSIZE == 2 * MiB

MfG Oliver

 

[schmatke]

mkfirm.rb ??? Ist das Ruby?
Ich kenn nur mkfirm.c

Und damit kann man *.bin erstellen. Auch ändern? :gruebel:
Wie?
Sorry, falls das ne blöde Frage ist, bin Programmierdoof!

 

[olistudent]

Ja genau, Ruby. Das Skript ist im qemu-trunk dabei...

MfG Oliver

 

[MaxMuster]

Und hier noch was für "die ganz harten" ;-) qemu-system-mipsel "für unter Windows zum Ausführen!"

Starten mit:

qemu-system-mipsel.exe -M fbox-4mb -L <Verzeichnis mit "flashimage.bin"> -parallel none -redir tcp:2323::23 -redir tcp:8080::80 -redir tcp:8181::81 2> :NUL

bitte kein -nographic, weil unter Windoofs serial sonst nicht klappt,:

Unable to open driver: stdio
qemu: could not open serial device 'mon:stdio'

und ohne "-nographic" hat man die "Serielle-Ausgabe" halt in einem Fenster...

Ich hoffe es klappt auch bei euch ...
Der Anhang ist eine .7z Datei, nur als .zip umbenannt, weil man keine .7z hochladen darf

Jörg