Skip to content
Switch branches/tags
Go to file

Latest commit

* juis_check: be more precise, if values have to be read from device

* juis_check: add 'jason_boxinfo.xml' to considered info sources ...

if the script is used from FRITZ!OS

The error message, if neither of both files was found, is left untouched
by intention - it mentions always 'juis_boxinfo.xml' if neither file exists.

These changes are untested (but are looking good to me) - don't hesitate to
test them yourself on a proper device (I have no device close at hand yet).

* juis_check: improve conversion of decimal values ...

starting with a zero digit

* juis_check: now decimal conversion should work better ...

the regex was checked with:

while [ $i -lt 1000 ]
  printf "%04u=%s\n" "$i" $(expr "$(printf "%04u\n" "$i")" : "0*\([1-9]*[0-9]\+\)")
 i=$(( i + 1 ))
done 2>&1 \
| less

* juis_check: debug artifacts removed

* juis_check: implement new parameter 'Buildtype'

Usage help still needs to be updated.

* juis_check: 'Nonce' is not really a JUIS variable, ...

and may not be read from device. But with the earlier check of 'culture
clashes' for exclusive parameters, it has to be ignored in the first
attempt to assign/collect data for request properties.

* juis_check: improve bash detection and network error handling

* juis_check: add option to show (prettified) response on STDERR

* juis_check: update german usage screen

* juis_check: update english usage screen

* juis_check: add display of known Buildtype names ...

and shorten german 'Public' description (the removed items should be known

* juis_check: update ...

... it has still to be reviewed with a markdown viewer.

* juis_check: update german ...

... has to be validated with a Markdown viewer, too.

* juis_check: remove rant about unwanted firmware updates ...

... it may not be solved finally, but it seems to get better meanwhile.

* juis_check: Markdown fixes for README files

* juis_check: improve XML_LINTER variable usage ...

it may now include options for the call and an existing '%s' within
is replaced by the file name. If no '%s' was specified, it will be
appended to the value. The first item (according to IFS rules) of
the value has to be the name of an executable and is checked using
a 'command -v <executable>' call. Only if this call succeeds, the
linter part is executed, otherwise a simple 'cat' will be used.

To show an example ... using 'sed' to insert line breaks after each
closing XML tag, 'XML_LINTER' could be used as follows:

XML_LINTER="sed -e 's|>\\(<[^/]\\)|>\\\\n\\\\t\\\\1|g'"

Because a combination of 'eval' and 'printf' statements is used to
prepare the command line of the linter, any backslash characters
have to be escaped as shown above for '\n', '\t' and '\1' - using
'\\(' is possible, but not critical, because '\(' (and '\)', too)
is not a valid escape sequence for 'printf'.

* juis_check: properly quote automatically appended file name

Git stats


Failed to load latest commit information.
Latest commit message
Commit time


The final target of this project is to provide a really dynamic package management for SOHO/consumer IADs built by well-known vendor (at least known in Germany) AVM from Berlin.

These devices integrate various functions into a single device and - even due to grant-aided sales over some bigger providers in Germany - they're used widely in many (non-professional) installations in Germany (some sources speak about a market share of 50-60 percent here), Austria and Switzerland.

Maybe there's a little active community using FRITZ!Box devices in Australia too ... sometimes you may find some (mostly older) bulletin board conversations from this country regarding AVM routers.

The firmware for these devices is built on-top of Linux with many proprietary components. AVM states, they would publish a package with the open source files used to build their system, but since they switched to kernel version 3.10.73, these source packages are very incomplete (at least I think, they are ... I'm unable to compile a running kernel from these sources and I'm not the only one with such problems).

This repository contains (yet) some smaller shell scripts and files supporting their use ... it's growing and each new script is created with the intention to support the future target - they are the building blocks, which will be put together sometime in the future to form a single integrated solution.

Currently I'm the only one working on this project, any fellows are very welcome.

The modfs project is a spin-off from this (earlier) project, it's a solution to change the firmware supplied by the vendor on the FRITZ!Box device itself without the needs to use an own Linux installation with a complete toolchain built by the Freetz project. It's only a command line based solution, created from some proof-of-concept shell scripts, but it got some attention since it's a really simple solution to customize the stock firmware for your own needs. Because it may be used to create incremental changes and it contains a "boot manager" solution to switch a FRITZ!Box router between two different systems, each installed in its own partitions in the NAND flash of modern devices, there's little or no risk to damage the router and even the risk to be forced to recover such a device is practically non-existant.

Why should anybody need such a solution?

Because most users of FRITZ!OS devices are missing only an OpenVPN server/client and a SSH server for secure access to the command shell of the devices, these packages are (according to my experiences in the support forum for the Freetz project from the IPPF BBS - the most used extensions to the stock firmware and a solution providing these additions as modular packages could save many people from the needs to make further changes to their devices, as the use of a "full-blown" Freetz image would do. Meanwhile the extensive changes made by the vendor to the GUI of the devices (it's now a "responsive design" :-)) renders some important Freetz packages useless and while Freetz is a really big solution, changing many aspects of the system and containing an own GUI (even if it's rather old and - meanwhile - unsecure compared with the stock firmware), some users want only smaller changes and prefer a solution, which can make them more "under the hood" without interferences with the original firmware.

It's not possible to implement the final solution in one fell swoop ... but the building blocks are growing step by step and meanwhile I think, we should be able to test the first integrated version during this year.