[Problem] BusyBox 1.24.2 aus der Freetz-Toolchain

[PeterPawn]

Ich suche jemanden, der mal die Gegenprobe für ein Problem macht, das mir aufgefallen ist.

In einer FRITZ!Box gibt es normalerweise keine Locale-Definitionen ... d.h. die Variablen "LC_ALL", "LANG" und "LC_CTYPE" sind nicht gesetzt im Environment. Auch in Freetz habe ich auf die Schnelle keine Stelle gefunden, wo sie gesetzt würden.

Damit aktiviert eine BusyBox, die mit der Option "FEATURE_CHECK_UNICODE_IN_ENV=y" übersetzt wurde, ihre Unicode-Fähigkeiten aber gar nicht erst ... das Ergebnis ist eine Länge von 6 für die Zeichenkette "äöü".

root@FB7490:~ $ test="äöü";echo ${#test}
6

So weit, so gut ... aber spannend wird es jetzt, wenn man das mal mit aktivierter Unicode-Locale wiederholt:

root@FB7490:~ $ export LC_ALL=en_US.UTF-8;test="äöü";echo ${#test} | hd
00000000  c3 a4 c3 33 0a                                    |...3.|
00000005

Anstelle des nunmehr korrekten Ergebnisses von 3 Zeichen, erhält man pro enthaltenem Multibyte-Zeichen ein Byte vom Beginn der Zeichenkette (das kann man mit zwei Umlauten auch schön testen) und erst danach das korrekte Ergebnis (hier die 0x33 als ASCII-Kodierung für die "3").

Nun wäre das alles halb so wild, ergäbe diese Auswertung der Länge nicht das komplett falsche Ergebnis.

Zwar ist es auch recht angenehm, bei der Shell-Eingabe mit Unicode-Zeichen zu arbeiten, weil dann auch das Zählen klappt und das Editieren von Eingabezeilen sogar dann funktioniert, wenn diese ein Multibyte-Zeichen enthalten (wer schon mal vom kleinen "L" auf das "ö" abgerutscht ist und das irgendwie am Command-Prompt korrigieren wollte, weiß was ich meine), aber darauf muß man dann offenbar besser verzichten, solange das Aktivieren von UTF-8 solche Probleme mit normalen (voll POSIX-kompatiblen) Shell-Konstrukten verursacht.

Bevor ich das jetzt in der BusyBox-Mailing-Liste einkippe (oder, wenn das dort bereits korrigiert sein sollte, einen Patch für Freetz und die 1.24.2 daraus zimmere), hätte ich gerne noch eine zweite Meinung bzw. jemanden, der meine o.a. Erfahrungen bei sich einmal verifiziert.

Danke vorab ...

EDIT:
Gerade habe ich eine 1.28.0 (die aktuelle Entwicklerversion der BusyBox) mal ausgecheckt und übersetzt ... da ergibt das auch eine "ordentliche" Ausgabe; es ist also im Upstream mittlerweile korrigiert.

@er13:
Was ist Deine Ansicht zur BusyBox? Mittlerweile ist die 1.27.2 ja "stable" seit Mitte August und die 1.24.2 im Freetz-Trunk ist ohnehin weiter als die von AVM immer noch verwendete 1.22.1 ... da stellt sich die Frage, ob man eher den betreffenden Patch als Backport in die 1.24.2 übernimmt (mal unterstellt, daß es problemlos machbar ist) oder ob man die BusyBox gleich komplett auf eine neue Version aktualisiert. Es sind ja auch einige interessante Applets mittlerweile hinzugekommen (z.B. ein Hex-Editor und ein paar Erweiterungen für Mehrprozessorsysteme).

 

[f666]

Also bei mir bekomme ich immer eine Länge von 6 Zeichen:

   __  _   __  __ ___ __
  |__ |_) |__ |__  |   /
  |   |\  |__ |__  |  /_

   The fun has just begun ...


BusyBox v1.24.2 (2017-08-10 17:46:50 CEST) built-in shell (ash)

root@FB7490-SF:/var/mod/root> busybox
BusyBox v1.24.2 (2017-08-10 17:46:50 CEST) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, [[, addgroup, adduser, arp, arping, ash, awk, basename, blkid, brctl, bunzip2, bzcat, bzip2, cat, chgrp, chmod, chown, chroot, clear, cmp, cp, crond, crontab, cryptpw, cut, date, dd,
        delgroup, deluser, df, diff, dirname, dmesg, dnsdomainname, dos2unix, du, echo, egrep, env, ether-wake, expr, false, fdisk, fgconsole, fgrep, find, findfs, flock, free, ftpget, ftpput,     
        fuser, getopt, grep, groups, gunzip, gzip, halt, head, hexdump, hostname, httpd, id, ifconfig, ifdown, ifup, inetd, init, insmod, ionice, iostat, ip, ipaddr, iplink, iproute, iprule,       
        iptunnel, kill, killall, killall5, klogd, less, ln, logger, login, logname, logread, ls, lsmod, lsof, lzcat, lzma, makedevs, md5sum, mkdir, mkfifo, mknod, mkpasswd, mkswap, modinfo,        
        modprobe, more, mount, mpstat, mv, nbd-client, nc, netstat, nice, nohup, nslookup, passwd, patch, pidof, ping, ping6, pivot_root, pmap, poweroff, printenv, printf, ps, pstree, pwd, pwdx,   
        readlink, realpath, reboot, renice, reset, rm, rmdir, rmmod, route, sed, seq, setconsole, setserial, sh, sha1sum, sha256sum, sha3sum, sha512sum, sleep, smemcap, sort, split,                
        start-stop-daemon, stat, stty, stun-ip, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac, tail, tar, tee, telnet, telnetd, test, tftp, time, top, touch, tr, traceroute,             
        traceroute6, true, tty, umount, uname, uniq, unix2dos, unlzma, unxz, unzip, uptime, uudecode, vconfig, vi, watch, wc, which, whois, xargs, xz, xzcat, yes, zcat                              
                                                                                                                                                                                                     
root@FB7490-SF:/var/mod/root> echo $LC_ALL $LANG $LC_CTYPE                                                                                                                                           
                                                                                                                                                                                                     
root@FB7490-SF:/var/mod/root> echo $TERM                                                                                                                                                             
xterm-256color                                                                                                                                                                                       
root@FB7490-SF:/var/mod/root> test="äöü";echo ${test} ${#test}; echo ${test}|hexdump                                                                                                                 
äöü 6                                                                                                                                                                                                
0000000 c3a4 c3b6 c3bc 0a00                                                                                                                                                                          
0000007                                                                                                                                                                                              
root@FB7490-SF:/var/mod/root> export LC_ALL=en_US.UTF-8;test="äöü";echo ${#test}                                                                                                                     
6

 

[f666]

Busybox .config

 

[PeterPawn]

@f666:
Nicht wirklich verwunderlich:

# CONFIG_UNICODE_SUPPORT is not set

EDIT:
Ich habe gerade mal in eine "frische" Freetz-Konfiguration geschaut ... da ist tatsächlich der komplette Unicode-Support ausgeschaltet. Angesichts dessen, daß AVM da irgendwann auch mal den Schritt zur UTF-8-Unterstützung vollzogen hat im System (bei der BusyBox weiß ich es gar nicht, aber z.B. beim Mounten und Indexieren von NAS-Speicher oder beim Zugriff auf den Online-Speicher kann man es ja sehen), hätte ich das jetzt nicht direkt erwartet ... aber genau aus einem solchen Grund fragte ich nach einer Gegenprobe.

Also ... danke an @f666.

EDIT2:
Ja, ich habe es gerade noch einmal überprüft ... zumindest nach den GPL-Quellen von AVM (für die 113.06.83) ist in der "busybox.config.vr9" auch der Unicode-Support eingeschaltet:

CONFIG_UNICODE_SUPPORT=y
# CONFIG_UNICODE_USING_LOCALE is not set
# CONFIG_FEATURE_CHECK_UNICODE_IN_ENV is not set
CONFIG_SUBST_WCHAR=63
CONFIG_LAST_SUPPORTED_WCHAR=767
# CONFIG_UNICODE_COMBINING_WCHARS is not set
# CONFIG_UNICODE_WIDE_WCHARS is not set
# CONFIG_UNICODE_BIDI_SUPPORT is not set
# CONFIG_UNICODE_NEUTRAL_TABLE is not set
# CONFIG_UNICODE_PRESERVE_BROKEN is not set

... damit ist auch klar, warum der bei mir aktiviert/aktivierbar ist.

 

[er13]

Hallo Peter,

kann das Problem mit der busybox-1.24.2 hier nachstellen. Das Verhalten ist genauso wie von Dir beschrieben. Meine Einstellungen sind dabei:

# cat .config | grep BUSYBOX_UNICODE
FREETZ_BUSYBOX_UNICODE_SUPPORT=y
FREETZ_BUSYBOX_UNICODE_USING_LOCALE=y
FREETZ_BUSYBOX_UNICODE_COMBINING_WCHARS=y
FREETZ_BUSYBOX_UNICODE_WIDE_WCHARS=y
# FREETZ_BUSYBOX_UNICODE_PRESERVE_BROKEN is not set

Kann das Problem mit der busybox-1.27.2 aus #2930 wiederum nicht mehr nachstellen. Je nach LC_ALL ist die Ausgabe entweder 3 oder 6 ohne jeglichen Müll.

In welchem Commit das Problem behoben wurde, konnte ich auf die schnelle nicht rausfinden. In dem Short-Changelog bezieht sich der jüngste Eintrag mit den Schlüsselwörtern "unicode|locale|multi-byte" auf 1.23. Die Suche in den Commit-Messages war auch erfolglos. Aber vielleicht liegt es an den von mir gewählten Suchwörtern...

VG, Gene

 

[PeterPawn]

Das deckt sich mit meinen "Erfahrungen" ... ich habe auch bei der Suche in den BB-Quellen (in "libbb" bei der MBCS-Behandlung und in "ash" beim Ermitteln der Länge einer Variablen) auf Anhieb keine Stelle gefunden, wo das als Änderung zwischen der 1.24.2 und der 1.28.0 zu erkennen war - damit wußte ich auch nicht, wo genau nun zu patchen wäre.

Wichtig für mich ist nur ein reproduzierbares Verhalten (und nicht dieses Kauderwelsch, was bei der 1.24.2 mit Unicode-Support herauskommt bei der Länge) ... auch habe ich ja gesehen, daß Du etwas in Richtung 1.27.2 für den Trunk in Angriff genommen hast. Wenn ich davon ausgehe, daß irgendwann demnächst die 1.27.2 im Trunk ist (ich nehme den ja als Quelle für Tools im "modfs"- und YourFritz-Repository), dann ist mir das bei der 1.24.2 auch ziemlich egal, wo das Problem genau liegt.

Meines Erachtens kannst Du zwei BusyBox-Patches inzwischen ganz beruhigt beiseite legen ... der SIGINT-Patch für den Telnet-Daemon und der CRTSCTS-Patch für "init" sind vermutlich überflüssig und bei letzterem habe ich den Zusammenhang zu dem Ticket, wo der als Revert vom Upstream eingeführt wurde, immer noch nicht durchschaut . Das sieht für mich nach einer Änderung auf Verdacht aus, die erst einmal gar nichts bewirkte und dann trotzdem nie rückgängig gemacht wurde, weil sie schlicht vergessen wurde und nun wird sie von Version zu Version weiter mitgeschleppt.

Das dürfte ja nicht einmal mit der "doppelten Nutzung" irgendwelcher UARTs bei bestimmten Modellen kollidieren ... schaut man bei AVM in die BusyBox-Quellen, ist der CRTSCTS-Teil im Code dort auch genau der aus der originalen "init.c" - aber das hatten wir vor einem knappen halben Jahr ja schon "andiskutiert" im Zusammenhang mit der 7412.

 

[er13]

Hallo Peter,

grundsätzlich bin ich da, wo es Gründe dafür gibt, immer dafür auszumisten (s. z.B. #2673). Angesichts der Probleme, auf die ich im Rahmen von #2930 gestoßen bin, werde ich jedoch bewusst darauf verzichten, den Bump und das Ausmisten im selben Zug zu machen... um eben die eventuellen Probleme eindeutig dem Version-Bump zuordnen zu können.

Was den von Dir angesprochenen SIGINT-Patch angeht - dieser hat es nie nach upstream geschafft. Deswegen kann es durchaus sein, dass er immer noch notwendig ist.

VG, Gene

 

[er13]

auf Anhieb keine Stelle gefunden, wo das als Änderung zwischen der 1.24.2 und der 1.28.0 zu erkennen war

der Vollständigkeit halber - das Problem scheint nur den ${#}-Operator zu betreffen