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

Nachdem ich gemäß dieser Anleitung die Linux-Bash installiert und nach joe_57's Anleitung hier auf Stand gebracht habe, bekomme ich nach Aufruf von
Code:
./juischeckupdate.sh 192.168.178.1
eine Fehlermeldung:
Code:
./juischeckupdate.sh: line 104: syntax error near expected token `$'\r''
`append()
Der Error kommt unabhängig vom Aufruf (d.h. mit oder ohne Box-IP).

Hab ich irgendwas vergessen?

Gruß
HSishi
 
Falschen Editor verwendet ... das Skript hat nun offenbar DOS-Zeilenenden (0x0D0A) und damit kann der Shell-Interpreter nicht.
 
Eh ... d.h. ich muss das im Editor dann anders abspeichern bzw. konvertieren.
Mein Notepad++ zeigt mir "Windows (CR LF)" an - richtig wäre "Unix (LF)"?
 
Umwandeln/Konvertieren in: Unix (LF)/UTF-8 ohne BOM
 
NotePad++ bietet direkt in der Statuszeile eine Konvertierung über Rechtsklick an; die Optionen sind "Windows (CR LF)", "UNIX (LF)" und "Mac (CR)". Die Unix-Option ist die richtige, danke für die beiden "Schubse" in die Richtung.
Nachzutragen ist noch, daß das auch für's Config-File gilt, sonst kommt der nächste Fehler.

Ausgeführt ohne Optionsangabe findet das Script nur die Release-Version .83 für die 7490, also muss ich etwas mit den Versionen spielen, da ich was Bestimmtes suche ...
 
Ich möchte (weil ich gerade am Skript etwas herumändere und mich für eine Version entscheiden mußte bei der Weiterentwicklung) noch einmal explizit auf die neuere Version "juis_check" anstelle des ursprünglichen "juischeckupdate" aufmerksam machen (s. EDIT in #1).

Diese braucht zwar anstelle der "bash" (für den TCP-Zugriff) wieder ein "nc"-Kommando (aber ohne die Unterstützung spezieller Optionen), aber dafür verwendet sie nur POSIX-kompatible Shell-Konstrukte und sollte auch auf einem System, wo "dash" als "/bin/sh" verlinkt ist, auf Anhieb funktionieren (wenn der Rest der Voraussetzungen erfüllt ist) - außerdem verwendet sie kein "xmllint", was bei einigen Installationen auch erst nachinstalliert werden muß (die Antworten sind simpel genug aufgebaut, da kann man mit "sed" noch die Daten recht zuverlässig extrahieren). Daher werde ich weitere Änderungen auch nur noch an dieser Version vornehmen.
 
Bei den neuen Betaversionen 6.88 scheint hier irgendetwas anders zu funktionieren, als bisher (?) Das Script findet kein Update, aber die Update-Suche in der Box hingegen schon...
 
Wenn ich Zeit finde, werde ich mir die neuen Versionen mal ansehen und die Abfragen mitschneiden - ist normalerweise nicht so meins, gleich bei den ersten Zuckungen von AVM auf solche (i.d.R. noch recht unfertigen) Entwicklungen anzuspringen. Aber wenn es auch an dieser Stelle Änderungen gibt, bleibt mir wohl nichts anderes übrig. :-(
 
  • Like
Reaktionen: Micha0815
Ich kann kein Problem bei der Suche nach Updates aus der "Mesh-Reihe" finden (zumindest nicht bei der zum Test verwendeten 7490) ... das ergibt aktuell bei mir (die Version vom Freitag ist noch nicht installiert):

Code:
# juis_check fb7490
Found newer version : 113.06.88-45942 Labor
URL=x:[email protected]/labor/Mesh-Labor/FRITZ.Box_7490_LabBETA.113.06.88-45942.image

Ich interpretiere das also als einen "Schluckauf" zwischendrin ... solange das nicht erneut auftritt, betrachte ich es als "erledigt".
 
  • Like
Reaktionen: SnoopyDog
Inzwischen findet ja auch die Suche nach Updates für DECT- und PLC-Geräte über den JUIS statt ... in der Firmware gibt es dazu ein neues Kommando "device_updatecheck":
Code:
$ device_updatecheck -?
usage: device_updatecheck device_updatecheck [options]
options:
  -?                 - print this help
  -v                 - with infomsg. (NOTSET)
  -t STRING          - type of device: DECT or PLC. (NULL)
  -h STRING          - hardware version (HW) of device (optional). (NULL)
  -m STRING          - manufacturer hardware version (MHW) of device. (NULL)
  -V STRING          - current firmware version of device. (NULL)
  -s STRING          - serial of device. (NULL)
  -l STRING          - language (of user interface) of device (optional). (NULL)
  -D STRING          - switch debug logs on. (FUNC)
DECT example:  device_updatecheck -t DECT -h 123 -m 345 -V 1.2 -s 12345678 -l de
und schneidet man dann dessen Abfragen einmal mit, stellt sich heraus, daß es halt ein anderer SOAP-Request ist (DeviceFirmwareUpdateCheck), während der verwendete Hostname für den Request offenbar weiterhin von der verwendeten Box abhängt:
Code:
POST /Jason/UpdateInfoService HTTP/1.1
Host: 185.jws.avm.de:80
Content-Length: 1156
Content-Type: text/xml; charset="utf-8"


<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:e="http://juis.avm.de/updateinfo" xmlns:q="http://juis.avm.de/request">
<soap:Header/>
<soap:Body>
<e:DeviceFirmwareUpdateCheck>
<e:RequestHeader>
<q:Nonce>tXmSwx0BIcO2srtmn40EfQ==</q:Nonce>
<q:UserAgent>TestClient</q:UserAgent>
<q:ManualRequest>true</q:ManualRequest></e:RequestHeader>
<e:BoxInfo>
<q:Name>FRITZ!Box 7490</q:Name>
<q:HW>185</q:HW>
<q:Major>113</q:Major>
<q:Minor>6</q:Minor>
<q:Patch>88</q:Patch>
<q:Buildnumber>45942</q:Buildnumber>
<q:Buildtype>1001</q:Buildtype>
<q:Serial>0896D7DEADCD</q:Serial>
<q:OEM>avm</q:OEM>
<q:Lang>de</q:Lang>
<q:Country>049</q:Country>
<q:Annex>B</q:Annex>
<q:Flag>prov_acs</q:Flag>
<q:UpdateConfig>1</q:UpdateConfig>
<q:Provider>oma_lan</q:Provider></e:BoxInfo>
<e:DeviceInfo>
<q:Type>2</q:Type>
<q:MHW>03.01</q:MHW>
<q:Version>03.60</q:Version>
<q:Serial>000000000000</q:Serial>
<q:Lang>de</q:Lang></e:DeviceInfo></e:DeviceFirmwareUpdateCheck></soap:Body></soap:Envelope>
Neben dem "BoxInfo"-Abschnitt (der denselben Aufbau hat wie bei der Abfrage für die Box-Firmware, soweit ich das sehe) gibt es also noch einen "DeviceInfo"-Abschnitt. Das "Type" dort ist "1" für DECT und "2" für PLC, aber das interessiert den Service (zur Zeit) wohl nicht wirklich.

Die Seriennummer muß auch nur dem formalen Aufbau genügen (AVM verwendet hier wohl ein Pattern mit dem Namen #AnonType_SerialDeviceInfo und dem Inhalt "(([A-Fa-f0-9]{2}:){5}([A-Fa-f0-9]{2}){1})|(([0-9]{12}){1})" - also entweder eine MAC-Adresse mit Doppelpunkten oder 12 Ziffern aus 0 bis 9) und wird - zumindest außerhalb ggf. speziell eingerichteter Gruppen für bestimmte Tests - auch nicht weiter geprüft.

"MHW" ist halt die Hardware-Version (hier ein MT-F) und bei "Version" hat der Service bei meinen Tests auch problemlos "00.00" geschluckt und mit der aktuellen Version (03.92) geantwortet ... allerdings nur, solange die angeblich installierte Version kleiner als die "03.92" war.

Nun weiß man zwar, wie diese Abfragen funktionieren, aber ich sehe irgendwie keinen brauchbaren Ansatz für ein halbwegs allgemeingültiges Skript, das sich dann auch zur Nachnutzung (außerhalb einer FRITZ!Box, denn da gibt es ja das o.a. "device_updatecheck" ohnehin schon) eignen würde. Im Gegensatz zur Box selbst, kann man die (Hard- und Software-)Version eines DECT-Gerätes ja nicht einfach direkt abfragen und muß ohnehin über die Box gehen, wo die angemeldet sind bzw. bei PLC müßte man auf L2 nach den Teilen suchen. Das macht wenig bis keinen Sinn in meinen Augen ... das kann dann die Box wieder besser und wer "Archivar" ist und praktisch alles sammelt, der muß dann halt über die Box nach "fremden" Versionen suchen lassen oder er paßt sich selbst ein Skript an, welches den oben gezeigten SOAP-Request erzeugt.

PS: Weiß zufällig jemand ohne große eigene Suche, wo man bei Xenforo die automatischen Emojis abstellt? Die nerven, denn das oben ist natürlich ein Doppelpunkt gefolgt von einer schließenden runden Klammer.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: SnoopyDog
[OT]
PS: Weiß zufällig jemand ohne große eigene Suche, wo man bei Xenforo die automatischen Emojis abstellt? Die nerven, denn das oben ist natürlich ein Doppelpunkt gefolgt von einer schließenden runden Klammer.

Früher (vor dem Wechsel der Forensoftware) nutzte ich dafür [noparse]:) ;) :eek: usw.[/noparse] was aber nun nicht mehr funktioniert wie man sieht da mit Xenforo [noparse] ersetzt wurde durch den BBCode [plain], nun also so:

[plain]:) ;) :o usw.[/plain]


Bzw. umgesetzt dann für deinen Fall:

"(([A-Fa-f0-9]{2}:){5}([A-Fa-f0-9]{2}){1})|(([0-9]{12}){1})"

Als Quelltext:
Code:
[plain]"(([A-Fa-f0-9]{2}:){5}([A-Fa-f0-9]{2}){1})|(([0-9]{12}){1})"[/plain]
[/OT]
 
Auch OT:
Danke für die Antwort ... das ist natürlich auch eine Alternative. Gibt es zufällig auch noch eine Einstellung irgendwo (die ich noch nicht gefunden habe), mit der man das Verhalten (also das Parsen nach potentiellen Smilies) generell abstellen kann?

Es ist zwar nicht mehr so häufig nötig, wie noch in vBulletin (da löste ja jede von einer Klammer gefolgte Acht gleich eine Photophobie aus) - aber da ließ es sich eben auch mit einem Klick (zumindest für den Beitrag) abstellen. Es kam zwar hier noch nicht vor, aber wenn man das an mehreren Stellen in einem längeren Text machen soll (daher ja vielleicht die Beschränkung auf 50.000 Zeichen?), schreibt man vermutlich besser gleich von Beginn an ohne Textauszeichnungen und nur noch als "plain".

Ich hatte irgendwann mal probehalber zum BBCode-Editor ohne WYSIWYG gewechselt, da ist die Schriftgröße bei der Eingabe dann allerdings winzig und man hat schon Probleme, ein "m" von einem "n" zu unterscheiden und die liegen ungünstigerweise auch noch nebeneinander auf meinem Keyboard. Bleibt wohl nur noch Spracheingabe ...
 
Jaa :-)

Mein Favorit: Alexa
Beim Fire TV Stick 2 ist noch nicht mal die "Alexa" Ansage nötig.
...einfach Mikroknopf drücken und:
starte IPPF und schreibe in die interessantesten Threadinhalte Ich bin eine Möhre Smile
(Knopf loslassen)
Alexa: Erledigt. Soll ich es noch einmal vorlesen?
(Knopf drücken)
Dankeschön
(Knopf loslassen)
Alexa: Gern geschehen
(Knopf drücken)
Oups, falscher Thread
(Knopf loslassen)
Alexa: Häh?
 
Für etwaige Nachfolgende Leser mit FB6590:
derzeit gibt es ein Problem mit juis_check und FB6590, siehe: https://www.ip-phone-forum.de/threads/freetz-für-6490.276768/page-4#post-2251037 ff.

nachfolgender Hotfix hat für mich das Skript https://github.com/PeterPawn/YourFritz/blob/master/tools/juis_check wieder für die FB6590 nutzbar gemacht:

Code:
fwmod@Linux-VM:~$ sed "s|<q:Flag></q:Flag>|<q:Flag>cable_retail</q:Flag>|" juis_check  >  juis_check_6590
fwmod@Linux-VM:~$ diff juis_check juis_check_6590
102c102
< body_tmpl="<soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:soap-enc=\"http://schemas.xmlsoap.org/soap/encoding/\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:e=\"http://juis.avm.de/updateinfo\" xmlns:q=\"http://juis.avm.de/request\"><soap:Header/><soap:Body><e:BoxFirmwareUpdateCheck><e:RequestHeader><q:Nonce>%s</q:Nonce><q:UserAgent>Box</q:UserAgent><q:ManualRequest>true</q:ManualRequest></e:RequestHeader><e:BoxInfo><q:Name>%s</q:Name><q:HW>%s</q:HW><q:Major>%s</q:Major><q:Minor>%s</q:Minor><q:Patch>%s</q:Patch><q:Buildnumber>%s</q:Buildnumber><q:Buildtype>%s</q:Buildtype><q:Serial>%s</q:Serial><q:OEM>%s</q:OEM><q:Lang>%s</q:Lang><q:Country>%s</q:Country><q:Annex>%s</q:Annex><q:Flag></q:Flag><q:UpdateConfig>1</q:UpdateConfig><q:Provider>oma_lan</q:Provider></e:BoxInfo></e:BoxFirmwareUpdateCheck></soap:Body></soap:Envelope>"
---
> body_tmpl="<soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:soap-enc=\"http://schemas.xmlsoap.org/soap/encoding/\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:e=\"http://juis.avm.de/updateinfo\" xmlns:q=\"http://juis.avm.de/request\"><soap:Header/><soap:Body><e:BoxFirmwareUpdateCheck><e:RequestHeader><q:Nonce>%s</q:Nonce><q:UserAgent>Box</q:UserAgent><q:ManualRequest>true</q:ManualRequest></e:RequestHeader><e:BoxInfo><q:Name>%s</q:Name><q:HW>%s</q:HW><q:Major>%s</q:Major><q:Minor>%s</q:Minor><q:Patch>%s</q:Patch><q:Buildnumber>%s</q:Buildnumber><q:Buildtype>%s</q:Buildtype><q:Serial>%s</q:Serial><q:OEM>%s</q:OEM><q:Lang>%s</q:Lang><q:Country>%s</q:Country><q:Annex>%s</q:Annex><q:Flag>cable_retail</q:Flag><q:UpdateConfig>1</q:UpdateConfig><q:Provider>oma_lan</q:Provider></e:BoxInfo></e:BoxFirmwareUpdateCheck></soap:Body></soap:Envelope>"
fwmod@Linux-VM:~$

mit Configfile:
Code:
fwmod@Linux-VM:~$ cat juis_check_6590.cfg
Box=$1
Serial=000000000000
Version=148.06.83-43781
Name="FRITZ\\!Box\\ 6590\\ Cable"
HW=220
OEM=avm
Lang=de
Annex=Kabel
Country=049
Public=1
fwmod@Linux-VM:~$

liefert den Download-Link zur FB6590 Image Datei:
Code:
fwmod@Linux-VM:~$ bash ./juis_check_6590
Found newer version : 148.06.85
URL=http://download.avm.de/firmware/6590/< SNIP >/FRITZ.Box_6590_Cable.de-en-es-it-fr-pl.148.06.85.image
fwmod@Linux-VM:~$

EDIT: Datei juis_check_6590.cfg gemäß Hinweise #136 von PeterPawn angepasst.
 
Zuletzt bearbeitet:
Mal was ganz anderes ... was sollen die "shift"-Zeilen in der Konfigurationsdatei genau bewirken?
;)
 
Danke für Hinweis!
Datei juis_check_6590.cfg in #135 ist angepasst.
 
Danke Shirocco88, mit deiner kurzen aber genauen Anleitung habe ich es nun auch geschafft.

Kurrios, mit dieser .cfg bekomme ich fast alle Boxen abgefragt. Ich brauche nur die "HW" ändern:
Code:
Serial=egal
Version=1.1.1-1
Name=egal
HW=156
OEM=avm
Lang=de
Annex=egal
z.B. geht da auch die 234 für die FB6890.
 
Zuletzt bearbeitet:
Kurrios, mit dieser .cfg bekomme ich fast alle Boxen abgefragt.
ja, ;-)
das mit Version=1.1.1-1 ist mir neu

ich selber habe keine FB6490, also habe ich gemäß Anleitung einfach alle erforderlichen Werte in die Configdatei gepackt, und Box= leer gelassen, so dass das Skript nicht auf den Einfall kommt irgendwelche Werte per http://$Host.name/juis_boxinfo.xml von der Fritzbox abgreifen zu wollen.

Siehe Skript von PeterPawn:
Code:
fwmod@Linux-VM:~$ cat juis_check
SNIP
# Any missing setting will be read from the FRITZ!Box router, which address or name is contained in   #
# the variable 'Box'. Only if all needed settings are provided otherwise, this read attempt is        #
# skipped.                                                                                            #
SNIP
fwmod@Linux-VM:~$
 
Zuletzt bearbeitet:
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.