Probleme beim libfreetz-Update

[olistudent]

Nachdem der Update auf libfreetz-0.3 gründlich schief gegangen ist (siehe z.B. hier), habe ich einen Patch angehängt, der die libfreetz nicht mehr gegen die libusbcfg von AVM linkt.

@Ralf
Für die neuen Firmwares (04.86) wird nur noch der Benutzer boxusr80 angelegt? Da müssen wir schauen inwiefern, dann der Zugriff über ftpuser (sowohl FTP als auch Samba) noch funktioniert.

Gruß
Oliver

 

[er13]

Patch, der die libfreetz nicht mehr gegen die libusbcfg von AVM linkt

gefällt mir nicht, weil ich nicht verstehe, wie/wieso es funktioniert

hast Du "libusbcfg in LD_PRELOAD vor libfreetz" schon ausprobiert?

wenn wir doch nicht gegen libusbcfg linken können, würde ich vorschlagen, dass wir es noch mit extern und dem weak attribute versuchen

 

[olistudent]

So?

extern struct T_USBCFG_config USBCFG_config __attribute__((weak));

Funktioniert bei mir nicht.

LD_PRELOAD=/lib/libusbcfg.so.1.0.0,/mod/root/libfreetz.so.1.0.0 ctlmgr

Der ctlmgr läuft aber passt die passwd nicht an.

Wenn ich die Reihenfolge der Libs tausche, dann bleibt er hängen:

6615 root      8560 S N  ctlmgr
 6616 root      2900 R    sh -c openssl_req -config /var/tmp/openssl.cnf -new -x509 -key /var/flash/websrv_ssl_key.pem -out /var/w

Ohne libusbcfg:

 LD_PRELOAD=/mod/root/libfreetz.so.1.0.0 ctlmgr -f
ctlmgr: 2010-10-29 15:28:58(1) [Segmentation fault] ctlmgr(6636) CRASHED at _ftext+0x404 (/mod/root/libfreetz.so.1.0.0 at 00000b64) accessing 00000000 (?)
ctlmgr: ze: 00000000 at: 1000ce01 v0: 00000000 v1: 00000000
ctlmgr: a0: 00000000 a1: 00000001 a2: 2b2bb000 a3: 00000001
ctlmgr: t0: fffffffe t1: 00000000 t2: 9406aee8 t3: fffffff0
ctlmgr: t4: 00000000 t5: 00000001 t6: 2ad2f710 t7: 2aabe59b
ctlmgr: s0: 00000000 s1: 2b2bb328 s2: 2b2bb2a8 s3: 00000001
ctlmgr: s4: 2ad9cd9e s5: 2aabeeec s6: 2aabef08 s7: 2ab33090
ctlmgr: t8: 2ad2e57c t9: 2acbe2d0 k0: 00000001 k1: 00000000
ctlmgr: gp: 2aad7010 sp: 7fc14538 fp: 2ab33090 ra: 2aabeb5c
ctlmgr: Code: 00000000  8fbc0018  8f828048 <16600024> 8c420000  8c430020  10600017  8f858024  8f948024
ctlmgr: [bt] Number of functions: 5
ctlmgr: [bt] (_ftext+0x2e0)+0x114 (/mod/root/libfreetz.so.1.0.0 at 00000a40)
ctlmgr: [bt] (write_users_acl+0x698)+0x88 (/usr/share/ctlmgr/libctlusb.so at 000061ec)
ctlmgr: [bt] (timsgprocessor_do_message+0x9fc)+0x104 (ctlmgr at 0042647c)
ctlmgr: [bt] instantiate_module+0x150 (ctlmgr at 0040f77c)
ctlmgr: [bt] main+0xf70 (ctlmgr at 0040d9ec)

Gruß
Oliver

 

[er13]

So?

extern struct T_USBCFG_config USBCFG_config __attribute__((weak));

Funktioniert bei mir nicht.

weiß ich nicht, muss ich selbst erst probieren

LD_PRELOAD=/lib/libusbcfg.so.1.0.0,/mod/root/libfreetz.so.1.0.0 ctlmgr

Der ctlmgr läuft aber passt die passwd nicht an.

Libraries in LD_PRELOAD werden mit ':', Leerzeichen oder Tab-Zeichen getrennt, s. da

 

[olistudent]

Beim Googeln bin ich auf folgenden Beitrag gestoßen: http://sourceware.org/ml/binutils/2008-08/msg00033.html

Bei den Versuchen habe ich festgestellt, dass sowohl das Library als auch das Binary mit -fPIC kompiliert werden müssen, dass das funktioniert.

root@fritz:/var/mod/root# LD_PRELOAD=./weak_plt_shared.so ./weak_plt_pic
calling weak_function
root@fritz:/var/mod/root# LD_PRELOAD=./weak_plt_shared.so ./weak_plt_nopic
weak_function not defined

#include <stdio.h>

extern int weak_function() __attribute__((weak));

int
main()
{
  if (weak_function) {
    fprintf(stderr, "calling weak_function\n");
    return weak_function();
  }
  else
   fprintf(stderr, "weak_function not defined\n");

  return 0;
}

Gruß
Oliver

edit: Ein LD_PRELOAD mit beiden Libs (libfreetz.so.1.0.0 und libusbcfg.so.1) bleibt hängen. strace zeigt kein Output.

edit 2:

#if 0
/* Perhaps we should support old style weak symbol handling
 * per what glibc does when you export LD_DYNAMIC_WEAK */
                                if (!weak_result)
                                        weak_result = (char *) DL_RELOC_ADDR(tpnt->loadaddr, sym->st_value);
                                break;
#endif

Was ist hiermit? (aus dl-hash.c)

 

[er13]

ich nehme mal an, die Ausgaben bekommst Du mit den ungepatchen binutils?

 

[olistudent]

Ich hab erstmal nichts an der Toolchain geändert.

Hier gibts noch einiges zu weak symbols.

Gruß
Oliver

 

[RalfFriedl]

Für die neuen Firmwares (04.86) ...

Ich habe keine Box, auf der eine 04.86 läuft. Die ersetzten Funktionen sollten das Gleiche tun wie im Original, außer daß nicht alle Benutzer gelöscht werden und der salt richtig funktioniert. Da die Namen der Benutzer nicht in dieser Library sind, sondern aus den AVM Datenstrukturen kommen, bin ich recht zuversichtlich, daß die Funktion identisch sein sollte. Aber ausprobieren kann das nur jemand, der eine entsprechende Box hat. Konkret muß man nur den ctlmgr mit bzw. ohne Preload starten, dann sieht man, ob die passwd und users.map gleich erstellt werden.

Wenn die Dateien gleich sind und der FTP-Server den ftpuser nicht mehr will, dann wird es auch mit original-Firmware nicht funktionieren.

Natürlich kann man eigene User anlegen, auch ftpuser, wenn diese nicht mehr gelöscht werden. Man muß nur das gecos-Feld so wählen, daß er nicht als AVM-User erkannt wird.

 

[olistudent]

@er13
Hattest du schon Zeit dich mit dem Problem zu beschäftigen? Ich komme mit weak nicht weiter. Grundsätzlich funktioniert das Überschreiben von weak Funktionen, wie oben beschrieben; in pic Objekten. Aber die libusbcfg lässt sich nicht mit LD_PRELOAD laden...

Gruß
Oliver

 

[er13]

noch nicht und komme an diesem WE leider auch nicht dazu, sorry, muss mich um andere Dinge kümmern

Edit:
ich hätte übrigens nichts gegen die Lösung "ohne extern mit genügend großen Struct", wenn Ralf mir erklären würde, wie/wieso es funktioniert. Ich verstehe es so. Durch die Definition des Symbols USBCFG_config in libfreetz und dadurch, dass diese wegen LD_PRELOAD als allererste geladen wird, ersetzt unser USBCFG_config-Symbol das gleichnamige Symbol aus libusbcfg. libusbcfg schreibt dann immer in die Struct aus libfreetz und nicht in die eigene. Das gilt alles für Funktionssymbole (und ich hätte kein Problem das zu verstehen). Die Frage, gilt das auch für Daten-Symbole, nicht dass dieses Symbol mal so, mal so aufgelöst wird, und demzufolge es mal in die Struct aus libfreetz, mal in die Struct aus libusbcfg geschrieben wird?

 

[RalfFriedl]

Es kommt nicht darauf an, wo die Struktur definiert wird, solange sie groß genug ist. Die ursprüngliche Größe paßte zur älteren Firmware, die neue Größe paßt zur neueren Firmware. Die Struktur wird über den Namen angesprochen, also sorgt der Linker dafür, daß immer der gleiche Speicherbereich angesprochen wird. Anders ist es, wenn wie beim Problem mit __progname das Symbol als hidden definiert wird, was aber hier nicht der Fall ist.
Da libfretz mit PRELOAD geladen wird, ist dort zwangsläufig die erste Definition des Symbols, und anscheinend gilt dann auch dessen Größe. Wenn die Struktur hier zu groß definiert wird, ist das nicht weiter schlimm, deswegen gibt es auch kein Problem mit älteren Firmware Versionen.
Wenn libusbcfg in seine eigene Kopie der Struktur schreiben würde, dann würde die Struktur in libfreetz den ursprünglichen Wert von 0 behalten. Und das würde man das sehr schnell merken, weil Elemente dieser Struktur als Pointer genutzt werden.

Im Prinzip ist es das Gleiche wie bei Funktionen auch. Es gibt einen Namen für ein Symbol, und in allen Dateien, Hauptprogramm und shared Libraries, wird für dieses Symbol die gleiche Adresse eingetragen.