Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[sch4kal]

Das Problem ist nicht der Weg zum Modem, sondern der Rückweg. Am Besten mit Wireshark mal nachschauen.
Ich muss jedenfalls eine DNAT Regel erstellen damit ich die Antwort des TC4400 bekomme. Danach kam ich zu jeder Tages- und Nachtzeit auf das WebIF/Spectrum Analyzer.

 

[Phase]

Bei uns war diese Nacht Analogabschaltung und Vodafone hat Docsis 3.1 mit aufgeschaltet

 

[Andreas1969]

Bei uns war diese Nacht Analogabschaltung und Vodafone hat Docsis 3.1 mit aufgeschaltet

Saubere Leitungswerte :zwinker:
Und, macht sich das irgendwie bemerkbar :kratz:
- Bessere Latenz?
- keine Speed Einbrüche Abends?

 

[omodebach]

Habe gerade mal wieder hier reingeschaut und gesehen, dass das Thema Zugriff auf das Webinterface über das WAN-Interface eines Routers immer noch aktuell ist. Hier mal kurz mein Kenntnisstand zu diesem Thema:

Das Problem ist nicht der Weg zum Modem, sondern der Rückweg. Am Besten mit Wireshark mal nachschauen.

Das trifft es wohl schon ziemlich gut. Ich denke beim Thema Nichterreichbarkeit des Webinterfaces kommen zwei Probleme in Frage:

• Zum Einen sollte ein "vernünftiger" Router keine RFC1918-Adressen in's Internet routen, sondern verwerfen. Fritzboxen tun das jedoch nicht, sondern routen die über das WAN-Interface raus und verlassen sich drauf, dass der nächste Router sie verwirft. Somit sollte das Modem eigentlich über das WAN-Interface erreichbar sein.

• Dass es trotzdem nicht erreichbar ist, liegt, wie @sch4kal schon richtig mutmaßt, am Rückweg, denn offensichtlich ist bei Fritzboxen (und wohl auch etlichen anderen Routern) das Reverse Path Filtering aktiv. Kurz gefasst sorgt das dafür, dass auf einem Interface Pakete von IP-Adressen verworfen werden, die über dieses Interface nicht erreichbar sind.

Mich hat auch genervt, dass ich über meine FB das Modem zwar pingen, aber das Web-IF nicht erreichen konnte. Also habe ich mir mal einen kleinen Linux-Router gebastelt, in der Annahme die FB sei doof und damit würde es gehen. Und was passierte? Genau, gleiches Verhalten wie bei der FB. Also kurz recherchiert und dann bin ich relativ schnell über diese Thematik, über die ich mir vorher noch nie Gedanken gemacht hatte, gestolpert.

Zitat von https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt:

rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path
Each incoming packet is tested against the FIB and if the interface
is not the best reverse path the packet check will fail.
By default failed packets are discarded.
2 - Loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet's source address is also tested against the FIB
and if the source address is not reachable via any interface
the packet check will fail.

Also kurzerhand mal ein

echo 0 > /proc/sys/net/ipv4/conf/<Interface-Name>/rp_filter

gemacht und schon war auch das Webinterface des TC4400 über das WAN-Interface meines Linux-Routers erreichbar.

Lange Rede, kurzer Sinn: mit geschlossenen Kisten (Fritzbox o.ä.) wird auch weiterhin das Webinterface nicht erreichbar sein, da lässt sich auch nichts zusammenbasteln. Auf OpenWRT und Konsorten wird man es wohl hinbekommen, das kann ich aber mangels Ressourcen nicht testen. pfSense werde ich mir bei Gelegenheit nochmal diesbezüglich anschauen, auch habe ich aktuell Zugriff auf einen Ubiquiti ER-8, mal sehen, was der dazu sagt.

 

[Andreas1969]

Lange Rede, kurzer Sinn: mit geschlossenen Kisten (Fritzbox o.ä.) wird auch weiterhin das Webinterface nicht erreichbar sein, da lässt sich auch nichts zusammenbasteln

Komisch ist nur, dass es nur beim TC4400 nicht funktioniert.
Sobald ich ein anderes Modem benutze, ist dessen WEB IF aus dem Netzwerk der Fritzbox heraus unter 192.168.100.1 erreichbar :winken: :kratz:
Irgendetwas macht das TC4400 also anders, als andere Modems.

Ist aber auch egal, dafür ist es ja unter der 10er IP erreichbar. :zwinker:

 

[hdtrhdyghtr]

Ich habe bei meinem EdgeRouter jetzt eine zweite IP Adresse aus 192.168.100.0/24 wie hier beschrieben konfiguriert: https://community.ubnt.com/t5/EdgeRouter/Cant-put-DHCP-client-and-static-ip-on-the-same-interface/m-p/1366538#M81172
Leider reicht das immer noch nicht, mein Router schickt ARP-Requests für 192.168.100.1 auf dem Interface raus. Die Requests bleiben unbeantwortet. Würde es hier reichen, die automatisch generierte Route zu 192.168.100.0/24 zu entfernen?

 

[omodebach]

Komisch ist nur, dass es nur beim TC4400 nicht funktioniert.
Sobald ich ein anderes Modem benutze, ist dessen WEB IF aus dem Netzwerk der Fritzbox heraus unter 192.168.100.1 erreichbar :winken: :kratz:

Kann ich so nicht bestätigen. Habe noch mit einem Vigor 130 DSL-Modem das exakt gleiche Verhalten wie beim TC4400 nachstellen können

Ist aber auch egal, dafür ist es ja unter der 10er IP erreichbar. :zwinker:

Das ist aber nur bedingt hilfreich, wenn man die DOCSIS-Parameter monitoren möchte und dazu alle 5 Minuten die entsprechende Seite aufruft, um dort die Infos raus zu parsen. Die Management-IP macht dann irgendwann dicht. Ich vermute, dass BPI/SEC eine Attacke erkennt und dann blockt. Dann hilft nur ein Neustart des Modems. Über die 192.168.100.1 funktioniert das jedoch dauerhaft einwandfrei, so dass ich auf deren Erreichbarkeit angewiesen bin.

 

[Andreas1969]

Kann ich so nicht bestätigen. Habe noch mit einem Vigor 130 DSL-Modem das exakt gleiche Verhalten wie beim TC4400 nachstellen können

Trotzdem komisch, bei meinem alten Modem konnte ich jederzeit aus dem Fritzbox Netzwerk heraus auf's Web IF unter der 192.168.100.1 zugreifen, sogar von Extern über das Fritzbox VPN :kratz:

 

[rv112]

Vernünftige Router routen sehr wohl RFC1918 Adressen an das Standardgateway. Die Frage ist was man als Standardgateway definiert. Ist es das von UM, wird dort hin geroutet. pfSense bekommt das out of the box sauber hin. Sowohl mit dem TC4400 als auch dem Vigor 130. nur bei Dual WAN muss man natürlich aufpassen welches Gateway man nutzt.

 

[robert_s]

Erklärungen, warum es generell nicht funktionieren kann, sind offensichtlich keine Erklärungen dafür, warum es beim TC4400 mit der 33er Firmware noch ging und mit der 40er Firmware nicht mehr.

 

[rv112]

Was passiert denn bei denen wo es nicht geht wenn sie einen Rechner mit fester 192.168.100.1 an den WAN Anschluss hängen. Ist der erreichbar? Reverse NAT?

 

[HandyMast]

So habe das Modem jetzt man direkt an einen W10 Rechner mit Wireshark gehängt.
Modem bootet und hat noch keine INet Verbindung:
W10 Rechner bekommt 192.168.100.10 und WebIf ist erreichbar und Modem pingbar

Modem ist mit dem CTMS Verbunden:
W10 Rechber bekommet öffentliche IP. Ab dann ist das Modem nicht mehr erreichbar (ICMP und 80). Auch warten bringt nichts.

Zusätzlich Adresse 192.168.100.10 manuell auf dem IF angelegt:
Keine Änderung. Im Wireshark fällt auf, dass keine Ping Pakete zum Modem rausgehen. Ein arp -a zeigt dass die MAC Adresse vom Modem nicht ermittelt werden kann

Statische MAC-IP Bindung <ModemEthernetMac> <-> 192.168.100.1 in Windows hinterlegt.
Modem ist zwar nicht pingbar ABER das Webif ist erreichbar.

Wieder Router angeschlossen:
Dort war die zusätzliche statische Adresse 192.168.100.10 auf dem WAN IF bereits vorhanden.
Habe dann wieder das statische MAC-IP Bindung eingetragen und auch damit ist zumindest das WebIf aus meinem ganzen Netzwerk erreichbar. Warum ICMP nicht funktioniert ist mir ein Rätsel - aber für mich nicht so schlimm. :hirnbump:


Hoffe das Hilft auch anderen. :super:


LG

H:M

 

[hdtrhdyghtr]

Vielen Dank an alle, die Tips posten!

Kann man die entsprechende MAC-Adresse des Modems auch Remote herrausfinden? Ich habe leider zur Zeit keinen physischen Zugriff auf die Sticker am Modem.

 

[HandyMast]

Modem Reset und dann mit arp -a nachschauen welche Mac mit 192.168.100.1 gebunden ist. Währenddessen ist das MOdem natürlich noch offline. Man hat also nur ca. eine Minute Zeit nach dem Modem Reset.
Ob das für dich überhaupt Sinn macht kannst du prüfen wenn du in den arp Cache von deinem Router guckst. Wenn dort die 192.168.100.1 vorhanden ist liegt ein anderes Problem vor.

 

[hdtrhdyghtr]

Modem Reset und dann mit arp -a nachschauen welche Mac mit 192.168.100.1 gebunden ist. Währenddessen ist das MOdem natürlich noch offline. Man hat also nur ca. eine Minute Zeit nach dem Modem Reset.
Ob das für dich überhaupt Sinn macht kannst du prüfen wenn du in den arp Cache von deinem Router guckst. Wenn dort die 192.168.100.1 vorhanden ist liegt ein anderes Problem vor.

Das wird schwierig wenn ich remote mit meinem Router verbunden bin :zwinker:
Dann warte ich bin heute Abend und werde dann von meinen Erfahrungen berichten. Auf jeden Fall ist in meinem Router keine MAC-Adresse für 192.168.100.1 vorhanden und die entsprechenden ARP Requests laufen ins Leere.

 

[HandyMast]

Schön zu hören dass ich nicht alleine bin...
Dann haben die wo es funktioniert wohl einen sehr ausdauernden arp cache ;-)

 

[quietsche]

Das wird schwierig wenn ich remote mit meinem Router verbunden bin :zwinker:

Klappt schon wenn der Router eine Shell und screen hat wie mein TO und dann halt automatisiert abfragen.
Ich habe zwar (noch) kein TC4400 laufen, aber ein Hitron CDA-32372 auf 192.168.100.1 (mit arp-Eintrag),
und habe einfach ein neue IP (SW Interface) auf meine eth1 (HW Interface) gelegt mit 192.168.100.2.

 

[hdtrhdyghtr]

Das wird schwierig wenn ich remote mit meinem Router verbunden bin :zwinker:

Klappt schon wenn der Router eine Shell und screen hat wie mein TO und dann halt automatisiert abfragen.
Ich habe zwar (noch) kein TC4400 laufen, aber ein Hitron CDA-32372 auf 192.168.100.1 (mit arp-Eintrag),
und habe einfach ein neue IP (SW Interface) auf meine eth1 (HW Interface) gelegt mit 192.168.100.2.

Leider habe ich keine Möglichkeit das Modem aus der Entfernung neuzustarten. Bevor ich da extra meinen Laptop, das Modem neustarte und die MAC-Adresse auslese: Findet man die MAC-Adresse auch irgendwo anders (Aufkleber o.ä.)? Ist das die gleiche MAC Adresse wie die, die man bei der Freischaltung angeben muss?

 

[rv112]

Nein, die ist anders.

 

[robert_s]

Also hat das TC4400 bis zur 33er Firmware bei etablierter Kabelverbindung noch auf arp-Requests für seine LAN-Adresse geantwortet, aber mit der 40er Firmware nicht mehr? Bug oder Feature...

 

[Phase]

Saubere Leitungswerte :zwinker:
Und, macht sich das irgendwie bemerkbar :kratz:
- Bessere Latenz?
- keine Speed Einbrüche Abends?

Bis jetzt konnte ich noch keine Veränderungen feststellen. Mit Speedeinbrüchen hatte ich zum Glück noch nie Probleme :super:

 

[Antennenkabel]

Hallo!

Eine Frage hätte ich noch bzgl. des Webinterfaces. Unter 192.168.100.1 lässt es sich nicht mit den im Internet angegebenen Anmeldedaten (user/password) darauf zugreifen.

Weiß jemand Rat?

Vielen Dank für die Hilfe und beste Grüße
Antennenkabel

 

[nts]

Versuch's mit denen hier: https://www.cable-wiki.xyz/index.php/Technicolor_TC4400#Webinterfaces

 

[Antennenkabel]

Versuch's mit denen hier: https://www.cable-wiki.xyz/index.php/Technicolor_TC4400#Webinterfaces

Super! Klappt wunderbar, vielen, vielen Dank!

 

[hdtrhdyghtr]

Leider klappt der Zugriff auf das Webinterface auch mit statischen ARP-Eintrag nicht:

root@ubnt:~# arp -a
[...]
? (192.168.100.1) at 00:10:95:xx:xx:xx [ether] PERM on peth2
[...]
root@ubnt:~# tcpdump -i eth2 -en host 192.168.100.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
08:47:00.094395 66:02:25:xx:xx:xx > 00:10:95:xx:xx:xx, ethertype IPv4 (0x0800), length 98: 192.168.100.10 > 192.168.100.1: ICMP echo request, id 22704, seq 1, length 64
08:47:01.101792 66:02:25:xx:xx:xx > 00:10:95:xx:xx:xx, ethertype IPv4 (0x0800), length 98: 192.168.100.10 > 192.168.100.1: ICMP echo request, id 22704, seq 2, length 64
08:47:02.101694 66:02:25:xx:xx:xx > 00:10:95:xx:xx:xx, ethertype IPv4 (0x0800), length 98: 192.168.100.10 > 192.168.100.1: ICMP echo request, id 22704, seq 3, length 64
[...]
5 packets captured
6 packets received by filter
0 packets dropped by kernel

Nebenbei habe ich auf einer anderen Konsole "ping 192.168.100.1" ausgeführt. Alle Befehle laufen direkt auf dem EdgeRouter, der mit dem Modem verbunden und online ist.

Mein Vorgehen war folgendes:

1. Pseudo-Interface peth2 anlegen, da das WAN Interface eth2 nicht gleichzeitig eine DHCP-IP und eine statisch konfigurierte haben kann.

2. peth2 mit 192.168.100.10/24 konfiguriert

3. Statischen ARP-Eintrag der Modem-MAC beim booten hinzugefügt

Habe ich noch irgendewas übersehen oder vergessen?