[Info] Update-Check über den neuen AVM-Service

Ich versuche das mal mit der Konfigurationsdatei nachzustellen ... sieht ja auf den ersten Blick so aus, als wäre die "komplett" und man bräuchte keine Box dafür.

Die läuft an sich einwandfrei. Wenn ich statt " 08 " eine "05" eintrage läuft alles problemlos durch. Scheinbar sind es nur die Nummern "08" und "09", die zu dieser Fehlermeldung führen. 0-7 und ab 10 sind kein Problem.
 
Zuletzt bearbeitet:
Etwas scheint sich beim Update-Script geändert zu haben. Ich halte für die 7490 folgende Fehlermeldung:

7490: Es wurden Daten mit einem unerwarteten Format empfangen vom Server.
./7490: Zeile 1438: printf: egal: Ungültige Zahl.

Die .cfg-Datei lieferte sonst problemlos den Verweis auf die 07.01 und eine ältere Laborversion:

Serial=000000000000
Name="FRITZ\\!Box\\7490"
HW=185
Version=egal
Major=113
Minor=06
Patch=80
Buildnumber=0
OEM=avm
Lang=de
Annex=egal
Flag=egal
Country=049
Public=0
 
Die Vornull in den (inzwischen) erreichten Versionsnummern stellte tatsächlich das Problem dar ... lt. POSIX-Standard sind Zahlen mit führender Null immer oktal, weil man da den ISO-C-Standard adoptiert hat:
Only the decimal-constant, octal-constant, and hexadecimal-constant constants specified in the ISO C standard, Section 6.4.4.1 are required to be recognized as constants.
und da sieht das Grammar so aus (die Suffix-Optionen kennt die Shell dann auch nicht):
Code:
integer-constant:
               decimal-constant integer-suffixopt
               octal-constant integer-suffixopt
               hexadecimal-constant integer-suffixopt

decimal-constant:
               nonzero-digit
               decimal-constant digit

octal-constant:
               0
               octal-constant octal-digit

hexadecimal-constant:
               hexadecimal-prefix hexadecimal-digit
               hexadecimal-constant hexadecimal-digit

hexadecimal-prefix: one of
               0x  0X

nonzero-digit: one of
               1  2  3  4  5  6  7  8  9

octal-digit: one of
               0  1  2  3  4  5  6  7

hexadecimal-digit: one of
               0  1  2  3  4  5  6  7  8  9
               a  b  c  d  e  f
               A  B  C  D  E  F

integer-suffix:
               unsigned-suffix long-suffixopt
               unsigned-suffix long-long-suffix
               long-suffix unsigned-suffixopt
               long-long-suffix unsigned-suffixopt

unsigned-suffix: one of
               u  U

long-suffix: one of
               l  L

long-long-suffix: one of
               ll  LL
Damit wird jede Variable mit einer Null am Beginn in einem arithmetischen Kontext automatisch zur Oktalzahl (soweit hatte @H'Sishi ja recht mit seiner Annahme - lt. der Grammatik oben kann eine Dezimalzahl nicht mit einer Null beginnen, da sind nur "non-zero digits" erlaubt) und da die Formatzeichenkette mit dem "%d" den Wert dann automatisch in einen solchen arithmetischen Kontext rückt, wird zuvor die Umwandlung versucht, die bei Ziffern außerhalb von 0 bis 7 eben fehlschlägt (bzw. mit der entsprechenden Warnung versehen wird, denn die gültigen Ziffern werden trotzdem umgewandelt):
Code:
vidar:/home/GitHub/YourFritz/juis $ printf "%d\n" 01234ABC
bash: printf: 01234ABC: invalid octal number
668
vidar:/home/GitHub/YourFritz/juis $
Ich werfe jetzt von diesen numerischen Werten (nur Major, Minor und Patch sind für mich da relevant, mit anderen muß das Skript nicht rechnen) einfach die Vornullen weg, wobei man aufpassen muß, daß die letzte Null noch übrigbleibt, wenn der Wert tatsächlich 0 ist.

Ich habe mich für:
Code:
value=$(expr "$value" : "0*\([0-9]\+\)")
entschieden, obwohl man das wahrscheinlich auch mit anderer Syntax hätte machen können. Aber so klappt es wenigstens mit demselben (und einem einzigen) Statement auch ohne Vornullen und mit beliebig vielen, bis hin zu Werten aus einer oder mehreren Nullen.

Damit wurde das tatsächlich dadurch ausgelöst, daß AVM wieder bei "0x" als "Patch" angekommen ist - ab FRITZ!OS 8 wäre es ebenfalls schief gegangen. Die "Buildnumber" hatte ich hingegen von Beginn an nur als "string" verwendet, daher haben die Ziffern jenseits der 7 in diesem Wert den Fehler nicht getriggert - das verwirrte mich etwas bei der Suche; genauso die Tatsache, daß das eigentliche "printf"-Kommando dann in einer Shell-Variablen "versteckt" ist und damit die Zeilennummer in der Fehlermeldung halt nur die Stelle ist, wo der Fehler ausgelöst wird.

Wie auch immer ... die neue Version ist eingecheckt. Sollte es weiterhin Probleme geben, bitte hier melden ... ich könnte mich beim "expr" auch vertan haben und irgendeinen Grenzfall nicht berüclsichtigen.

-------------------------------------------------------------------------------

@Daniel Lücking:
Ich würde die "Name="-Einträge so gestalten, daß da keine Escapes erforderlich sind ... beide Namen:
Code:
Name="FRITZ\\!\\"
und 
Name="FRITZ\\!Box\\7490"
sehen etwas komisch aus. Man muß ja nur die Zeichen maskieren, die in Shell-Code eine spezielle Bedeutung hätten, wie das Leerzeichen (welches als "token delimiter" wirkt in Zeichenketten, die nicht in "quotes" (Single oder Double) eingeschlossen sind) in meinem Beispiel im "usage screen" des Skripts:
Code:
Name="FRITZ!Box\\ 7490"
Hier wird also das Leerzeichen "maskiert" - das "!" muß (an dieser Stelle) tatsächlich nicht maskiert werden, obwohl es im Shell-Grammar ein "reserved word" ist (steht irgendwo am Beginn noch anders, da war es aber auch noch ein anderes Skript).

In den oben gezeigten Einträgen ist also das Maskieren entweder überflüssig (ja, das Ende im ersten Beispiel wäre sogar ein Syntax-Fehler - damit würde ja das "double-quote" maskiert, wenn die Auswertung nicht durch ein "eval" erfolgen würde, was auch der Grund dafür ist, daß hier doppelte Escapes anzugeben sind anstelle eines einzelnen) oder es fehlt das Zeichen, welches tatsächlich eine besondere Bedeutung hätte.

Es schadet zwar auch nichts, wenn ein einzelnes Zeichen (hier dann die 7 im zweiten Beispiel oben) am Ende maskiert wird, solange das keine spezielle Bedeutung hat ... dann wird das Maskieren einfach ignoriert. Aber es irritiert dann doch irgendwie ...
 
  • Like
Reaktionen: cbeckstein und bino
Top! Danke @PeterPawn !

Aber eine generelle Frage noch: hast du mit den Änderungen einen Downloadpfad für die aktuelle 07.08 ausgeworfen bekommen?
 
Nein, habe ich nicht ... ich tippe mal, die ist nicht für den JUIS gedacht oder AVM hat die Tests ausgeweitet.

Hat das schon mal jemand mit einer realen 7590 (wo dann alles, außer "Version", den richtigen Wert hat) getestet?

Auch bei der 6490 hat AVM ja in der Labor-Phase irgendwelche zusätzlichen Tests verwendet, denn ich glaube kaum, daß man für die (halböffentlichen) Beta-Tester irgendeinen anderen Mechanismus hatte.
 
Mit der realen 7590 wird nichts gefunden. Von der 06.98 verweist das Skript nur auf die 60985-Inhaus und ansonsten auf die 154.07.01. Von der 07.01. aus keine Treffer.
 
Gibts die korrigierte Version zum download, oder muss sie noch getestet werden?

Harry
 
Gemeint ist das PeterPawn's Github, siehe seine Signatur.
 
Prima Tool... vielen Dank.
Ich habe dazu eine Frage, die vielleicht gar nicht direkt mit dem Tool zu tun hat sondern eventuell mit AVM dahinter.

Müsste nachfolgend die Box mit r67223 nicht das Update auf r67449 anzeigen?

Code:
Checking for updates for fritz784 (inhouse):
 Es wurde keine neue Version gefunden, die Prüfung erfolgte ausgehend von der Version '154.07.08-67223'.
Checking for updates for fritz785 (inhouse):
 Es wurde keine neue Version gefunden, die Prüfung erfolgte ausgehend von der Version '154.07.08-67449'.
 
Welches Update für welche Ausgangsversion von AVM "angeboten" wird, entscheidet nur der JUIS ... und wenn dort ein "Update-Pfad" nicht hinterlegt ist (das Feld "Buildtype" im SOAP-Request kann noch deutlich andere Inhalte haben, es gibt auch Werte für "Labor", "PHONE", "Beta" und "PLUS"), wird die JUIS-Abfrage den auch nicht ausgeben.

Nur die Angabe der alten Version reicht also auch nicht für den "Vergleich", wenn man vermutet, daß es einen solchen Update-Pfad geben sollte ... man muß immer auch das "Buildtype"-Feld zusätzlich im Auge haben.

Die derzeit veröffentlichte Version von "juis_check" verwendet allerdings nur die "Buildtype"-Werte "1001" für die öffentliche und "1000" für die Inhouse-Abfragen ... andere Werte (z.B. "1004" für PHONE-Versionen wie die 113.06.98-54015 oder auch die "stinknormale" Version mit der einfachen "1" für eine Release-Version als Ausgangspunkt) kann bisher nur eine unveröffentlichte (und weiterhin zu testende) Version, die ich bei mir hier einsetze.

Leider kann man solche Fälle immer nur zu bestimmten Zeiten testen ... eine Beta-Version wird eben vom JUIS nur solange angezeigt, wie es noch keine neuere Release-Version gibt und bei der Bewertung der Ergebnisse bzw. Antworten ist man auch immer etwas aufs Raten angewiesen, ob das nun alles richtig ist oder nicht. Daher lasse ich die öffentliche Version lieber noch so, wie sie im Moment ist ... besser als die Leute zusätzlich zu verwirren mit weiteren Optionen.
 
Vielen Dank für die Info.
Es geht darum, dass eine ältere Inhouse keine neuere Inhouse findet (also beides Buildtype 1000).
 
Falls mal jemand die Signatur unter einer JUIS-Antwort überprüfen will, braucht er dazu den öffentlichen Teil des Schlüsselpaars, mit dem die Signatur erzeugt wurde.

Den hat AVM nicht in irgendeiner Datei abgelegt, sondern direkt in die "libjuisclient.so" eingebaut.

Extrahiert man den dort, erhält man den Modulus und den Exponenten:
Code:
vidar:/home/peh $ openssl rsa -in juis_pubkey.pem -pubin -text -noout
Public-Key: (2048 bit)
Modulus:
    00:a0:e5:3a:fd:61:08:82:c3:ab:be:b3:07:1b:98:
    ac:08:bf:bc:e1:c6:12:da:9f:25:41:f0:d0:e9:11:
    ab:dc:a2:67:a7:3d:75:8b:d5:85:74:47:37:27:35:
    8b:91:67:25:40:75:d6:21:d2:1c:ca:e2:33:6e:bb:
    87:52:bb:2d:13:01:08:d3:08:29:f8:b8:60:23:63:
    96:77:2d:b1:c8:57:51:08:65:74:4e:30:dc:7b:80:
    5e:75:1a:ba:e6:aa:95:fa:81:91:ef:ca:d6:aa:f4:
    a2:55:8a:e0:e2:cb:b2:6e:5b:43:d2:f0:ec:59:5f:
    5f:3c:02:99:3b:5a:05:93:85:1b:31:42:48:bd:d7:
    74:c3:80:62:a0:8d:ea:dc:02:9d:ff:75:1e:a3:83:
    33:24:bc:d8:c2:c7:49:c4:ca:d9:97:e5:9f:54:a0:
    5a:1b:2f:aa:3c:10:8a:b6:f2:bd:76:a1:fd:f8:a2:
    17:54:ac:01:97:4b:c0:bc:f5:ba:81:9b:93:93:6a:
    6c:82:16:98:3b:78:5f:a1:18:6e:04:af:df:c0:58:
    09:85:94:2b:6a:f7:66:35:5c:7c:93:a4:98:48:10:
    bc:2a:c7:ee:cc:a7:e4:0f:c9:e6:0b:f8:aa:63:84:
    a4:fb:0b:bc:65:a9:3f:0c:d2:f4:86:5c:86:10:c1:
    be:73
Exponent: 65537 (0x10001)
vidar:/home/peh $
Wer den Key gleich im PEM-Format erhalten möchte, kann sich der Datei im Anhang bedienen ... nicht vergessen, diese nur mit der Erweiterung "pem" zu speichern oder jeweils das korrekte Format mit anzugeben. Umformen in andere Formate kann man die dann leicht selbst.
 

Anhänge

  • juis_pubkey.pem.txt
    451 Bytes · Aufrufe: 58
  • Like
Reaktionen: TomTomNavigator
Ich denke mal, ich habe jetzt alles durchgetestet, was mir so in die Finger kam ... mit Linux-CLI-Tools (von anderen) ist keine erfolgreiche Prüfung der Signatur einer Antwort möglich bzw. gelingt zumindest mir eine solche einfach nicht. Man müßte sich ein eigenes Tool dafür schreiben - man könnte zumindest eine XML-Signatur-Library benutzen, auch wenn da die Auswahl ebenfalls nicht allzu riesig ist, wenn man nicht gerade mit Java unterwegs ist (denn für die diversen Application-Server gibt es mehr Implementierungen, als ich mir anzuschauen bereit war - bis hin zum Websphere-Server von IBM).

Das noch am besten geeignete Paket (xmlsec) scheitert in der Linux-Version daran, daß es den XML-Node mit der ID "Body" nicht erfolgreich über die XPointer-Interfaces der "libxml2" selektieren kann - in der .NET-Version soll es angeblich funktionieren.

Selbst der Versuch, es "von Hand" zu verifizieren, scheitert daran, daß es kein vernünftiges Tool zur "Canonicalization" gibt, welches ein Format erzeugen würde, das man an "sha256sum" verfüttern könnte. Versucht man es mit "xmllint" und der Option "--exc-c14n", kann man parallel keinen "xpath"-Ausdruck verwenden (mit
Code:
--xpath '//*[@ID="Body"]'
kriegt man wenigstens noch den Node mit der ID "Body" selektiert, wenn man "xmllint" verwenden will) und solange man das nicht beides beim selben "xmllint"-Aufruf abhandeln kann, fehlt entweder nach dem "--exc-c14n" die Namespace-Definition im "Body"-Element (weil die bereits im "Envelope" steht und nicht wiederholt wird) oder (nach der Selektion per "--xpath" für den "Body") die gesamte Definition für den Namespace "soap", woraufhin dann das "xmllint" wieder die Arbeit mit der Option "--exc-c14n" verweigert, weil das XML-Dokument nicht mehr gültig ist.

Zwar kann man die Signatur einer Antwort mit dem öffentlichen Schlüssel dann auch erfolgreich decodieren:
Code:
vidar:/home/peh $ sed -n -e "s|.*<SignatureValue>\(.*\)</SignatureValue>.*|\1|p" juis_answer.xml | base64 -d | openssl rsautl -verify -inkey /home/GitHub/YourFritz/juis/juis_pubkey.pem -pubin -asn1parse
    0:d=0  hl=2 l=  49 cons: SEQUENCE
    2:d=1  hl=2 l=  13 cons:  SEQUENCE
    4:d=2  hl=2 l=   9 prim:   OBJECT            :sha256
   15:d=2  hl=2 l=   0 prim:   NULL
   17:d=1  hl=2 l=  32 prim:  OCTET STRING
      0000 - 22 d9 be 0e 4b 12 de 42-6a 1a f3 ac d7 fa 7a 73   "...K..Bj.....zs
      0010 - e6 d9 ac da b4 fb f4 06-3f 22 a2 6f 72 e2 0f d6   ........?".or...
vidar:/home/peh $
, aber für das Berechnen des eigenen Hash-Wertes zur Kontrolle (sowohl für die "DigestValue" als auch die "SignatureValue") braucht es eben die funktionierende Canonicalization nach "exc-c14n" (https://www.w3.org/TR/xml-exc-c14n/) und die baue ich garantiert nicht nach in Shell-Code mit irgendwelchen Hilfsprogrammen. Leider ist "xmllint" da auch nicht wirklich hilfreich, weil das schon bei der "xpath"-Option nicht mit XML-Namespaces umgehen kann, selbst wenn die alle passend in der XML-Datei (bis rauf zum Root-Element) zu finden wären.

Mein Fazit wäre es daher, daß es mit Standard-Tools (wozu ich auch noch "openssl" oder "xmlsec" zählen würde) wohl nichts wird mit der Überprüfung der Signatur in einer JUIS-Antwort. Bleibt noch die Option, sich dafür ein kleines Tool in C zu schreiben ... oder "xmlsec" doch noch dazu zu bringen, daß über "libxml2" erfolgreich der richtige Node auch bei der "#id"-Syntax im URI-Attribut eines "Reference"-Elements selektiert werden kann.
 
Es gibt eine neue Version von juis_check, allerdings steht sie (bis morgen) nur in einem gesonderten Branch und wartet auf Tester - sollte ich keine Klagen lesen, werde ich den morgen dann irgendwann in den master-Branch mischen.

Was hat sich geändert?

Es gibt jetzt einen Parameter Buildtype, mit dem man den gewünschten Entwicklungszweig für die Abfrage bei AVM festlegen kann. Das geht entweder direkt numerisch (wenn man den Wert im Kopf hat) oder über ein paar vordefinierte Namen für die bisher (am häufigsten) gesehenen Geschmacksrichtungen von AVM-Firmware.

Folgende Werte sind dabei hinterlegt (Groß-/Kleinschreibung spielt keine Rolle):
Code:
Bezeichnung   Wert
--------------------
RELEASE       1 (das ist auch Standard, falls der Wert nicht von der Box gelesen wurde)
LABOR         1001
BETA          1001
LABBETA       1001
PLUS          1007
LABPLUS       1007
INHOUSE       1000
INHAUS        1000
PHONE         1004
LABPHONE      1004
Werte, die in dieser Liste nicht auftauchen, kann man selbst als Zahl angeben (der Wertebereich für Buildtype wäre bei AVM eine ein- bis fünfstellige Nummer, sagt zumindest der JUIS bei falschen Angaben) - die gleichzeitige Angabe von Buildtype und Public ist nicht möglich. Generell sollte Public nicht mehr verwendet werden (dann wird z.B. bei Puma6-Boxen auch mal keine neue Firmware gefunden, obwohl es sie gibt) und stattdessen von jetzt an Buildtype angegeben werden.

Außerdem wurde noch die Behandlung von Leerzeichen innerhalb eines Parameterwertes verbessert, Genaueres steht im Hilfe-Bildschirm des Skripts, den man mit juis_check -h anzeigen lassen kann.

Last, but not least ... neben ein paar anderen, kleineren Verbesserungen wird jetzt auch bei Netzwerk-Problemen früher eingegriffen und diese werden (ausgehend von einer Antwort, die gar keine Daten enthält) jetzt gesondert ausgewiesen, mit einem zusätzlichen Exit-Code (dessen Wert dann 5 wäre) signalisiert und die weitere Verarbeitung wird dann auch sofort abgebrochen. Damit gibt es keine "unerwarteten Daten" mehr vom Server, wenn da gar keine Kommunikation stattgefunden hat. Nur wenn der Server auch antwortete, bleibt's beim bisherigen Fehler 4.

========================================================

Aber auch der neue Buildtype-Parameter führt natürlich nicht dazu, daß man damit automatisch über alle Versionsnummern nach der aktuellen Labor-/Inhouse-Reihe suchen kann - letztlich ist das Skript von der AVM-Antwort abhängig und da wird nur dann (bisher) eine neue Version signalisiert, wenn die Versionsnummer (bis hin zu Patch, was im Moment die 24 aus der Angabe 07.24 wäre) auch paßt.

Ich weiß nicht, ob andere Implementierungen das anders handhaben ... aber da die Versionsnummer, mit der AVM gemeinhin eine Inhouse- oder Labor-Reihe startet, nicht festgelegt ist und auch nicht (exakt!) vorhergesagt werden kann und obendrein das juis_check eigentlich nicht zum "blinden Probieren" gedacht war/ist (das steht hier im Thread schon weiter vorne sehr deutlich), sehe ich keine (verläßliche) Möglichkeit (und auch keine Notwendigkeit), da irgendwelche "Heuristiken" einzubauen.
 
Es gibt jetzt einen Parameter Buildtype, [...]

Ah, sehr schön! Hatte dein altes Tool für mich dbzgl. schon "schmutzig" gepatcht gehabt:
Diff:
--- juis_check    2020-10-15 15:31:56.075053953 +0200
+++ juis_check_enhc    2020-10-15 20:08:42.831701054 +0200
@@ -148,7 +148,9 @@
         __nl "            z.B. (derzeitiger Stand, kann sich bei AVM jederzeit ändern) die Angabe von"
         __nl "            'cable_retail', damit man eine sinnvolle Antwort erhält"
         __nl "-----------------------------------------------------------------------------------------------"
-        __nl "$inhouse_option_name      '1', um nur nach offziellen Versionen zu suchen oder '0', um auch die sogenannten"
+##NDhED_ON
+        __nl "$inhouse_option_name      z.B. '1' oder '9', um nur nach offziellen Vers. zu suchen oder '0', um auch die sog."
+##NDhED_OFF
         __nl "            'Inhouse'-Versionen (zumindest bei einigen dieser Firmware-Einträge steht dann ein"
         __nl "            'Inhouse' oder 'Inhaus' auch in der Beschreibung der Version in der SOAP-Antwort,"
         __nl "            daher habe ich diese Benennung irgendwann mal übernommen) zu finden, für die AVM"
@@ -281,7 +283,9 @@
         __nl "Country     the ITU recommended country code (E.164)"
         __nl "Flag        a comma-delimited list of flags to be included into the request"
         __nl "-----------------------------------------------------------------------------------------------"
-        __nl "$inhouse_option_name      '1' to check only for public versions, '0' to accept 'inhouse builds' instead"
+##NDhED_ON
+        __nl "$inhouse_option_name      e.g. '9' to check only for public retail vers., '0' to accept 'inhouse builds' instead"
+##NDhED_OFF
         __nl "-----------------------------------------------------------------------------------------------"
         __nl "Nonce       this parameter is strictly optional, its absence will not trigger any attempt to"
         __nl "            read from the 'Box' device and its value isn't checked further (has to be a Base64"
@@ -390,12 +394,26 @@
L10N_ERR_002_de="Die IP-Adresse oder der DNS-Name der FRITZ!Box fehlt in den Parametern."
L10N_ERR_003_en="Error reading '%%s' from FRITZ!Box device with address '%%s:%%s'."
L10N_ERR_003_de="Fehler beim Lesen der Geräteparameter (%%s) von der FRITZ!Box mit der Adresse '%%s:%%s'."
-L10N_ERR_004_en="'%%s' item may only be empty or set to a fixed boolean value."
-L10N_ERR_004_de="Der Wert für '%%s' muß leer sein oder fest auf '0' oder '1' (bzw. 'false' oder 'true') gesetzt werden."
+##NDhED_ON
+L10N_ERR_004_en="'%%s' item may only be empty or set to a fixed boolean value:
+0/false = Buildtype 1000 (Intern/Inhaus)
+1       = Buildtype 1001 (Labor/LabBETA)
+6       = Buildtype 1006 (Test)
+7       = Buildtype 1007 (Plus/LabPLUS)
+9/true  = Buildtype 1    (Retail) -> Standardvalue"
+L10N_ERR_004_de="Der Wert für '%%s' muß leer sein oder fest auf '0', '1', '6', '7' oder '9' (bzw. 'false' oder 'true') gesetzt werden:
+0/false = Buildtype 1000 (Intern/Inhaus)
+1       = Buildtype 1001 (Labor/LabBETA)
+6       = Buildtype 1006 (Test)
+7       = Buildtype 1007 (Plus/LabPLUS)
+9/true  = Buildtype 1    (Retail) -> Standardwert"
+##NDhED_OFF
L10N_ERR_005_en="Unknown setting '%%s' found at command line."
L10N_ERR_005_de="Der Parameter '%%s' ist unbekannt."
-L10N_ERR_006_en="The '%%s' item has to be set to '0' for 'inhouse versions' or '1' for others."
-L10N_ERR_006_de="Der Wert für '%%s' kann nur '0' für die Suche nach internen Versionen sein, ansonsten ist '1' die einzige gültige Alternative und auch gleichzeitig der Standardwert."
+##NDhED_ON
+L10N_ERR_006_en="The '%%s' item has to be set to '0' for 'inhouse versions' or '1', '6', '7' and '9' for others."
+L10N_ERR_006_de="Der Wert für '%%s' kann nur '0' für die Suche nach internen Versionen sein, ansonsten ist '1', '6', '7' und '9' die einzige gültige Alternative und '9' der Standardwert."
+##NDhED_OFF
L10N_ERR_007_en="Unexpected data received from network."
L10N_ERR_007_de="Es wurden Daten mit einem unerwarteten Format empfangen vom Server."
L10N_ERR_008_en="Unexpected error code %s returned from %s."
@@ -649,7 +667,9 @@
# special 'boolean' option, usable to retrieve internal updates from AVM' servers, if they're published
# via JUIS - finally it modifies the 'buildtype' parameter of our SOAP request
# the (variable's) name and meaning are a little bit confusing, but really 'true' or 'false' in shell
-# syntax  ... a value of "1" means "no inhouse version" (or 'inhouse=false') and "0" searches for non-public
+##NDhED_ON
+# syntax  ... a value of e.g. "1" or "9" means "no inhouse version" (or 'inhouse=false') and "0" searches for non-public
+##NDhED_OFF
# versions
inhouse_option_name="Public"
# nonce variable name for response signature
@@ -1334,16 +1354,27 @@
     elif [ "$n" = "$inhouse_option_name" ]; then
         if ! [ -z "$var" ]; then
             d="$(printf -- "%s\n" "$var" | sed -e "y/AEFLRSTU/aeflrstu/")"
+##NDhED_ON
+#            [ "$(printf -- "%s\n" "$d" | sed -n -e "s|^false\$|0|p")" = "0" ] && var=0
+#            [ "$(printf -- "%s\n" "$d" | sed -n -e "s|^true\$|1|p")" = "1" ] && var=1
             [ "$(printf -- "%s\n" "$d" | sed -n -e "s|^false\$|0|p")" = "0" ] && var=0
             [ "$(printf -- "%s\n" "$d" | sed -n -e "s|^true\$|1|p")" = "1" ] && var=1
-            if ! [ "$var" = "0" ] && ! [ "$var" = "1" ]; then
+            [ "$(printf -- "%s\n" "$d" | sed -n -e "s|^true\$|6|p")" = "6" ] && var=6
+            [ "$(printf -- "%s\n" "$d" | sed -n -e "s|^true\$|7|p")" = "7" ] && var=7
+            [ "$(printf -- "%s\n" "$d" | sed -n -e "s|^true\$|9|p")" = "9" ] && var=9
+#            if ! [ "$var" = "0" ] && ! [ "$var" = "1" ]; then
+            if ! [ "$var" = "0" ] && ! [ "$var" = "1" ] && ! [ "$var" = "6" ] && ! [ "$var" = "7" ] && ! [ "$var" = "9" ]; then
+##NDhED_OFF
                 __emsg "$(__get_localized ERR_004)" "$inhouse_option_name"
                 exit 1
             else
                 eval $inhouse_option_name=$var
             fi
         else
-            eval $inhouse_option_name=1
+##NDhED_ON
+#            eval $inhouse_option_name=1
+            eval $inhouse_option_name=9
+##NDhED_OFF
         fi
     elif [ -z "$var" ] || [ "$var" = "detect" ]; then
         val="$(extract_xml "$boxinfo" "$ns" $n)"
@@ -1416,12 +1447,21 @@
# prepare additional variables                                                                        #
#                                                                                                     #
#######################################################################################################
+##NDhED_ON
[ -z "$(eval printf "%s" "\$$inhouse_option_name")" ] && eval $inhouse_option_name=1
-if ! [ "$(eval printf "%s" "\$$inhouse_option_name")" = "0" ] && ! [ "$(eval printf "%s" "\$$inhouse_option_name")" = "1" ]; then
+#if ! [ "$(eval printf "%s" "\$$inhouse_option_name")" = "0" ] && ! [ "$(eval printf "%s" "\$$inhouse_option_name")" = "1" ]; then
+if ! [ "$(eval printf "%s" "\$$inhouse_option_name")" = "0" ] && ! [ "$(eval printf "%s" "\$$inhouse_option_name")" = "1" ] && ! [ "$(eval printf "%s" "\$$inhouse_option_name")" = "6" ] && ! [ "$(eval printf "%s" "\$$inhouse_option_name")" = "7" ] && ! [ "$(eval printf "%s" "\$$inhouse_option_name")" = "9" ]; then
+##NDhED_OFF
     __emsg "$(__get_localized ERR_006)" "$inhouse_option_name"
     exit 1
fi
-eval type="100\$$inhouse_option_name"
+##NDhED_ON
+if [ "$(eval printf "%s" "\$$inhouse_option_name")" = "9" ]
+    then eval type="1"
+else
+    eval type="100\$$inhouse_option_name"
+fi
+##NDhED_OFF
if [ -z "$HW" ]; then
     __emsg "$(__get_localized ERR_014)"
     exit 4


Die Anwendung damit per "Public" sah dann so aus:
Rich (BBCode):
0 oder false = Buildtype '1000' (Intern/Inhaus)
1            = Buildtype '1001' (Labor/LabBETA)
6            = Buildtype '1006' (Test)
7            = Buildtype '1007' (Plus/LabPLUS)
9 oder true  = Buildtype '1'    (Retail), Standardwert


Fehlt bei dir noch "Test" (1006). Aber da man nun auch selbst (5-stellige) Werte vorgeben kann, braucht es das auch nicht.
 
Fehlt bei dir noch "Test" (1006).
Das habe ich absichtlich ausgelassen - gibt es (zumindest nach boxmatrix.info) nur für 5530 und 6850 und war wohl irgendwie die allererste Version.

Ist mir aber auch egal ... die Liste mit den "bekannten" Namen ist jetzt schon lang genug (ich war schon bei den Alternativen für dieselben Werte anfangs skeptisch) und ich glaube kaum, daß jemals eine solche Suche mit Buildtype=1006 notwendig oder gar erfolgreich sein wird.

Eigentlich war ich sogar der Ansicht, das wäre die hexadezimale Darstellung irgendeines 16-Bit-Wertes und da wären eben irgendwelche Bits gesetzt für bestimmte Fähig- oder Abhängigkeiten (z.B. "es gibt eine Folgeversion" oder "Downgrade möglich" oder etwas in der Richtung) - aber die Fehlermeldung bei falschem Aufbau spricht tatsächlich von 1-5 Ziffern und damit ist "hexadezimal" schon mal draußen.

Dann wird das also irgendeine "willkürliche" Nummerierung sein (die 1000 wäre ja auch wieder "typisch menschlich") und dann fehlen da wohl auch noch die 1002, 1003, 1005, usw. - ich würde zumindest annehmen, daß da ab 1000 dann wieder sequentiell nummeriert wurde.

Genau die Tatsache, daß man da unbekannte (oder wenig genutzte/bekannte) Werte auch direkt angeben kann, gab letztlich auch den Ausschlag dafür, daß jetzt so umzusetzen. Ich hatte tatsächlich zuerst auch eine Erweiterung von Public in Erwägung gezogen (und vor knapp 2 Jahren auch schon mal angefangen, was ich erst letztens dann nach GitHub gepusht hatte als Beispiel für jemanden), aber nach ein paar zusätzlichen Denkrunden (Rückwärtskompatibilität, Notwendigkeit zum Merken irgendwelcher Zahlen, Erweiterbarkeit für bisher unbekannte Werte, etc.) bin ich dann dabei gelandet ... und bisher eigentlich auch ganz zufrieden mit dem Ergebnis. :)

Auch das mit dem --show-response war/ist eigentlich mehr Spielerei für diejenigen, die das tatsächlich "von Hand" aufrufen und das Ergebnis genauer sehen wollen - aber da ich das auch schon ein paar Male mit --save-response aufgerufen hatte, nur um diese Datei danach an den Linter zu verfüttern, ist das noch eine "gängige Benutzung" und solange die nur aus so wenigen Zeilen besteht, ist mir das "Aufblähen" auch egal ... selbst wenn ich sonst gerne bei "one tool - one job" bin.
 
... und ich glaube kaum, daß jemals eine solche Suche mit Buildtype=1006 notwendig oder gar erfolgreich sein wird.

Wie das in Zukunft aussehen wird, weiß ich natürlich nicht. Aber in der Vergangenheit hatte ich schon min. einen Fall, wo man nur mit dem Buildtype 1006 eine erfolgreiche Antwort erhalten hatte, für die bereits erwähnte 6850 5G:
XML:
Request:
Date/Time:    2020-12-14_18-11-45
HW-Revision:  258
Modell:       FRITZ!Box68505G
FW-Version:   258.07.24-0
Branding:     avm
Buildtype:    1006
Annex:        Ohne
Flag:         empty
Language:     de
Country:      049
Serial:       000000000000
IP-Adress:    empty
Tool:         juis_check_enhc
Debug:        false

Response JUIS:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
  <soap:Body ID="Body">
    <ns2:BoxFirmwareUpdateCheckResponse xmlns:ns2="http://juis.avm.de/updateinfo" xmlns:ns3="http://juis.avm.de/response" xmlns:ns4="http://juis.avm.de/request">
      <ns2:ResponseUpdateInfo>
        <ns3:ResponseHeader>
          <ns3:Nonce>xxxxxxxxxxxxxxxxxxxxxx==</ns3:Nonce>
        </ns3:ResponseHeader>
        <ns3:UpdateInfo>
          <ns3:CheckInterval>48</ns3:CheckInterval>
          <ns3:Found>true</ns3:Found>
          <ns3:Name> EXTERN LabTest Provider</ns3:Name>
          <ns3:Version>258.07.24-84474 LabTEST</ns3:Version>
          <ns3:Type>1</ns3:Type>
          <ns3:DownloadURL>*beep*//download.avm.de/labor/PSQ19Phase2/68505G/FRITZ.Box_6850_5G-07.24-84474-LabTEST.image</ns3:DownloadURL>
          <ns3:InfoURL>*beep*//download.avm.de/labor/PSQ19P2/7590/infolab.txt</ns3:InfoURL>
          <ns3:InfoText/>
          <ns3:HintURL/>
          <ns3:IconURL/>
          <ns3:Priority>1</ns3:Priority>
          <ns3:AutoUpdateStartTime>1800</ns3:AutoUpdateStartTime>
          <ns3:AutoUpdateEndTime>19800</ns3:AutoUpdateEndTime>
          <ns3:AutoUpdateKeepServices>true</ns3:AutoUpdateKeepServices>
        </ns3:UpdateInfo>
      </ns2:ResponseUpdateInfo>
    </ns2:BoxFirmwareUpdateCheckResponse>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
        <Reference URI="#Body">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
          <DigestValue>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==</SignatureValue>
    </Signature>
  </soap:Body>
</soap:Envelope>

Mit den anderen Buildtypes gab es damals keinen FW-Fund. Also bzgl. "erfolgreich" kann ich wiedersprechen. Aber ob auch "notwendig", das wäre eine andere Frage. ;)

Scheint wohl so zu sein, dass dieser FW-/Build-Type mitunter für Geräte im Feldtest bei Providern verwendet wird, wie bspw. bei der 5530.
 
Auch die 7581 findet mit 1006-Test die aktuelle Firmware: download.avm.de/labor/MESH18NL3/7581/FRITZ.Box_7581-07.13-84683-LabPLUS.image
Allerdings auch gleich wieder eine Einschränkung der Sinnhaftigkeit, da man diese auch mit 1007-Plus ebenso findet.
Hingegen findet die 7582 weder mit Test noch Plus nur irgendetwas, da muß man die beiden LabPlus Links genau kennen, 83377 und 84684.
Ich erwähne dies, da die Builds der letzten Version wie man sehen kann sehr ähnlich sind, ähnl. 7490/7590.
 
Zuletzt bearbeitet:
Allerdings auch gleich wieder eine Einschränkung der Sinnhaftigkeit, da man diese auch mit 1007-Plus ebenso findet.

Eben. Es geht wohl eher darum, wenn man ausschließlich mit dem Buildtype 1006 eine Antwort für eine bestimmte FW erhält (so wie in dem Beispiel aus #278). Das ist bei deinem Beispiel jedoch nicht der Fall (da gibt es meiner Erinnerung nach auch noch einige weitere Fälle).
 
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.