Fritz!Load…

Wenn der Wunsch besteht, kann das ja natürlich rückgängig gemacht werden, bzw. bestimmte Skins wieder zurückgeholt werden.
Geschah aus der Überlegung heraus, dass sämtliche Anpassungen in letzter Zeit nur für den MT Skin gemacht wurden.

Und die Zeit zählt von jedem Einzelnen, auch ich habe schon einiges an Zeit investiert.

Das erste Problem ist, es sind schon mal unterschiedliche Einträge bei einer 7270 und einer 7390 - auf diese beiden Geräte hab ich Zugriff.

Das andere ist, was machen, wenn der User die Freigabe wieder rückgängig machen will, bzw. ändert? Man muss das irgendwo mitspeichern und was, wenn diese Datei verloren geht? Bei allen config Dateien bzgl. FL ist das ja nicht schlimm, bzgl. einer conf Datei der Box schon.
Die Warnhinweise bzgl. Ändern der Regeln auf der Freetz Seite sind auch nicht zu verachten ...

Was meinst du mit "Einstellungen bequem in den Optionen anpassen" bzw. auf welcher Revision von FL bist du? 
stunnel ist nun implementiert, d.h. du gibst einfach den stunnel Port nach außen frei. Somit hast du eine SSL gesicherte Verbindung von außen zu FL.
Ob die Portfreigabe direkt in FL kommt ist noch ungewiss, ich habe zwar mal damit angefangen, aber das ist nicht reif/stabil genug für die Freigabe.

FL ist auf einen eigenen Webserver umgezogen, Problem gelöst.

Danke für deine Rückmeldung.

Das macht er deswegen:

	elif grep -qi ">Premium download</button>" $f; then
		errmsg "Du lädst schon von diesem Hoster"
		waiting 0 10
		break
	fi

Mit dem "waiting 0 10" lässt du 10 Minuten warten und dann weiter im Code.

Siehe lib/reconnect.sh:

# waiting [SECONDS] [MINUTES] [WAITMAX] [CURL-MSG]
# => [SECONDS]+[MINUTES] = Wartezeit
# => WAITMAX => ist nur noch diese Wartezeit über, löse keinen Reconnect mehr aus, weil es sich nicht mehr lohnt
# - Ist Wartezeit (seconds+minutes) größer als waitmax,
#   : Reconnect erlaubt => so wird nicht gewartet (Abbruch)
#   : ansonsten wird gewartet
# - Ist Wartezeit kleiner als waitmax (und waitmax ist gesetzt)
#   : Erlaube Reconnect, führe selbst aber keinen Reconnect aus (weil wir innerhalb
#     der gewünschten Wartezeit sind (Zum Beispiel Download-Wartezeit)!
# - Während der Wartezeit über waiting Funktion ist ein Reconnect erwünscht!
#
# waiting 100 0 100 "Testmeldung" => Warte 100 Sekunden mit Statusmeldung "Testmeldung"
#                                    Löse keinen Reconnect selber aus.
# waiting 100 0 0   "Testmeldung" => Falls Reconnect erlaubt löse sofort einen Reconnect aus (waitmax ist Null!)
# waiting 100 0 20  "Testmeldung" => Falls Reconnect erlaubt löse sofort einen Reconnect aus (falls nur noch 20 Sekunden zu warten sind, löse keinen Reconnect mehr aus)
# waiting 100                     => Warte 100 Sekunden und löse keinen Reconnect selber aus

AHA, ich sehe grade dein Problem. Er macht einen Reconnect, obwohl er nicht sollte. Hmm, interessant, fällt mir auf die Schnelle nichts ein.

Ich check es mal ein.

Mit

top

kann man den Ressourcenverbrauch kontrollieren.

Wer mit lighttpd mal spielen will, hier sind mit freetz kompilierte packages:

mips: https://mega.co.nz/#!ZxZiTTaJ!ak8Y03vP1 … -hKpQTpn4Q
mipsel: https://mega.co.nz/#!EgZjlJ6Q!6WDBz9cFl … FZlIIyUt6g

Anscheinend gibt es hier kein static binary.

Gibt es wichtige Punkte, die dagegen sprechen, die Möglichkeit zur Portfreigabe auf der Box direkt in FL zu implementieren?

Ich hätte gesagt, das setzt zwingend den aktivierten Passwortschutz voraus.
Bin mir auch noch nicht ganz sicher, ob es sich so realisieren lässt, aber mir fällt nichts ein was komplett dagegen spricht.