Sammelthema für FB 7590 mit Firmware "Intern"/"Inhaus" bis 07.22

[koyaanisqatsi]

erst ab Vdsl

So ist es
Schade auch, dass ich bei...
Anschluss über WAN

...mein "Gliedermaßstab" befragen muss.

 

[Björn Otto 1993]

Also mein wunsch wer das auch ich meine leitungslänge sehen würde !
ADSL 2+ (ITU G.992.5) Annex B !!!

Die anzeige sollte jeder sehen auch die leute mit Adsl !!
-------------
Wie wer es den mit einer Funktion zum testen ob auf meiner Kupferleitung irgend ein fehler ist ,,
Ja so was gibt es funktioniert aber nur wenn lange Zeit kein Dsl da gewesen ist,,
//
DSL-Leitungstest
Wenn Sie über einen längeren Zeitraum keinen DSL-Sync (mehr) erreichen können, können Sie hier einen DSL-Leitungstest ausführen.

was haltet ihr davon ??

---------
so jetzt schreibe ich auch noch mal was zum WLAN WPA 2 und WPA 3
Vielleicht sollte Avm die option aufmachen das mann nur WPA3 auswählen kann !!

 

[avm_7170]

@bino:

Welche Version soll denn heute erschienen sein.

Es bedraf nur die Beta Labor und keine Inhaus
schau mal hier da geht es zu diesem Thema weiter

 

[Björn Otto 1993]

Tut mir echt leid bei mir steht immer noch der 12.12.2019 bis jetzt !!!

 

[avm_7170]

bei mir steht immer noch der 12.12.2019

per FTP geht der Download

 

[Björn Otto 1993]

Ist das normal das über nacht mein 1750e aus dem mesh geht ?? warum ist das so ist das ein fehler ??

 

[HarryP_1964]

Normal ist das nicht, ist aber mindestens seit der vorletzten Inhouse so.
Kurzer Tastendruck und er ist wieder eingemesht.

Bliebe noch die Frage, ob der 1750E mit der Beta von gestern auch aus dem MESH fliegt.

Harry

 

[Björn Otto 1993]

Mein Problem ist nur ich habe nur eine 7590 zum Testen hätte ich zwei könnte ich eine Labor und eine Inhaus laufen lassen.

Mein Geldbeutel ist aber leider nicht so voll das ich mir noch eine zweite Kaufen könnte

 

[avm_7170]

Mir ist nun auch aufgefallen, dass bei der neuen Inhaus ...die Beschreibung des Internetzugangs bein Nutzung als WLAN Repeater anders als früher ist .... dazu habe ich zum Vergleich zwei Screenshots angehängt

Alt


Neu

 

[stoney]

@bjoerni1993 linux_fs_start emrmöglicht es Dir ohne Geld auszugeben

 

[NDiIPP]

Also mein wunsch wer das auch ich meine leitungslänge sehen würde !
ADSL 2+ (ITU G.992.5) Annex B !

Dann wirst du wohl auf einen VDSL2-Anschluss wechseln müssen, denn bei ADSL1/2/2+ wird kein "final electrical length" Wert übermittelt (siehe G.993.2 von 02/2019 bspw. unter Punkt 7.2.1.3.2.1 (Seite 36) + Punkt 12.3.3.2.1.2 (Seite 220)), den AVM vermutlich für die Berechnung der Leitungslänge heranzieht.

Die anzeige sollte jeder sehen auch die leute mit Adsl !

Was sollen die (allermeisten) Leute damit anfangen? Wenn einem das wirklich so wichtig wäre, könnte man ja bereits die angezeigte Leitungsdämpfung (welche auch bei ADSL angezeigt wird) für grobe Spekulationen bzgl. Leitungslänge heranziehen.
Da aber die genauen Parameter des jeweiligen Kabels den meisten wohl unbekannt sind und die angezeigte Leitungsdämpfung sich auf den Durchschnitt der Dämpfung der jeweils verwendeten Träger bezieht (im Gegensatz zum Wert "final electrical length" bei VDSL2, welcher sich auf eine bestimmte Dämpfung (1dB) bezieht), wäre die Ermittlung der Leitungslänge auf dieser Basis (und auch aufgrund der üblicherweise möglichen größeren Leitungslängen bei ADSL) noch sehr viel ungenauer als man es jetzt schon von der angezeigten Leitungslänge kennt (daher auch der Begriff "Spekulation" anstatt Berechnung). Das würde die Leute u.U. eher noch mehr verwirren, als es die angezeigte Leitungslänge jetzt schon bei VDSL2-Anschlüssen tut, denn auch dieser ermittelte Wert bei VDSL2 ist nur eine Schätzung, wenn ggf. auch aufgrund des o.g. Parameter, welcher bei der Aushandlung bei VDSL2 übermittelt wird, auch genauer möglich ist als bei ADSL.

 

[Björn Otto 1993]

Und wo finde ich das programm (linux_fs) ???

 

[avm_7170]

@bjoerni1993:

linux_fs_start ist ein Kommando zum Umschalten der Partition einer Fritzbox und kein Programm ...
lässt sich in der Powershell oder im CMD ausführen

 

[stoney]

Und wo finde ich...

Via Suchmaschine lassen sich auch "Anleitungen" dazu finden.......

 

[Björn Otto 1993]

Hi mir ist was aufgefallen geht um Powerline. ich kann kein mimo anstellen z.b beim 1240,1260 mit dem Powerline Programm.

Powerline-Spektrum zwischen dem Powerline-Adapter geht auch nicht wirklich eigentlich gar nicht.

kann das an der Inhaus Version liegen??

Kann mir das jemand bestätigen oder bin ich mit dem Fehler alleine ?

 

[Grisu_]

Werde Mitglied bei Liverpool - they'll never walk alone
Frohe Weihnachten wollt ich sagen ...

 

[gerold]

Ich habe auf der letzten Inhouse mal den Telnet aktiviert. Dafür reicht es nicht aus, nur den telnetd-link in /usr/sbin auf /bin/busybox und den Systemd-Service für den telnetd anzulegen.
Beim Aufruf von Telnet wird von der FB nun die Eingabe von user und pw verlangt, wobei root als Kennung nicht mehr akzeptiert wird (Meldung: Login incorrect, noch bevor nach dem pw gefragt wird).
Erst nachdem ich in der /etc/securetty Datei die Einträge pts/0, pts/1und pts/2 hinzugefügt hatte, wurde root akzeptiert.
Mit dem root passwort hatte ich dann auch noch ein Problem, die Passwörter, die ich in früheren Inhouse Versionen benutzt hatte, wurden nicht akzeptiert. Ich habe deshalb eine neuen User mit root Berechtigungen in die passwd Datei eingefügt, mit dem der Zugriff endlich klappt.

In der angehängten Datei ist die Ausgabe von kallsyms und der Kernelkonfiguration, die @PeterPawn vor einigen Tagen gewünscht hatte:

 

[PeterPawn]

Beim Aufruf von Telnet wird von der FB nun die Eingabe von user und pw verlangt

Erst einmal danke für die Ausgabe der Daten, ich sehe nachher mal rein.

Partiell steht aber seit 74611 schon fest, daß AVM auch den Hardware-Support für Crypto-Operationen benutzt: https://www.ip-phone-forum.de/threa...-os-der-labor-reihe-07-19.305167/post-2351216 ... hier hat die neue Labor-Version das Erfüllen meiner Bitte durch den ersten User mit Shell-Zugang überholt.

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

Beim Anmeldeproblem rate ich einfach mal, daß Du vergessen hast, dem "telnetd" noch das richtige Login-Programm mit auf den Weg zu geben - ich hatte zwar weiter vorne geschrieben:

Da müßte man nur das aufgerufene Programm (in ExecStart) entsprechend anpassen auf den telnetd aus der BusyBox

, aber der korrekte Aufruf des Applets sieht dann so aus, wie er auch bei mir (wenn ich den wirklich gesondert starten lasse und nicht über den "telefon"-Daemon) in praktisch allen Skript-Dateien zu finden ist, z.B. hier:

modfs/modscripts/inactive/mod_telnet_start at master · PeterPawn/modfs

modify firmware for NAND-flash based FRITZ!Box routers and install it on such a device - PeterPawn/modfs

github.com

... das ergibt dann also einen Aufruf mit /usr/sbin/telnetd -l /sbin/ar7login.

Die Notwendigkeit des Eintrags in die "/etc/securetty" dürfte auch nur dem Umstand geschuldet sein, daß hier (ohne Angabe eines alternativen Login-Programms) das "login"-Applet der BusyBox verwendet wird und das arbeitet nun mal mit "/etc/passwd" und ggf. sogar "/etc/shadow" (da stehen aber keine "Login-Namen" aus dem FRITZ!OS, sondern "boxusrXX"-Einträge - XX ist das Mapping von UID auf Login-Namen in der "ar7.cfg") und schaut wohl auch in die "securetty".

Wenn man hier gleich "ar7login" nutzt, sind auch die Accounts aus dem FRITZ!OS gültig und verwendbar ... die werden dann ohnehin alle auf "root" gemappt, wenn sie Admin-Rechte haben - sonst geht auch kein Login mit einem FRITZ!OS-Account.

Den Unterschied zwischen "login" und "ar7login" sieht man schon am Prompt, mit dem nach dem Benutzernamen gefragt wird:

root@fb7490:~ $ telnetd --help
BusyBox v1.27.2 multi-call binary.

Usage: telnetd [OPTIONS]

Handle incoming telnet connections

        -l LOGIN        Exec LOGIN on connect
        -f ISSUE_FILE   Display ISSUE_FILE instead of /etc/issue
        -K              Do not close connection as soon as login exits,
                        but wait until all programs close slave pty
        -p PORT         Port to listen on
        -b ADDR[:PORT]  Address to bind to
        -F              Run in foreground
        -i              Inetd mode
        -w SEC          Inetd 'wait' mode, linger time SEC
        -S              Log to syslog (implied by -i or without -F and -w)
root@fb7490:~ $ busybox login
fb7490 login: root
Password:
Login incorrect
fb7490 login: ^C
root@fb7490:~ $ /sbin/ar7login
Fritz!Box user: admin
password:
^C
root@fb7490:~ $

Bei Verwendung von "ar7login" sollte jedenfalls nichts weiter notwendig sein von den beschriebenen Aktionen (User anlegen, Kennwort vergeben, "/etc/securetty" anpassen) - ich kann zumindest definitiv sagen, daß es auf meiner 7490 noch genauso mit "ar7login" funktioniert, wie schon eh und je.

Vielleicht war da meine "Beschreibung" etwas zu kurz geraten, aber die Angabe des Login-Programms für den "telnetd" ist eben auch schon seit Urzeiten dieselbe, wenn man es "von Hand" starten muß - nur sah man es ggf. nicht immer, wenn der Daemon über "telefon" gestartet wurde ... wobei auch dann exakt dieser Aufruf in der Prozessliste zu sehen ist.

 

[gerold]

Danke für die ausführliche Darlegung, das ar7login hatte ich nicht mit angegeben.
Dafür wird jetzt beim Zugriff auf die Box nicht mehr die Meldung von den "nicht vom Hersteller unterstützen Anwendungen" auf der Weboberfläche der FB ausgegeben.

 

[PeterPawn]

Dafür wird jetzt beim Zugriff auf die Box nicht mehr die Meldung von den "nicht vom Hersteller unterstützen Anwendungen" auf der Weboberfläche der FB ausgegeben.

Wer das - trotz "ar7login" - nicht will und nicht einfach nur die Meldung aus dem GUI rauspatcht, der kann auch etwas wie das hier:

YourFritz/tools/resetsigned at main · PeterPawn/YourFritz

dynamic package management for AVM routers. Contribute to PeterPawn/YourFritz development by creating an account on GitHub.

github.com

einfach in die "/etc/profile" mit aufnehmen ... die Möglichkeiten sind da vielfältig. Auch ein "Inkludieren" weiterer Dateien in die "/etc/profile" ist keine so schlechte Idee, wenn man sich regelmäßig mit der Shell in der Box beschäftigt ... die wird schließlich bei jedem Login ausgeführt und solche Sachen wie zusätzliche Verzeichnisse im Pfad oder andere Umgebungsvariablen, bis hin zu irgendwelchen Shell-Prompts und "bunter Anzeige" im Terminal, sind am besten in einer eigenen Datei aufgehoben, die man dann nur noch mit dem "dot"-Kommando in die AVM-Datei einfügt - damit muß man die nicht bei jedem Update komplett neu zusammenschreiben (lassen).

Aber wie gesagt ... da führen nicht nur viele Wege nach Athen, sondern praktisch jeder und man muß sich überlegen, wie man die Eulen transportieren will.

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

Beim Blick in die Kernel-Symbole (alles mit "ipsec" liegt im "kdsldmod"-LKM) und in die Einstellungen zur Build-Time, würde ich erst mal sagen, daß für IPSec wohl doch noch kein Hardware-Support genutzt wird.

Zumindest sehe ich da keine Variable, die ich irgendwie mit EIP97 o.ä. in Zusammenhang bringen würde. Aber ggf. stimmt ja auch nur mein "ipsec" als Bestandteil von exportierten Kernel-Symbolen zu diesem Thema nicht (wobei im "kdsldmod" schon jede Menge davon vorhanden sind) ... aber ich hätte bei den Config-Variablen dann immer noch etwas wie in diesem Patch (bzw. das ist ein Ausschnitt aus einem solchen) erwartet als aktives Symbol:

 16 diff --git a/drivers/crypto/Kconfig.grx500 b/drivers/crypto/Kconfig.grx500
 17 new file mode 100644
 18 --- /dev/null
 19 +++ b/drivers/crypto/Kconfig.grx500
 20 @@ -0,0 +1,37 @@
 21 +config CRYPTO_DEV_LANTIQ_EIP97
 22 +  tristate "Support Lantiq Crypto"
 23 +  depends on LANTIQ && SOC_GRX500
 24 +
 25 +config LTQ_CRYPTO
 26 +  tristate "Lantiq Crypto Hardware support"
 27 +  depends on CRYPTO_DEV_LANTIQ_EIP97
 28 +  select CRYPTO_AUTHENC
 29 +  select CRYPTO_SHA1
 30 +  select CRYPTO_SHA256
 31 +  select CRYPTO_SHA512
 32 +  select CRYPTO_MD5
 33 +  select CRYPTO_AES
 34 +  select CRYPTO_DES
 35 +  select CRYPTO_MANAGER_DISABLE_TESTS
 36 +
 37 +  default n
 38 +
 39 +config LTQ_CRYPTO_TEST
 40 +  tristate "Lantiq Crypto Test"
 41 +  depends on m && LTQ_CRYPTO
 42 +  help
 43 +       Test suites for the hw crypto algs
 44 +
 45 +config LTQ_MPE_IPSEC_SUPPORT
 46 +  bool
 47 +  depends on LTQ_PPA_MPE_IP97
 48 +  default y
 49 +
 50 +config LTQ_CRYPTO_MAX_RING_USED
 51 +  int "Maximum number of ring used in the driver"
 52 +  default "4" if LTQ_MPE_IPSEC_SUPPORT
 53 +  default "2"
 54 +  help
 55 +    Number of rings used in the driver. By default, the driver supports up to
 56 +    two rings. However, if MPE firmware is used, we only use 1 ring in the driver
 57 +

und davon ist auch nichts zu sehen in der "config.gz" (vielleicht bei den nicht aktivierten, wenn AVM einen ähnlichen Patch von Lantiq/Intel auf die Kernel-Quellen losgelassen hat).

Ich hätte halt irgendwas in der Richtung erwartet (und tatsächlich auch als "exportierte Symbole", die in jedem Falle in der "ksymtab" auftauchen, schon damit andere Module beim Laden die Adressen auflösen können):

202 int ltq_ipsec_setkey(struct ltq_crypto_ipsec_params *ipsec_params);
203 int ltq_get_ipsec_token(struct ltq_crypto_ipsec_params *ipsec_params);
204 void ltq_destroy_ipsec_sa(struct ltq_crypto_ipsec_params *ipsec_params);
205 int ltq_ipsec_enc(u32 spi, u8 *in, u8 *out, void (*callback)(struct ltq_ipsec_complete *done),
206                         unsigned int buflen, void *ip_data);
207 int ltq_ipsec_dec(u32 spi, u8 *in, u8 *out, void (*callback)(struct ltq_ipsec_complete *done),
208             unsigned int buflen, void *ip_data);
209 int ltq_get_length_params(u32 spi, unsigned int *ivsize, unsigned int *ICV_length,
210                         unsigned int *blksize);

, weil auch AVM in der "avm_eip97.c" darauf zurückgreifen würde, wenn man den (alten) 7.01-Quellen glauben will.

Also vertagen wir das Thema erst mal ... irgendwann rückt AVM hoffentlich auch die 07.19-Quellen raus, meine Anforderung dafür (bzw. meine Bitte um Bereitstellung derselben) ist schon vom 10.12.2019. Ich glaube nicht so richtig daran, daß sich da am Montag noch etwas tun wird ... also wird es wohl eher "nächstes Jahr" werden, hoffentlich nicht erst nach dem Erscheinen einer Release-Version.

Anfang Januar hake ich noch einmal nach und wenn sich dann auch nichts tut, versuche ich mal das "legal team" der FSFE zu kontaktieren, was man da aus deren Sicht machen könnte. Schon die fehlende Vollständigkeit der Kernel-Quellen ist eine "Unsitte", die immer mehr einreißt bei AVM (auch wenn ich die inzwischen bereitgestellten Quellen der 07.11/07.12 noch nicht daraufhin untersucht habe - ich hatte das noch einmal explizit in meiner Mail an AVM geschrieben, daß auch "__avm_kernel_config" durchaus dabei sein darf).

AVM geht eben mit der Nutzung des Rechts, den Linux-Kernel für die FRITZ!Boxen zu verwenden, auch gleichzeitig die Verpflichtung ein, sich an die Lizenzbestimmungen der GPLv2 für diesen Kernel zu halten. Das ist also keine "Nettigkeit" oder "Gnade" seitens AVM, wenn man diese Daten bereitstellt ... sie sind schlicht dazu verpflichtet und zwar auch in dem Umfang, wie es die Lizenzbestimmungen verlangen. Weigern sie sich (wobei sie ja das nicht einmal explizit ausgesagt haben bis zu den 07.0x-Quellen - da läßt man eben einfach etwas weg und geht auf entsprechende Nachfragen gar nicht weiter ein), muß man als Lizenznehmer eben auch schauen, wie man so viel Lärm veranstalten kann, daß man da doch noch zum Ziel kommt. Vielleicht reagieren sie ja auf eine Anfrage der FSFE oder von Journalisten dann doch noch anders und "erklären" sich wenigsten mal - für den Fall, daß sie das mit der "Verpflichtung" zur Veröffentlichung anders sehen wollen.