Flashen mit linux?

Wie blitze ich ein Bild - Permanent Outgoing Incomes
jw
Interessierter
Interessierter
Beiträge: 56
Registriert: Dienstag 12. Juli 2005, 22:48

Flashen mit linux?

Beitrag von jw »

Hallo!

Ich versuche eine Nokia 2x Intel (avia500) von einem linux aus zu flashen. Auf der Box ist bereits ein aelteres Neutrino (1.1.??) drauf. Als Grundlage habe ich http://www.dietmar-h.net/linux.html und http://wiki.tuxbox-cvs.sourceforge.net/ ... tion:Linux genommen.

Ich habe die Box in /etc/hosts und /etc/ethers eingetragen. In /etc/dhcpd.conf steht folgendes:

Code: Alles auswählen

option domain-name "beimir";
option domain-name-servers 192.168.1.200;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.1.0 netmask 255.255.255.0 {
}
host dbox2 {
  hardware ethernet  00:50:9C:3e:17:b5;
  fixed-address 192.168.1.14;
  allow bootp;
  server-name "192.168.1.12";
  filename "/dbox2/tftpboot/ppcboot";
}
Sowohl rarpd als auch dhcpd laufen, die Serielle ist angeschlossen und steht auf 9600, 8n1, kein flowcontrol. Parallel dazu laeuft ein Ethereal, um zu sehen wo die Prozedur scheitert.

Wenn ich die Box einschalte, schickt sie einen bootp-request an 255.255.255.255. Dieser wird vom dhcpd beantwortet (wieso braucht es denn da eigentlich den rarpd?). In dieser Antwort ist auch korrekt der server-host sowie das boot-file eingetragen. Jetzt wuerde ich ja erwarten, dass die box versucht mittels tftp das bootfile zu laden. Das passiert aber nicht. Stattdessen bootet das im flash enthaltene (alte) neutrino durch, und die Box geht in den Normalbetrieb ueber. Auf der Seriellen passiert ueberhaupt nix.

Hat jemand eine Idee, was ich da falsch mache?
Wieso unternimmt die Box keinen Versuch, das Boot-file zu holen?
An der grundsaetzlichen Netzwerk-Konfiguration kann es ja nicht liegen, sonst wuerde der bootp request/reply nicht tun?
Wer kann mir da helfen?
Nachtvogel
Tuxboxer
Tuxboxer
Beiträge: 4391
Registriert: Freitag 21. Mai 2004, 17:16

Beitrag von Nachtvogel »

Hallo!

Weshalb verwendest Du icht die Expertenfunktion von Neutrino?
http://wiki.tuxbox-cvs.sourceforge.net/ ... n:Neutrino

Gruß Nachtvogel
Bild
jw
Interessierter
Interessierter
Beiträge: 56
Registriert: Dienstag 12. Juli 2005, 22:48

Beitrag von jw »

Weshalb verwendest Du icht die Expertenfunktion von Neutrino?
Bevor ich womoeglich das Flash zerschiesse, will ich erst wissen, wie ich die Box wiederbeleben kann. Will sozusagen auf Nummer Sicher gehen.

Ahja: Immerhin weiss ich jetzt, warum auf der Seriellen nix kommt: Ein Gender-Changer gibt eben noch lange kein echtes cross-over-Kabel ':oops:'.

Jetzt bekomme ich folgendes:

Code: Alles auswählen

debug: BMon V1.0  mID 01
debug: feID 7a    gtxID 0b
debug: fpID 5a     dsID 01-2e.99.42.07.00.00-41
debug: HWrev X5  SWrev 0.81
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
dbox2:root> debug:
BOOTP/TFTP bootstrap loader (v0.3)
debug:
debug: Transmitting BOOTP request via broadcast
debug: Given up BOOTP/TFTP boot
boot net failed
Das waere laut http://www.dietmar-h.net/flashprob.html der "Klassiker schlechthin". Aber auch die hier beschriebene Methode (Standby+Pfeil-nach-oben, anschliessend "boot net") klappt nicht:

Code: Alles auswählen

debug: BMon V1.0  mID 01
debug: feID 7a    gtxID 0b
debug: fpID 5a     dsID 01-2e.99.42.07.00.00-41
debug: HWrev X5  SWrev 0.81
debug: B/Ex/Fl(MB) 32/00/08
WATCHDOG reset enabled
debug: &_text 0x10000, &_etext 0x26160, &_data 0x26160, &_edata 0x29c50
debug: &_end 0x347dc,  &__stack 0x400000
debug: Memory tests (0x400000 -- 0x2000000)
debug: NumberTest: debug: passed
debug: MarchTest: debug: passed
debug: PermTest:  debug: passed
dbox2:root> boot net
debug:
BOOTP/TFTP bootstrap loader (v0.3)
debug:
debug: Transmitting BOOTP request via broadcast
debug: Given up BOOTP/TFTP boot
boot net failed
boot: elfcopy failed: 16
dbox2:root>
Egal was ich mache, auf dem Ethernet kommen immer nur die zwei im Original-Artikel beschriebenen Telegramme (BOOTP-Request von der Box und BOOTP-Reply vom dhcp). Die Box versucht nicht, das Bootfile via tftp zu laden.
saruman
Erleuchteter
Erleuchteter
Beiträge: 682
Registriert: Samstag 13. Juli 2002, 10:05

Beitrag von saruman »

Schau Dir mal das Log von Deiner Linux-Büchse an. Da muss zumindest der BOOTP-Request eingehen. Falls nicht: Beim Starten der Box ruhig mal mit tcpdump am Netzwerkinterface Deiner Linux-Kiste lauschen.
jw
Interessierter
Interessierter
Beiträge: 56
Registriert: Dienstag 12. Juli 2005, 22:48

Beitrag von jw »

saruman hat geschrieben:Schau Dir mal das Log von Deiner Linux-Büchse an. Da muss zumindest der BOOTP-Request eingehen. Falls nicht: Beim Starten der Box ruhig mal mit tcpdump am Netzwerkinterface Deiner Linux-Kiste lauschen.
Das hatte ich doch schon zweimal geschrieben: der BOOTP-Request kommt an und dhcpd antwortet mit einem BOOTP-Reply. Nun waere es an der dbox, per TFTP das bootfile abzuholen. Und hier passiert eben nichts mehr. Nur zwei Pakete: BOOTP-request und BOOTP-Reply. Danach nichts mehr.
Npq
Senior Member
Beiträge: 1339
Registriert: Donnerstag 24. April 2003, 12:12

Re: Flashen mit linux?

Beitrag von Npq »

jw hat geschrieben:255.255.255.255. Dieser wird vom dhcpd beantwortet (wieso braucht es denn da eigentlich den rarpd?).
Für den BMon braucht man den rarpd nicht, der ist nur für die BN selber wichtig.

Es gab hier im Forum mal Berichte von dhcpds, welche Antworten schicken mit denen der BMon nichts anfangen kann.

Guck mal hier:
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=27288
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=35543
jw
Interessierter
Interessierter
Beiträge: 56
Registriert: Dienstag 12. Juli 2005, 22:48

Re: Flashen mit linux?

Beitrag von jw »

Npq hat geschrieben:Es gab hier im Forum mal Berichte von dhcpds, welche Antworten schicken mit denen der BMon nichts anfangen kann.

Guck mal hier:
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=27288
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=35543
Da ich (wie in den genannten Threads) eine suse-9.0 habe, scheint das die richtige Spur zu sein, Danke!

Der Unterschied scheint wohl zu sein, dass mein dhcpd den bootp-reply an 255.255.255.255 schickt, waehrend die dhcpd's mit denen es funktioniert, den bootp-reply an die tatsaechliche IP-Adresse sendet. Ehrlich gesagt, verstehe ich das aber nicht so ganz. Zu dem Zeitpunkt wo der bootp-reply kommt, hat die dbox doch noch garkeine IP-Adresse. Wie kann dann das Paket bei der dbox ankommen :gruebel:? IMHO ist der bootp-reply an 255.255.255.255 das korrekte Verhalten. Oder was habe ich hier uebersehen?

BTW: Hat jemand Erfahrung mit dem dhcpd von suse-9.3? Da ich eh auf 9.3 updaten wollte, wuerde ich mir gerne das Kompilieren des dhcpd ersparen :)
Houdini
Developer
Beiträge: 2183
Registriert: Mittwoch 10. Dezember 2003, 07:59

Beitrag von Houdini »

Zu dem Zeitpunkt wo der bootp-reply kommt, hat die dbox doch noch garkeine IP-Adresse. Wie kann dann das Paket bei der dbox ankommen
Ein Paket wird immer zuerst an eine MAC Adresse geschickt, die wurde beim DHCP request mitgeliefert.

Gruss
Houdini
jw
Interessierter
Interessierter
Beiträge: 56
Registriert: Dienstag 12. Juli 2005, 22:48

Beitrag von jw »

Ein Paket wird immer zuerst an eine MAC Adresse geschickt, die wurde beim DHCP request mitgeliefert.
Es muessten also beide Pakete ankommen. Aber die Dbox akzeptiert es nur dann wenn die IP nicht 255.255.255.255 ist. Warum ist das so?
Npq
Senior Member
Beiträge: 1339
Registriert: Donnerstag 24. April 2003, 12:12

Beitrag von Npq »

Houdini hat geschrieben:Ein Paket wird immer zuerst an eine MAC Adresse geschickt, die wurde beim DHCP request mitgeliefert.
Richtig, und das Problem ist vermutlich, daß der BOOTP-Reply-Broadcast nicht an die MAC geht (das ergäbe ja auch keinen Sinn). Dieses Vorgehen erspart dem dhcpd die Manipulation des ARP-Cache. (Die MAC steht natürlich im BOOTP-Paket drin, ansonsten hätte der Client ja keine sichere Möglichkeit herauszufinden, ob der Broadcast an ihn ging oder nicht).

Also, entweder der BMon lauscht nur auf seine MAC oder es ist ein Bug.

Am besten mal die 7478 anrufen und fragen. :)
jw
Interessierter
Interessierter
Beiträge: 56
Registriert: Dienstag 12. Juli 2005, 22:48

Beitrag von jw »

Npq hat geschrieben: Richtig, und das Problem ist vermutlich, daß der BOOTP-Reply-Broadcast nicht an die MAC geht (das ergäbe ja auch keinen Sinn). Dieses Vorgehen erspart dem dhcpd die Manipulation des ARP-Cache. (Die MAC steht natürlich im BOOTP-Paket drin, ansonsten hätte der Client ja keine sichere Möglichkeit herauszufinden, ob der Broadcast an ihn ging oder nicht).

Also, entweder der BMon lauscht nur auf seine MAC oder es ist ein Bug.
Hab grad nochmal nachgeschaut: der reply geht an die MAC ff:ff:ff:ff:ff:ff, was wohl (laut ethereal) auch broadcast bedeuten soll. Weiss jemand, ob das RFC-Konform ist?
Am besten mal die 7478 anrufen und fragen. :)
Wer oder was ist 7478?
Houdini
Developer
Beiträge: 2183
Registriert: Mittwoch 10. Dezember 2003, 07:59

Beitrag von Houdini »

Hab grad nochmal nachgeschaut: der reply geht an die MAC ff:ff:ff:ff:ff:ff, was wohl (laut ethereal) auch broadcast bedeuten soll
Genau, aber so oder so musst Du deinen dhcpd ändern weil den BMON wird wohl keiner mehr patchen.

Schönen Sonntag
Houdini
Npq
Senior Member
Beiträge: 1339
Registriert: Donnerstag 24. April 2003, 12:12

Beitrag von Npq »

jw hat geschrieben: Hab grad nochmal nachgeschaut: der reply geht an die MAC ff:ff:ff:ff:ff:ff, was wohl (laut ethereal) auch broadcast bedeuten soll. Weiss jemand, ob das RFC-Konform ist?
Natürlich, was für einen Sinn ergäbe denn ein Broadcast an eine MAC? Der soll ja gerade von allen Clients angenommen werden.
jw hat geschrieben: Wer oder was ist 7478?


Bei BR war das die interne Telefonnummer vom BR-Coder. Taucht auf, wenn man im BMon mal "Help" eintippt. :D