Aastra Dect GW - Mobilteil Firware aafon6xxd.dnld nicht ladbar

Für Mobilteile aastra 6xxd ist
die mit MD 7.02 ausgelieferte Firmware nicht ladbar.
Das gilt für Mobilteile die an RFP(L)32 IP angebunden sind.


***   FTS : 0x0000f425 max. filesize (2424832) reached
***   FTS : 0x0000f425 unpack ./doa <<== tftp://10.202.10.2/pool/aafon6xxd.dnld command failed (command 'tar -x -z -f /var/run/omm/pipe0x0000f425 -C ./doa' failed error 1) (102356 bytes/sec for 23.690 sec)
***   KI- : DM/dmfwhd.c(315): ftsEnd error: command 'tar -x -z -f /var/run/omm/pipe0x0000f425 -C ./doa' failed error 1 - error code=8

Ursache scheint eine Größenbeschränkung der 32IP zu sein.

Ich habe die Version durch eine ältere ersetzt.
Damit funktioniert das wieder.

Die Mobilteil FW muss also wohl abhängig vom Typ des GW eingestellt werden, oder es findet sich eine Möglichkeit diese Größenbeschränkung anzupassen.

Rainer

Hallo Rainer,

die Firmware ist darauf ausgelegt mit den Basisstations-Firmwares 3.X und 4.X klarzukommen. Leider gibt es hier auf seiten von Aastra eine kleine Konzeptlücke, weshalb es nicht so einfach ist, mehrere Unterschiedliche Mobilteil-Firmwares parallel vorzuhalten. Vorerst ist zumindest der beste gangbare Weg, diese Datei manuell zu ersetzen, falls es noch nötig ist die Mobilteile an einem RFP32 mit einer neueren Firmware zu versorgen.

Für den reinen Betrieb ist die Mobilteilfirmare nicht unbedingt notwendig, hauptsächlich braucht man diese wenn man ältere Mobilteile hat und selbige auf die aktuelle Version bringen möchte.

Grüße,
Jan

War effektiv nur ein kosmetisches Problem. (Ließ sich ja mit bereitstellen einer kompatiblen Version lösen).
Ist aber wohl zusammen mit der Firmwarekonfiguration für GW anzugehen:
Wenn eine RFP32 als master gekennzeichnet wird, könnte man ja die RFP firmware auf 2.1 “downgraden” und die entsprechende Mobilteilfirmware bereitstellen.
(Dass Aastra nicht einfach eine URL weitergibt, die man dann auf die MD leiten köönte, sondern vom OMM aus die Verteilung unter Kontrolle halten will, ist durchaus verständlich…)

Rainer

Hallo Rainer,

ganz so einfach ist es leider nicht. Alle Aastra-DECT-OMMS der Firmware-Versionen 2.1, 3.0 und 4.0 fragen leider immer dieselbe Firmware-Datei ab, dieser Pfad ist nicht konfigurierbar. Jetzt ist es aber mit der MobyDick möglich, mehr als 1 DECT-System gleichzeitig zu betreiben (z. B. mehrere Standorte mit jeweils einem eigenen System). Die Mobilteil-Firmware ist in diesem Fall global für alle DECT-Systeme gleich, d. h. wenn in Standort 1 ein RFP 32 mit 2.1 und in Standort 2 ein RFP 34 mit 4.0 ist, und ich die ältere Firmware auf den TFTP-Server lege, passt die Version nichtmehr zum Standort 2.

Zusätzlich werden die RFP32 nichtmehr gebaut, und soweit ich das sehen kann auch seit längerem nichtmehr neu verkauft, so das man alle neu installierten Systeme ohne Probleme mit Firmware 3.0 oder 4.0 betreiben kann. Aus diesem Grund haben wir uns entschieden, die neueste Mobilteilfirmware mitzuliefern. Ich werde allerdings demnächst den von dir beschriebenen Workaround in der Wiki Dokumentieren, so das Benutzer älterere Systeme zumindest recht problemlos die “passende” Firmware in den TFTP bringen können.

Grüße,
Jan

Hallo Jan,
wenn ich das korrekt gesehen habe, dann wird die Firmware für die Mobilteile (mit festem Namen aafon6xxd.dnld)
unter dem gleichen Pfad abgerufen, wie die RFP firmware auch.
Also …/pool/iprfp2G_V3.tftp wird zu …/pool/aafon6xxd.dnld. Ich hatte früher ein …/firmware/aastra subdirectory mit den beiden files und das hat funktioniert.
Es ist allso nicht der vollständige Pfad hardcoded.

Daher scheint eigentlich alles beisammen, um dediziert Firmware bereitzustellen:

  1. In “Basisdaten” kann die “allgemeine Zielversion” hinterlegt werden.

  2. In “Basisstationen” wird je Basisstation ggf. abweichende FW hinterlegt (hier wäre eine Einstellung des Typs (z.B. RFPL32IP) für den user eingängiger als nur die Einstellung einer (ggf. zu 1. abweichenden FW Version).
    Ist der Typ nicht kompatibel kann man entsprechend anpassen.
    (Annahme: der Default passt in der Regel; Abweichungen sind eigentlich eher durch (technische) Beschränkungen geboten)

    Die FW Version aus der Konfiguration der RFP kann den dhcp Eintrag (tftp-boot) kontrollieren. Der wird ohnehin je Basisstation eingestellt. Wenn man dazujeweils ein spezifisches verzeichnis vorhält und dort einträgt,
    dann sollte das bereits heute klappen.

Fehlt also eigentlich nur bei der Konfiguration eines master/failover RFPs ein augenfälliger Hinweis, dass ein RFP32 nur mit Version <= 2.1 lauffähig ist.
(Ideal wäre natürlich, wenn man das z.B. aus der MAC entnehmen könnte - aber man darf ja träumen - die explizite Angabe des Typs würde auch helfen, - man kann ja immer noch ein explizites override der FW Version vorsehen
(mit entsprechender Warnung bei bekannten Problemkonstellationen).)
Dann muss man zwar immer noch damit leben, dass man ein Mobilteil an einer RFP32 nicht auf die gleiche FW heben kann, wie ein Mobilteil an einer RFP34. Aber wer diesen HW-mix fährt hat diese Thema vermutlich öfter.

Rainer

Hallo Rainer,

vorneweg zur “default”-Einstellung der Firmware. Man kann bei Aastra-DECT ja in den Basisdaten eine “globale”-Firmware hinterlegen, die für alle RFPs im DECT System gilt. Hat man jetzt aber einen Gemischtbetrieb aus RFP34 und RFP32, und will die Firmware 4.0 verwenden (Was auch mit RFP32 möglich ist, solange ein RFP34 master ist), so muss man hier bei den RFP32-Basisstationen eine vom Eintrag “default”-abweichende Firmwaredatei auswählen, da dieser RFP32 mit den Dateien für die RFP34 nichts anfangen kann. Hat man einen “homogenen” Bestand an Basisstationen, kann man den Eintrag einfach auf “default” lassen und alle RFPs bekommen die in der “Basisdaten”-Maske eingestellte Firmware geliefert.

Deine Anmerkung mit dem subdirectory wäre eine Möglichkeit, nur leider ist unser Firmware Pool im Moment konzeptionell nicht auf das Verwalten von Unterordnern ausgelegt. Wir müssen hier zuerst u. a. die Firmware-Management-GUI anpassen, bevor wir hier korrekt mit Unterordner arbeiten können. Nichtsdestotrotz habe ich für deine Anregung hier einen Verbesserungsvorschlag aufgenommen, aber es wird vorraussichtlich etwas dauern bis wir das umsetzen können.

Grüße,
Jan