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

[bino]

Hallo PeterPawn,

habe Dein Skript ausprobiert, leider klappt etwas noch nicht bei mir.
Bisher habe ich Dein älteres Skript unter Win 10 verwendet (bzw. das Skript von Stoney).
Soviel nebenbei.
Das neue Skript bricht (nach Eingabe von: ./juis_check 192.168.13X.1) mit folgenden Meldungen ab:
: not foundk: 49: ./juis_check: {
./juis_check: 462: ./juis_check: Syntax error: word unexpected (expecting "do")
Die Datei "juis_check" habe ich mit Notepad++ im Format "UTF-8 ohne BOM" gespeichert.
Wo liegt bei mir der Fehler?

Gruß
bino

 

[koyaanisqatsi]

Dankeschön

Hat bei mir, so wie es stoney auch demonstriert hat, auf Anhieb funktioniert.


Meckerecke


Inhalt von LC_ALL und LANG = C
Alternative/Workaround: env -i ./juis_check ...

 

[stoney]

getestet auf freetz-1.4.1

Der Syntax für die "manuelle" Abfrage bzw via config bin ich noch nicht durchgestiegen
(werde ich heute auch nicht mehr )

 

[PeterPawn]

@eisbaerin:
Von der Box selbst (vielleicht noch direkt aus AVM-Versionen heraus) hatte ich die letzten Änderungen nicht mehr getestet, hole ich noch nach - wobei ich hier zuerst auf ein Problem mit dem "nc" tippen würde, denn das sieht mir eher danach aus, daß er gar keinen Kontakt zu der Box aufnehmen kann.

Bei der Sprache hast Du etwas falsch verstanden ... da gilt nicht die Angabe der Sprache des FRITZ!Box-GUI, sondern die Angabe im (Unix-)Environment und dort haben die FRITZ!Boxen gar keinen entsprechenden Eintrag (bzw. der vom FRITZ!OS ist in einer anderen Schreibweise, was groß oder klein anbelangt). Bei "modfs" wird tatsächlich die Sprache aus dem (laufenden) FRITZ!OS zur Entscheidungsfindung genutzt, hier aber (da es meist eher außerhalb der Box eingesetzt (werden) wird), die "übliche" Einstellung unter Unix (auch wenn die "locale"-Funktionen nicht komplett durchgezogen werden).

Wenn Du das also mit deutschen Ausgaben sehen möchtest, müßtest Du (als eine Variante) es so aufrufen:

root@FB7490:~ $ cd /var/tmp/
root@FB7490:/var/tmp $ wget https://raw.githubusercontent.com/PeterPawn/YourFritz/master/juis/juis_check
Connecting to raw.githubusercontent.com (151.101.112.133:443)
juis_check           100% |**************************************************************| 71298   0:00:00 ETA
root@FB7490:/var/tmp $ chmod u+x juis_check
root@FB7490:/var/tmp $ LANG=de_DE.utf-8 ./juis_check -h | cat

juis_check, version 0.3

This script is a part of the YourFritz project from https://github.com/PeterPawn/YourFritz.

Copyright (C) 2010-2018 P.Haemmerlein ([email protected])

This project is free software, you can redistribute it and/or modify it under the terms of the GNU
General Public License as published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License under http://www.gnu.org/licenses/gpl-2.0.html for more details.

Zweck:

Mit diesem Shell-Skript kann man über den AVM-Update-Service (JUIS) nach neuer Firmware
suchen lassen.
[...]
root@FB7490:/var/tmp $

Warum das zusätzliche "cat" am Ende? Bei mir enthält die BusyBox auch ein "less"-Applet ... aber dieses versteht es leider nicht, ANSI-ESC-Sequenzen in der Datei richtig auf das Terminal zu bringen. Daher wird mit dem zusätzlichen "cat" verhindert, daß für das Skript die Ausgabe auf ein Terminal erfolgt (das sieht halt die Pipe als Ziel) und automatisch "less" für die Hilfe-Ausgabe verwendet wird.

Bei mir klappt es von der 7490 aus jedoch ... solange ich bei der "ash" bleibe und damit "nc" verwendet wird. Die BusyBox kann man auch so übersetzen lassen, daß diese "bash" als Synonym für das "ash"-Applet bereitstellt ... allerdings kann das dadurch noch lange das "/dev/tcp" nicht benutzen. Daher (und auch weil ich wirklich eine "bash" auf der Box habe) verhindere ich das "respawn" und erhalte folgendes Ergebnis:

root@FB7490:/var/tmp $ LANG=de_DE.utf-8 ./juis_check -d -n 192.168.13X.1
debug: -------------------------------------------------------
debug: Lesen der Parameter von '192.168.13X.1:80/juis_boxinfo.xml': .
debug: Antwort vom Gerät:
debug: -------------------------------------------------------
       HTTP/1.1 200 OK
       Cache-Control: max-age=120
       Connection: close
       Content-Type: text/xml;charset=utf-8
       Date: Mon, 01 Jan 2018 22:07:38 GMT
       ETag: "FD5545BAFF7CCA002"
       Expires: Mon, 01 Jan 2018 22:09:38 GMT
       Last-Modified: Thu, 28 Dec 2017 17:44:40 GMT
       Mime-Version: 1.0


       <e:BoxInfo xmlns:e="http://juis.avm.de/updateinfo" xmlns:q="http://juis.avm.de/request">
       <q:Name>FRITZ!Box 7490</q:Name>
       <q:HW>185</q:HW>
       <q:Major>113</q:Major>
       <q:Minor>6</q:Minor>
       <q:Patch>92</q:Patch>
       <q:Buildnumber>47565</q:Buildnumber>
       <q:Buildtype>0</q:Buildtype>
       <q:Serial>0896D7CAFEDE</q:Serial>
       <q:OEM>avm</q:OEM>
       <q:Lang>de</q:Lang>
       <q:Country>049</q:Country>
       <q:Annex>B</q:Annex>
       <q:Flag></q:Flag>
       <q:UpdateConfig>1</q:UpdateConfig>
       <q:Provider></q:Provider></e:BoxInfo>
debug: Zusammengesetzte Versionsnummer für die Prüfung: '113.06.92-47565'
debug: -------------------------------------------------------
debug: Werte der Variablen:
debug: -------------------------------------------------------
debug: Serial="0896D7CAFEDE"
debug: Name="FRITZ!Box 7490"
debug: HW="185"
debug: OEM="avm"
debug: Lang="de"
debug: Annex="B"
debug: Country="049"
debug: Major="113"
debug: Minor="6"
debug: Patch="92"
debug: Buildnumber="47565"
debug: Flag=""
debug: Public="1"
debug: type="1001"
debug: hostname="185.jws.avm.de"
debug: nonce="/cEXGZDI/Wruw/QpIpJ1Bg=="
debug: -------------------------------------------------------
debug: Gesendete Abfrage:
debug: -------------------------------------------------------
       POST /Jason/UpdateInfoService HTTP/1.1
       Host: 185.jws.avm.de:80
       Content-Length: 1168
       Content-Type: text/xml; charset="utf-8"
       Connection: close

       <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>/cEXGZDI/Wruw/QpIpJ1Bg==</q:Nonce>
               <q:UserAgent>Box</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>92</q:Patch>
               <q:Buildnumber>47565</q:Buildnumber>
               <q:Buildtype>1001</q:Buildtype>
               <q:Serial>0896D7CAFEDE</q:Serial>
               <q:OEM>avm</q:OEM>
               <q:Lang>de</q:Lang>
               <q:Country>049</q:Country>
               <q:Annex>B</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>
debug: -------------------------------------------------------
debug: Lesen der Antwort von '185.jws.avm.de:80': .
debug: Empfangene Antwort:
debug: -------------------------------------------------------
       HTTP/1.1 200 OK
       Server: nginx
       Content-Type: text/xml;charset=UTF-8
       Content-Length: 1949
       Connection: close
       Download-Delay: 2960
       Date: Mon, 01 Jan 2018 22:07:41 GMT
       Access-Control-Allow-Origin: http://scope.avm.de
       Access-Control-Allow-Headers: content-type

       <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"></SOAP-ENV:Header><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>/cEXGZDI/Wruw/QpIpJ1Bg==</ns3:Nonce></ns3:ResponseHeader><ns3:UpdateInfo><ns3:CheckInterval>48</ns3:CheckInterval><ns3:Found>false</ns3:Found><ns3:Version></ns3:Version><ns3:DownloadURL></ns3:DownloadURL><ns3:InfoURL></ns3:InfoURL><ns3:InfoText></ns3:InfoText><ns3:HintURL></ns3:HintURL><ns3:Priority>1</ns3:Priority><ns3:AutoUpdateStartTime>0</ns3:AutoUpdateStartTime><ns3:AutoUpdateEndTime>0</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#"></CanonicalizationMethod><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod><Reference URI="#Body"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod><DigestValue>napaWFOV8L9uyl+QWEaz3mDY50SVkJoX8t9Apbc49Q8=</DigestValue></Reference></SignedInfo><SignatureValue>aXMzNVYk2NCnJsGyNWEiq1e00mbJXbI47ZdcvMXvUUZ5/6QIfmobxC4pQ6rfMD7GYAp7UnagS11ggCTTijCQjMDkEdkceP+B1gfDx5CUN6IGxv5GQQb8lmWaAnLYXVtcumzu9OU7BlQycKCFTLOBJbJLnVRawmj5zu31XNBR/hRKlE1+z5EG5m6Gz7k7kgIH8sJhB+k/af9s93BrpSXg0Bz+4JrHeT2GffrtUsL/w8qK1I5wW6RXau3NrzISwtvhPLm27e5uSst8uJjTPfb0Yyje+f9AfMebdLjCLycN5OSWwnb5Gsp+p/w+rqa6NzVKa8EUDfXXS6YDXOKXvHE4Pg==</SignatureValue></Signature></soap:Body></soap:Envelope>
debug: -------------------------------------------------------
juis_check: Es wurde keine neue Version gefunden, die Prüfung erfolgte ausgehend von der Version '113.06.92-47565'.
root@FB7490:/var/tmp $

... zumindest in meiner Konfiguration (BusyBox aus dem YourFritz-Repo im "binaries"-Branch, mit "nc"-Applet) funktioniert es also auch irgendwie. Bei der Verwendung der "bash" (ist aber bei mir eben eine "echte"), spinnt dann irgendwo das "sed" beim Auslesen der Daten aus der "juis_boxinfo.xml":

root@FB7490:/var/tmp $ LANG=de_DE.utf-8 ./juis_check -d 192.168.13X.1
debug: Neustart des Skripts mit einer Bash-Shell mit dem Kommando: command bash ./juis_check --debug --no-respawn 192.168.13X.1
debug: -------------------------------------------------------
debug: Lesen der Parameter von '192.168.13X.1:80/juis_boxinfo.xml': .
debug: Antwort vom Gerät:
debug: -------------------------------------------------------
       HTTP/1.1 200 OK
       Cache-Control: max-age=120
       Connection: close
       Content-Type: text/xml;charset=utf-8
       Date: Mon, 01 Jan 2018 22:13:33 GMT
       ETag: "FD5545BAFF7CCA002"
       Expires: Mon, 01 Jan 2018 22:15:33 GMT
       Last-Modified: Thu, 28 Dec 2017 17:44:40 GMT
       Mime-Version: 1.0


       <e:BoxInfo xmlns:e="http://juis.avm.de/updateinfo" xmlns:q="http://juis.avm.de/request">
       <q:Name>FRITZ!Box 7490</q:Name>
       <q:HW>185</q:HW>
       <q:Major>113</q:Major>
       <q:Minor>6</q:Minor>
       <q:Patch>92</q:Patch>
       <q:Buildnumber>47565</q:Buildnumber>
       <q:Buildtype>0</q:Buildtype>
       <q:Serial>0896D7CAFEDE</q:Serial>
       <q:OEM>avm</q:OEM>
       <q:Lang>de</q:Lang>
       <q:Country>049</q:Country>
       <q:Annex>B</q:Annex>
       <q:Flag></q:Flag>
       <q:UpdateConfig>1</q:UpdateConfig>
       <q:Provider></q:Provider></e:BoxInfo>
sed: /tmp/1514844813_1256/1514844813_1256: No such file or directory
sed: /tmp/1514844813_1256/1514844813_1256: No such file or directory
sed: /tmp/1514844813_1256/1514844813_1256: No such file or directory
sed: /tmp/1514844813_1256/1514844813_1256: No such file or directory
sed: /tmp/1514844813_1256/1514844813_1256: No such file or directory
sed: /tmp/1514844813_1256/1514844813_1256: No such file or directory
sed: /tmp/1514844813_1256/1514844813_1256: No such file or directory
sed: /tmp/1514844813_1256/1514844813_1256: No such file or directory
sed: /tmp/1514844813_1256/1514844813_1256: No such file or directory
sed: /tmp/1514844813_1256/1514844813_1256: No such file or directory
debug: Zusammengesetzte Versionsnummer für die Prüfung: '0.00.00-'
debug: -------------------------------------------------------
debug: Werte der Variablen:
debug: -------------------------------------------------------
debug: Serial=""
debug: Name=""
debug: HW=""
debug: OEM="avm"
debug: Lang=""
debug: Annex=""
debug: Country="049"
debug: Major=""
debug: Minor=""
debug: Patch=""
debug: Buildnumber=""
debug: Flag=""
debug: Public="1"
debug: type="1001"
debug: hostname=".jws.avm.de"
debug: nonce="/2j1HEKJdJIjHd1J/xp71g=="
debug: -------------------------------------------------------
debug: Gesendete Abfrage:
debug: -------------------------------------------------------
[...]
       POST /Jason/UpdateInfoService HTTP/1.1
       Host: .jws.avm.de:80
       Content-Length: 1125
       Content-Type: text/xml; charset="utf-8"
       Connection: close
[...]
root@FB7490:/var/tmp $ command -v bash
/var/custom/bin/bash
root@FB7490:/var/tmp $ command bash --version
GNU bash, version 3.2.57(2)-release (mips-unknown-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
root@FB7490:/var/tmp $

Da sollte ich wohl (neben der Suche der Ursache für das "sed"-Problem) noch eine Prüfung (zumindest für "HW", denn ohne Wert stimmt nicht mal der Servername bei AVM) einbauen, ob wirklich die Daten aus der XML-Datei gelesen wurden und die Parameter gesetzt sind. Wobei ich das wohl wirklich auf "HW" beschränken würde, ansonsten wären die anderen plötzlich nicht mehr "frei konfigurierbar" und für die 6590 reicht es z.B. schon, wenn "HW" richtig steht und "cable_retail" im Flag steht ... der Rest interessiert AVM wohl nicht wirklich, da kann auch das aus einer 7490 Gelesene in den Daten stehen.

@bino:
In der W10-Bash habe ich auch selbst getestet (dort mußte ich auch erst das "realpath" mit "sudo apt-get install realpath" nachinstallieren, aber die Fehlermeldung dazu kam "ordentlich" bei mir) ... ich bin etwas erstaunt ob der Adresse "192.168.13X.1" - das "X" war ja bei mir eine Ziffer in der IP-Adresse und diese wurde hier nur durch ein "X" ersetzt, weil ich die verwendeten Subnetze verschleiern wollte (die "X" sind auch unterschiedliche für die 7490 und die 6490).

Wobei das wohl nicht die Ursache des Problems hinter der Fehlerausschrift ist, denn Zeile 462 hat eher mit der Auswahl der Sprache zu tun als mit einem Problem der IP-Adresse oder des DNS-Namens.

Andererseits weiß ich nicht, ob nicht doch im Notepad++ etwas schiefgegangen ist (ich weiß ja nicht, wofür der (EDIT: "Notizblock" oder doch besser "das Programm"?) hier gebraucht wurde) - die einfachste Art der Installation in einer Windows-Bash wäre folgende:

peh@Bragi:~$ wget https://raw.githubusercontent.com/PeterPawn/YourFritz/master/juis/juis_check
--2018-01-01 22:44:37--  https://raw.githubusercontent.com/PeterPawn/YourFritz/master/juis/juis_check
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.112.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.112.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 71298 (70K) [text/plain]
Saving to: ‘juis_check’

100%[===============================================================>] 71,298      --.-K/s   in 0.05s

2018-01-01 22:44:37 (1.36 MB/s) - ‘juis_check’ saved [71298/71298]

peh@Bragi:~$ chmod u+x juis_check
peh@Bragi:~$ ./juis_check 192.168.178.1
juis_check: No newer version found, check was made with source version '153.06.92-47571'.
peh@Bragi:~$

(kommt auch irgendwann noch in den vorherigen Beitrag, aber muß erst noch niedergeschrieben werden).

Du kannst ja mal nach dem Download mit "wget" die entstandene Datei mit dem vergleichen, was derzeit bei Dir gespeichert ist ... vielleicht war das ja auch nur ein falscher Tastendruck im Notepad++ vor dem Speichern.

 

[stoney]

Zum Thema manuelle Abfrage (via 7490):

nano juis_check.cfg
Serial=000000000000
Name="FRITZ\\!Box\\ 6490\\ Cable"
HW=213
Version=egal
Major=141
Minor=06
Patch=83
Buildnumber=0
OEM=avm
Lang=de
Annex=Kabel
Country=049
Flag=egal
Public=0

./juis_check -d

Spoiler: 6490

./juis_check -d
debug: Neustart des Skripts mit einer Bash-Shell mit dem Kommando: command bash ./juis_check --debug --no-respawn
debug: Verarbeiten der Konfigurationsdatei '/home/freetz/YourFritz-new/YourFritz/juis/juis_check.cfg' mit folgendem Inhalt:
debug: -------------------------------------------------------
Serial=000000000000
Name="FRITZ\\!Box\\ 6490\\ Cable"
HW=213
Version=egal
Major=141
Minor=06
Patch=83
Buildnumber=0
OEM=avm
Lang=de
Annex=Kabel
Country=049
Flag=egal
Public=0debug: -------------------------------------------------------
debug: Ende der Verarbeitung der Konfigurationsdatei
debug: Zusammengesetzte Versionsnummer für die Prüfung: '141.06.83-0'
debug: -------------------------------------------------------
debug: Werte der Variablen:
debug: -------------------------------------------------------
debug: Serial="000000000000"
debug: Name="FRITZ\!Box\ 6490\ Cable"
debug: HW="213"
debug: OEM="avm"
debug: Lang="de"
debug: Annex="Kabel"
debug: Country="049"
debug: Major="141"
debug: Minor="06"
debug: Patch="83"
debug: Buildnumber="0"
debug: Flag="egal"
debug: Public="0"
debug: type="1000"
debug: hostname="213.jws.avm.de"
debug: nonce="SF4H+f1WkAxVLD80Okn3BA=="
debug: -------------------------------------------------------
debug: Gesendete Abfrage:
debug: -------------------------------------------------------
POST /Jason/UpdateInfoService HTTP/1.1
Host: 213.jws.avm.de:80
Content-Length: 1182
Content-Type: text/xml; charset="utf-8"
Connection: close

<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>SF4H+f1WkAxVLD80Okn3BA==</q:Nonce>
<q:UserAgent>Box</q:UserAgent>
<q:ManualRequest>true</q:ManualRequest>
</e:RequestHeader>
<e:BoxInfo>
<q:Name>FRITZ\!Box\ 6490\ Cable</q:Name>
<q:HW>213</q:HW>
<q:Major>141</q:Major>
<q:Minor>06</q:Minor>
<qatch>83</qatch>
<q:Buildnumber>0</q:Buildnumber>
<q:Buildtype>1000</q:Buildtype>
<q:Serial>000000000000</q:Serial>
<q:OEM>avm</q:OEM>
<q:Lang>de</q:Lang>
<q:Country>049</q:Country>
<q:Annex>Kabel</q:Annex>
<q:Flag>egal</q:Flag>
<q:UpdateConfig>1</q:UpdateConfig>
<qrovider>oma_lan</qrovider>
</e:BoxInfo>
</e:BoxFirmwareUpdateCheck>
</soap:Body>
</soap:Envelope>
debug: -------------------------------------------------------
debug: Lesen der Antwort von '213.jws.avm.de:80': .
debug: Empfangene Antwort:
debug: -------------------------------------------------------
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/xml;charset=UTF-8
Content-Length: 2240
Connection: close
Download-Delay: 2887
Date: Mon, 01 Jan 2018 22:22:27 GMT
Access-Control-Allow-Origin: http://scope.avm.de
Access-Control-Allow-Headers: content-type

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"></SOAP-ENV:Header><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>SF4H+f1WkAxVLD80Okn3BA==</ns3:Nonce></ns3:ResponseHeader><ns3:UpdateInfo><ns3:CheckInterval>8</ns3:CheckInterval><ns3:Found>true</ns3:Found><ns3:Name>EXTERN Release [AVM Retail]</ns3:Name><ns3:Version>141.06.87</ns3:Version><ns3:Type>1</ns3:Type><ns3ownloadURL>http://download.avm.de/firmware/6490/********/FRITZ.Box_6490_Cable.de-en-es-it-fr-pl.141.06.87.image</ns3ownloadURL><ns3:InfoURL>ftp://ftp.avm.de/archive/fritz.box/fritzbox_6490_cable/firmware/deutsch/info.txt</ns3:InfoURL><ns3:InfoText></ns3:InfoText><ns3:HintURL></ns3:HintURL><ns3:IconURL></ns3:IconURL><ns3riority>1</ns3riority><ns3:AutoUpdateStartTime>7200</ns3:AutoUpdateStartTime><ns3:AutoUpdateEndTime>18000</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#"></CanonicalizationMethod><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod><Reference URI="#Body"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod><DigestValue>eyVXoPhBN3xqdmGLF8IikeXwKHQADrNSXM9ZlDbeajQ=</DigestValue></Reference></SignedInfo><SignatureValue>nIct3B4Amj22bc8IrkHGHyi5IjsCL4S4DPkejVTgryi6/pBFMtTsYx867HeuQ364MQBt3mC7IPikJKLF+NQivdGoNIw7I0IH4FQsuH7StkvxN4517SYvluCipaoE7UziwPaq3Ntp7Q02gAAUtVvOXB0ga7wd89n48/GzUu4dM7NQJVlC0lvkUImvyZqPQdDXX+qWyQPzZ3J1979E08/g4SaWT8bt9Vo855aXbgCasHXRGwRAowOYkwmiXsW2ygHfARO99Ejd4Rj7Sxoj2ucgWSbp/1A9daSFQQPn9YOmq8YX92Vc0cNFs+cz7bx4LD0b6xJ64FDYR14WyIoglaG43g==</SignatureValue></Signature></soap:Body></soap:Envelope>
debug: -------------------------------------------------------
juis_check: Neue Version gefunden: 141.06.87
URL=http://download.avm.de/firmware/6490/********/FRITZ.Box_6490_Cable.de-en-es-it-fr-pl.141.06.87.image
DelayDownload=2887

 

[eisbaerin]

von denen "realpath" schon das exotischste wäre

So "exotisch" ist die IMO aber gar nicht, denn im Gegensatz zu "nc" ist die in der normalen busybox der FB enthalten und auch gelinkt.

EDIT:

wobei ich hier zuerst auf ein Problem mit dem "nc" tippen würde

Das "nc" nehme ich aus der (offiziellen?) busybox1.26.2 von busybox.net.
Dieses geht eigentlich in allen anderen Skripten.
Jetzt ahne ich, warum auch dein altes juis_check bei mir ohne .cfg nie ging.
Warum nimmst du da kein "wget"?

 

[PeterPawn]

@stoney:
Bei der 6490 geht es halt auch ohne das "cable_retail", bei der 6590 wohl nicht - so zumindest die Erkenntnis im anderen Thread und aus meinen eigenen Versuchen im Rahmen der letzten Änderungen, wo ich nur "HW" und "Version" passend setzen mußte ("Version" aber auch nur, damit die kleiner als die aktuelle ist - die "Major"-Angabe interessiert dort offenbar nicht wirklich und war die von der 7490) und der Rest von der 7490 gelesen werden konnte ... trotzdem kam die Antwort für eine 6590 (das war anhand des Servernamens bei AVM auch klar) und zwar auch eine korrekte mit der 06.85.

@eisbaerin:
Das mit dem "respawn" gab es ja zuvor gar nicht ... da kann also ein "Mimikry" der "ash" als "bash" (die Einstellung heißt "CONFIG_BASH_IS_ASH" und ich weiß nicht, wie die bei den Binaries von busybox.net gesetzt ist) auch nicht die Ursache gewesen sein.

Aber da kommen natürlich noch ganz andere Klippen in Betracht, wenn Du eine statische BusyBox von dort benutzt ... da geht bis zur C-Library, die für diese verwendet wurde (selbst wenn es eine uClibc ist, bliebe die Frage nach der Version) und wie gut diese zum Kernel in der FRITZ!Box paßt. Da kann immer irgendetwas nicht zueinander passen ... dafür gibt es ja die Einstellungen beim Build, damit man das aneinander angleichen kann und da wird so eine "fertige" BusyBox definitiv schlechter passen, als eine für die FRITZ!Box übersetzte, die auch noch die richtige C-Library benutzt (selbst wenn die ohnehin schon statisch dazugelinkt ist).

Aber diese Version von "juis_check" ist ohnehin eher für die Benutzung außerhalb der Box gedacht (das "check_update" aus "modfs" habe ich auch nicht angefaßt in diesem Kontext, das kann aber halt nur die lokale Box abfragen, weil die XML-Datei direkt und nicht über das Netzwerk gelesen wird) - daß bei AVM das "nc"-Applet nicht mehr dabei ist (außer bei den DOCSIS-Boxen, zumindest war es dort vor kurzem noch präsent), ist mir schmerzlich bewußt ... aber außer der Bereitstellung einer passenden binären (und statisch gelinkten) BusyBox im "binaries"-Branch des Repos weiß ich auch nicht, was ich noch tun kann. Ich war sogar schon soweit, auf der Box den (automatischen) Download aus dem GitHub-Repo zu erwägen ... das scheitert daran, daß GitHub nur noch über HTTPS erreichbar ist (korrekterweise, das ist kein Stück Kritik) und die AVM-Firmware "out of the box" nicht in der Lage ist, von einer HTTPS-URL zu laden - zumindest gelingt mir das mit "httpsdl" nicht bei GitHub (steht aber bei "modfs" auch schon länger und ist die einzige Ursache dafür, daß ich das Paket als TAR-File auch direkt über yourfritz.de zum Download anbiete).

 

[stoney]

Die 6490 war ein doofes Beispiel meinerseits, stimmt.

Mir ging es allgemein um den Aufbau der .cfg da dieser ja bislang noch nicht direkt niedergeschrieben ist.

 

[PeterPawn]

@koyaanisqatsi:
Ich habe jetzt erst in die Bilder geschaut und gesehen, daß die auch eine "Fehlermeldung" sein sollen.

Die dort verwendete Umgebung wirkt komisch ... einerseits erweckt es den Anschein, als ob bereits der Versuch, auf "LC_ALL" oder "LANG" im Environment zuzugreifen, irgendwelche Auswirkungen in der Shell hat, denn ich verwende im Skript ja gar keine "echten" Funktionen im Zusammenhang mit einer "locale" (auch kein "setlocale") und auf der anderen Seite scheint gar kein "locale"-Support vorhanden zu sein. Das Skript versucht wirklich nur, die Variable auszulesen, Großbuchstaben in kleine zu übersetzen und dann alles vom Beginn an, was aus Buchstaben besteht (bei "de_DE.utf-8" wären das nur die ersten beiden Zeichen), in einer Variablen zu speichern. Wenn die dann weder "en" noch "de" enthält (wie bei Dir beim "C"), sollte das weiterhin bei "en" bleiben mit der Sprache und gar keine Fehlermeldungen hervorrufen. Warum das nun bei Dir so ist und was das überhaupt für eine Shell bzw. für ein System ist, weiß ich nicht - aber es ist schon "amazing".

EDIT: Daß die Umgebung bei Dir dann keine ESC-Sequenzen unterstützt (wenn es nicht nur das "less"-Problem ist, welches auch die BusyBox hat, s.o. in der Antwort an @eisbaerin), käme dann noch hinzu - wobei das außerhalb von "less" ja offenbar zumindest in Farbe funktioniert.

Zwar könnte man noch irgendwie versuchen, den ANSI-Support zu ermitteln ... aber Systeme ohne sind heutzutage eher selten (das "less"-Applet ist eine ziemliche Ausnahme in meinen Augen und ein "richtiges" Programm als "less" kann das auch problemlos).

Falls irgendjemand einen zuverlässigen(!) Weg kennt, bei der "bash" die Unterstützung von "/dev/{tcp,udp}" für den Netzwerkzugriff zu erkennen, kann er mir ja mal einen Tipp geben ... allerdings bitte keinen, der auf irgendwelchen Meldungen auf STDOUT oder STDERR basiert, die dann auch noch von der eingestellten Sprache beeinflußt werden bzw. wo sich solche Meldungen dann im Fehlerfall nicht unterdrücken lassen und das "Gesamtbild" verhunzen.

EDIT2:
Was mir noch aufgefallen ist ... wer über "LC_ALL" oder "LANG" auf deutsche Ausgaben umstellt, der sollte sicherstellen, daß auch UTF-8 verwendet wird (entweder als Standard oder durch explizite Angabe im Wert) - ansonsten sehen die deutschen Umlaute halt auch komisch aus, wie man bei @koyaanisqatsi im Screenshot des "less" sehen kann.

 

[eisbaerin]

wenn Du eine statische BusyBox von dort benutz

OK, ich habe jetzt alle "nc" Links zu dieser busybox gelöscht:
erst so:

7362SL:$(pwd)# nc
BusyBox v1.26.2 (2017-01-10 16:11:14 UTC) multi-call binary.

Usage: nc [-iN] [-wN] [-l] [-p PORT] [-f FILE|IPADDR PORT] [-e PROG]

Open a pipe to IP:PORT or FILE

        -l      Listen mode, for inbound connects
                (use -ll with -e for persistent server)
        -p PORT Local port
        -w SEC  Connect timeout
        -i SEC  Delay interval for lines sent
        -f FILE Use file (ala /dev/ttyS0) instead of network
        -e PROG Run PROG after connect

dann so:

7362SL:$(pwd)# nc
-sh: nc: not found

dann habe ich Links zu deiner busybox erstellt:

7362SL:$(pwd)# ln -s /var/media/ftp/busybox1.24.1PeterPawnBE /var/tmp/nc
7362SL:$(pwd)# nc
BusyBox v1.24.1 (2016-02-18 15:52:26 CET) multi-call binary.

Usage: nc [-iN] [-wN] [-l] [-p PORT] [-f FILE|IPADDR PORT] [-e PROG]

Open a pipe to IP:PORT or FILE

        -l      Listen mode, for inbound connects
                (use -ll with -e for persistent server)
        -p PORT Local port
        -w SEC  Connect timeout
        -i SEC  Delay interval for lines sent
        -f FILE Use file (ala /dev/ttyS0) instead of network
        -e PROG Run PROG after connect

trotzdem klappt es nicht

7362SL:$(pwd)# juis_check_v3 -d 192.168.3.1
debug: -------------------------------------------------------
debug: Reading values from '192.168.3.1:80/juis_boxinfo.xml': .
debug: Error reading 'juis_boxinfo.xml' from FRITZ!Box device with address '192.168.3.1:80'.
debug: -------------------------------------------------------
debug: Reading values from '192.168.3.1:80/jason_boxinfo.xml': .
var/media/ftp/juis_check_v3: Error reading 'jason_boxinfo.xml' from FRITZ!Box device with address '192.168.3.1:80'.
7362SL:$(pwd)#

Was mach' ich jetzt noch falsch?

Noch mal die Frage aus #186
Warum nimmst du da kein "wget"?

 

[PeterPawn]

@eisbaerin:
Keine Ahnung ... Timeout sollte es schon mal nicht sein (daher wohl immer noch ein "Verbindungsproblem"), denn dann sollte sich in den 10 Sekunden (die für lokale Zugriffe als Timeout verwendet werden) die Liste mit den Punkten hinter dem "Reading values ..." in jeder Sekunde um einen verlängern.

Was passiert denn, wenn Du einfach:

root@FB7490:/var/tmp $ printf "GET /juis_boxinfo.xml HTTP/1.0\n\n" | nc 192.168.178.1 80; printf "\n"
HTTP/1.1 200 OK
Cache-Control: max-age=120
Connection: close
Content-Type: text/xml;charset=utf-8
Date: Tue, 02 Jan 2018 00:38:22 GMT
ETag: "274DB0DAB57462D8F"
Expires: Tue, 02 Jan 2018 00:40:22 GMT
Last-Modified: Thu, 01 Jan 1970 00:00:38 GMT
Mime-Version: 1.0


<e:BoxInfo xmlns:e="http://juis.avm.de/updateinfo" xmlns:q="http://juis.avm.de/request">
<q:Name>FRITZ!Box 7580 (UI)</q:Name>
<q:HW>225</q:HW>
<q:Major>153</q:Major>
<q:Minor>6</q:Minor>
<q:Patch>92</q:Patch>
<q:Buildnumber>47571</q:Buildnumber>
<q:Buildtype>1</q:Buildtype>
<q:Serial>E0286DCAFEDE</q:Serial>
<q:OEM>1und1</q:OEM>
<q:Lang>de</q:Lang>
<q:Country>049</q:Country>
<q:Annex>B</q:Annex>
<q:Flag></q:Flag>
<q:UpdateConfig>2</q:UpdateConfig>
<q:Provider></q:Provider></e:BoxInfo>
root@FB7490:/var/tmp $

aufrufst - das wäre ein "wget" von Hand unter Benutzung von "nc".

Etwas anderes macht das Skript am Ende auch nicht ... es wird nur noch etwas mit FIFOs hantiert, damit die verstrichene Zeit angezeigt werden kann (eben mit den erwähnten Punkten) und damit das Skript nicht einfach hängenbleibt, wenn da auf dem Port zwar die Verbindung angenommen wird, aber keine Antwort kommt. Falls es tatsächlich an den FIFOs bzw. den I/O-Redirections liegt, kann das auch wieder in einer anderen BusyBox seine Ursachen haben ... am einfachsten wäre es halt, wenn Du einfach mal mit der BusyBox aus dem Repo testest - die sollte auch ohne große Symlink-Orgien fast immer die internen Applets verwenden (sowohl für "mknod" bei den FIFOs als auch für "nc"), weil die mit "PREFER_APPLETS" übersetzt wurde. Beim "nc" wird jedenfalls auch nur noch der "pure Aufruf" ohne jede Option verwendet, damit kann das nicht mehr daran scheitern, daß unterschiedliche Implementierungen unterschiedliche Optionen verwenden.

 

[PeterPawn]

So, das Problem mit dem "sed" bei mir auf einer FRITZ!Box mit einer "bash" ist auch lokalisiert ... dort wurde (und wird) das "mktemp" nicht gefunden (es gibt keinen Symlink auf die BusyBox für dieses Applet, ich verlasse mich dort darauf, daß es aus der "ash" wegen "PREFER_APPLETS" ohnehin gefunden wird und verwende meist auch selbst die "ash" auf der Box) und es wurde auf die Emulation umgeschaltet.

Diese verwendete aber die aktuelle Uhrzeit für die Bildung des Namens einer temporären Datei und da dort innerhalb derselben Sekunde zwei Namen "abgefragt" wurden, wobei die zweite Datei planmäßig wieder gelöscht wurde, wurde das eben auch der ersten Datei (die hatte halt denselben Namen) zum Verhängnis (die wurde natürlich schon beim Schreiben der zweiten Datei mit diesem Namen überschrieben, aber das wurde erst später bemerkt). Jetzt wird die Datei direkt angelegt und sollte bereits eine Datei gleichen Namens existieren, wird solange die PID der aktuellen Instanz an den Namen angehangen, bis der endlich eindeutig ist.

Bei der Gelegenheit habe ich dann auch noch die Prüfung eingebaut, daß "HW" unbedingt vorhanden sein muß ... sonst stimmt ja nicht einmal der (virtuelle?) Servername bei AVM.

 

[bino]

@bino:
In der W10-Bash habe ich auch selbst getestet (dort mußte ich auch erst das "realpath" mit "sudo apt-get install realpath" nachinstallieren, aber die Fehlermeldung dazu kam "ordentlich" bei mir) ... ich bin etwas erstaunt ob der Adresse "192.168.13X.1" - das "X" war ja bei mir eine Ziffer in der IP-Adresse und diese wurde hier nur durch ein "X" ersetzt, weil ich die verwendeten Subnetze verschleiern wollte (die "X" sind auch unterschiedliche für die 7490 und die 6490).

Wobei das wohl nicht die Ursache des Problems hinter der Fehlerausschrift ist, denn Zeile 462 hat eher mit der Auswahl der Sprache zu tun als mit einem Problem der IP-Adresse oder des DNS-Namens.

Andererseits weiß ich nicht, ob nicht doch im Notepad++ etwas schiefgegangen ist (ich weiß ja nicht, wofür der (EDIT: "Notizblock" oder doch besser "das Programm"?) hier gebraucht wurde) - die einfachste Art der Installation in einer Windows-Bash wäre folgende:

peh@Bragi:~$ wget https://raw.githubusercontent.com/PeterPawn/YourFritz/master/juis/juis_check
--2018-01-01 22:44:37--  https://raw.githubusercontent.com/PeterPawn/YourFritz/master/juis/juis_check
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.112.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.112.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 71298 (70K) [text/plain]
Saving to: ‘juis_check’

100%[===============================================================>] 71,298      --.-K/s   in 0.05s

2018-01-01 22:44:37 (1.36 MB/s) - ‘juis_check’ saved [71298/71298]

peh@Bragi:~$ chmod u+x juis_check
peh@Bragi:~$ ./juis_check 192.168.178.1
juis_check: No newer version found, check was made with source version '153.06.92-47571'.
peh@Bragi:~$

(kommt auch irgendwann noch in den vorherigen Beitrag, aber muß erst noch niedergeschrieben werden).

Du kannst ja mal nach dem Download mit "wget" die entstandene Datei mit dem vergleichen, was derzeit bei Dir gespeichert ist ... vielleicht war das ja auch nur ein falscher Tastendruck im Notepad++ vor dem Speichern.

Hallo PeterPawn,

Ok, der Fehler lag an der Sprache.
"realpath" habe ich noch einmal drüberinstalliert

Ein Fehler ist noch übrig geblieben und zwar in Zeile 1
Nach Aufruf von "./juis_check 192.168.178.1" bekomme ich zur Antwort:
./juis_check: Zeile 1: #!: Befehl nicht gefunden
Das Skript läuft aber dann durch.

 

[PeterPawn]

@bino:
Jetzt bin ich verwirrt, aber ich habe beim Ansehen der Auswertung der Sprache tatsächlich noch eine mögliche Schwachstelle gefunden, falls jemand in der Variablen "LC_ALL" oder "LANG" einen Wert mit einem Newline-Zeichen stehen hätte. Das wäre zwar (m.W. jedenfalls) ohnehin ungültig als Wert, aber es hätte ggf. zu einer "Verwirrung" im Skript führen können, weil daraus ein Wert von "$check" entstehen kann, der Leerzeichen (bzw. Zeilenumbrüche) enthält:

vidar:~/GitHub/YourFritz/juis # printf "de_DE.UTF-8\nen_US.UTF-8\n" | sed -n -e "s|^\([A-Za-z]*\).*|\1|p" | sed -e "y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/"
de
en
vidar:~/GitHub/YourFritz/juis #

Das erklärt mir aber noch nicht, was Du mit

Ok, der Fehler lag an der Sprache.

meinst ... was hattest Du denn dort eingestellt, daß daraus so ein Fehler entstehen konnte? Ich will ja auch sichergehen, daß so etwas nicht bei anderen ebenfalls passiert.

Was ich dann gar nicht mehr begreife ... wie kann Zeile 1 mit dem SheBang als "Befehl nicht gefunden" angesehen werden (soll jetzt das SheBang (also "#!") selbst dieser Befehl sein oder das "/bin/sh" dahinter?) und im Anschluß läuft das Skript trotzdem? Das geht ja eigentlich nur dann, wenn man es mit "bash" oder "sh" oder "dash" oder was auch immer unter Angabe des Skriptnamens aufruft ... aber welche Shell erkennt dann nicht, daß die Zeile mit einem "#" beginnt und ohnehin nur als Kommentar zu bewerten wäre, wenn man in ihr nicht "nachlesen" will, welches Programm zur Verarbeitung gestartet werden soll (was ja nicht mehr notwendig ist, wenn man die Shell direkt aufruft)? Das ist alles etwas mysteriös ...

Es wäre hilfreich, wenn man da mal die komplette Eingabe und die Ausgabe als Konsolen-Protokoll hätte ... ich werde jedenfalls im Moment daraus nicht wirklich schlau. Aber immerhin habe ich dadurch die potentielle Schwachstelle mit der falschen "LC_ALL"- oder "LANG"-Variablen gesehen und auch gleich geändert ... jedoch kann ich Dir ohne wirkliche Idee (die setzt das erwähnte Protokoll voraus) nicht helfen.

 

[eisbaerin]

Was passiert denn, wenn Du einfach:

7362SL:# printf "GET /juis_boxinfo.xml HTTP/1.0\n\n" | nc 192.168.3.1 80; printf "\n"

7362SL:#

Mit beiden "nc": Nichts, außer einer Leerzeile.

 

[PeterPawn]

@eisbaerin:
Dann funktioniert irgendetwas im Netzwerk bei Dir nicht richtig ... wie Du oben bei mir sehen konntest, wäre die normale Reaktion (sofern auf der Zieladresse an Port 80 ein HTTP-Server läuft, wovon ich mal ausgehe) zumindest eine HTTP-Fehlermeldung, wie in den folgenden Beispielen:

root@FB7490:~ $ printf "TEST\n\n" | nc 192.168.178.1 80; printf "\n"
HTTP/1.0 400 Bad Request
Content-Length: 182
Content-Type: text/html; charset=utf-8

<HTML><HEAD><TITLE>400 Bad Request (ERR_INVALID_REQ)</TITLE></HEAD><BODY><H1>400 Bad Request</H1><BR>ERR_INVALID_REQ<HR><B>Webserver</B> Tue, 02 Jan 2018 10:52:11 GMT</BODY></HTML>

root@FB7490:~ $ printf "GET /JUIS HTTP/1.0\n\n" | nc 192.168.178.1 80; printf "\n"
HTTP/1.0 404 Not Found
Content-Length: 1713
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<html>
<head>
<meta http-equiv=content-type content="text/html; charset=utf-8" />
<meta http-equiv="Cache-Control" content="private, no-transform" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta name="format-detection" content="telephone=no" />
<meta http-equiv="x-rim-auto-match" content="none" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui" />
<meta name="mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
<meta http-equiv="cleartype" content="on">
<link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" />
<link rel="apple-touch-icon" href="/css/default/images/kopfbalken_links.png" />
<link rel="apple-touch-startup-image" href="/css/default/images/kopfbalken_links.png">
<link rel="stylesheet" type="text/css" href="/css/rd/singleside_old.css"/>
<title>FRITZ!Box</title>
</head>
<body>
<div id="main_page_all">
<header class="" name="" id="blueBarBox">
<div class="blue_bar_titel" name="" id="blueBarTitel">FRITZ!Box</div>
</header>
<div id="page_content_no_menu_box">
<div class="area_box">
<div class="blue_bar_back" >
<div><h2>FRITZ!Box</h2></div>
</div>
<div class="page_content">
<p>Die angegebene URL wurde nicht gefunden. Sie werden auf die Startseite der FRITZ!Box weitergeleitet.</p>
<p>Falls Sie nicht automatisch auf die Startseite der FRITZ!Box weitergeleitet werden, klicken Sie <a href="/">hier</a>.</p>
<br>
</div>
</div>
</div>
</div>
<script>
window.setTimeout(function () {
window.location.href = "/";
}, 10000);
</script>
</body>
</html>

root@FB7490:~ $

Die einzelne Leerzeile bei Dir entsteht ja nur durch das angehangene

printf "\n"

und das soll eigentlich nur dazu dienen, daß der nächste Shell-Prompt auf der nächsten Zeile landet, weil die Ausgabe des HTTP-Servers kein abschließendes Zeilenende enthält.

Entscheidend sind halt die zwei Newline-Zeichen am Ende der Eingabe für den HTTP-Server, denn erst der zweite Zeilenumbruch schließt den Request ab. Warum bei Dir jetzt das "nc"-Kommando nicht funktionieren will (und dann auch noch auf mehreren Boxen und mit mehreren Versionen von "nc"), weiß ich auch nicht - was passiert denn, wenn Du damit auf einen FTP-Server "losgehst"? Das kann man ja auch lokal machen:

root@FB7490:~ $ nc localhost 21
220 FRITZ!Box7490 FTP server ready.
USER anonymous
331 Password required for anonymous.
PASS [email protected]
530 Login incorrect.
QUIT
221 Goodbye.
root@FB7490:~ $

und dabei ist die "Syntax" dann einfacher.

Ansonsten habe ich auch keine Idee, wie man das noch testen sollte ... irgendetwas stimmt halt mit dem "nc" nicht - bist Du denn sicher, daß es sich um das richtige Programm handelt? Vielleicht rufst Du es ja auch einmal mit "busybox nc" auf oder sogar mit dem kompletten Pfad zur BusyBox.

Ich kann mir das fast nur noch damit erklären, daß da die C-Library (gegen die das Programm mit dem "nc"-Applet gelinkt wurde) mit ihren Netzwerk-Funktionen tatsächlich nicht zum AVM-Kernel in der FRITZ!Box paßt ... war der letzte Test nun mit meiner Version der BusyBox aus dem YourFritz-Repo oder wieder mit der von der busybox.net-Seite?

EDIT: Was das auch noch sein könnte ... ein "nc"-Kommando, das beim Dateiende auf STDIN sofort komplett beendet wird, so daß die Antwort vom Server gar keine Chance mehr hat, empfangen zu werden. Das wäre allerdings eine komische Konstellation ... die Verwendung des FIFO mit dem Namen "pin" in "run_nc()" soll eigentlich genau das verhindern. Der FIFO sollte nach dem "cat" kein EOF signalisieren, sondern auf weitere Daten warten - damit kriegt auch das "nc" theoretisch kein EOF auf STDIN, was es zum Abbruch bzw. Beenden verleiten könnte.

 

[koyaanisqatsi]

Ist es richtig/"der einzige Weg", dass "Box" nur über das Environment übergeben werden kann, wenn keine .cfg mit -i angewiesen wird ?

Beispiel:

env -i Box=fritz.box ./juis_check -i Version=000.00.00-00000 Public=1 HW=221 Serial=ffffffffff Flag=empty

 

[PeterPawn]

@koyaanisqatsi:
Wenn ich die Frage richtig verstehe: Ja.

Die Variable "Box" wird auf der Kommandozeile nicht als Name/Wert-Paar akzeptiert ... das wäre irgendwo dasselbe, wie die Angabe der Adresse als erster (positional) Parameter, wenn die (implizite) Konfigurationsdatei ohnehin aus "Box=$1; shift" besteht (das geht ja weiterhin).

Wenn man eine (eigene) Konfigurationsdatei verwendet, muß man "Box" eben irgendwie setzen und wenn man keine verwenden will (dafür gibt es ja "-i"), dann muß man auf anderem Weg (z.B. durch vorherigen "export" ins Shell-Environment oder durch Angabe von "Box=<addr>" auf derselben Zeile, aber vor dem Aufruf des Skripts) die Variable irgendwie setzen, wenn die anderen nicht komplett sind am Ende und auf die Box zugegriffen werden muß.

 

[bino]

@bino:
Jetzt bin ich verwirrt, aber ich habe beim Ansehen der Auswertung der Sprache tatsächlich noch eine mögliche Schwachstelle gefunden, falls jemand in der Variablen "LC_ALL" oder "LANG" einen Wert mit einem Newline-Zeichen stehen hätte. Das wäre zwar (m.W. jedenfalls) ohnehin ungültig als Wert, aber es hätte ggf. zu einer "Verwirrung" im Skript führen können, weil daraus ein Wert von "$check" entstehen kann, der Leerzeichen (bzw. Zeilenumbrüche) enthält:

vidar:~/GitHub/YourFritz/juis # printf "de_DE.UTF-8\nen_US.UTF-8\n" | sed -n -e "s|^\([A-Za-z]*\).*|\1|p" | sed -e "y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/"
de
en
vidar:~/GitHub/YourFritz/juis #

Das erklärt mir aber noch nicht, was Du mit

meinst ... was hattest Du denn dort eingestellt, daß daraus so ein Fehler entstehen konnte? Ich will ja auch sichergehen, daß so etwas nicht bei anderen ebenfalls passiert.

Was ich dann gar nicht mehr begreife ... wie kann Zeile 1 mit dem SheBang als "Befehl nicht gefunden" angesehen werden (soll jetzt das SheBang (also "#!") selbst dieser Befehl sein oder das "/bin/sh" dahinter?) und im Anschluß läuft das Skript trotzdem? Das geht ja eigentlich nur dann, wenn man es mit "bash" oder "sh" oder "dash" oder was auch immer unter Angabe des Skriptnamens aufruft ... aber welche Shell erkennt dann nicht, daß die Zeile mit einem "#" beginnt und ohnehin nur als Kommentar zu bewerten wäre, wenn man in ihr nicht "nachlesen" will, welches Programm zur Verarbeitung gestartet werden soll (was ja nicht mehr notwendig ist, wenn man die Shell direkt aufruft)? Das ist alles etwas mysteriös ...

Es wäre hilfreich, wenn man da mal die komplette Eingabe und die Ausgabe als Konsolen-Protokoll hätte ... ich werde jedenfalls im Moment daraus nicht wirklich schlau. Aber immerhin habe ich dadurch die potentielle Schwachstelle mit der falschen "LC_ALL"- oder "LANG"-Variablen gesehen und auch gleich geändert ... jedoch kann ich Dir ohne wirkliche Idee (die setzt das erwähnte Protokoll voraus) nicht helfen.

Hallo PeterPawn,

Mit der Sprache habe ich gemeint,
dass ich meine gespeicherte Datei "juis_check" mit Hilfe von Notepad++ in das Unix-Format (LF) konvertiert habe.
Anstatt CRLF steht jetzt am Ende jeder Zeile nur noch ein LF.

Zum anderen Thema mit der Benutzung des neuen Skriptes melde ich mich später noch einmal.

 

[PeterPawn]

[...] in das Unix-Format (LF) konvertiert habe.

Das verstehe ich eben auch nicht ... die hat doch bei GitHub schon Zeilenenden, die nur aus LF bestehen. Wenn da beim Speichern/Download am Ende Zeilen mit CR/LF entstehen, ist das Kommando für den Download schon "fragwürdig".

Solche Konvertierungen können vielleicht bei der Verwendung von FTP (im Text-Modus) ausgeführt werden (kann man GitHub-Repos per FTP auslesen?), aber doch nicht beim Klonen (außer die .gitattributes oder andere lokale Einstellungen forcieren es - dann sollte man aber diese mal überprüfen) und auch nicht beim HTTP(S)-Download - ein schönes Beispiel dafür wäre der Download der Export-Datei einer FRITZ!Box, die man danach auch nicht mit dem (Windows-)Editor (aka notepad.exe) öffnen kann (bzw. öffnen schon, aber nicht wirklich lesen), weil die Zeilenumbrüche nur aus LF bestehen.