Remote-Recovery

---

BoxMatrix >> Development >> Remote-Recovery

@ BoxMatrix   -   IRC-Chat   -   Translate: de es fr it nl pl

News

Selectors

Models

Accessories

Components

Environment

Config

Commands

System

Webif

Software

Develop

Lexicon

Community

Project

Media

---

Tarballs

GPL-Browser

FW-Probes

FW-History

FW-News

Supportdata

Hardware

SVN

Trac

Freetz-News

Freetz-Timeline

Freetz-Releases

Freetz-Mirror

OpenWRT

Research

---

---

This is currently being created and is unfinished, come back frequently to see it evolve! This message will be removed once it's finished.

---

Introduction

Recovery.exe and push_firmware are important tools during development. Both use TinyFTP built in ADAM2 or EVA,
Both require a computer with a static IP in the default subnet 192.168.178.x and an IP not being 192.168.178.1.
A second usage of static IP is the Emergency-IP for accessing a box wih unknown IP, which is 169.254.1.1 or 192.168.178.254 (lan:0).

For this my development machine has 2 network interface cards, one for my personal LAN, one for Fritzbox work with these subnets:

• 192.168.1.x - Alice IAD (Hansenet).
• 192.168.2.x - Telekom and Congstar models.
• 192.168.178.x - Fritzbox default subnet and old Emergency-IP.
• 169.254.x.x - Fritzbox new Emergency-IP.

My personal LAN of course uses another subnet. This worked fine so far until my main development machine broke recently.
I took an "emergency laptop" which has a broken LAN port and only WLAN. The question is: How to use Recovery.exe and push_firmware now?
The idea of wireless recovery was born of sheer necessity. Why not directly develop a flexible remote recovery solution?

Conception

What is required is an easy to use and flexible bridge from an arbitrary computer to the box to access its bootloader.
Well, this sounds like a job for a modified Fritzbox. Looking at my Hardware-Probes I was searchng for a model.

Hardware

The most compact model compared to its abilities is the 7320, and it is really cheap in germany (second hand).
The 7320 has the following useful features for this project:

• Very small, the size of a male hand, same size as the 4020.
• 300 Mbps WLAN (ath0) for wireless access by a computer and/or a WLAN-socket like the DeLock 11826.
• 1 Gbps LAN1 (separate eth0) for wired access by a computer.
• 1 Gbps LAN2 (separate eth1) to connect the probe.
• 1x USB 2.0 port to connect USB-Storage.
• 1x USB 2.0 port to connect an USB Serial-Comsole cable to the probe later.
• DECT to alternatively control a FRITZ!DECT 200 socket to power cycle the probe later,

Firmware

The latest AVM firmware for the 7320 is 6.34. Building a 7330 (german) alien with Freetz-ng it is 6.55.
Both firmwares are only available with german Webinterface. The Freetz-ng interface can be set to english in menuconfig.

User competence:

• Level of user competence: Expert

Model selection:

• Hardware type: 7330
• Target region: avm - germany (avme - english is way older and can not be built alien 7320 yet).
• Firmware version: FRITZ!OS 06.50+
• Compile image for 'alien' hardware: selected
• Alien hardware type: 7320

Replace kernel:

Since we need to use iptables we can't use the AVM kernel and have to activate Replace kernel.
Fortunately the Freetz built kernel runs stable for the 7320 (alien 7330).

Removal patches:

The 7320 only has 16MB flash memory, so we need to remove various features to have space for own stuff.
Before using these patches make sure the box is in IP-Client mode and debranded (firmware_version avm):

• Remove: leftover, module bins, showdsldstat, assistant (wizard), SIP assistant
• Keep: 2nd Annex (not present) and dsld (for now)
• Keep: AHA (for DECT socket) and AURA (for Serial-Console with Windows)
• Remove: WebDAV, mediasrv, NAS, MyFritz, DDNSD, VPN
• Remove: brandings >> 1und1 (after debranding the box), CAPIoverTCP, chronyd
• Keep: DECT (for DECT socket)
• Remove: dtrace, ftpd, help, ramzswap.ko, NTFS (we use ext on USB-Storage)
• Keep: NLS, USB-Host (for USB-Storage)
• Remove: printserv. usblp.ko, run_clock, Samba/NQCS
• Keep: support files (until support.lua could be kept separately)
• Remove tr069, tr064, fwupdate, httpsdl, ISP dbs, UMTS
• Keep: UPnP (required for AURA)
• Remove: kids, QoS, e2fsprogs
• Keep: WLAN (well, for WLAN :)

Other patches:

• Patch webif features (not really required but cheap)
• Add Freetzmount, automount ext2, ext3, fat (disable NTFS)
• Add /etc/services
• Disable console for serial port (for crossover Serial-Console later)
• Disable igd/upnp (maybe not), ntp-client, tr069
• Disable services by preload: DNS, DHCP, LLMNR (we use dnsmasq)

Configuration

AVM-Webinterface:

The AVM Webinterface is only required to set up the box as an IP-Client once.
Since the interface is in german language here a howto:

• Internet >> Zugangsdaten
  • Anschluss >> Externes Modem oder Router: select
  • Betriebsart >> Vorhandene Internetverbindung mitbenutzen (IP-Client-Modus): select
  • Zugangsdaten >> Nein: select

Freetz-Webinterface:

Low-level config is done in rc.custom.

To defeat unpredictable activity of the AVM packet accelerator we disable it (could be removed from the kernel later):

echo disable > /proc/net/avm_pa/control

Since the helper box should not conflict with the Emergency-IP of the probe we give it another IP:

ifconfig lan:0 192.168.178.250

To have full control over eth1 we separate it from the lan bridge. After this the lan bridge only consists of eth0 and ath0:

brctl delif lan eth1

Enable IP formwarding (is already enabled)

echo 1 > /proc/sys/net/ipv4/ip_forward

All rules from here on will turn a script which could be edited and rerun. Thus we start cleaning all previous rules:

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F