Erfahrungsbericht über SIP-403, alte Provider-Firmware, EVA, Freetz-NG und zwei FRITZ!Boxen in ReihenschaltungVodafone kündigt in einer mail an, daß SIP-Daten geändert werden.
“Wichtige Umstellung der Telefonie” heisst es. Und:
Du verwendest einen eigenen Kabel Router: wir haben wichtige Neuigkeiten für Dich.
Es ist aus technischen Gründen nötig, neue SIP Zugangsdaten in Deinem Kabel-Router einzugeben. Diese benötigst Du für Telefonie.
Du möchtest am Tag der Umstellung Deine Telefonie direkt weiter nutzen? Dann findest Du die SIP-Zugangsdaten in MeinVodafone.
Dein Internet- und TV- Dienst ist hiervon nicht betroffen.
9. Oktober 2026 · Erfahrungsbericht
“Dein Festnetz geht nicht” – sagte mein Kumpel am Handy. Oh..
Ich erinnerte mich an die Email, die Vodafone ein paar Tage zuvor
geschickt hatte. Tatsächlich leuchtete die Telefon-“Lampe” an der
6490-Cable Fritzbox rot.
Einen Brief hatte ich nicht erhalten, aber irgendwo in den Tiefen des
MyVodafone-Accounts konnte ich tatsächlich neue SIP Daten finden.
Also – eigentlich sollte es eine Kleinigkeit sein: Vodafone hatte neue
SIP-Zugangsdaten bereitgestellt. Die FRITZ!Box 6490 Cable, die seit langem
direkt am Kabelanschluss lief, sollte damit wieder telefonieren.
Internet ging problemlos => Telefonie seit der Umstellung nicht mehr.
Ein paar Stunden später waren ein Kali-Linux in VirtualBox, ein EVA-Bootloader,
mehrere FTP-Kommandos und eine zweite FRITZ!Box beteiligt.
Immerhin: Am Ende funktionierten ein- und ausgehende Anrufe wieder.
Vielleicht erspart diese Dokumentation jemandem einen Teil der Sucherei.
Ausgangslage
- FRITZ!Box 6490 Cable: ehemalige NetCologne-Box, FRITZ!OS 7.01, produktives Vodafone-Kabelmodem und Router.
Kein Update-Menü. - FRITZ!Box 6590 Cable: aus der Krabbelkiste – hatte ich zum Glück noch vorrätig. International Edition, Artikelnummer 20002820, FRITZ!OS 6.84
Kein Update-Menü. - Vodafone NRW: neue SIP-Daten, unter anderem Registrar
fixed.vodafone.deund Proxyegf11.fixed.vodafone.de. - Telefon: Gigaset-DECT-Mobilteil.
Eingabe der neuen Daten führten jedoch zu Fehlern. Keine Registrierung
möglich; im Logfile der 6490 fanden sich “403” Errors.
Versuch von diversen Schreibweisen der Telefonnr – kein Connect.
Der auffällige Unterschied in der Vodafone-Anleitung vom Mai 2026:
Es gibt getrennte Angaben für den Benutzernamen (Telefonnummer mit +49)
und den Authentifizierungsnamen (IMPI_…).
Eingabe des Benutzernamens (Tel-Nr) sollte je nach Anleitung mit “(<vorwahl>) Rufnummer” oder auch mit +49<vorwahl><rufnummer> erfolgen. Das ging aber alles schief.
Die alten Oberflächen meiner beiden Boxen boten zudem die Option
“Authentifizierungsname” gar nicht an.
Ob in das Feld “Benutzername” nun die Nummer oder der Authentifizierungsname
gehörte, war nicht klar. Am Ende funktionierte keine der Möglichkeiten.
Version zu alt – “missing Update Menu”
Die Version 7.01 auf der 6490 war anscheinend zu alt für diese Eingabemöglichkeit. Leider gab es auch den “Update” Knopf nicht – wohl, weil diese Box ehemals bei einem Kabelprovider im Einsatz war.
Erst DNS, dann SIP
Ein normaler A-/AAAA-Lookup auf die Vodafone-Servernamen lieferte keine Adressen. Das ist aber nicht automatisch ein DNS-Fehler: Der Proxy ist über SIP-SRV auflösbar. Der entscheidende Test unter Windows war:
nslookup -type=SRV _sip._udp.egf11.fixed.vodafone.de 192.168.178.1
Ergebnis: vier SBC-Ziele (sbc19, sbc29, sbc39, sbc49) auf Port 5060/UDP mit unterschiedlichen Prioritäten. Damit war die DNS-SRV-Seite plausibel. Die wiederholten 403-Antworten zeigten zudem, dass der Vodafone-SIP-Server zumindest zeitweise tatsächlich erreicht wurde. Ob 403 aus falscher Identität, Passwort, Provisionierung oder einer anderen Policy resultierte, war daraus nicht eindeutig abzuleiten.
Plan B: Die 6590 aktualisieren, nicht den produktiven Anschluss riskieren
Ein direktes Update der aktiven 6490 hätte bei einem Fehlschlag den
Internetanschluss mitgerissen. Deshalb fiel die Wahl auf die unbenutzte 6590 Cable.
Ihr Firmwarestand war noch älter, aber sie konnte ohne Risiko für die
6490 bearbeitet werden.
Auch hier wurde leider kein “update” Knopf angezeigt. Ein Flash der
Firmware über einen lokalen PC war die Antwort.
FRITZ!Box 6590 Cable FRITZ!OS 6.84 auf 7.57
Die 6590 wurde daher via ethernet-Kabel direkt an einen windows-pc angeschlossen,
der vom WLAN getrennt war. Die Gefahr, aus Versehen das produktive Gateway
(die 6490) zu bearbeiten, musste verhindert werden.
Der EVA-/ADAM2-Bootloader war nach einem Neustart für wenige Sekunden
unter 192.168.178.1:21 erreichbar.
Powershell:
$ip = “192.168.178.1”
while ($true) {
$tcp = [Net.Sockets.TcpClient]::new()
try {
$result = $tcp.BeginConnect($ip, 21, $null, $null)
if ($result.AsyncWaitHandle.WaitOne(150) -and $tcp.Connected) {
“EVA erreichbar!”
$tcp.Close()
break
}
} catch {}
$tcp.Close()
Start-Sleep -Milliseconds 100
}
Die laufende 6590 hatte nach dem Start die 192.168.178.250 aus vorherigen Versuchen.
Ich hatte zunächst DHCP – IP Vergabe gewählt; wollte ja keine doppelten IPs im Netz.
Diese beiden Betriebszustände muss man strikt unterscheiden.
Über den FTP-Client lassen sich zunächst lesend Variablen abfragen:
ftp 192.168.178.1
username: adam2
password: adam2
quote SYST
quote GETENV HWRevision
quote GETENV ProductID
quote GETENV firmware_version
quote GETENV firmware_info
quote GETENV linux_fs_start
quote GETENV bootloaderVersion
Die entscheidenden Ergebnisse lauteten:
HWRevision 220
ProductID Fritz_Box_HW220a
firmware_version avm
firmware_info 148.06.84
bootloaderVersion 1.3125
linux_fs_start nicht gesetzt
Wichtig: Diese Werte gelten für genau dieses Gerät. Bei anderen Boxen können ProductID, Branding, Bootloader und Flashstruktur abweichen. Keinesfalls blind übernehmen.
Original-Firmware und Freetz-NG
Für die International Edition wurde das originale AVM-Image FRITZ!OS 7.57, „other“ verwendet
Unter https://download.avm.de/fritzbox/ liegen die normal zugänglichen (nicht-Provider) Versionen.
Vor dem Flashen wurden Dateistruktur und var/content des Archivs geprüft. Sie bestätigten unter anderem:
tar -xOf Fritz……image ./var/content
Product=Fritz_Box_HW220a (FRITZ!Box 6590 Cable)
Version=07.57
Build=107831
OEMs=avm
Zum Einsatz kam push_firmware aus Freetz-NG, ausgeführt in Kali Linux in einer VirtualBox-VM. Die VM hatte eine Netzwerkbrücke auf den physischen Ethernet-Port zum Gerät; NAT innerhalb von VirtualBox wäre für den kurzen EVA-Zugriff nicht die gewünschte Konfiguration gewesen.
Vorher wurden die Werkzeugoptionen kontrolliert:
./push_firmware --help
Achtung: Der folgende Befehl führt tatsächlich einen Firmware-Flash aus. Er gehört nur hierher, weil die Hardwarekennung geprüft, die Box entbehrlich und die Folgen eines Fehlschlags akzeptiert waren. Keine -f-Option und kein manuell erzwungener Firmware-Slot:
./push_firmware ./FRITZ.Box_6590_Cable-07.57-other.image -ip 192.168.178.1
Das Skript erkannte die Dual-Boot-Struktur und wählte bei nicht gesetztem linux_fs_start den Slot 1. Es übertrug ARM- und x86-Komponenten in die MTD-Partitionen 11 bis 14.
Am Ende standen vier abgeschlossene Transfers mit 226 Transfer complete, anschließend SETENV linux_fs_start 1, REBOOT und done. Daneben tauchte die Meldung Can't open 'mtd' auf. Sie verhinderte den erfolgreichen Start in diesem Fall nicht; man sollte sie aber nicht pauschal als harmlos einstufen.
Nach dem Neustart zeigte die Weboberfläche tatsächlich FRITZ!OS 7.57. Das Gerät war also weder gebrickt noch in einer Bootschleife.
Eine FRITZ!Box als Kabelrouter, die andere als Telefonanlage
Die 6590 wurde nicht als Kabelmodem bei Vodafone registriert. Stattdessen blieb die 6490 am Koaxanschluss und stellte die Internetverbindung bereit. Die 6590 nutzte diese über LAN 1 als IP-Client / Mitbenutzer einer bestehenden Internetverbindung. Ihre Adresse änderte sich im Zuge der Netzwerkkonfiguration auf eine per DHCP vergebene LAN-IP.
Erst jetzt konnte die neue SIP-Konfiguration mit getrennten Feldern für Telefonnummer und IMPI_… sinnvoll getestet werden. In der Übersicht erschien die Rufnummer als aktiv. Ausgehende Telefonate funktionierten, und eingehende Anrufe wurden in der Anrufliste der 6590 angezeigt.
Der letzte Stolperstein war DECT: Das Mobilteil ließ sich an der 6590 anmelden, der interne Klingeltest funktionierte, externe Anrufe klingelten aber nicht. Nach dem Abschalten des DECT-Moduls an der alten 6490 klingelte das Gigaset wieder. Es war offenbar die alte Basisstation im Weg.
Ergebnis und Einschränkungen
Funktionierender Aufbau: Vodafone-Kabel → 6490 (DOCSIS/Router) → LAN → 6590 (IP-Telefonie/DECT) → Gigaset. Ein- und ausgehende Gespräche funktionieren. Dafür ist allerdings eine zweite Box im Dauerbetrieb nötig.
Nicht bewiesen ist, dass die fehlende IMPI-Trennung die einzige Ursache des ursprünglichen Fehlers auf der 6490 war. Ich hatte Firmware, Gerät und Netzwerktopologie verändert. Das Ergebnis belegt die funktionierende Kombination, nicht eine vollständig isolierte Root-Cause-Analyse.
Die internationale 6590 (Artikelnummer 20002820) direkt als DOCSIS-Kabelmodem bei Vodafone registrieren zu lassen, wäre ein separater Weg – mit zusätzlichem Aktivierungs- und Kompatibilitätsrisiko. Die funktionierende Internetverbindung wollte ich dafür nicht aufs Spiel setzen.
Fazit: Was mit neuen SIP-Zugangsdaten begann, endete mit einem erfolgreichen Firmware-Update über EVA und einer zweiten FRITZ!Box als Telefonanlage. Keine elegante Architektur, aber wieder ein funktionierendes Telefon. Die produktive 6490 blieb die ganze Zeit (bis auf die nicht erfolgreichen Tests) unangetastet.
Hinweis: Die verwendeten Screenshots wurden für diese Fassung redigiert. Flashen über EVA geschieht auf eigenes Risiko; ein falsches Image oder ein unterbrochener Schreibvorgang kann das Gerät unbrauchbar machen.
