[Frage] Freetz in https

[frater]

I probably didn't properly implement your patch, but I did a "git pull" in the git folder I have from you.
It updated several stuff....

I copied the stunnel folder and the privatekeypassword to the "trunk" and did a new make
It compiled stunnel and privatekeypassword, but after testing it with the firmware it still needs a password for the key

root@meer:/var/mod/root# ls -altr /var/flash/websrv_ssl_key.pem
crw-r--r--    1 root     root      250, 201 Jan  1  1970 /var/flash/websrv_ssl_key.pem
root@meer:/var/mod/root# ls -altr /var/flash/websrv_ssl_cert.pem
crw-r--r--    1 root     root      250, 202 Jan  1  1970 /var/flash/websrv_ssl_cert.pem

With entering the certificate twice is that I use the AVM-interface to add the certificate for the AVM-interface and then I need to do the same for the Freetz interface.
I think it's more elegant when that only needs to be done once.
When this thing would work it would also have the private key more obscured....

Enter /var/flash/websrv_ssl_key.pem pass phrase:
[ ] Clients allowed=500
[.] stunnel 5.42 on mips-unknown-linux-gnu platform
[.] Compiled/running with OpenSSL 1.0.2l  25 May 2017
[.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
[ ] errno: (*__errno_location ())
[.] Reading configuration from file /var/mod/etc/stunnel.conf
[.] UTF-8 byte order mark not detected
[.] FIPS mode disabled
[ ] Compression disabled
[ ] PRNG seeded successfully
[ ] Initializing service [https]
[ ] Ciphers: HIGH:!DH:!aNULL:!SSLv2
[ ] TLS options: 0x83004BFF (+0x83004BFF, -0x00000000)
[ ] Loading certificate from file: /var/flash/websrv_ssl_cert.pem
[ ] Certificate loaded from file: /var/flash/websrv_ssl_cert.pem
[ ] Loading private key from file: /var/flash/websrv_ssl_key.pem
[:] Insecure file permissions on /var/flash/websrv_ssl_key.pem
[!] error queue: 140B0009: error:140B0009:lib(20):func(176):reason(9)
[!] error queue: 906A068: error:0906A068:lib(9):func(106):reason(104)
[!] SSL_CTX_use_PrivateKey_file: 906406D: error:0906406D:lib(9):func(100):reason(109)
[!] Service [https]: Failed to initialize TLS context
Starting stunnel ... failed.

EDIT:
I now also copied your dropbear folder to mine..
It's now compiling and I will flash it, but then I will be off to catch a train.
In the train I will test some and may be able to read your reaction.

 

[frater]

Now I lost my Zabbix.....
It is gone in "make menuconfig" (no 2.4.6 anymore although the folders are there) and in the Freetz AVM
Also missing the possibility to add a certificate manually.....
Each day I make a back-up of the .config, but taking the one from several days earlier doesn't fix it....

 

[PeterPawn]

OK, step by step:

- If your Zabbix package does not showup in the Kconfig dialog, it's probably a timestamp mismatch and a cached view - that's not a complete disaster, it's only a little problem, which has to be solved. Try a "touch" command on the "Config.in" file in the "make/zabbix" directory and it should be included again - check it with a "make oldconfig". If there are any error messages from Kconfig, do not continue ... instead try to solve the errors first.

- Which files were changed by the last merge of your clone with my fork? Which packages were re-built by the following "make"? I'm unsure, whether you really got (completely) the current changes.

Why I'm hesitant here?

According to your log above, your "stunnel" binary still checks the permissions for the key file, but due to the patch from Freetz the code should never reach this test for a character device:

static
int is_fritzbox_key(const char *file_name) {
    struct stat sb;
    if (!stat(file_name, &sb))
        return 0;
    /* if it's a character device, assume it's the Fritz!OS private key file from TFFS */
    return S_ISCHR(sb.st_mode);
}

NOEXPORT int load_key_file(SERVICE_OPTIONS *section) {
    int i, success;
    int fritzbox_key=is_fritzbox_key(section->key);

    s_log(LOG_INFO, "Loading private key from file: %s", section->key);
    if(!fritzbox_key && file_permissions(section->key))
        return 1; /* FAILED */

    set_prompt(section->key);
  if (fritzbox_key) {
[...]

[ It's annoying, that the new board software doesn't support manual attribute changes (colors/styles) within CODE blocks. ]
If a character device was found (S_ISCHR() is true), the "fritzbox_key" value should be set and the second part of the if-condition after the "Loading ..."-message should never be called.

I've double-checked, that my (published) fork uses now the same content as the upstream for "900-box_certificate.patch" (after it was accidentially deleted earlier) ... it's now the same version and it was last changed (in its logic, later versions have only updated some line numbers) by @er13 in this commit: https://github.com/Freetz/freetz/co...e43ca9f#diff-8c516edcb5fef1e37b4c782fdd31e3cd

But I really didn't test this last change by @er13 myself, as I saw meanwhile ... I had an older patch from private e-mail exchange with @er13 and I used this one for my own "stunnel" binary. So I have to test it again with the (published) patch ... I'll be back with the results here in a short while.

Meanwhile you can try to find the reason for the "vanishing" of your zabbix package from the configuration. Have a look into the .config file too, whether FREETZ_PACKAGE_ZABBIX symbol (and possibly some "children") is still present or not.

 

[frater]

It was removed out of the webinterface in the firmware.
That the Zabbix 2.4.6 agent with webif was removed out of the dev platform was a mistake.
There's a Zabbix 1.8.15 in "Packages" and there I was also looking for the improved Zabbix package, but that one is in the section "Unstable".
Because I was missing it in the target firmware and wasn't able to see it beneath the other Zabbix 1.8.5 I combined these 2 too quickly.

But still I don't have an explanation yet for parts missing in the WebIF.
Also the "stunnel" only had a section for the "Services"... The section for the cert and key were gone as well...

I will bake another one soon, but this will be tomorrow....

After I flashed the exact same binary as it was running the whole week it still had no Zabbix. Then I noticed that all flashes since the initial one of today didn't succeed.
I'm now restoring the Freetz backup of last night....

 

[frater]

Last evening I tried to flash it one more time. I chose the "remote flash option" this time.
After that I completely lost the box.
I need to go there Monday morning...

 

[PeterPawn]

OK, all of your further problems with other images are (imho) unrelated to the "stunnel" package ... as far as I understood it (and think).

But the "stunnel" problem has its roots in the current patch ... and it's only a single (and hard to see) character in the source file.

The first attempt was still correct, but during some optimizations an error was inserted here: The call for "stat()" returns "0" in case of success and an afterward check with "!stat(...)" is wrong, if it's interpreted as "it's not a FRITZ!Box key".

So it was only the additional exclamation mark, which had to be deleted ... but nevertheless I've made some other changes. So I've adopted the programming style of the original author again, added an additional marker to the debug message, if the FRITZ!Box private key was used and removed the proxy-related code, 'cause it's unnecessary with the new version of privatekeypassword.

The changes are available in my fork ... until they're copied to the upstream, you could apply this last patch to your current tree.

A test on a 7490 (this time with the correct binary, which was built from these sources) shows the intended behaviour:

root@FB7490:/var/media/ftp $ ( ( echo ======; cat stunnel-test.conf; echo ======; ); ./stunnel stunnel-test.conf; sleep 5; killall stunnel; sleep 2 )
======
cert = /var/flash/websrv_ssl_cert.pem
key = /var/flash/websrv_ssl_key.pem
debug = 7
output = /proc/self/fd/2
syslog = no

[GUI]
client = no
accept = 8080
connect = 80
======
2017.08.19 14:53:29 LOG7[ui]: Clients allowed=500
2017.08.19 14:53:29 LOG5[ui]: stunnel 5.42 on mips-unknown-linux-gnu platform
2017.08.19 14:53:29 LOG5[ui]: Compiled/running with OpenSSL 1.0.2l  25 May 2017
2017.08.19 14:53:29 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
2017.08.19 14:53:29 LOG7[ui]: errno: (*__errno_location ())
2017.08.19 14:53:29 LOG5[ui]: Reading configuration from file /var/media/ftp/stunnel-test.conf
2017.08.19 14:53:29 LOG5[ui]: UTF-8 byte order mark not detected
2017.08.19 14:53:29 LOG5[ui]: FIPS mode disabled
2017.08.19 14:53:29 LOG7[ui]: Compression disabled
2017.08.19 14:53:29 LOG7[ui]: Snagged 64 random bytes from /var/media/ftp/root/.rnd
2017.08.19 14:53:29 LOG7[ui]: Wrote 1024 new random bytes to /var/media/ftp/root/.rnd
2017.08.19 14:53:29 LOG7[ui]: PRNG seeded successfully
2017.08.19 14:53:29 LOG6[ui]: Initializing service [GUI]
2017.08.19 14:53:29 LOG7[ui]: Ciphers: HIGH:!DH:!aNULL:!SSLv2
2017.08.19 14:53:29 LOG7[ui]: TLS options: 0x03004004 (+0x03004000, -0x00000000)
2017.08.19 14:53:29 LOG6[ui]: Loading certificate from file: /var/flash/websrv_ssl_cert.pem
2017.08.19 14:53:29 LOG6[ui]: Certificate loaded from file: /var/flash/websrv_ssl_cert.pem
2017.08.19 14:53:29 LOG6[ui]: Loading private FRITZ!Box key from file: /var/flash/websrv_ssl_key.pem
2017.08.19 14:53:29 LOG6[ui]: Private key loaded from file: /var/flash/websrv_ssl_key.pem
2017.08.19 14:53:29 LOG7[ui]: Private key check succeeded
2017.08.19 14:53:29 LOG7[ui]: ECDH initialization
2017.08.19 14:53:29 LOG7[ui]: ECDH initialized with curve prime256v1
2017.08.19 14:53:29 LOG5[ui]: Configuration successful
2017.08.19 14:53:29 LOG7[ui]: Listening file descriptor created (FD=6)
2017.08.19 14:53:29 LOG7[ui]: Option SO_REUSEADDR set on accept socket
2017.08.19 14:53:29 LOG7[ui]: Service [GUI] (FD=6) bound to 0.0.0.0:8080
2017.08.19 14:53:29 LOG7[main]: No pid file being created
2017.08.19 14:53:29 LOG7[cron]: Cron thread initialized
2017.08.19 14:53:34 LOG7[main]: Found 1 ready file descriptor(s)
2017.08.19 14:53:34 LOG7[main]: FD=4 events=0x2001 revents=0x1
2017.08.19 14:53:34 LOG7[main]: FD=6 events=0x2001 revents=0x0
2017.08.19 14:53:34 LOG7[main]: Dispatching signals from the signal pipe
2017.08.19 14:53:34 LOG7[main]: Processing SIGNAL_TERMINATE
2017.08.19 14:53:34 LOG5[main]: Terminated
2017.08.19 14:53:34 LOG7[main]: Closing service [GUI]
2017.08.19 14:53:34 LOG7[main]: Service [GUI] closed (FD=6)
2017.08.19 14:53:34 LOG7[main]: Service [GUI] closed

Note the additional "FRITZ!Box" in the debug message prior to loading the private key.

If you specify "key" and "cert" once outside of service definitions, you don't need them again for a service, as long as they are not to be overwritten for this service.

If your problems with the configuration mask for "stunnel" are still present, please show me the HTML source of the generated page. If I use my Freetz CGI emulation (it's a slightly modified "mod" package without absolute path names, because the hard-coded names in "libmodcgi.sh" prevent it's usage outside of freetz, even for test purposes) with the "stunnel.cgi" source, the results are as follows:

<div class='section' >
<div class='sec'><h2>$(lang de:"Starttyp" en:"Start type")</h2>
<p>

<input id="enabled_yes" type="radio" name="enabled" value="yes"><label for="enabled_yes">Automatisch</label>
<input id="enabled_no" type="radio" name="enabled" value="no"><label for="enabled_no">Manuell</label>
</p>
</div>
</div>
<div class='section' >
<div class='sec'><h2>$(lang de:"Konfiguration" en:"Configuration")</h2>
<p>
Standard-Zertifikat f&uuml;r Server-Dienste:&nbsp;
<input id="use_box_cert_yes" type="radio" name="use_box_cert" value="yes"><label for="use_box_cert_yes">Ger&auml;te-Zertifikat verwenden</label>
<input id="use_box_cert_no" type="radio" name="use_box_cert" value="no"><label for="use_box_cert_no">Eigenes Zertifikat verwenden (s.u. zum Bearbeiten)</label>
</p>
<h2>Erweiterte Einstellungen:</h2>
<p>
<label for="ssloptions">OpenSSL Optionen: </label><input type="text" name="ssloptions" id="ssloptions" size="20" maxlength="255">
</p>
<p>Log-Level:
<select name='verbose'>
<option value="crit">0</option>
<option value="err">1</option>
<option value="warning">2</option>
<option value="notice">3</option>
<option value="info">4</option>
<option value="debug">5</option>
</select>
</p>
</div>
</div>
<div class='section' >
<div class='sec'><h2>$(lang de:"Dienste" en:"Services")</h2>
<ul>
<li><a href="/cgi-bin/file/stunnel/svcs">Dienste bearbeiten</a></li>
<li><a href="/cgi-bin/file/stunnel/certchain">Eigene Zertifikats-Kette bearbeiten</a></li>
<li><a href="/cgi-bin/file/stunnel/key">Eigenen privaten Schl&uuml;ssel bearbeiten</a></li>
</ul>
</div>
</div>

This looks as expected ... but I didn't view it with a browser so far. HTML Tidy has no problem with this chunk - beside the missing "body" tag and a "DOCTYPE" hint - and so I think, it's valid and the vanishing sections from the GUI are a mystery and rather unrelated to the patch.[/CODE]

 

[frater]

Hi Peter,

First thing in the morning I went to my client with his unresponsive Fritz!Box.
Nothing was working (couldn't even get on it using http://169.254.1.1), but after a powercycle everything was working.
I even flashed one of the firmwares on it that I created last Friday...
The stunnel wasn't working, though.

Today I attached another 7390 on which I loaded the same config.
I did a "git pull" in your folder and copied the "stunnel" folder to the make folder.
I flashed the new firmware and to my surprise the stunnel was working fine with the Fritzbox certificates

freetz@freetz:~/peterpawn/freetz$ git pull
remote: Counting objects: 8, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 8 (delta 6), reused 8 (delta 6), pack-reused 0
Unpacking objects: 100% (8/8), done.
From https://github.com/PeterPawn/freetz
   dc473e9..999caf0  master     -> origin/master
Updating dc473e9..999caf0
Fast-forward
 make/stunnel/patches/boxcert/900-box_certificate.patch | 41 ++++++++++++++++++++---------------------
 make/stunnel/stunnel.mk                                |  1 -
 2 files changed, 20 insertions(+), 22 deletions(-)
freetz@freetz:~/peterpawn/freetz$ cp -pr make/stunnel ~/trunk/make/
freetz@freetz:~/peterpawn/freetz$ cd ~/trunk/

To be sure I made the text blank where I had the certificates in stunnel.....

Am I now the first to have this working (with AVM certificates)??
Not a prestige thing, but I'm right that it has never actually worked for anyone before, did it?

To make sure....
My private key is now only obscured for those with root access or not?
It's not really secure, but just a bit less easy to obtain, right?

BTW.... I dared to flash this new firmware remotely to the Fritz!Box that became unresponsive last weekend and that succeeded.....
They are on holiday anyhow...

 

[PeterPawn]

Your private key is indeed decrypted with the device password, if the "stunnel" daemon starts ... but it's never stored outside of memory allocated to "stunnel" and therefore it's as secure as in an installation without "stunnel". [ But it's simple to compute the password, if someone knows your "maca" address. ]

The decrypted private key isn't stored anywhere in the filesystem ... that was the primary intention of this patch. If it doesn't matter, whether you store the decrypted key in "tmpfs" (or somewhere else), because you do not care on security, you could simply decrypt the key with any "openssl" binary (and the appropriate password) and use "stunnel" with the unencrypted key file stored somewhere - as it the Freetz CGI does with its key from the textbox, because there's no method to provide a decryption keyword to the starting "stunnel" daemon - afaik.

There maybe a solution with FIFOs, which may get the same effect (provide a password for key decryption at runtime and do not store this somewhere in a filesystem) - but it's more complicated and injection of such text into a standard stream (here into STDIN) is usually dangerous (and will not work, if you use more than one encrypted key).

But because AVM adds another level of security on its own key (for the FTP, HTTP and UPnP server(s)), it wasn't a good approach to weaken key's security with such a decryption.

That's why I've added some patches (or sometimes only suggestions, how to use it, if the software already provides an interface to automatically enter a password to decrypt the key) for popular firmware extensions - ShellInABox, dropbear, stunnel, OpenVPN, apache2.

The latter two projects already have the needed interface and can call a program (e.g. "privatekeypassword") to get the password at runtime - for the others are patches available.

So you're not the first one anywhere, who uses "stunnel" with the box key ... but obviously you're the first who uses it, after the patch 14 months ago rendered the decryption unusable. And surely I had tested it, before I suggested the original patch - that means, it was functioning in the past and it's possible, that someone else uses (or has used) the older version too (and prior than you ).

I've used my own version so far (without the changes by @er13 and this own, original patch was finally the reason, why the 900-....patch from upstream wasn't present in my fork - it was (intentionally) never "stage"d for commits and the upstream version had I to remove during a merge run in the past) and so I had no idea/info, that the "stunnel" patch from Freetz wasn't working as expected anymore.

 

[frater]

Is the "use AVM certificate" supposed to work if you don't upload your own certificate?
I was expecting it to use the selfsigned certificate that AVM puts there....

If it's supposed to work then it doesn't work on this box.
I have yet to test an uploaded certificate through the AVM-interface
Using an uploaded certificate through the Freetz-interface works.....

 

[PeterPawn]

No, sorry, now one of us is completely confused - I can't see, if that's your problem or mine.

The Freetz GUI for "stunnel" stores the certificate and the key (entered into the provided textbox controls) in an absolutely different manner. There's no encryption of the private key (afaik).

The original firmware stores a self-generated private key or the private key of an uploaded certificate (naturally the upload has to use the AVM GUI) with encryption in the file (better in the TFFS node) "websrv_ssl_key.pem". The password used to encrypt this key is derived from the "maca" address in the "urlader environment".

This private key (and its certificate) is a "highlander" (the german title of the movie was "Highlander - Es kann nur einen geben") and uploading an own certificate and key replaces the automatically generated files. The associated certificate is stored in "websrv_ssl_cert.key" and this is not encrypted (it's senseless here).

If you assign these files (OK, only the key file does matter here) to a "stunnel" service, the password needed for decryption is provided automatically, if the file is opened in "stunnel" ... the "it is a character device" property of the used key file is the "key point" for this decision.

If the "key" entry in the configuration file points to a "regular file" (or anything else, which is NOT a character device inode, even if it's a FIFO or any other socket), selecting the additional option "support to use FRITZ!OS certificate" will change ABSOLUTELY NOTHING in the behavior of the "stunnel" daemon.

Only the configuration mask is every time affected on how it's implemented now ... even without the patch the new radio button group with name "use_box_cert" still exists. But in my opinion this is not really a mistake, because some user could be interested in using these files (instead of textbox content), even if he has to provide the password himself. As far as I know, these files did not exist at creation time of this package and so it was not necessary, to differentiate there.

Further I don't know any good way to apply a patch to the "files" directory of a package and I don't know (and I don't care anymore), whether selected options (here FREETZ_PACKAGE_STUNNEL_BOXCERT) are available and usable (at runtime) to customize the content of a CGI form.

If the answer is "yes", they could be used in such decisions ... if this option is available, the added radio button group could be surrounded by an appropriate "if" statement in shell code and in the end suppressed - if my approach from above will be declined by someone.

My CGI patch gives you the opportunity to automatically assign these files in the section outside of service definitions in the "stunnel" configuration file, where otherwise the files in "tmpfs" (generated from the content of textbox controls) would be referenced ... but this requires the right selection in this form.

Meanwhile I don't understand any longer (and I have no plausible idea anymore), what your problem is and what's running as expected (and intended, if your expectations are different) and what's obviously wrong.

If you expect further help, you need to provide the used configuration file (it will be generated by "modload" or something else, I'm not familiar with Freetz internals and not really interested in a further investigation), screenshots (or complete descriptions) of the selected settings and - as far as possible - the logs for "stunnel".

If you have problems to retrieve the needed log messages, you may control this aspect of "stunnel" with "debug", "output" and "syslog" settings as shown above - some of them are configurable with the Freetz interface.

If you have no own syslog service running, you can use the newly implemented storage for syslog messages from AVM ... run "showshringbuf log" and redirect the output of this command to get a syslog file of the last messages ... this uses a ring-buffer, where older messages get overwritten.

 

[frater]

Hi Peter.

Sorry for this confusing message... I removed part of my post which made it unclear....

I have a box on which it is working fine.
The box only has a certificate uploaded using the AVM-interface and stunnel is configured to use that.
It's working after applying the latest patches.

Today I flashed another box.
On that one the openssl is not working with the AVM certificate

Just now I uploaded my wildcard certificate which is working for the AVM-interface, but not for stunnel....
So I restarted the box and then it came back with parts missing and the zabbix agent not working anymore. The box does not react on a "reboot" which I gave from the CLI.

Only after doing a "restart" using the AVM-interface it went down again.... this time to never come back. Maybe a powercycle works. I will find out tomorrow.

 

[PeterPawn]

Maybe you have FRITZ!Box devices, where the self-signed certificate was generated far in the past ... meanwhile FRITZ!OS uses a 2048 bit key and a SHA-256 signature for the certificate.

If your self-compiled OpenSSL components require a larger key and a current signature algorithm, the OpenSSL libraries could decline to use such an old key and/or certificate ... only one idea from various possible problems.

Otherwise I would not understand, why "openssl" is involved into a problem regarding "stunnel" ... and in my opinion, you should better investigate, why your wildcard certificate isn't usable with "stunnel" and where the problem is located, before you try to upload it in the GUI. You can test this all together, even if the certificate was not uploaded with the AVM GUI yet.

It's a big difference, whether the key can not be decrypted or whether the certificate can not be used (e.g. is not accepted) by the daemon.

The more problems occur, the more I'm unsure, whether your problems are really the result of my modifications for "stunnel" or whether you mix various problems together and one is the source of another.

Your screenshots are the best example ... if you setup the "stunnel" daemon (at runtime !! - this is not the same as the FREETZ_something option mentioned earlier) to use the FRITZ!OS certificate, the additional "configuration files" for the private key and the certificate chain will not be registered any longer with the CGI interface: https://github.com/PeterPawn/freetz/blob/master/make/stunnel/files/root/etc/init.d/rc.stunnel#L22 ... the result is the first screenshot, which is in your opinion "strange".

But if you have configured the "stunnel" daemon to use the FRITZ!OS certificate, why would you need these two files anymore? Even if you think, you still would need them - it's a litte bit confusing for other users, if more than one (default) certificate and key may be configured at the same time.

If you want to use the box certificate, select this with the radio button group labeled "default certificate for 'client=no' services" (a complicated description, but I considered it better than "default certtificate for server services") and during the next start, the service will use the internal certificate/key in the newly generated configuration file.

This configuration file is re-created on each start of the service ... the script "rc.stunnel" calls "modlib_start" (in "modlibrc"), this calls "start" in "rc.stunnel", this calls "modlib_startdaemon" (back in "modlibrc"), this calls "config" (again in "rc.stunnel"), this calls "modlib_config" (in .. I'd bet you guessed it ... "modlibrc"), which calls "stunnel_conf" (another script in "/etc/default.stunnel"), which writes a new "outer section" of the "stunnel" configuration, before the second line in the "config" function from "rc.stunnel" appends the configured service descriptions.

If I'm not completely wrong with this execution order, I can't see any reason, why switching to "use device certificate" in the CGI form should not lead to a valid configuration on a restart of the service ("modlib_restart" is only a junction of "modlib_stop" and "modlib_start"). On the next device restart (or any other reason, why "rc.stunnel" (or "rc.stunnel load") is called again), the two "files" with data for the alternative option "use own certificate" are not registered again ... your service uses now the FRITZ!OS files.

But the two links for "Edit own ..." are still displayed ... if this irritates someone, they could be removed with an additional condition (from the generated form at all, but adding JS to hide them "on the fly", is too much effort in my opinion).

If you want to switch back to "own files", you have to store the changed configuration (after you selected the other radio button) and to initiate an "unload/load" cycle for the package.

I skipped the registration of these two files, because they are not used by most users, if the FRITZ!OS files are assigned ... so it's unnecessary to create them in "tmpfs" and this is the direct result of a registration with "modreg". This little "inconvenience" with the additional unload/load cycle (which is automatically the result of a FRITZ!Box restart, if someone doesn't know, how to initiate it manually) is acceptable ... in my opinion.

If someone thinks, it's better at all, to remove the "use own files" parts already at build-time, if FREETZ_PACKAGE_STUNNEL_BOXCERT was selected, that's another possible approach ... at least it avoids confusions, if the reaction to a changed setting in the HTML form is not an immediate change of the generated links at the bottom of the form. But on the other hand the descriptive text for the sub-option (in Kconfig) indicates, it is an (optional to use) addition and not a replacement.

 

[frater]

I don't have a different webif on my first box where the stunnel is working with the AVM interface.
Before the reboot that part was still there.
But it's not the only thing that's missing. Also Port Forwards are gone in the IF (not in ar7.cfg as I did all this remotely)
Zabbix stopped working... probably because of its config
I don't know what;s with the box... it's the same erratic behaviour I saw last Friday.
It's as if it is unable to write some config because it has no space and becomes corrupter.

I think the stunnel thing is working fine, but on the 7390 I just have not enough memory.
I will start testing on 7490 only and revisit the 7390 later....

[EDIT]
The end-user just power-cycled the modem and it came back with all its menus and everything working. I'm not touching it again. I will not use a production modem for this again near soon.