[Info] Guten Tag, ich bin auf der Suche nach Informationen.

Maybe its better write the same in english to. Its very difficult to understand. Google translate its not very helpful.
Some of us also speak spanish.

Also the freetz-page you can read in english with a lot of howtos etc.

http://freetz.org/wiki/WikiStart.en

Some points/opinions:

1. Freetz uses original firmware images from the vendor and modifies them to contain additional software (and some changes against original scripts). Therefore the term "freetz firmware" is a little bit confusing ... it's AVM's firmware which will "kill" the telnet daemon and this is done only by removing a symlink. If you create this symlink (for and not necessarily to) /usr/sbin/telnetd (the vendor's version of busybox will be patched to check the existence of such a link, not its target) yourself, the telnet service is available again. Using Freetz it's unnecessary to set this link (but it will be created during "busybox install procedure" indeed), because the used version of the Busybox source files does not contain the patch from AVM, which checks the symlink. So there are two options to "revive" the telnet daemon:

a) use a busybox version without the patch
b) create the symlink as needed and use the original busybox version from AVM (with the patch)

Because the internal start code for the telnet daemon is located in the "telefon" daemon (it's a closed source component from AVM) and this code tries to start "/usr/sbin/telnetd -l /sbin/ar7login", it's useful (but not required) to have such a symlink present.

2. There's only one trunk of Freetz (do you mean various "changesets" ?), it's the developer version of Freetz. In this branch the 7490 device is fully supported up to the latest official release version 06.30. Afaik there are some findings with the "replace kernel" option (it's a question of the required extensions to the stock firmware, if you need to replace the original kernel too) for the international firmware version ... but creating a simple Freetz image should work with the "trunk version" of Freetz. If I'm not wrong, the 7490 device is not supported in the older stable branch, at least not with the newest released firmware. The latest "labor branch" (beta) by AVM uses a complete new kernel (3.10) and is not supported yet by Freetz.

3. If your only intention is to revive the telnet daemon, there's an easier way to do this ... the 7490 is a "dual boot device" and in the past I wrote a shell script to modify an existing firmware image and write the result to the inactive partition. This is done on the 7490 device itself without the needs of any external Linux machine. If you want to modify only script code (busybox shell and/or Lua scripts are used by AVM), this could be the better way ... but it depends on your intentions and objectives, where less effort is needed.

4. Some "permanent provider settings" could be realized using an entry at the "urlader environment" ... but if it's done there, you should find the entry "provider xyz" in a listing of the variables defined there (as you've expected as far as I understood). If it does not exist, perhaps there's no provider default setting this way ... there are some other possibilities to realize such defaults - which option your provider uses, shouldn't be hard to detect, but we need some further information. The "support data" output is a good starting point for such explorations.

5. Please drop a reference to the "oracle VM busybox and windows 10" problem ... without it we're unable to know what you're talking about.

Ok, as far as I understand it now, it's an issue with VirtualBox virtualization software and not with Freetz itself ... I'm using "VMware Workstation" and can't help here.

The "support data" generated by the FRITZ!Box firmware contains two different kinds of "secret data" ... the one is changed to the string "SECRET" during output and others are kept "original" and will be displayed using the internal representation as "encoded data". In the latter case these strings are shown as four dollar signs followed by characters from A-Z and 1-6 (a "special" Base32 encoding). It's possible to decode these strings within a telnet session from a firmware version prior to 06.25.

Afaik the FRITZ!OS does not store any "hashed" passwords/credentials (it's impossible - in theory - to get the original string from a hashed value). But you're right, we don't want to see any encrypted strings here ... at least not together with the "maca" and "wlan_key" values from the "urlader environment" (cat /proc/sys/urlader/environment), because these values are used to encode the data for each individual box and the knowledge of these values together with any encrypted string is sufficient to decode the data. If you don't know the "key values", you can publish any encoded data and still rest assured, because no-one should be able to decode them (in theory too).

It's configured as bridge to your normal network card

You could use the free "VMware Player" software and there are tools in the wild to convert "ova" files to "vmdk" - VMware itself has an "importer", which should do the job too (not tested personally).

But I'd prefer a XEN based VM image (for Linux users) or even an image for Microsoft's Hyper-V (for Windows users) in the future ... and docker containers and many other formats are gaining ground and the "old" Ubuntu image still uses 12.04 LTS (afaik).

It's time for a new image and/or some other formats (AWS/EC2 would be another option available to everybody without a "classic PC", no matter if it's using Windows or Linux) ... but there's nobody to do this work, it seems (or the people with the required skills are busy on other projects).

For the 7490 do not use the stable version ... you've to use the trunk (developer version) to produce a Freetz image based on one of the latest release versions from the vendor.

- freetz.org is available again ... you've found one of the rarely down periods - the 1st, today - after my last posting, which was three weeks ago.

- The mentioned "dual boot function" of the 7490 didn't point you to an ability to boot from an external drive. The NAND flash of most newer AVM devices (4020 is the only known exception at the time of this writing, afaik) contains doubled partitions for the Linux kernel and the used filesystem. A variable (linux_fs_start) from the settings area (TFFS partitions) is used to select one of those "sets" (usually MTD0/1 or MTD2/3 - from the view of a running system - and the device names may vary more) at boot time. Usually it's possíble to change the value of "linux_fs_start" from a FTP session to the bootloader, how to do this should be described already somewhere, but do not ask me to provide a link.

On Tuesday I wrote someone else a personal message - and such a FTP session was involved too ... I'd like to provide the part of this message regarding "FTP access to EVA" here, but please try yourself (as hard as you can) to find other postings here or somewhere else (wehavemorefun.de is good source for information, sometimes they're rather old, but you can get inspired there).

personal message schrieb:

But - as written above - I'm not sure, why the telnet service from your device isn't accessible ... and perhaps you remember, that there's another way to change the "branding" using the bootloader with a FTP session. Possibly it's easier to use this one than keep trying to get a telnet session.

To get this access, you've to put the device and a machine with a FTP client program together using a LAN cable and (best practice) an additional (network) switch between them to avoid hassle with "media sensing".

After "power on" the FRITZ!Box device will wait 5 seconds for a FTP connection to their bootloader IP address, which is usually 192.168.178.1, but you'll find the correct value under "my_ipaddress" in the "urlader environment" (which is contained within the "support data" mentioned above).

Therefore you've to start the FTP client within 5 seconds after power-on using the command "ftp 192.168.178.1". If you get connected, you'll be asked for a an username and password, the whole process (including the needed commands "GETENV" and "SETENV") is described here: http://www.wehavemorefun.de/fritzbox/TinyFTP

This article is rather old and something has changed meanwhile, but the needed commands (login and SETENV/GETENV) are unchanged and will work as written there - you can translate it to a known language with "Google Translator" (looks odd mostly, but it's rather technically and should be able to suit your needs).

Zum Vergrößern anklicken....

EDIT: I'm sure, it was the first down time of freetz.org today, because I'm monitoring this system using my Icinga server and the admin of freetz.org will be notified by e-mail on drop-outs. The failure today was the first one, where the server answered with an "internal server error" and it looks like I've to change my tests (ping, http access to trac.freetz.org and svn.freetz.org) a little bit and to check not only the HTTP "return code" (which was still "200 OK", while the HTML text said "Internal server error"):

icinga event log schrieb:

{ "timestamp": 1445551698, "date_time": "23-10-2015 00:08:18", "log_entry": "SERVICE ALERT: freetz.org;SVN;OK;SOFT;2;HTTP OK: HTTP/1.0 200 OK - 618 bytes in 0.034 second response time"},

Zum Vergrößern anklicken....

Those "user friendly HTTP error pages" are "a pain in the ass" for an automatic monitoring. I'll change the test and look for the expected HTML content in the future and then I hope, such failures are detected earlier again.

The UNIX I/O system (adopted by Linux) has an extreme flexibility ... but it's still impossible to use a "regular file" with a simple "symlink" to it instead of a piece of hardware without a "special crafted" hardware driver.

It's possible to use emulated "MTD block devices" with some drivers (block2mtd is one example), but the USB subsystem is initialized a long period after the first MTD block device has to be available (the Linux kernel is read from it, do you have an idea, when this will happen?).

Providing MTD devices (to start a FRITZ!Box out of them) from an external source is comparable to reading the BIOS firmware for a regular "personal computer" from an attached printer with a memory card reader ... it's impossible (at the first instance, sometimes called "bare metal").