Wer eine FRITZ!Box flashen will, die im Bootloader(!) eine Adresse verwenden soll, deren letzte Stelle NICHT
.1 ist, dem nutzt keine Einstellung im FRITZ!OS-GUI irgendetwas. Der einzige (mir bekannte) Weg ist es dann, die startende Box über UDP-Port 5035 (Broadcast-Paket, weil die IP-Adresse ohnehin noch nicht gesetzt ist bzw. die falsche wäre) anzuweisen, eine solche Adresse zu setzen. Eine einmal auf diesem Weg gesetzte Adresse wird auch beibehalten, bis sie durch ein weiteres UDP-Paket geändert würde.
Wie weit es funktioniert, diesen Eintrag auch schon VORHER im Environment vorzunehmen (mit Shell-Zugriff auf das Gerät geht das ja auch) und ob der dann von aktuellen EVA-Versionen ebenso berücksichtigt wird, muß man halt probieren. Ich würde es zwar erwarten, habe DAS aber noch nicht getestet, weil ich ohnehin jedesmal die Box zuvor suchen lasse und die mir genehme Adresse dabei dann auch gleich neu setzen lasse - egal, was da zuvor verwendet wurde.
Das AVM-Recovery-Programm hilft hier nicht weiter, weil es immer die
.1 setzt und wenn es eine andere aktive Box mit dieser Adresse gibt (und die zu flashende NICHT gesondert verkabelt werden soll), wird das Ganze zum Glücksspiel, wenn von L3-Adressen in L2-Adressen "übersetzt" werden soll. Abhilfe könnte hier u.U. ein vorübergehend statisch gesetzter ARP-Eintrag schaffen, dann kämen die Pakete wenigstens bei der Box an (wie bei den 6490-Geräten, die bei zerstörtem TFFS-Inhalt mit einer falschen MAC-Adresse auf ARP-Suchen reagieren) ... aber die falsche Ziel-IP in den Paketen wird vermutlich trotzdem zum Problem werden. Das AVM-Recovery-Programm schreibt auch immer ein neues TFFS-Image, in dem diese Adresse wieder auf
192.168.178.1 gesetzt wird (beim nächsten Start) - egal, was die Box dort gerade stehen hat.
Daher bleibt UDP 5035 die m.E. die beste Lösung und dafür bietet
push_firmware keine Unterstützung an. Das hatte ich mit
@cuma auch mal andiskutiert (den gesamten Ablauf beim "Power-On-Reset"), ich weiß aber nicht mehr, wo das war. Es gibt in
push_firmware zwar Code, der erst mal nach der IP-Adresse schaut ... und dann zum Power-On-Reset der Box auffordert. Aber der setzt eben gerade keine abweichende IP-Adresse und so findet er die neu startende Box dann eben auch nicht, wenn sie in EVA mit einer anderen Adresse arbeitet.
Früher gab es noch das
ruKernelTool, was auch diesen Mechanismus verwendete ... daher kamen dann die merkwürdigen IP-Adressen
99.88.77.1 in damit behandelten Boxen.
Es gibt in Freetz zwar auch noch ein Perl-Skript
recover_eva, aber das ist (sofern ich das richtig sehe) nicht für die Verwendung mit neueren Boxen (mit Start aus dem RAM) geeignet, auch wenn es am Beginn anders aussehen mag (wg. der Option
-s) ... zumindest kommt da ein FTP-Dialog bei heraus, wie er von AVM bei diesen Geräten nicht geführt wird.
Daher sind die einzigen (mir bekannten) Angebote, die mit UDP-Paketen arbeiten, tatsächlich
eva_discover und
EVA-Discovery.ps1, bei bzw. mit denen kann man die FRITZ!Box auf die gewünschte IP-Adresse einstellen und sie daher auch "in voller Verkabelung" flashen, sofern einem nicht die Besonderheit von EVA, daß dabei alle Ethernet-Ports mit "LANx"-Namen in einer Bridge sind, auf die Füße fällt (das Problem läßt sich auch nicht ausschließlich auf/mit der FRITZ!Box lösen).
Wer z.B. eine FRITZ!Box mit ihren Ethernet-Ports an einen VLAN-fähigen Switch klemmt und üblicherweise auf LAN4 ein Gastnetz betreibt (oder die anderen Port als gesonderte Anschlüsse für VPN-Verbindungen betreibt), der kann sich auf diesem Weg schon mal L2-Probleme einhandeln ... dann hilft es u.U. auch nicht mehr, daß man die Box im Bootloader auf eine Adresse gesetzt hat, die nicht auf
.1 endet. Aber dann kann es natürlich auch hilfreich sein, wenn man solche Verbindungen auf der anderen Seite (also dem Switch) per Software deaktivieren kann (Port down). Jedoch ist das i.d.R. auch ein anderer "Spezialfall" und wer tatsächlich nur einen IP-Client im LAN flashen will, ohne die Verkabelung zu ändern, kommt mit UDP 5035 gut aus.
Die Fragen, welche IP-Adresse die Box hat und wie man die Firmware auf der Box installiert, sind jedenfalls zwei getrennte ... daher gibt es von mir dafür auch zwei getrennte Skript-Angebote, die der Benutzer nacheinander ausführen muß bzw. soll.
Bei
push_firmware startet die Benutzung normalerweise mit einer FRITZ!Box, die noch mit einem kompletten System läuft und über
ping erreichbar ist (da kommt dann die Aufforderung, den Stecker zu ziehen), aber durch die fehlende Kontrolle über die verwendete IP-Adresse (die kann man auch nicht ohne weiteres über FTP kontrollieren, wenn die Box (noch) im FRITZ!OS ist) kann es dabei durchaus passieren, daß die Box, wenn sie wieder über die vermutliche IP-Adresse erreichbar ist, schon längst wieder erneut im FRITZ!OS angekommen ist (und den FTP-Server auch noch deutlich später erst startet, obwohl sie schon längst auf ICMP-Pakete geantwortet hat). Und dann hat man die EVA-Phase eben einfach übersprungen ...
