Ja, ich habe natürlich auch erst einmal mit dem Vergleich der beiden Busyboxen (allerdings bei der modifizierten eben auf der Basis meiner .config und nicht auf der von Freetz) begonnen und dabei festgestellt, daß die folgenden bisher von mir in der Busybox verbauten Applets auch in der AVM-Firmware (mit abweichenden Programmen) vorhanden sind:
Code:
base64
blkid
ftpd
ipcs
lsusb
nanddump
Das ist an vielen Stellen auch kein Problem, weil AVM-Skripte inzwischen schon "gelernt" haben und meistens direkt mit vollem Pfad solche Utilities aufrufen (dann kann da niemand über eine geänderte PATH-Variable andere Binaries oder Skripte ausführen lassen).
Was bei mir in der Busybox fehlte, aber bei AVM vorhanden war, waren das "fstrim"- und das "xz"-Applet ... alles andere war "zuviel" in meiner Version.
Ich weiß inzwischen auch schon, daß es "lsusb" nicht ist.
"base64" in der AVM-Version hat keine "usage"-Funktion (auch nicht in der "strings"-Ausgabe
), kennt aber sowohl das Kodieren ohne weitere Parameter als auch das Dekodieren mit "-d" - habe ich einfach mal probeweise rausgelassen aus der Busybox.
Der "ftpd" sollte hier keine Rolle spielen.
Die Anzeige von "ipcs" sieht beim Applet und bei der gesonderten Version von AVM zunächst mal identisch aus, ob da intern noch ein Aufruf mit anderen Parametern erfolgt:
Code:
# ipcs -h
ipcs provides information on ipc facilities for which you have read access.
Resource Specification:
-m : shared_mem
-q : messages
-s : semaphores
-a : all (default)
Output Format:
-t : time
-p : pid
-c : creator
-l : limits
-u : summary
-i id [-s -q -m] : details on resource identified by id
usage : ipcs -asmq -tclup
ipcs [-s -m -q] -i id
ipcs -h for help.
weiß ich nicht ... habe ich einfach ebenso rausgeworfen wie "lsusb" aus der Busybox, weil AVM ja da auch ein anderes (Ausgabe-)Format erwartet.
Hat bis hier alles nicht geholfen, meine Busybox hat noch die folgenden Applets "mehr" als die von AVM:
Code:
# ./busybox_mod | sed -e "1,/^Current/d" | sed -e "s/,/\n/g" | sed -e "/^$/d" | sed -e "s/[ \t]*\(.*\)/\1/" >applets.mod
# ./busybox_org | sed -e "1,/^Current/d" | sed -e "s/,/\n/g" | sed -e "/^$/d" | sed -e "s/[ \t]*\(.*\)/\1/" >applets.org
# ./busybox_mod diff -Naur applets.org applets.mod | sed -n -e "s/^+\([^+].*\)/\1/p"
addgroup
adduser
awk
base64
bash
bbconfig
blockdev
chat
chattr
chpst
cksum
clear
comm
conspy
cpio
crond
crontab
cryptpw
cttyhack
dc
delgroup
deluser
depmod
devmem
dhcprelay
diff
dnsd
dos2unix
dpkg
dpkg-deb
dumpleases
envdir
envuidgid
expand
fatattr
fdisk
findfs
flash_eraseall
flash_lock
flash_unlock
flashcp
fold
fsck
fsync
ftpd
fuser
hd
hdparm
head
hexdump
hostid
httpd
ifenslave
inotifyd
install
ipcalc
klogd
last
less
logger
logread
losetup
lsattr
lspci
lzcat
lzma
makedevs
makemime
microcom
mkpasswd
mktemp
modinfo
mountpoint
nandwrite
nc
nmeter
ntpd
od
openvt
patch
pgrep
pipe_progress
pkill
pscan
rdate
rdev
reformime
rev
rfkill
rpm
rpm2cpio
run-parts
runsv
runsvdir
rx
sendmail
setlogcons
setsid
setuidgid
sha1sum
sha256sum
sha512sum
shuf
slattach
softlimit
split
start-stop-daemon
strings
stun-ip
sv
svlogd
syslogd
tac
taskset
tcpsvd
telnet
tftpd
timeout
traceroute6
tunctl
tune2fs
udhcpc
udhcpc6
udhcpd
udpsvd
unexpand
unix2dos
unlink
unlzma
users
usleep
uudecode
uuencode
watch
watchdog
which
who
yes
zcip
Mein Hauptproblem ist die Entscheidung, wie ich vorgehen will ... entweder von der AVM-Version aus nach und nach Applets hinzufügen oder aus meiner Stück für Stück weitere Applets entfernen.
Wobei ich gerade sehe, daß das "base64" immer noch drin ist. Da bin ich ggf. durcheinander geraten, weil ich verschiedene Buildroot-Umgebungen (mit unterschiedlichen Einstellungen für's Suchen beim dynamischen Laden) habe, damit die fertigen Binaries auch ohne irgendwelche "LD_*"-Environment-Settings funktionieren, wenn die zusätzlichen Bibliotheken z.B. unter meinem Standardpfad "/var/custom/lib" zu finden sind.
Ich will am Ende auf so wenige Zusätze wie möglich verzichten ... eigentlich hätte ich gerne ein einzelnes "schuldiges" Applet, das dann in der Busybox einen anderen Namen kriegt und trotzdem drin bleibt. :mrgreen:
Da ich eigentlich nichts ausgelassen habe (alle Applets auch mit "long options"), kann ich mir irgendwie nicht vorstellen, daß AVM da irgendetwas verwenden will, was meine Busybox an Optionen nicht hergibt bzw. wo die Optionen abweichen. Zuerst dachte ich eben auch an ein Applet, was anstelle eines gesonderten Programms aufgerufen wird, weil die Busybox ja die Option kennt, zuerst nach Applets zu schauen, bevor externe Programme gesucht werden.
Aber alle o.a. Programme sind "unknown commands", wie man leicht feststellen kann:
Code:
# ./busybox_mod diff -Naur applets.org applets.mod | sed -n -e "s/^+\([^+].*\)/\1/p" | wc -l
139
# ./busybox_mod diff -Naur applets.org applets.mod | sed -n -e "s/^+\([^+].*\)/\1/p" | while read cmd; do cmd 2>/dev/null; [ $? -eq 127 ] && echo "unknown" || echo "found"; done | grep unknown | wc -l
139
Das mit dem "Zählen" ist nur für hier zur Demo (die Liste ist eher länglich), ich habe schon auch auf stderr jeweils geprüft, daß es wirklich "unknown command" ist, was die Ursache für rc=127 angeht.
Da ich auch keine Symlinks auf die Busybox neu setzen lasse (was dann ja auch noch zum Aufruf eines Applets anstelle einer Angabe des Programms mit vollem Pfad führen könnte), kann das auch nicht die Ursache sein.
Wenn ich nichts finde, werde ich auch mal die "usage"-Screens vergleichen ... der nächste Schritt wird es wohl sein, daß ich mich dem Problem "von beiden Seiten" nähere. Also erst einmal eine Busybox mit genau denselben Applets wie bei AVM bauen und wenn schon die nicht arbeiten will, ist es eine der Optionen, die sich nicht in Form zusätzlicher Applets niederschlagen. Ich habe also erst einmal mit den wahrscheinlichsten Ursachen begonnen (falsches Programm wird aufgerufen), wenn es das nun offenbar nicht ist, dann stutze ich es als nächstes auf AVM zurecht und entscheide anhand des Ergebnisses, wo ich weiter suchen will. Wenn jemand das mal mit seiner Busybox-Konfiguration vergleichen will, ich hänge die meine mal hier an (für die oben verwendete "busybox_mod", die "busybox_org" ist das AVM-Original aus der 06.50 der 7490).
Meine "Erklärung" der Schwierigkeiten bezog sich also auch mehr auf das, was zu erwarten wäre als auf bisherige Versuche, wobei ich am Beginn noch so blauäugig war und wirklich jedes der nach meiner Ansicht wahrscheinlichsten Applets (lsusb, blkid, nanddump (hier war schon wieder unklar, wo das benutzt würde), base64) immer schön einzeln entfernt habe ... immer in der Hoffnung, es könnte in der nächsten Runde schon funktionieren.
Ob das bei der 7390 (wo Du ja verglichen hast) jetzt wirklich dasselbe Problem ist, weiß ich auch nicht ... nicht, daß das jetzt falsch verstanden wird. Aber die beschriebenen Symptome passen zu denen bei meiner 7490 und da das bei mir dann auch wieder auftrat, als ich die Box komplett angepaßt hatte, mußte ich halt erst einmal diverse andere Ursachen ausschließen und habe mit Libraries begonnen - auf die Busybox bin ich erst am Ende gekommen, weil ich eben in der neuen WLAN-Konfiguration (das frühere /etc/ath ist ja verschwunden, wenn auch schon etwas früher auf libacfg.so umgestellt wurde, aber bei der 06.50 ist es nun wirklich "weg") nicht darauf gekommen wäre, daß da externe Programme aufgerufen werden - jedenfalls nicht in nennenswertem Umfang.
Auch schlägt nach meiner Interpretation meiner Fehlermeldungen in der wland_support.log schon das Laden der Kernel-Module fehl (woher sollte sonst der passende Eintrag im procfs kommen, wenn nicht aus einem Treiber), daher suchte ich als erstes in der Richtung "insmod"/"modprobe" und da fand ich bei der ersten Prüfung der Busybox keinen nennenswerten Unterschied. Das Suchen über diverse Libs nach irgendwelchen Strings ist auch nicht so richtig prickelnd, weil einfach zu viele Fundstellen existieren, wenn man nach den doch eher gebräuchlichen Namen irgendwelcher Applets sucht ... einfach weil Symbole für Funktionen das meist auch im Namen haben.
Ich mache einfach Stück für Stück weiter und beobachte diesen Thread, falls jemand anderes das schuldige Applet vor mir findet. Wobei ich schon mal daran interessiert wäre, ob andere das Problem mit dem Ersetzen der Busybox genau so auch bestätigen können ... man braucht ja nur die Busybox aus build/original in fwmod_custom noch einmal vor dem Packen nach build/modified zu kopieren und ggf. die neue irgendwie umbenennen, wenn der Platz für beide reicht (bei der 7490 ja kein Problem).
