Firmware für 7390 mit Freetz erstellen...

[er13]

Wir beide würden wahrscheinlich keinen Vorteil darin sehen. Es gibt jedoch Leute, die zwar Ihre Firmware modifizieren möchten jedoch (aus was auch immer welchen Gründen) kein Freetz installieren möchten.

Als schöner Nebeneffekt der (mehr oder weniger) modularen Programmierung von Freetz kann Freetz auch solchen Leuten helfen. fwmod kann (seit r12055 ohne Schönheitsfehler) als reines "entpacke und packe wieder ohne etwas zu modifizieren"-Tool verwendet werden. Zwischen den entpacke/packe-Schritten wird natürlich erwartet, dass der User die von ihm gewünschten Änderungen selbst vornimmt.

 

[Falconcrest]

Nun habe ich es mit freetz wieder versucht, doch mir stellen sich inzwischen weitere Fragen:

- installiert habe ich freetz-devel 12055
- wenn ich es nicht falsch interpretiert habe, dann wurde im Verlauf des Zusammensetzens der Firmware von AVM die letzte Stable geladen(7390_de 84.06.03 rev 27349), ich nutze doch aber bereits die letzte Labor 84.06.10-28022, dann platzt mir doch bestimmt das Image beim Einspielen, da die Konfigurationseinstellungen sicherlich teilweise bereits verändert sind
- es kam folgende Meldung: Warning: This kernel can only load 50 modules at the same time, try `replace kernel`. Die Meldung davor lautete: Kernel modules installed: 75 entries in modules.dep and 81 .ko-files found. Ist das problematisch?
- erzeugt wurde also 7390 06.03-freetz-devel-12055.de_20140524-124211.image,

Wie kann ich erzwingen, dass von einer bestimmten Firmware ausgehend, eine neue Firmware zusammengesetzt wird?

 

[PeterPawn]

Wir beide würden wahrscheinlich keinen Vorteil darin sehen. Es gibt jedoch Leute, die zwar Ihre Firmware modifizieren möchten jedoch (aus was auch immer welchen Gründen) kein Freetz installieren möchten.

Einen möglichen Grund (nämlich meinen) kann ich da anbieten:
Sofern man in den originalen AVM-Teilen der Firmware einen Fehler findet (und da fallen mir auf Anhieb noch einige ein) oder ansonsten ein Problem mit der AVM-Firmware hat (die vorherige Version für 7390i hatte z.B. arge Probleme mit ISDN an einem A1-Anschluß in Österreich), beisst man bei AVM einfach nur auf Granit, wenn man keine Support-Daten anbieten kann oder will.

Geht dann aus diesen Supportdaten irgendwie hervor, daß man die Box mit "Freetz" betreibt, kann ich das Lachen der Support-Mitarbeiter bis hier hören (und das sind knapp 20 km Luftlinie bis zum AVM-HQ). Und zwar unabhängig davon, ob der Fehler auch nur im entferntesten mit Freetz zu tun haben könnte oder nicht ...

Baue ich hingegen meine eigenen Erweiterungen so ein, dass sie nur beim Vorhandensein eines passenden USB-Sticks eingebunden werden, kann ich durch einfaches Abziehen (bzw. -lassen, wenn die Box remote ist) testen, ob meine Erweiterungen oder die originale Firmware das Problem verursachen.

Lösche ich dann noch per telnet die debug.cfg und fw_attrib per clearid, kann ich nach einem Neustart auch die Support-Daten ruhigen Gewissens an AVM geben, da sie - meiner Meinung nach - keinen Grund für das Verweigern des Supports in diesen Daten finden werden. Anschließend ist die debug.cfg schnell wiederhergestellt und dann noch den Stick dran ... voila, Problem zwar wahrscheinlich noch da, aber alles ohne irgendwelches Recovern der Box (Remote-Problem).

Als schöner Nebeneffekt der (mehr oder weniger) modularen Programmierung von Freetz kann Freetz auch solchen Leuten helfen. fwmod kann (seit r12055 ohne Schönheitsfehler) als reines "entpacke und packe wieder ohne etwas zu modifizieren"-Tool verwendet werden. Zwischen den entpacke/packe-Schritten wird natürlich erwartet, dass der User die von ihm gewünschten Änderungen selbst vornimmt.

Wohl jeder, der eigene Erweiterungen auf der Box laufen läßt, die nicht nur aus Skript-Code bestehen, wird doch ohnehin mit hoher Wahrscheinlichkeit auf freetz zurückgreifen. Selbst wenn sein Wunschpaket vielleicht nicht im Trunk vorhanden ist ... alleine die Toolchain spart doch schon vielen doppelte Arbeit.

Beim "Umpacken" eines AVM-Images würde ich aber Deinem "Vorredner" wieder zustimmen ...
Wenn ich ohnehin schon Freetz für das Erstellen eines eigenen *Images* benutze, kann ich auch gleich das komplette Framework für Hooking, Konfiguration und GUI nutzen. Jedenfalls bei meiner Motiviation für minimalinvasive Eingriffe ...

 

[PeterPawn]

Wie kann ich erzwingen, dass von einer bestimmten Firmware ausgehend, eine neue Firmware zusammengesetzt wird?

make menuconfig

"Level of user competence" auf "Expert"
"Firmware version" einstellen (Labor in Deinem Falle)

 

[Falconcrest]

Hallo zusammen,

bitte verwirrt Falconcrest mit Euren Antworten nicht. So wie ich es vestehe, hat er diesen Beitrag von mir gelesen und möchte eigentlich nur das und nicht mehr, i.e. nicht unbedingt Freetz installieren.

Das geht schon halbwegs, ich will ja auch etwas dabei lernen...

@Falconcrest: wenn Du bereit bist, Freetz zu installieren, so musst Du nach einer beliebigen (funktionierenden) Anleitung Freetz installieren und keinen Patch zusätzlich manuell aus dem oben referenzierten Beitrag anwenden. Der Patch ist in Freetz bereits enthalten und wird immer automatisch angewandt, d.h. insbesondere, dass der entsprechende mknod-Befehl aufgerufen wird (grob gesagt "debug.cfg wird angelegt") und debug.cfg auch automatisch aus rc.tail.sh gestartet (so wie es in allen früheren Firmware-Versionen der Fall war). D.h. es ist kein expliziter Aufruf von debug.cfg aus rc.custom notwendig (grundsätzlich wäre auch das (statt rc.tail.sh) möglich, man hätte aber den mknod-Teil nicht vergessen dürfen).

Mein erster Versuch damit ging wohl wie etwas höher beschrieben, daneben. Ich wollte ein Image, welches auf der letzten LabBETA basiert und nicht der letzten STABLE.
Auf Antworten und Tipps dazu warte ich noch, aber wenn es denn so geht, wie ich es mir vorstelle, dann soll es eben auch komplett freetz sein.

Wenn Du Freetz jedoch nicht installieren möchtest, sondern die AVM-Firmware mit Hilfe von Freetz entpacken, anpassen und wieder packen möchtest (so wie es in dem Beitrag von mir gemeint war), so versuche bitte die in dem Beitrag referenzierte Anleitung.

Jetzt habe ich es noch einmal nach der von Dir beschriebenen Methode versucht. Auch dabei kommen Meldungen, die ich noch nicht so recht deuten kann:
STEP 3: PACK
WARNING: firmware does not seem to be modified by the script... und dann noch ein
WARNING: Not enough free flash space for answering machine!

Ist das nun bedenklich oder vernachlässigbar? Ein Image wurde jedenfalls gebaut, ich traue mich nur noch nicht, es zu flashen, bevor ich nicht weiss, ob die Meldungen unbedenklich sind.

p.s. ohne debug.cfg kommt man derzeit nicht aus. Die aktuelle LCR-Version installiert sich in diese.

Wieder was dazu gelernt.

 

[Falconcrest]

make menuconfig

"Level of user competence" auf "Expert"
"Firmware version" einstellen (Labor in Deinem Falle)

Hrrrrrrr, das ich darauf nicht selbst gekommen bin...
Ich habe mich über BEGINNER nicht hinaus getraut.

Übrigends, sollte man immer neu "Auschecken", bevor man wieder eine FW erstellen will?

 

[PeterPawn]

Übrigends, sollte man immer neu "Auschecken", bevor man wieder eine FW erstellen will?

Eher nicht.

Wenn Du unbedingt die allerletzten Änderungen in dem von Dir benutzten Branch erwischen willst, reicht auch ein

svn update

Allerdings ist ja nicht jede Änderung für Dich auch notwendig. Wenn jemand z.B. wie in r12057 Änderungen am callmonitor vornimmt und Du diesen aber gar nicht in Deinem Image hast/haben willst, brauchst Du auch diese Änderungen nicht.

Faustregel: Erst bei ungeklärten Fehlern (oder bei für Dich interessanten Änderungen im SVN ... das Journal findest Du hier) updaten. Fehler (und die kommen bekanntermaßen immer wieder mal vor) in Komponenten, die Du nicht brauchst, die aber beim make dann zum Show-Stopper werden, muß man ja nicht unbedingt haben.

 

[RalfFriedl]

Übrigends, sollte man immer neu "Auschecken", bevor man wieder eine FW erstellen will?

Normalerweise ist das nicht notwendig. Wenn aber unerklärliche Fehler auftauchen, dann sollte man es zuerst mit einem neuen Verzeichnis versuchen. Im obigen Fall, wo klar war, dass Du einige Änderungen vorgenommen hattest, aber nicht unbedingt klar war, welche Änderungen dies waren, hatte ich deswegen empfohlen, komplett neu anzufangen.

Wie bereits geschrieben, kann man das Verzeichnis dl trotzdem gemeinsam nutzen, zum Beispiel durch einen Symlink auf ein vorhandenes Verzeichnis. Dadurch muss nicht alles neu herunter geladen werden.

 

[Falconcrest]

So, es ist vollbracht. Meine erste eigenhändig erstellte FW läuft...
Ich habe mich dann doch für Freetz komplett entschieden, weniger weil ich der Anleitung nicht traute, sondern eher meinem Patchen der bestehenden FW.
Ein kleines Manko ist noch da, der LCR ist zwar im Menü vorhanden, aber beim Aufruf steht Murks im Browserfenster.
Ich werde den LCR nochmal neu installieren und mal sehen, wie es dann aussieht.

Danke nochmals allen für die kompetente Unterstützung und die Beantwortung meiner nervenden Fragen!

Edit: Und schon geht`s weiter....

Das erneute Einspielen des LCR brachte nichts, ich komme auf (fritz.box/cgi-bin/tsb/index.html), wo ich das PW eingeben kann und nach dem Betätigen des Anmelde-Buttons steht ...illegal option 'c' usage: allcfgconv allcfgconv [options] options: -?.... usw. im Browser.

Ich denke aber, ich werde den Thread wechseln müssen, denn Freetz läuft ja.

 

[er13]

Beim "Umpacken" eines AVM-Images würde ich aber Deinem "Vorredner" wieder zustimmen ...

Mich musst Du nicht überzeugen, was besser ist. Bei mir läuft Freetz auf jeder Box in der Familie und im Freundeskreis. Ich habe lediglich eine Möglichkeit für all diejenigen aufgezeigt, die (aus, wie gesagt, was auch immer welchen Gründen) kein Freetz installieren möchten.

Das erneute Einspielen des LCR brachte nichts, ich komme auf (fritz.box/cgi-bin/tsb/index.html), wo ich das PW eingeben kann und nach dem Betätigen des Anmelde-Buttons steht ...illegal option 'c' usage: allcfgconv allcfgconv [options] options: -?.... usw. im Browser.

Das wird wohl daran liegen, dass allcfgconv den Parameter -c nicht mehr unterstützt (s. diesen Beitrag von PeterPawn für die vollständige Liste aller "Macken" der neuen Labors).

 

[TelefonSparbuch]

Im LCR dürfte das nur Auswirkungen auf die Auswertung der Anrufliste und Anzeige der Wahltabellenseite haben. Allerdings geht durch die fehlende -c Option auch das Login nicht mehr... Ich werde dazu noch eine Lösung schreiben, in dem der Daemon sich das letzte erfolgreiche Login merkt und mit diesem "gesicherten" Passwort die Hintergrundaufgaben wahrnimmt. Login ist bereits schon auf die AVM Routine umgeschrieben und benötigt das Kennwort nicht mehr zum Abgleich.

 

[Falconcrest]

Im LCR dürfte das nur Auswirkungen auf die Auswertung der Anrufliste und Anzeige der Wahltabellenseite haben. Allerdings geht durch die fehlende -c Option auch das Login nicht mehr... Ich werde dazu noch eine Lösung schreiben, in dem der Daemon sich das letzte erfolgreiche Login merkt und mit diesem "gesicherten" Passwort die Hintergrundaufgaben wahrnimmt. Login ist bereits schon auf die AVM Routine umgeschrieben und benötigt das Kennwort nicht mehr zum Abgleich.

So dürfte sich dann meine kürzliche Aktivierung(& Investition) vom LCR wieder lohnen und die Arbeit mit freetz noch weitere Freude bereiten.
Danke vorab schon einmal dafür!

 

[PeterPawn]

Mich musst Du nicht überzeugen, was besser ist. Bei mir läuft Freetz auf jeder Box in der Familie und im Freundeskreis. Ich habe lediglich eine Möglichkeit für all diejenigen aufgezeigt, die (aus, wie gesagt, was auch immer welchen Gründen) kein Freetz installieren möchten.

Dich wollte ich auch gar nicht überzeugen ...
Das war mehr ein "Abschwächen" einer sonst vielleicht in meinen Text hineinzulesenden generellen Ablehnung ge"freetz"ter Boxen. Es ist eben ein Unterschied, ob man seine private Box oder die im Home-Office eines Kunden mit einem "fremden" Image versieht.

Ich finde es sogar gut, daß Du Deine eigene Anleitung (und wohl auch fwmod) nach entsprechendem Test noch einmal nachgebessert hast.

Ich hatte mir einen eigenen Patch für fwmod gebaut (wie Deiner aussieht schaue ich mir gleich mal an), weil ich das Info-File nicht wollte und weil die Filesystem-Struktur in build/modified nicht stimmt, wenn man kein 'make' gemacht hat.

===================================================================
--- fwmod       (Revision 11941)
+++ fwmod       (Arbeitskopie)
@@ -28,6 +28,7 @@
     -f         force pack even if image is too big for flash (AVM SDK)
     -z         zip file system into archive for USB/NFS root
     -c <dir>   copy file system to target directory for NFS/USB root (implies -z)
+    -x         do not integrate freetz info file into packed firmware image
   input/output
     -i <cfg>   input file for configuration data (default: .config)
     -d <dir>   build directory (default: <orig_firmware>.mod)
@@ -60,11 +61,11 @@

 # Default values for unset command line parameters
 DOT_CONFIG="$(dirname "$0")/.config"
-DO_UNPACK=0; DO_MOD=0; DO_PACK=0; FORCE_PACK=0; DO_ZIP=0; _OPT=0
+DO_UNPACK=0; DO_MOD=0; DO_PACK=0; FORCE_PACK=0; DO_ZIP=0; _OPT=0; DO_NOINFO=0;
 COPY_FS_DIR=; DIR=

 # Parse command line parameters
-while getopts umpanfzc:i:d: opt; do
+while getopts umpanfzc:xi:d: opt; do
        case "$opt" in
                u) DO_UNPACK=1; _OPT=1 ;;
                m) DO_MOD=1; _OPT=1 ;;
@@ -74,6 +75,7 @@
                f) FORCE_PACK=1 ;;
                z) DO_ZIP=1 ;;
                c) COPY_FS_DIR="$OPTARG"; [ "$COPY_FS_DIR" ] && DO_ZIP=1 ;;
+               x) DO_NOINFO=1 ;;
                i) DOT_CONFIG="$OPTARG" ;;
                d) DIR="$OPTARG" ;;
                *) usage >&2; exit 1 ;;
@@ -1427,18 +1429,20 @@
        modstring="${modimagenameprefix}${modbaseimagename}${modimagenamesuffix}_$modmakedate"
        modimage="${modstring}.image"

-       # Create freetz-info
-       echo1 "integrate freetz info file into image"
-       freetz_info_file="$MOD_DIR/filesystem/etc/freetz_info.cfg"
-       echo "export FREETZ_INFO_BOXTYPE='${FREETZ_TYPE_PREFIX_ALIEN_HARDWARE}${FREETZ_TYPE_PREFIX%_0?_??}${FREETZ_TYPE_PREFIX_LABOR_FIRMWARE}'" > "$freetz_info_file"
-       echo "export FREETZ_INFO_FIRMWAREVERSION='${FIRMWAREVERSION}'" >> "$freetz_info_file"
-       echo "export FREETZ_INFO_SUBVERSION='${SUBVERSION}'" >> "$freetz_info_file"
-       echo "export FREETZ_INFO_LANG='${FREETZ_TYPE_LANGUAGE}'" >> "$freetz_info_file"
-       echo "export FREETZ_INFO_MAKEDATE='$modmakedate'" >> "$freetz_info_file"
-       echo "export FREETZ_INFO_IMAGE_NAME='$modimage'" >> "$freetz_info_file"
-       echo "export FREETZ_INFO_COMMENT='${FREETZ_USER_DEFINED_COMMENT}'" >> "$freetz_info_file"
-       externalised_files=$(find build/modified/external/ -type f 2>/dev/null | sed -e '/external\.pkg/d;/\.external/d;s,build/modified/external/,,')
-       echo "export FREETZ_INFO_EXTERNAL_FILES='${externalised_files}'" >> "$freetz_info_file"
+       if [ "$DO_NOINFO" -eq 0 ]; then
+               # Create freetz-info
+               echo1 "integrate freetz info file into image"
+               freetz_info_file="$MOD_DIR/filesystem/etc/freetz_info.cfg"
+               echo "export FREETZ_INFO_BOXTYPE='${FREETZ_TYPE_PREFIX_ALIEN_HARDWARE}${FREETZ_TYPE_PREFIX%_0?_??}${FREETZ_TYPE_PREFIX_LABOR_FIRMWARE}'" > "$freetz_info_file"
+               echo "export FREETZ_INFO_FIRMWAREVERSION='${FIRMWAREVERSION}'" >> "$freetz_info_file"
+               echo "export FREETZ_INFO_SUBVERSION='${SUBVERSION}'" >> "$freetz_info_file"
+               echo "export FREETZ_INFO_LANG='${FREETZ_TYPE_LANGUAGE}'" >> "$freetz_info_file"
+               echo "export FREETZ_INFO_MAKEDATE='$modmakedate'" >> "$freetz_info_file"
+               echo "export FREETZ_INFO_IMAGE_NAME='$modimage'" >> "$freetz_info_file"
+               echo "export FREETZ_INFO_COMMENT='${FREETZ_USER_DEFINED_COMMENT}'" >> "$freetz_info_file"
+               externalised_files=$(find build/modified/external/ -type f 2>/dev/null | sed -e '/external\.pkg/d;/\.external/d;s,build/modified/external/,,')
+               echo "export FREETZ_INFO_EXTERNAL_FILES='${externalised_files}'" >> "$freetz_info_file"
+       fi

        # Pack var.tar (use old tar for compatibility)
        echo0 "packing var.tar"

Ich hätte den auch eingereicht, wenn ich nicht so fest in meinen Vorurteilen verhaftet wäre :blonk: und automatisch eine Diskussion: "Wer sollte das je brauchen können ?" erwartet hätte.

Vielleicht klappt es ja auch noch mit einer weiteren Änderung ?

Bisher priorisierte fwmod die Einstellungen in der .config, egal was auf der Kommandozeile angegeben wurde. Selbst wenn man explizit '-p' angab und in .config war das Packen ausgeschaltet (weil man beim make nur die Binaries für den eigenen Stick, aber kein Image wollte), wurde die Angabe aus .config berücksichtigt.

Ist das nach Deiner Änderung jetzt anders ? Wenn nein, hätte ein zusätzlicher Switch wie '-P' für "force packing of image, ignore .config settings" o.s.ä. Aussicht auf Übernahme ins SVN ? Ich baue den auch ein ...

 

[koyaanisqatsi]

Moin

Ich werde dazu noch eine Lösung schreiben...

Bis dahin:
Das Programm allcfgconv aus der Releasefirmware funktioniert noch mit dem -c Switch.
Dann mit mount -o bind den auf der Box mit dem "über" mounten. Ist doch freetz.

mount -o bind /var/media/NEW_LINK/mips/allcfgconv /bin/allcfgconv

...vielleicht auch nur temporär, rückgängig dann...

umount /bin/allcfgconv

...und es ist im Sinne von AVM wieder "sicher".

 

[MatuAC]

Ich habe kein vollständiges freetz installiert, sondern wie in diesem Beitrag beschrieben nur den Patch eingebunden, zusätzlich aber die allcfgconv einfach mit der aus dem 6.05er Release überschrieben.

Fritz!Box läuft, LCR läuft, bisher noch keine Fehler erhalten...

 

[PeterPawn]

zusätzlich aber die allcfgconv einfach mit der aus dem 6.05er Release überschrieben.

Ich vermute mal, bei der 7390 meinst Du das Release 06.03.

Mit allcfgconv funktioniert dann der LCR weiter, solange die dynamisch gelinkten Bibliotheken mit allcfgconv spielen wollen.

Der Vollständigkeit halber kannst Du bei dieser Methode dann auch noch die Binaries usbcfgconv und wlancfgconv ersetzen, dann funktioniert (wieder nur solange, wie AVM an den Libs nichts ändert) auch anderes, z.B. das Auslesen von Kennwörtern mit dem ruKernelTool, wieder.

Spätestens beim Ersetzen des "telefon"-Binaries (um die Abarbeitung der calllog-Scripte wieder aufzunehmen) dürfte diese Methode aber an ihre Grenzen stoßen ... und auch das Wiederbeleben von "NoCheck=yes"-Importen durch Austausch von firmwarecfg ist sicherlich nicht zu empfehlen.

 

[MatuAC]

Ich vermute mal, bei der 7390 meinst Du das Release 06.03.

Ah, ja richtig, hätte ich erwähnen sollen.
Hier ging es zwar ursprünglich um die 7390, ich habe es aber auf einer 7490 umgesetzt - das Verhalten beider Boxen ist ja mit der Beta-Firmware identisch.

Die weiteren Binaries werde ich im Moment nicht ersetzten. Mir ging es erst einmal nur um den LCR, für den scheint erst einmal die allcfgconv zu reichen.
Lediglich das Abrufen der Anrufliste klappt nicht mehr, was aber vermutlich an der nicht mehr funktionierenden Abarbeitung der callog-Scripte liegt. Kann ich aber verkraften

 

[molfi]

Hallo TelefonSparbuch.

[...]Ich werde dazu noch eine Lösung schreiben[...]

An der Lösung wäre ich wirklich sehr interessiert. Gibt's da schon Neuigkeiten?

Gruß
molfi

 

[TelefonSparbuch]

Im Prinzip ist es in dem Bereich fertig. Login via AVM Routine (Kennwort wird dann beim Login nicht im Klartext übertragen - MD5 Prüfsumme mit Salt von AVM). allcfgconv -c wird verifziert, falls es nicht möglich ist das Kennwort auszulesen, kann man Nutzer/Kennwort in den Einstellungen hinterlegen um die Anrufliste/Wahltabelle innerhalb des LCRs zu nutzen. Es fehlen noch ein paar Tests, vor allem mit den älteren Firmwares.

 

[MatuAC]

EDIT: Nehme alles im folgenden Gesagte zurück Lag tatsächlich - wie von koyaanisqatsi vermutet - an der fehlenden Ausführungsberechtigung für die allcfgconv...


In der letzten Beta (06.10-28374) reicht übrigens das Ersetzen der allcfgconv durch die Version aus der letzten Release-Version scheinbar nicht mehr aus (s. mein Beitrag #35 etwas höher in diesem Thread).
Der LCR scheint zwar zu funktionieren.

ABER:
Wenn in der Fritz!Box die Option zur Anmeldung mit FRITZ!Box-Benutzernamen und Kennwort ausgewählt ist, erscheint bei der Anmeldung im LCR keine Auswahlbox für den Benutzer mehr, sondern nur noch das Feld für die Passworteingabe - dies hatte mir der vorherigen Labor-Version noch geklappt, nachdem ich die allcfgconv ausgetauscht hatte.
Zusätzlich erscheint folgende Fehlermeldung:

/usr/www/html/cgi-bin/tsb/index.html: /var/tmp/tsb/lib/www/login.inc: line 26: allcfgconv: Permission denied

Beim Aufruf der Wahltabelle erscheint dann folgende Fehlermeldung:

/usr/www/html/cgi-bin/tsb/index.html: line 3: allcfgconv: Permission denied 
Login nicht erfolgreich

Ist in der Fritz!Box die Option "Anmeldung mit dem FRITZ!Box-Kennwort" ausgewählt, erscheint bei der Anmeldung zwar nicht die Fehlermeldung, trotzdem aber die Meldung bei der Wahltabelle.

Nur wenn "Keine Anmeldung" ausgewählt ist, funktioniert auch die Wahltabelle.


Somit scheint AVM mittlerweile also weitere Änderungen an der allcfgconv vorgenommen zu haben...