[Problem] WLan Gastzugang für 7320-IP-Clienten (fehlende L2TP Binaries im 6.54 Kernel der 7330SL)

[CaptainMorgan]

Ich weiß nicht was ich falsch mache:
Ich habe nun zwei Tage gemurkst, aber jedes mal läuft etwas anderes schief.
Mittlerweile kann ich die zahlreichen FW-Informationen erfolgreich anpassen, sodass ich die Firmware bequem über die Freetz-GUI laden kann.
Dazu hatte ich die neue Freetz-Linux geladen, um einfach Fehler auszuschließen.
Jetzt funktioniert allerdings das l2tp nicht mehr manierlich, selbst wenn ich die .config aus der Firmware verwende die NDiIPP mir ursprünglich gesandt hat.
Die, wie auch alle anderen, laufen beim make einigermaßen fehlerfrei los, aber die Supportdaten zeigen ein Problem:

##### END SECTION vpn
##### BEGIN SECTION l2tpv3d Suppotdata l2tpv3d
##### BEGIN SECTION l2tpv3d_log log

L2TPv3 log
----------
##### END SECTION l2tpv3d_log
##### BEGIN SECTION l2tpv3d_sessions sessions

L2TPv3 sessions
---------------
/bin/supportdata: line 493: /sbin/l2tp: Permission denied
/bin/supportdata: line 494: /sbin/l2tp: Permission denied

Ein nachschlagen über telnet oder das entpacken des fertigen Images zeigt:
Ja l2tp und l2tpv3d sind mit gepackt worden, aber statt "not found" kommt jetzt "permission denied".
Was mache ich falsch?

 

[PeterPawn]

Und ... haben die auch die "x"-Flags entsprechend gesetzt?

 

[CaptainMorgan]

Die Idee ist mir auch gekommen, aber mir war für die längste Zeit nicht klar wie, wann und wo.
In der Box ist nichts mehr zu machen, in den Flash kann so erstmal nicht geschrieben werden.
Die entsprechenden Dateien in meiner unpacked 7272.06.50 waren auf 777 gesetzt.
Wo es zu zählen scheint ist in /build/modified/***. Ein einfaches ändern dort bringt aber auch nichts, das cp aus der fwmod_customs setzt sie wieder auf 755.

Hat sich das in Ubuntu irgendwann mal geändert? Oder gibt es da Voreinstellungen?
Ich habe defakto keine Ahnung von Linux, und verwende immer nur Anwendungsbezogen VM's, quasi für jeden Usecase eine eigene VM.

Einen ersten workaround, der Linux-Kennern vermutlich Tränen in die Augen treibt, war "cp" durch "install -m 777" in der fwmod_customs auszutauschen, aber funktionieren tut es leider nicht nicht, jetzt passiert folgendes:

##### BEGIN SECTION l2tpv3d Suppotdata l2tpv3d
##### BEGIN SECTION l2tpv3d_log log

L2TPv3 log
----------
##### END SECTION l2tpv3d_log
##### BEGIN SECTION l2tpv3d_sessions sessions

L2TPv3 sessions
---------------
/sbin/l2tp: '/lib/' is not an ELF file
/sbin/l2tp: '/lib/' is not an ELF file
/sbin/l2tp: '/usr/lib/' is not an ELF file
/sbin/l2tp: can't load library ''
/sbin/l2tp: '/lib/' is not an ELF file
/sbin/l2tp: '/lib/' is not an ELF file
/sbin/l2tp: '/usr/lib/' is not an ELF file
/sbin/l2tp: can't load library ''
##### END SECTION l2tpv3d_sessions
##### BEGIN SECTION l2tpv3d_guest guest filter

Guest filter
------------
1: 1 lo normal
2: 2 tunl0 normal
3: 3 eth0 normal
4: 4 eth1 normal
5: 5 adsl normal
6: 6 lan normal
7: 7 guest guest-bridge
8: 8 wifi0 normal
9: 9 ath0 normal
10: 10 guest2 guest
fw_drop 0 in_drop 14 out_drop 0 ill_drop 0
##### END SECTION l2tpv3d_guest
##### END SECTION l2tpv3d

 

[PeterPawn]

Man kann auch einfach ein "chmod 777 <filename>" verwenden ... die Fehlermeldungen sehen danach aus, daß vom "install" die Datei nicht direkt kopiert, sondern eher durch einen Proxy ersetzt wurde.

Aber interessant ist es erst einmal, die die Dateien am Ende im SquashFS-Image aussiehen (in der Variante ohne "install") und das kriegt man mit einem "ls -l /sbin/l2tp*" in der Konsole am ehesten heraus.

 

[CaptainMorgan]

fwmod_custom:

all() {
   dummy=0
   ##   L2TP Binarys
     cp $HOME/freetz-trunk-7320/unpacked/7272/6.50/original/filesystem/sbin/l2tp ./filesystem/sbin/l2tp
    chmod 777 ./filesystem/sbin/l2tp
    cp $HOME/freetz-trunk-7320/unpacked/7272/6.50/original/filesystem/sbin/l2tpv3d ./filesystem/sbin/l2tpv3d
    chmod 777 ./filesystem/sbin/l2tpv3d
    mv ./filesystem/etc/default.Fritz_Box_HW188/ ./filesystem/etc/default.Fritz_Box_7320/

Supportdaten:

##### BEGIN SECTION l2tpv3d Suppotdata l2tpv3d
##### BEGIN SECTION l2tpv3d_log log

L2TPv3 log
----------
##### END SECTION l2tpv3d_log
##### BEGIN SECTION l2tpv3d_sessions sessions

L2TPv3 sessions
---------------
/sbin/l2tp: '/lib/' is not an ELF file
/sbin/l2tp: '/lib/' is not an ELF file
/sbin/l2tp: '/usr/lib/' is not an ELF file
/sbin/l2tp: can't load library ''
/sbin/l2tp: '/lib/' is not an ELF file
/sbin/l2tp: '/lib/' is not an ELF file
/sbin/l2tp: '/usr/lib/' is not an ELF file
/sbin/l2tp: can't load library ''
##### END SECTION l2tpv3d_sessions
##### BEGIN SECTION l2tpv3d_guest guest filter

Guest filter
------------
1: 1 lo normal
2: 2 tunl0 normal
3: 3 eth0 normal
4: 4 eth1 normal
5: 5 adsl normal
6: 6 lan normal
7: 7 guest guest-bridge
8: 8 wifi0 normal
9: 9 ath0 normal
10: 10 guest2 guest
fw_drop 0 in_drop 0 out_drop 0 ill_drop 0
##### END SECTION l2tpv3d_guest
##### END SECTION l2tpv3d

Ergebnis in der Konsole:

root@FritzBoxGarten:/var/mod/root# cd /sbin/
root@FritzBoxGarten:/sbin# ls -l l2tp*
-rwxrwxrwx    1 root     root         46782 Jan  9 03:40 l2tp
-rwxrwxrwx    1 root     root         83462 Jan  9 03:40 l2tpv3d

 

[PeterPawn]

Vergleiche mal die originale zu kopierende Datei aus dem entpackten 7320-Image mit der Datei, die am Ende im Image landet - da das Kopieren unter "fakeroot" erfolgt, kann es bei wiederholter Abarbeitung der Schritte Probleme geben, wenn zuvor nicht alles "sauber" war (sprich: alles neu entpackt wurde).

Gerade dann, wenn man nur "repacken" will nach Modifikationen, sollte man jedesmal neu entpacken. Je nachdem, welchen Weg man nun wirklich benutzt (fwmod-Aufrufe mit passenden Parametern oder "no freetz"-Modus mit passender .config), sind dazu unterschiedliche Aktionen erforderlich. Will man "make" benutzen, löscht man einfach nur das "build"-Verzeichnis unterhalb des Freetz-Verzeichnisses, ansonsten entpackt man jedesmal neu (fwmod -u).

EDIT:
Wenn Du die Dateien vergleichen solltest, prüfe ruhig auch noch einmal, daß die entpackten Versionen in "freetz-trunk-7320/unpacked/7272" tatsächlich auch mit dem Inhalt der originalen AVM-Firmware übereinstimmen. Sollte schon beim Auspacken in dieses "unpacked/7272" (gerade das erfolgt ja unter "fakeroot"-Steuerung, denn dabei müssen die Rechte halbwegs korrekt gesetzt werden - auch unter einem "normalen" Benutzer) etwas daneben gegangen sein (solange die x-Flags nicht gesetzt waren, war der Inhalt der Dateien ja erst recht egal, auch im ersten Anlauf mit dem "permission denied"), kann problemlos auch schon die Ausgangsdatei "falsch" sein und dann kann das "cp" da natürlich auch nichts mehr machen.

 

[NDiIPP]

Ich habe mal Beitrag #36 editiert. Im 2. Code-Tag zum kopieren also zusätzlich die Option "--preserve=all" (Edit: hier war ein Tippfehler, - anstatt =) verwenden (das hatte ich vergessen), dann sollte es direkt funktionieren.

 

[CaptainMorgan]

Tatsache, frisch entpackt sind l2tp und l2tpv3d einige bytes kleiner als die Varianten die noch vorrätig waren.
Dann funktioniert es auch mit ganz normalem cp, wobei --preserve all oder chmod 777 sicherlich nicht falsch wären, denn diese tags werden ins squash-fs mitgenommen, und alle andere binaries haben 777.

Dann wollte ich mir eine fwmod_custom bauen die das jedes mal neu macht, aber da kommt ein neuer Stolperstein:

   ##   L2TP Binarys
    rm -rf $HOME/freetz-trunk-7320/unpacked/7272/6.50/*
    rm -rf $HOME/freetz-trunk-7320/unpacked/7272/6.50/.unpacked.
    /$Home/freetz-trunk-7320/fwmod -u -d ./unpacked/7272/6.50/ ./images/FRITZ.Box_7272.120.06.50.image
    cp --preserve-all $HOME/freetz-trunk-7320/unpacked/7272/6.50/original/filesystem/sbin/l2tp ./filesystem/sbin/l2tp
    cp --preserve-all $HOME/freetz-trunk-7320/unpacked/7272/6.50/original/filesystem/sbin/l2tpv3d ./filesystem/sbin/l2tpv3d
 
    mv ./filesystem/etc/default.Fritz_Box_HW188/ ./filesystem/etc/default.Fritz_Box_7320/

freetz@Freetz-Server:~/freetz-trunk-7320$ /$HOME/freetz-trunk-7320/fwmod -u -d ./unpacked/7272/6.50/ /$HOME/freetz-trunk-7320/images/FRITZ.Box_7272.120.06.50.image
STEP 1: UNPACK
unpacking firmware image
splitting kernel image
ERROR: kernel splitting failed - maybe you should configure a firmware with FREETZ_AVM_HAS_SEPARATE_FILESYSTEM_IMAGE/FREETZ_AVM_HAS_INNER_OUTER_FILESYSTEM

Das entpacken funktioniert nur wenn in der .config auch eine 7272 oder ähnliches festgehalten ist.

Edit:
Habs selbst rausbekommen.
Zusätzliche .config anlegen, Parameter -i benutzen, HOME muss großgeschrieben werden.

##   L2TP Binarys
    rm -rf $HOME/freetz-trunk-7320/unpacked/7272/6.50/*
    rm -rf $HOME/freetz-trunk-7320/unpacked/7272/6.50/.unpacked.
    /$HOME/freetz-trunk-7320/fwmod -u -i /$HOME/freetz-trunk-7320/7272entpacken.config -d /$HOME/freetz-trunk-7320/unpacked/7272/6.50/ /$HOME/freetz-trunk-7320/images/FRITZ.Box_7272.120.06.50.image
    cp $HOME/freetz-trunk-7320/unpacked/7272/6.50/original/filesystem/sbin/l2tp ./filesystem/sbin/l2tp
    chmod 777 ./filesystem/sbin/l2tp
    cp $HOME/freetz-trunk-7320/unpacked/7272/6.50/original/filesystem/sbin/l2tpv3d ./filesystem/sbin/l2tpv3d
    chmod 777 ./filesystem/sbin/l2tpv3d
   
    mv ./filesystem/etc/default.Fritz_Box_HW188/ ./filesystem/etc/default.Fritz_Box_7320/

 

[NDiIPP]

Dann wollte ich mir eine fwmod_custom bauen die das jedes mal neu macht,

Warum? Einmal sollte doch reichen.

aber da kommt ein neuer Stolperstein:

Imo kein Wunder, fwmod funktioniert nur wenn man vorher per menuconfig eine zur entpackenden Firmware kompatibles Modell auswählt (hier bietet sich also direkt die Wahl der 7272 an). Die 7320/7330 verwendet aber ein anderes Firmware-Image Format, daher kann man nicht in einem "make-Zug", zumindest so wie du es versuchst, die Firmware der 7272 entpacken und eine Firmware für die 7320/7330 bauen.

 

[CaptainMorgan]

Warum? Einmal sollte doch reichen.

Nun, es hat sich ja bereits vorher einmal korrumpiert, was soll es davon abhalten es wieder zu tun.

mo kein Wunder, fwmod funktioniert nur wenn man vorher per menuconfig eine zur entpackenden Firmware kompatibles Modell auswählt (hier bietet sich also direkt die Wahl der 7272 an). Die 7320/7330 verwendet aber ein anderes Firmware-Image Format, daher kann man nicht in einem "make-Zug", zumindest so wie du es versuchst, die Firmware der 7272 entpacken und eine Firmware für die 7320/7330 bauen.

Du hast Recht. Der Workaround steht oben. fwmod erlaubt mit Parameter -i das anvisieren einer alternativen .config, das ganze kann in fwmod_customs geschehen.
Hat man bereits den Aufwand betrieben für diese eine Box einen seperaten Ordner anzulegen, geht es jetzt durchaus mit einem make.

Edit:
FYI, cp --preserve-all schmeißt eine Fhelrmeldung, chmod hat sich sich als sinnvoller erwiesen.

 

[NDiIPP]

Nun, es hat sich ja bereits vorher einmal korrumpiert, was soll es davon abhalten es wieder zu tun.

Das sollte normalerweise nicht passieren (ist mir auch noch nicht passiert). Und wenn doch so könnte das ja jederzeit wieder passieren wenn das bei jedem bauen der Firmware erneut gemacht wird, also so gesehen sogar ungünstiger.
Aber bei mir wirft "--preserve=all" auch keine Fehlermeldung aus. Das liegt aber zugegebenermaßen vermutlich daran, dass du meinen Tippfehler (--preserve-all anstatt --preserve=all) mit übernommen hattest (habe das mittlerweile in #36 und #47 korrigiert).

 

[PeterPawn]

Das sollte normalerweise nicht passieren (ist mir auch noch nicht passiert).

Mir ist das bei der Verwendung von "fakeroot" schon so manches Mal passiert (gerade dann, wenn man mit "fwmod -u" und "fwmod -p" arbeitet) ... irgendwo darin steckt m.E. noch ein Fehler. Nur hatte ich bisher nie so richtig Lust, mir das zugrundeliegende Problem mal genauer anzusehen, weil mein "Workaround" (alles immer frisch entpacken) eben auch funktioniert. Vielleicht ist es auch ein "Anwenderproblem", wenn man zwischen dem Entpacken unter "fakeroot"-Bedingungen und dem erneuten Einpacken noch Änderungen an den entpackten Dateien vornehmen läßt ... das Ergebnis waren aber auch bei mir "zerstörte" Dateien, bei denen (vermutlich durch Probleme bei der Inode-Zuordnung) der Inhalt nicht mit dem Original übereinstimmte.

Allerdings muß man hier tatsächlich nicht zwangsläufig zwei (ineinander geschachtelte) Versionen verwenden (und damit wäre das zweite "fwmod -u" verzichtbar) ... man könnte hier sogar ganz gezielt mittels "unsquashfs" auch nur die beiden benötigten Dateien aus der "fremden" Firmware extrahieren, wobei man dann erst mal die richtige Image-Datei aus dem TAR-File extrahieren muß. Wenn dabei der Eigentümer der Dateien nicht richtig gesetzt werden kann (schließlich ist man normalerweise nicht "root"), kann man das sogar ignorieren ... denn neue Versionen von "fwmod" verwenden beim Einpacken die Option "-all-root" (https://github.com/Freetz/freetz/blob/master/fwmod#L242) und damit erhalten die Dateien im SquashFS-Image dann trotzdem die richtigen IDs.

 

[stoney]

Wie sieht es eig. im Repeaterbetrieb mit KRACK aus, kann man diesen Fix auch irgendwie rein patchen? (natürlich von einer "aktuellen" FW eines anderen Modells)

​