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

Daniel Lücking

IPPF-Promi
Mitglied seit
18 Apr 2008
Beiträge
3,491
Punkte für Reaktionen
127
Punkte
63
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:

Daniel Lücking

IPPF-Promi
Mitglied seit
18 Apr 2008
Beiträge
3,491
Punkte für Reaktionen
127
Punkte
63
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
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,050
Punkte für Reaktionen
718
Punkte
113
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

Daniel Lücking

IPPF-Promi
Mitglied seit
18 Apr 2008
Beiträge
3,491
Punkte für Reaktionen
127
Punkte
63
Top! Danke @PeterPawn !

Aber eine generelle Frage noch: hast du mit den Änderungen einen Downloadpfad für die aktuelle 07.08 ausgeworfen bekommen?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,050
Punkte für Reaktionen
718
Punkte
113
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.
 

Daniel Lücking

IPPF-Promi
Mitglied seit
18 Apr 2008
Beiträge
3,491
Punkte für Reaktionen
127
Punkte
63
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.
 

HarryP_1964

Mitglied
Mitglied seit
5 Aug 2017
Beiträge
556
Punkte für Reaktionen
46
Punkte
28
Gibts die korrigierte Version zum download, oder muss sie noch getestet werden?

Harry
 

stoney

Moderator
Teammitglied
Mitglied seit
7 Okt 2015
Beiträge
4,823
Punkte für Reaktionen
337
Punkte
83

H'Sishi

Aktives Mitglied
Mitglied seit
31 Jan 2007
Beiträge
1,979
Punkte für Reaktionen
40
Punkte
48
Gemeint ist das PeterPawn's Github, siehe seine Signatur.
 

myfb7590

Neuer User
Mitglied seit
16 Jan 2019
Beiträge
14
Punkte für Reaktionen
0
Punkte
1
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'.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,050
Punkte für Reaktionen
718
Punkte
113
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.
 

myfb7590

Neuer User
Mitglied seit
16 Jan 2019
Beiträge
14
Punkte für Reaktionen
0
Punkte
1
Vielen Dank für die Info.
Es geht darum, dass eine ältere Inhouse keine neuere Inhouse findet (also beides Buildtype 1000).
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,050
Punkte für Reaktionen
718
Punkte
113
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

  • Like
Reaktionen: TomTomNavigator

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,050
Punkte für Reaktionen
718
Punkte
113
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.
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
232,047
Beiträge
2,018,219
Mitglieder
349,338
Neuestes Mitglied
copsi