VDSL+VoIP Fritz!Box to OpenWRT-on-FB-7412 migration cheat sheet

Overview

This document is a suggestion for a migration to an OpenWRT-19.07-powered AVM Fritz!Box 7412 (a.k.a. "1&1 WLAN-Modem VDSL") providing VDSL2+vectoring connectivity, and running in combination with any other stock-firmware AVM Fritz!Box that handles VoIP/telephony functions, assuming this situation:

  • You are a customer in Germany at 1&1 having a VDSL2-with-vectoring Deutsche-Telekom-resale connection (up to 100 MBit/s downstream, up to 40 MBit/s upstream)
  • You are currently using an AVM Fritz!Box router with stock firmware that provides DSL connectivity, wireless access and VoIP/telephony
  • You run dual-stack IPv4 and IPv6, with IPv6 SLAAC addressing
  • You want OpenWRT for any reason, for example because you finally want rock-solid port forwarding instead of the wonky stuff that the stock firmware of e.g. the Fritz!Box 7360 or 7412 does when running IPv4 and IPv6 dual-stack
  • You know your way around Linux and its command line, but aren't really that familiar with routing and networking

The basic idea here is that you purchase a used 1&1-branded AVM Fritz!Box 7412, put OpenWRT 19.07 on it and set it up to do everything your current Fritz!Box router does, minus the VoIP stuff (which OpenWRT currently does not support for lack of hardware firmware/drivers).
After the OpenWRT box is up and running, you make a settings backup of your current Fritz!Box, then configure it to run in "IP-Client" mode while handling the 1&1 VoIP telephony.

For starters some information about the AVM Fritz!Box 7412 ("Why the 7412?"):

Pros

  • They are abundant and cheap, being the basic no-extra-cost router offered by 1&1, and people usually part with them for EUR 20 or less if you pick them up in person and pay cash (you can find offers in your local classified ads, or just ask your friends or co-workers)
  • They have flash and memory galore (128 MB flash and also 128 MB memory)
  • They are VDSL2-with-vectoring capable

Cons

  • Their CPU power is somewhat lacking, and if you have the full 100 MBit/s downstream your speed is CPU-limited to about 80 MBit/s, at which point one of the two CPU cores is saturated with kernel load
  • They only have a single LAN port, so you will need an extra Ethernet switch
  • You'll have to obtain the binary DSL modem firmware from somewhere else, and extracting it from the stock firmware is not exactly easy

Recommendation: What the hell, just get two 7412s, for these obvious reasons:

  • Again, they are dirt cheap
  • You'll have a spare
  • You can keep your current router untouched if you use the second 7412 for VoIP/telephony, so you always have a clean way back if something goes wrong with the new setup

What else?

  • It might not be possible to flash the 7412 back to its stock firmware (this is just a guess, I did not actually try it)
  • To make things like initial private IPv4 address setup and router resets easier, you should have a second PC whose Ethernet adapter configuration you can change without problems
  • This cheat sheet does not cover UPnP and assumes you do not need it
  • You might have to disable handing out IPv6 unique local addresses (ULA) in OpenWRT because this might confuse your VoIP stock-firmware Fritz!Box and make telephony unreliable (but then, the stock-firmware Fritz!Box does not hand out ULA addresses either)
  • You'll likely learn an awful lot while you go down the rabbit hole of OpenWRT internals and routing; depending on your personal disposition this can be a Pro or a Con

Tasks outline

  1. Obtain your real VDSL user name and password from your current Fritz!Box from a Fritz!Box WAN reconnect traffic dump with Wireshark
  2. Obtain the binary firmware for the Fritz!Box 7412 VDSL modem from the stock firmware or from a fellow forum member
  3. Purchase one or more Fritz!Box 7412 routers
  4. Update, de-brand and factory-reset your 7412s (can't hurt to do so)
  5. Boot, then flash OpenWRT 19.07 on one 7412
  6. Integrate the OpenWRT 7412 into your LAN: Disable DHCP and DNS services and set a temporary private IPv4 address
  7. Configure OpenWRT on the 7412 to your liking
    7.a) Install custom packages
    7.b) Install the LuCI web interface, served by nginx
    7.c) Copy the VDSL modem firmware to OpenWRT
    7.d) Set the VDSL parameters
    7.e) Set global DHCP and DNS settings
    7.f) Set up DHCP static leases
    7.g) Set up IPv4 port forwarding
    7.h) Set up IPv6 "port forwarding"
    7.i) TODO Prioritize VoIP traffic
    7.j) Set up wireless LAN
    7.k) Add valuable files to /etc/sysupgrade.conf
  8. Re-enable the OpenWRT 7412's DHCP and DNS services and set the final private IPv4 address
  9. Hook up your shiny new OpenWRT 7412 to your landline and do a field test
  10. Assuming the OpenWRT 7412 works as expected: Set the second 7412 or your old router to "IP-Client" mode and configure VoIP on it

1. Obtain your real VDSL user name and password

Install Wireshark.

With your current Fritz!Box, perform a packet capture of a VDSL reconnect, and open the resulting dump file in Wireshark. You are looking for a packet with protocol "PPP PAP" and an information text like this:

Authenticate-Request (Peer-ID='H1und1/(XXXXXXXXX)yyyyyyyyyy@online.de', Password='zzzzzzzzzzzzzz')

The Peer-ID is your DSL connection user name, and the Password is obviously the password.

The password may also look like "(XXXXXXXX)pppppp" if your "official" password, here "pppppp", is short. In that case indeed the whole "(XXXXXXXX)pppppp" is your "real" DSL connection password, this seems to be some sort of automatic key stretching.

2. Obtain the Fritz!Box 7412 VDSL modem firmware

List of firmware binaries with checksums

For Germany/Annex B you will want this one:

File version:          5.9.0.C.1.7-5.9.0.A.0.2
sha1sum:               756553dcb16ffee8bc1a92f13ae1670d6db35a79
File size:             905028
Firmware version A:    9.0.C
Application type A:    VDSL over ISDN incl. vectoring support
Firmware version B:    9.0.A
Application type B:    ADSL Annex B

It can be extracted from the stock Fritz!Box 7412 firmware version 137.06.86, however this requires special tools, namely a command line application "unsquashfs4-avm-be" from the Freetz development tools.

Extracting the modem firmware:

7z e FRITZ.Box_7412.137.06.85.image -r filesystem.image
7z e filesystem.image filesystem_core.squashfs
unsquashfs4-avm-be filesystem_core.squashfs -e lib/modules/dsp_vr9/

The xDSL firmware file can be found in "squashfs-root/lib/modules/dsp_vr9/"; it should be the largest file in the directory and its name is likely vr9-B-dsl.bin.
NOTE: unsquashfs4-avm-be is part of http://freetz.org/. You have to checkout the freetz source and build the tools (make tools) to get the binary.
NOTE: p7zip version 15.09 or newer is required to extract the images.

If you are an Arch Linux user you are in luck, there is an AUR package that provides the required Freetz application.

3. Purchase some Fritz!Box 7412 routers

Look at local classifieds, eBay Kleinanzeigen or just ask any personal acquaintances.

4. Update, de-brand and factory-reset your 7412s

This is most conveniently done with the extra PC, outside of your LAN, by setting its Ethernet port to a static IPv4 address of e.g. 192.168.178.222/24.

Removing the 1&1 branding (German)

If for any reason you cannot connect to the web interface, the Fritz!Box 7412 (and others) can be reset to factory defaults by connecting a telephone and dialing this magic phone number:

#991 *159 0159 0*

5. Boot, then flash OpenWRT 19.07

AVM Fritz!Box 7412 tech data
Device-specific OpenWRT installation instructions
Generic OpenWRT FTP installation instructions

6. Integrate the OpenWRT 7412 into your LAN as client

We will be doing almost the entire configuration using scripts (don't worry, we will also install LuCI).
The idea is that you copy the script templates here to text files, change them to whatever you need, and then paste portions of the scripts into an OpenWRT command line session.
That way you can quickly restore your settings even after an unintentional OpenWRT factory reset.

While you are configuring OpenWRT you want it to be accessible in your LAN, but you do not want it to hand out IP addresses with DHCP. Therefore we do some initial setup to give the OpenWRT 7412 router a temporary private IPv4 and disable DHCP.

Disconnect your extra PC from your LAN end set its Ethernet port to have this static IPv4 address: 192.168.1.222/24.
You do not need to set a DNS server or a default route.

Connect the Fritz!Box 7412 LAN port with your extra PC's LAN port, and you should be able to ping OpenWRT:

ping 192.168.1.1

Log in to the OpenWRT command line interface with SSH:

ssh -l root 192.168.1.1

Assumption: Your local network is 192.168.99.0/24
Assumption: Your current Fritz!Box router's private IPv4 address is 192.168.99.1
Assumption: IPv4 address 192.168.99.9 is unused in your local network

# Set root password
passwd root

# Set temporary local IPv4 address
uci set network.lan.proto='static'
uci set network.lan.ipaddr='192.168.99.9'
uci set network.lan.netmask='255.255.255.0'
uci set network.lan.gateway='192.168.99.1'
uci set network.lan.dns='192.168.99.1'
uci commit network

# Set host name and other system-level settings
uci set 'system.@system[0]'.hostname='router-openwrt' # TODO Choose host name
uci commit system

# Do NOT advertise an IPv6 unique local address prefix
# Apparently some devices get confused, such as some AVM Fritz!Box
# routers that are supposed to provide VoIP/telephony in "IP Client"
# mode
uci delete network.globals.ula_prefix
uci commit network.globals

# Temporarily disable DHCP and DNS services
/etc/init.d/dnsmasq disable
/etc/init.d/odhcpd disable

## REBOOT
reboot

Disconnect the OpenWRT 7412 from your extra PC and connect it to a switch in your local network, or to one of the extra LAN ports (2..n) of your current Fritz!Box.

After OpenWRT has rebooted you can login at its new IPv4 address from your "regular" PC:

ssh -l root 192.168.99.9

7. Configure OpenWRT

The goal is to set up OpenWRT to feature parity with the current Fritz!Box, with the exception of VoIP telephony and UPnP.

7.a) Install some packages and set some command line preferences

# Load the list of available packages
opkg update

# Optional: Install miscellaneous packages by personal preference
opkg install nano htop rsync

# Optional: Set nano as default command line text editor
echo '# Set the default command line text editor
export EDITOR=/usr/bin/nano' > '/etc/profile.d/98-custom-default-editor.sh'
chmod ugo+r '/etc/profile.d/98-custom-default-editor.sh'

7.b) Install LuCI, served by nginx over HTTPS on a custom port

LuCI essentials

Assumption: The desired HTTP port is 10080
Assumption: The desired HTTPS port is 10443
Assumption: You have opkg installed the command line text editor nano, see above

# Install LuCI (web browser configuration interface) served by nginx
opkg install luci-ssl-nginx
# Disable the uhttpd HTTP server, instead nginx will be used
/etc/init.d/uhttpd stop
/etc/init.d/uhttpd disable
# By default we do not want to start nginx and LuCI on reboot, this can
# always be done from the root shell when the need arises
# Disable automatic start of nginx
/etc/init.d/nginx disable
# Disable automatic start of LuCI
/etc/init.d/uwsgi disable

Edit /etc/nginx/nginx.conf so that LuCI is served with HTTPS on port 10443, and that HTTP requests to port 10080 are redirected to HTTPS at 10443.
Also, for security reasons, nginx should only accept incoming connections on your OpenWRT router's private IPv4 address, currently 192.168.99.9. (You will have to change this later when you assign the final IPv4 address.)

You can use nano to edit text files on the command line: nano /etc/nginx/nginx.conf

(...)
http {
    (...)
    server {
        listen 192.168.99.9:10080 default_server;
        (...)
        # Send everything to HTTPS
        return 301 https://$host:10443$request_uri;
    }
    server {
        listen 192.168.99.9:10443 ssl default_server;
        (...)
    }
(...)
}

To start LuCI you just run these: /etc/init.d/nginx start; /etc/init.d/uwsgi start
After that LuCI should be accessible in your web browser at https://192.168.99.9:10443/cgi-bin/luci/.
As it is not using a signed HTTPS certificate you will need to add a certificate exception in your browser on the first connection attempt.

To stop LuCI you run these: /etc/init.d/nginx stop; /etc/init.d/uwsgi stop

7.c) Copy the VDSL modem firmware to the OpenWRT Fritz!Box 7412

Assumption: The firmware file should be placed on the OpenWRT router at /usr/lib/firmware/modem/5.9.0.C.1.7/vr9-B-dsl.bin

In your OpenWRT SSH session, create the firmware directory:

mkdir -p /usr/lib/firmware/modem/5.9.0.C.1.7

On your desktop PC in a command line sesstion, copy the firmware file to OpenWRT with scp:

scp /desktop/pc/path/to/vr9-B-dsl.bin root@192.168.99.9:/usr/lib/firmware/modem/5.9.0.C.1.7/vr9-B-dsl.bin

7.d) Set the VDSL parameters

This here is the secret 1&1-via-Telekom VDSL+vectoring sauce that made VDSL work for me:

# Set up VDSL parameters
uci set network.dsl.annex='b' # Maybe not required? Does VDSL have an annex?
uci set network.dsl.line_mode='vdsl'
uci set network.dsl.ds_snr_offset='0'
uci set network.dsl.firmware='/usr/lib/firmware/modem/5.9.0.C.1.7/vr9-B-dsl.bin'
uci set network.dsl.tone='bv'
uci commit network.dsl

# Set up PPPOE / DSL login parameters
# WAN section
uci set network.wan.ifname='dsl0.7' # .7 to use VLAN ID 7
uci set network.wan.proto='pppoe'
#uci set network.wan.username='H1und1/(XXXXXXXXX)yyyyyyyyyy@online.de' # TODO Use your user name
#uci set network.wan.password='zzzzzzzzzzzzzzzz' # TODO Use your password
uci set network.wan.ipv6='auto'
uci commit network.wan

# ATM section
uci set network.atm.vpi='1'
uci set network.atm.vci='32'
uci set network.atm.encaps='llc'
uci set network.atm.payload='bridged'
uci set network.atm.nameprefix='dsl'
uci commit network.atm

7.e) Set up DHCP and DNS services (global settings)

Assumption: DHCP should hand out IPv4 addresses from 192.168.99.100 to 192.168.99.249
Assumption: DHCP leases should last 48h
Assumption: IPv6 addressing should only be done with SLAAC

# Set up DNS service
uci set 'dhcp.@dnsmasq[0]'.rebind_protection='1'
# Set up DHCP service
uci set dhcp.lan='dhcp'
uci set dhcp.lan.interface='lan'
uci set dhcp.lan.start='100'
uci set dhcp.lan.limit='149' # I.e. 100..249
uci set dhcp.lan.leasetime='48h'
# IPv6: Only use SLAAC addressing
uci set dhcp.lan.dhcpv6='disabled'
uci set dhcp.lan.ra='server'
# ra_management='0': A-flag (SLAAC only)
# ra_management='1': A-flag and M-flag (both SLAAC and DHCPv6)
# ra_management='2': M-flag (DHCPv6 only)
uci set dhcp.lan.ra_management='0'
uci commit dhcp

7.f) Set up DHCP static leases

As it unfortunately turns out, if you put a stock-firmware Fritz!Box into "IP-Client" mode, you lose the ability to set a static private IPv4 address for it.

At least for my VoIP/telephony Fritz!Box 7412 this was the case - I had set a static IPv4 address before I set it to "IP-Client" mode, and after the reboot it was not accessible by that address anymore.
Turns out, it had started using DHCP, and the menu section where one can set a static IPv4 address had disappeared.
I had to go look for its IPv4 address in my router's "Devices on LAN" section.

Since we will have to set up port forwarding for VoIP, the stock-firmware Fritz!Box needs to always have the same private IPv4 address, and to achieve this we will set up a static lease for it.

For convenience reasons we declare a shell function that sets up a static lease (just paste it into your OpenWRT session):

# Set up a static (infinite) DHCP lease
#
# The DHCP UID and the IPv6 Host ID can be left blank if no DHCPv6 is
# used and IPv6 addressing is done with SLAAC
#
# The "hostid" IPv6 host identifier (address suffix) is given in
# hexadecimal notation, presumably like this:
#   aaaabbbbccccdddd
#
# setDhcpStaticLease macAddr ipv4Addr dhcpUid ipv6HostId name
setDhcpStaticLease () {
    local mac="$1"; shift
    local ip="$1"; shift
    local duid="$1"; shift
    local hostid="$1"; shift
    local name="$1"; shift

    uci -q delete "dhcp.$name" 
    uci set "dhcp.$name"='host'
    uci set "dhcp.$name".name="$name"
    uci set "dhcp.$name".mac="$mac"
    uci set "dhcp.$name".dns="1"
    uci set "dhcp.$name".hostid="$hostid"
    uci set "dhcp.$name".duid="$duid"
    uci set "dhcp.$name".ip="$ip"
    uci set "dhcp.$name".leasetime="infinite"
}

Assumption: The VoIP/telephony Fritz!Box's private IPv4 address should be 192.168.99.2.
Assumption: The VoIP/telephony Fritz!Box's MAC address is aa:bb:cc:dd:ee:ff.

Install the static lease for the VoIP/telephony Fritz!Box:

setDhcpStaticLease 'aa:bb:cc:dd:ee:ff' '192.168.99.2'    '' '' fritz_box_phone
uci commit dhcp

7.g) Set up IPv4 port forwarding

For this we will also use a shell function:

# Set up IPv4 port forwarding
#
# setFirewallDnatRedirect proto dest_ip ports name
setFirewallDnatRedirect () {
    local proto="$1"; shift
    local dest_ip="$1"; shift
    local src_dport="$1";
    local dest_port="$1"; shift
    local name="$1"; shift

    uci -q delete "firewall.$name"
    uci set "firewall.$name"="redirect"
    uci set "firewall.$name".name="$name"
    uci set "firewall.$name".target="DNAT"
    uci set "firewall.$name".src="wan"
    uci set "firewall.$name".dest="lan"
    uci set "firewall.$name".proto="$proto"
    uci set "firewall.$name".src_dport="$src_dport"
    uci set "firewall.$name".dest_ip="$dest_ip"
    uci set "firewall.$name".dest_port="$dest_port"
}

For starters we need some port forwarding for our VoIP router:

# Port forwarding for "fritz_box_phone"
setFirewallDnatRedirect tcp 192.168.99.2     '5060'       ipv4_telephony_SIP_TCP
setFirewallDnatRedirect udp 192.168.99.2     '5060'       ipv4_telephony_SIP_UDP
setFirewallDnatRedirect udp 192.168.99.2     '7078:7109'  ipv4_telephony_RTP
uci commit firewall

Maybe you have an FTP server and a BitTorrent instance at 192.168.99.20, and a web server at 192.168.99.21:

# Port forwarding for "homeserver"
setFirewallDnatRedirect tcp 192.168.99.20      '21'       ipv4_homeserver_FTP_server_login
setFirewallDnatRedirect tcp 192.168.99.20   '11100:11159' ipv4_homeserver_FTP_server_passive
setFirewallDnatRedirect tcp 192.168.99.20   '11160'       ipv4_homeserver_BitTorrent_TCP
setFirewallDnatRedirect udp 192.168.99.20   '11160'       ipv4_homeserver_BitTorrent_UDP

# Port forwarding for "webserver"
setFirewallDnatRedirect tcp 192.168.99.21      '80'       ipv4_webserver_HTTP_server
setFirewallDnatRedirect tcp 192.168.99.21     '443'       ipv4_webserver_HTTPS_server
uci commit firewall

7.h) Set up IPv6 "port forwarding"

With IPv6 the devices on your LAN have their own, publicly-routable IPv6 addresses, with which they can be accessed from the internet.
Well, almost. Because this would be one hell of a security problem, routers by default block all IPv6 access attempts that come in from the internet, and OpenWRT is no exception.
Instead of "forwarding" something, allowing IPv6 access is just a matter of telling the OpenWRT firewall to let certain connection attempts through.

Aaand you guessed it, here is another shell function:

# Set up firewall (open ports by IPv6 address)
#
# setFirewallIpv6AcceptRule proto dest_ip ports name
setFirewallIpv6AcceptRule () {
    local proto="$1"; shift
    local dest_ip="$1"; shift
    local src_dport="$1";
    local dest_port="$1"; shift
    local name="$1"; shift

    uci -q delete "firewall.$name"
    uci set "firewall.$name"="rule"
    uci set "firewall.$name".name="$name"
    uci set "firewall.$name".target="ACCEPT"
    uci set "firewall.$name".src="wan"
    uci set "firewall.$name".dest="lan"
    uci set "firewall.$name".proto="$proto"
    uci set "firewall.$name".family="ipv6"
    uci set "firewall.$name".src_dport="$src_dport"
    uci set "firewall.$name".dest_ip="$dest_ip"
    uci set "firewall.$name".dest_port="$dest_port"
}

There is however one slight hitch with this plan: Your devices' IPv6 addresses are not static. Every time your VDSL reconnects all devices in your LAN get a new IPv6 address, and your internet service provider dictates the "global" (left) part of that new IPv6 address.

Fortunately for you, the right half of an IPv6 address, also known as the "IPv6 interface identifier", is yours to define. With SLAAC, the interface identifier will be derived from the device's (static) MAC address.

Very likely your current Fritz!Box already uses SLAAC addressing and you can have a look at your devices' IPv6 addresses to find out their interface IDs.

What we need now is a way to tell the firewall to let an access attempt through if

  • The target IPv6 address has a certain interface ID
  • It uses a certain port

The trick to match by an IPv6 interface ID is to mask out the leftmost 64 bit of an IPv6 address in the matching directive, which is done with a negative bit mask, -64.

Assumption: Your VoIP router's IPv6 interface ID is ::1:22:333:4444.
Assumption: Your home server's IPv6 interface ID is ::5555:6666:7777:8888.
Assumption: Your web server's IPv6 interface ID is ::9999:aaaa:bbbb:cccc.

# Ports for "fritz_box_phone"
setFirewallIpv6AcceptRule tcp       '::1:22:333:4444/-64'   '5060'       ipv6_telephony_SIP_TCP
setFirewallIpv6AcceptRule udp       '::1:22:333:4444/-64'   '5060'       ipv6_telephony_SIP_UDP
setFirewallIpv6AcceptRule udp       '::1:22:333:4444/-64'   '7078:7109'  ipv6_telephony_RTP

# Ports for "homeserver"
setFirewallIpv6AcceptRule tcp '::5555:6666:7777:8888/-64'     '21'       ipv6_homeserver_FTP_server_login
setFirewallIpv6AcceptRule tcp '::5555:6666:7777:8888/-64'  '11100:11159' ipv6_homeserver_FTP_server_passive
setFirewallIpv6AcceptRule tcp '::5555:6666:7777:8888/-64'  '11160'       ipv6_homeserver_BitTorrent_TCP
setFirewallIpv6AcceptRule udp '::5555:6666:7777:8888/-64'  '11160'       ipv6_homeserver_BitTorrent_UDP

# Ports for "webserver"
setFirewallIpv6AcceptRule tcp '::9999:aaaa:bbbb:cccc/-64'     '80'       ipv6_webserver_HTTP_server
setFirewallIpv6AcceptRule tcp '::9999:aaaa:bbbb:cccc/-64'    '443'       ipv6_webserver_HTTPS_server
uci commit firewall

7.i) Prioritize VoIP traffic

TODO I have not looked into this yet as my telephone appears to be working well enough without it.

7.j) Set up wireless LAN

TODO I use a different device as access point.
Just use LuCI to configure wireless connectivity, I tried it once and it worked immediately without having to install any extra packages.

7.k) Add valuable files and directories to /etc/sysupgrade.conf

At some point in the future you will want to install a newer version of OpenWRT.
The upgrade procedure will keep /etc/config/, so your uci set ... settings will be kept.
By default it will however not keep any custom files you edit or add.

If you want to keep extra files or directories you need to add them to the /etc/sysupgrade.conf text file, for example with nano /etc/sysupgrade.conf:

# Keep various manual configuration
/etc/nginx/nginx.conf
/etc/profile.d/

# Keep this file
/etc/sysupgrade.conf

# Keep root's stuff
/root/

# Keep any firmware, for example for the VDSL modem
/usr/lib/firmware/

8. Re-enable DHCP and DNS services and set the final private IPv4 address

Almost done. Now we just need to set the final IPv4 address (the one currently in use by your stock-firmware Fritz!Box) and re-enable DHCP and DNS services.

If you are anything like me - that is, lazy - you can do that on your LAN.
I.e. you make the final adjustments, set the IPv4 address and do a reboot, and immediately disconnect the box from your LAN by removing the Ethernet cable (because its IPv4 address will conflict with your current stock-firmware Fritz!Box router's IPv4 address).

Remember also to edit /etc/nginx/nginx.conf to make it listen on the new IPv4 address.

Here goes:

# Set final local LAN IPv4 address
uci set network.lan.proto='static'
uci set network.lan.ipaddr='192.168.99.1'
uci set network.lan.netmask='255.255.255.0'
uci delete network.lan.gateway
uci delete network.lan.dns
uci commit network

# Re-enable DHCP and DNS service
/etc/init.d/dnsmasq enable
/etc/init.d/odhcpd enable

## REBOOT
reboot

9. Field test!

Unless you already have the VoIP/telephony Fritz!Box ready you should do this at a time of day when nobody wants to use the phone. Or internet. :wink:

Unplug your current stock-firmware Fritz!Box and plug in the OpenWRT 7412.
(Except the telephone, no point in plugging this into the OpenWRT router).

If everything goes as planned the OpenWRT 7412 will sync up its VDSL and connect to the internet, and everything should just work with your LAN.

Give it some time. My subjective impression is that the VDSL sync takes longer than with the AVM stock firmware; at least 2 minutes.

You can watch LuCI's status page, or you can, on the command line, watch the system log scroll by with:

logread -l 20 -f

You can get the same VDSL modem status summary as is shown on the LuCI status page on the command line, with:

/etc/init.d/dsl_control status

Hopefully eventually you will see something like this:

ATU-C Vendor ID:                          Broadcom 192.26
ATU-C System Vendor ID:                   Broadcom
Chipset:                                  Lantiq-VRX200
Firmware Version:                         5.9.0.12.1.7
API Version:                              4.17.18.6
XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2
Annex:                                    B
Line Mode:                                G.993.5 (VDSL2 with down- and upstream vectoring)
Profile:                                  17a
Line State:                               UP [0x801: showtime_tc_sync]
Forward Error Correction Seconds (FECS):  Near: 0 / Far: 53
Errored seconds (ES):                     Near: 16125 / Far: 2124
Severely Errored Seconds (SES):           Near: 3 / Far: 744
Loss of Signal Seconds (LOSS):            Near: 7 / Far: 0
Unavailable Seconds (UAS):                Near: 568 / Far: 568
Header Error Code Errors (HEC):           Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P):        Near: 49 / Far: 0
Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
Power Management Mode:                    L0 - Synchronized
Latency [Interleave Delay]:               0.16 ms [Fast]   0.0 ms [Fast]
Data Rate:                                Down: 99.986 Mb/s / Up: 36.996 Mb/s
Line Attenuation (LATN):                  Down: 4.9 dB / Up: 3.1 dB
Signal Attenuation (SATN):                Down: 5.0 dB / Up: 3.1 dB
Noise Margin (SNR):                       Down: 13.2 dB / Up: 11.4 dB
Aggregate Transmit Power (ACTATP):        Down: -4.9 dB / Up: 13.1 dB
Max. Attainable Data Rate (ATTNDR):       Down: 91.776 Mb/s / Up: 43.824 Mb/s
Line Uptime Seconds:                      168464
Line Uptime:                              1d 22h 47m 44s

All right, maybe with shorter uptimes. In any case you are eligible for a win beer.

10. Set up the VoIP/telephony router

Assumption: You have bought a second AVM Fritz!Box 7412 for this purpose, it is up-to-date, de-branded and has its factory settings
Assumption: Your new OpenWRT 7412 box is has replaced your previous Fritz!Box router

As with the de-branding section, set your extra PC's IPv4 address to 192.168.178.222/24 and connect it to the VoIP-to-be Fritz!Box, then go to the Fritz!Box management interface at http://192.168.178.1/.
If prompted, set a password, and cancel the connection wizard.

It seems that changing the Fritz!Box web UI to English is not that straightforward, so watch out, Here Be German.

  • Click the three-dots button in the top right corner, and in the pop-up menu you enable "Erweiterte Ansicht"
  • In the left-side menu, go to Internet -> Zugangsdaten, tab "Internetzugang"
  • At the "Internetanbieter" area, in the upper drop-down selection, choose "Weitere Internetanbieter"
  • In the lower drop-down selection, choose "Anderer Internetanbieter"
  • The "Name" field can be left blank
  • "Anschluss" section below: Choose "Anschluss an ein externes Modem oder Router"
  • "Betriebsart" section below: Choose "Vorhandene Internetverbindung mitbenutzen (IP-Client-Modus)"

After that you hit "√úbernehmen". Maybe the Fritz!Box wants a reboot. After that, hook it up to your proper LAN network, and if you did the static DHCP lease right, it should now have the IPv4 address 192.168.99.2.
Connect your physical telephone to the Fritz!Box.

Open the Fritz!Box web interface from your desktop PC, now at http://192.168.99.2/.

  • Again, in the left-side menu, go to Internet -> Zugangsdaten, but this time click tab "IPv6"
  • Check the check-box for "IPv6-Unterst√ľtzung aktiv"
  • Un-check "DHCPv6 Rapid Commit verwenden"

If you go to the "√úbersicht" page you should now see, in the "Verbindungen" section, something like this:

Internet    IPv4, Eine bestehende Internetverbindung im Netzwerk wird mitbenutzt.
            IPv4-Adresse: 192.168.99.2
Internet    IPv6, Eine bestehende Internetverbindung im Netzwerk wird mitbenutzt.
            IPv6-Adresse: 2003:d8:670c:4500:1:22:333:4444

Now you set up your VoIP telephony with the usual parameters, in Telefonie -> Eigene Rufnummern, and afterwards configure your physical telephone in Telefonie -> Telefoniegeräte.

And that should be it.

For bonus points you can do some actual hands-on home improvement and wall-mount the two 7412s side-by-side. Sort of like that:

Welp, I hope this write-up helps somebody. Enjoy!

5 Likes

Dear eomanis,
It may sound stupid, but do you know a manual on how to "make tool" under MacOS?

Thanks!

Look here:
Internet -> Zugangsdaten -> Tab Internetzugang -> Verbindungseinstellungen ändern -> IP-Adresse manuell festlegen

Another option is the static "emergency" IP address: 169.254.1.1
It works well as long as there is only one Fritz!Box connected to the PC.

2 Likes

I'll be damned, it moved there. Good catch!

That does not sound stupid at all, but I do not know how to prepare a Mac for building these applications, sorry.

I think the easiest way for you is to boot up/install Manjaro Linux in a virtual machine, and then build the freetz-tools-git AUR package in the VM.

After the package has been built and installed you extract the firmware inside the VM as described.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Migration cheat sheet errata

Sorry for being so late with this. Anyhow, the cheat sheet has a few shortcomings, which I will address here.

2. Obtain the Fritz!Box 7412 VDSL modem firmware

There meanwhile is a newer, better VDSL modem firmware available, from the Fritz!Box 7490:

File version:          5.9.1.4.0.7-5.9.0.D.0.2
sha1sum:               ceace0e9ccfa09372248371c2bad4d7fc4cc9b35
File size:             908376
Firmware version A:    9.1.4
Application type A:    VDSL over ISDN incl. vectoring support
Firmware version B:    9.0.D
Application type B:    ADSL Annex B

Again, see this list of firmware binaries.

7.f) (Erratum) Set up DHCP static leases

Contrary to what is stated in that section, and as @mpa has rightfully pointed out, you can set a static private IPv4 address for a Fritz!Box with Fritz!OS running in "IP-Client" mode:

This makes step 7.f) entirely optional, i.e. you do not need to install a static lease for your VoIP Fritz!Box if you set it to a static IPv4 address that way.

7.h) (Erratum) Set up IPv6 "port forwarding"

The shell function is slightly wrong; the parameter src_dport is not applicable here.
Setting it does not prevent the rules from functioning, however it will cause some warnings in the OpenWRT log when the firewall is being reloaded and these rules are being applied.

This is the rectified shell function:

# Set up firewall (open ports by IPv6 address)
#
# setFirewallIpv6AcceptRule proto dest_ip ports name
setFirewallIpv6AcceptRule () {
    local proto="$1"; shift
    local dest_ip="$1"; shift
    local dest_port="$1"; shift
    local name="$1"; shift

    uci -q delete "firewall.$name"
    uci set "firewall.$name"="rule"
    uci set "firewall.$name".name="$name"
    uci set "firewall.$name".target="ACCEPT"
    uci set "firewall.$name".src="wan"
    uci set "firewall.$name".dest="lan"
    uci set "firewall.$name".proto="$proto"
    uci set "firewall.$name".family="ipv6"
    uci set "firewall.$name".dest_ip="$dest_ip"
    uci set "firewall.$name".dest_port="$dest_port"
}

7.l) (New section) Increase load resilience of PPPoE (VDSL) connection

I have made the experience that a single person downloading something large from my place, so that my upload is saturated, will

  • immediately cause my own internet experience to grind to a screeching halt,
  • prevent other persons from connecting/downloading, and
  • after about 50 seconds, cause my PPPoE connection to hang up (i.e., cause a VDSL reconnect),

by what appears to be this situation.

Basically, their traffic on my upstream prevents the PPPoE control/keep-alive packets from going through, leading to pppd assuming that the link has been cut.

Now, pppd has a very sensible option lcp-echo-adaptive that basically is "as long as there is traffic going on, assume that the link is still working". It unfortunately is not active by default, and there also is no direct OpenWRT setting to enable it.

It however does get enabled if a different, but thematically related option is set, network.wan.keepalive, that controls the number and frequency of these keep-alive packets.

So, to prevent the VDSL reconnects, set these settings:

# Workaround for bug: FS#1259 - PPPoE disconnects under high upstream load
# https://bugs.openwrt.org/index.php?do=details&task_id=1259
# First integer:  LCP echo failure threshold, in number of packets
# Second integer: LCP echo interval, in seconds
uci set network.wan.keepalive='8 5'
uci commit network.wan

You can check the efficacy in a process listing that shows the pppd process and its command line, for example in htop, after e.g. a reboot:

/usr/sbin/pppd nodetach ipparam wan ifname pppoe-wan lcp-echo-interval 5 lcp-echo-failure 8 lcp-echo-adaptive ...

While this will hopefully deal with the VDSL reconnects, it does not help at all against the "cannot use internet while someone is downloading" thing, which leads right up to the next new section:

7.m) (New section) Traffic shaping / Smart Queue Management (SQM)

This, as it turns out from the above, is absolutely required.

Unfortunately for us, the limited CPU power of the Fritz!Box 7412 means that

  • enabling SQM will shave even more bandwidth off the downstream, and
  • we can only use the simplest SQM schemes.

In my case it boils down to a downstream penalty of about 1.5 MByte/s to a speed of about 6.5 MByte/s.
Still, subjectively I find that this does not degrade everyday internet use very much.

SQM / traffic shaping mostly works by having the router limit and control how fast any connection may send data out through the upstream link, so that hopefully each connection gets its fair share, and in particular that a high-sustained-throughput connection (file download/upload) does not starve multiple low-throughput, low-latency connections (VoIP telephony, gaming, browsing).

(The router cannot really control how fast it receives data on the downstream link.)

This means that, for SQM to function, the SQM logic must be aware of the upstream link's top speed, and artificially cap its speed slightly below that, so that there is always some leftover bandwidth for time-critical stuff.
So, the most critical and important SQM setting is its upload setting.

For an upstream data rate of about 33 MByte/s as reported by /etc/init.d/dsl_control status I am using an SQM upload speed of 29000 (MBit/s, presumably):

# Install smart queue management (SQM) with LuCI integration
opkg install luci-app-sqm

# Configure SQM
uci -q delete sqm.eth1
uci set sqm.eth1=queue
uci set sqm.eth1.interface='pppoe-wan'
uci set sqm.eth1.download='62500'
uci set sqm.eth1.upload='29000'
uci set sqm.eth1.linklayer='ethernet'
uci set sqm.eth1.overhead='34'
uci set sqm.eth1.qdisc_advanced='0'
uci set sqm.eth1.verbosity='2'
uci set sqm.eth1.debug_logging='0'
uci set sqm.eth1.enabled='1'
uci set sqm.eth1.qdisc='fq_codel'
uci set sqm.eth1.script='simplest_tbf.qos'
#uci set sqm.eth1.qdisc='fq_codel'
#uci set sqm.eth1.script='simplest.qos'
uci commit sqm
/etc/init.d/sqm enable

Be aware that, in the event that your upstream speed changes, you need to manually adjust this upload setting's value accordingly; at least I am not aware of an automatism that can be used for this.

Seeing that the VDSL upstream speed slightly varies on each VDSL re-sync you should probably leave enough room / use a conservative value that is appreciably lower than the upstream of a "bad" VDSL sync.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.