Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[tq1199]

trace.jpg

OK, das geht dann mit Layer 2. Mit "arp -av" / "ip n s" sollte man das Modem dann auch im arp-cache deiner pfsense sehen.

 

[Andreas1969]

Letztendlich stellt sich für mich jetzt nur noch eine Frage:

Warum kommt @nts aus seinem Netz heraus auf´s Web IF und auf den Spectrum Analyzer des Modems,
bei mir erreiche ich aber nur den Spectrum Analyzer, nicht aber das Web IF :kratz:
Um das Web-If aufzurufen muß ich mit einem Rechner mit fester IP (192.168.100.x) direkt an den zweiten WAN Port des Modems.
Ist für mich momentan noch unlogisch.
An der FritzBox und dem dort eingestellten Subnetz liegt es jedanfalls nicht.
Habe es auch schon mal mit einem ganz anderen Router und ganz anderem Subnetz getestet, aber kein Unterschied, selbiges Verhalten.

Meine Vermutung geht jetzt dahin:
An meinem Anschluß ist grundsätzlich was Faul (CMTS Seitige Kundenanschlusskonfiguration)
Mein altes Modem reagiert halt nach einigen Stunden Betrieb mit heftigen Latenzproblemen darauf (bei addicted und MichaelBre und 2 weiteren UM-Kunden passiert das aber nicht)
Und das TC4400 reagiert halt mit der Nichterreichbarkeit des Web_if´s aus meinem Netzwerk darauf, läuft aber ansonsten fehlerfrei.
Damit kann ich leben, komme ja über den zweiten WAN-Port auf´s Web-IF

Na, keiner ne Idee, oder liege ich hier mit meiner Vermutung goldrichtig :zwinker:

 

[tq1199]

Letztendlich stellt sich für mich jetzt nur noch eine Frage:

Warum kommt @nts aus seinem Netz heraus auf´s Web IF und auf den Spectrum Analyzer des Modems,
...

Na, keiner ne Idee, ...

Sind die Modems identisch (Bezugsquelle, Firmware, ...)?

 

[rv112]

trace.jpg

OK, das geht dann mit Layer 2. Mit "arp -av" / "ip n s" sollte man das Modem dann auch im arp-cache deiner pfsense sehen.

Im ARP Table ist die 192.168.100.1 nicht aufgeführt.

 

[Andreas1969]

Sind die Modems identisch (Bezugsquelle, Firmware, ...)?

Jo, sind sie :winken:

 

[tq1199]

Im ARP Table ist die 192.168.100.1 nicht aufgeführt.

Auch dann nicht, wenn Du unmittelbar vorher, von der pfsense einen erfolgreichen Ping auf die IP-Adresse 192.168.100.1 gemacht hast?

 

[#DiRK]

Nun der Router weiß aber ...

Routenverfolgung zu 192.168.100.1 über maximal 30 Hops 1 <1 ms <1 ms <1 ms pfsense.networks [192.168.1.1] 2 <1 ms <1 ms <1 ms 192.168.100.1
Ablaufverfolgung beendet.

Wie sieht es aus, wenn Du direkt auf deiner pfsense ein traceroute an die IP-Adresse 192.168.100.1 machst?

trace.jpg

Interessant. Kannst du bitte mal die Routing Tabelle deiner pfSense posten? Ich glaube, "netstat -rn"

 

[rv112]

Im ARP Table ist die 192.168.100.1 nicht aufgeführt.

Auch dann nicht, wenn Du unmittelbar vorher, von der pfsense einen erfolgreichen Ping auf die IP-Adresse 192.168.100.1 gemacht hast?

<i>
</i>[2.4.2-RELEASE][[email protected]]/root: ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=0.657 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.724 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.628 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=0.714 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=0.626 ms
^C
--- 192.168.100.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.626/0.670/0.724/0.042 ms
[2.4.2-RELEASE][[email protected]]/root: arp -a
? (10.0.0.1) at xx:xx:xx:xx:xx:xx on re2.100 permanent [vlan]
xxx (192.168.1.105) at xx:xx:xx:xx:xx:xx on re2 expires in 1144 seconds [ethernet]
xxxs (192.168.1.10) at xx:xx:xx:xx:xx:xx on re2 expires in 1196 seconds [ethernet]
xxx (192.168.1.1) at xx:xx:xx:xx:xx:xx on re2 permanent [ethernet]
xxx (192.168.1.60) at xx:xx:xx:xx:xx:xx on re2 expires in 1195 seconds [ethernet]
xxx (192.168.1.113) at xx:xx:xx:xx:xx:xx on re2 expires in 1170 seconds [ethernet]
xxx (192.168.1.17) at xx:xx:xx:xx:xx:xx on re2 expires in 1180 seconds [ethernet]
xxx (192.168.1.18) at xx:xx:xx:xx:xx:xx on re2 expires in 1173 seconds [ethernet]
xxx (192.168.1.53) at xx:xx:xx:xx:xx:xx on re2 expires in 20 seconds [ethernet]
xxx (192.168.1.20) at xx:xx:xx:xx:xx:xx on re2 expires in 90 seconds [ethernet]
xxx(192.168.1.150) at xx:xx:xx:xx:xx:xx on re2 expires in 1174 seconds [ethernet]
HSI-KBW-134-xxx-xxx-xxx.hsi14.kabel-badenwuerttemberg.de (134.xxx.xxx.xxx) at xx:xx:xx:xx:xx:xx on re1 permanent [ethernet]
HSI-KBW-134-3-212-1.hsi14.kabel-badenwuerttemberg.de (134.3.212.1) at xx:xx:xx:xx:xx:xx on re1 expires in 1192 seconds [ethernet]

Interessant. Kannst du bitte mal die Routing Tabelle deiner pfSense posten? Ich glaube, "netstat -rn"

Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 134.3.212.1 UGS re1
10.0.0.0/24 link#9 U re2.100
10.0.0.1 link#9 UHS lo0
127.0.0.1 link#4 UH lo0
134.3.212.0/22 link#2 U re1
134.xxx.xxx.xxx link#2 UHS lo0
192.168.1.0/24 link#3 U re2
192.168.1.1 link#3 UHS lo0
192.168.3.0/24 192.168.3.2 UGS ovpns1
192.168.3.1 link#10 UHS lo0
192.168.3.2 link#10 UH ovpns1

re1 ist WAN, re2 LAN.

Mit dem Ping Diagnosetool kann ich die Quelle auswählen. Setze ich dort WAN und pinge eine LAN IP, läuft dieser Ping ins Leere. Pinge ich die 192.168.100.1 erhalte ich Antwort. Demnach geht der Ping definitiv direkt ans Modem über die WAN Schnittstelle.

PING 192.168.100.1 (192.168.100.1) from 134.xxx.xxx.xxx: 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=0.769 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.885 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.599 ms
--- 192.168.100.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.599/0.751/0.885/0.117 ms

 

[addicted]

Für das EPC3212 hab ich damals explizit eine Interface-Route (also mit ARP) 192.168.100.1/32 auf wan gesetzt, dann ging das, das Modem hat auf den ARP-Request geantwortet.
Bei meinem aktuellen Gerät (wie Andreas mit NDA) antwortet das Modem nur auf ARP, solange es keine Config gezogen hat. Nach dem Aktivieren einer Docsis-Config benötige ich einen statischen ARP-Eintrag.
Allerdings greift sich das Modem auch so alle Pakete, die an 192.168.100.1 gehen, d.h. wenn ich diese Adresse auf dem Router gemäß der default-Route behandle, klappt das auch, obwohl das Paket auf Ethernet-Ebene eigentlich an den UM-Nexthop (CMTS-Mac) geht. Ganz schön grauenvoll.

 

[rv112]

Mein default Gateway bekomme ich von UM zugeteilt (134.3.212.1 CMTS?). Ansonsten habe ich keine statischen Routen oder sowas gesetzt.

Ich habe hier etwas Interessantes dazu gelesen:

I'd occasionally wondered the same thing myself. I can also access my cable modem (192.168.100.1) from my LAN (192.168.1.x) without having to specify a static route.

On one hand this makes sense as all non-local traffic will go out through the default gateway. On the other hand 192.168.100.1 is a "non-routable" private address.

I had assumed that as 192.168.100.1 was "non-routable", traffic destined for it would not be forwarded to the WAN interface of the router. Having read RFC 1597 (http://www.faqs.org/rfcs/rfc1597.html) it appears to be the job of the destination router to reject the incoming traffic; "Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks". -- So that makes sense now.

Quelle: https://www.snbforums.com/threads/router-wan-port-passing-out-private-ip.23213/

 

[#DiRK]

Für das EPC3212 hab ich damals explizit eine Interface-Route (also mit ARP) 192.168.100.1/32 auf wan gesetzt, dann ging das, das Modem hat auf den ARP-Request geantwortet.
Bei meinem aktuellen Gerät (wie Andreas mit NDA) antwortet das Modem nur auf ARP, solange es keine Config gezogen hat. Nach dem Aktivieren einer Docsis-Config benötige ich einen statischen ARP-Eintrag.
Allerdings greift sich das Modem auch so alle Pakete, die an 192.168.100.1 gehen, d.h. wenn ich diese Adresse auf dem Router gemäß der default-Route behandle, klappt das auch, obwohl das Paket auf Ethernet-Ebene eigentlich an den UM-Nexthop (CMTS-Mac) geht. Ganz schön grauenvoll.

Ich pflichte dir bei. Eigentlich sollte das Modem auf Layer 3 nichts zu suchen haben. D.h. alle Pakete unabhängig von der IP-Zieladresse durchleiten.

Dennoch besteht das Dilemma, dass das Modem für evtl. Konfigurationen via HTTP erreichbar sein möchte (dann logischerweise auf Layer 3 und Layer 4). Somit "fischt" es sich alle Pakete an "seine" (fiktive) IP-Adresse raus und beantwortet diese. Dazu muss der Router natürlich auch die RFC1918 Netze routen (was eigentich nicht sein sollte). Dies ist ein m.E. ein "dreckiger" Hack den die Hersteller da machen, statt es "sauber " über ein eigenes Management LAN oder VLAN zu spielen.

 

[tq1199]

Mein default Gateway bekomme ich von UM zugeteilt (134.3.212.1 CMTS?). Ansonsten habe ich keine statischen Routen oder sowas gesetzt.

Ich habe hier etwas Interessantes dazu gelesen:

Das trifft m. E. hier für die (direkte) Kommunikation zwischen deiner pfsense (nicht als Router betrachtet) und deinem Modem (IP 192.168.100.1), nicht zu, ... denn es findet ja kein Routing statt bei dem das gateway (IP 134.3.212.1) oder die pfsense-Firewall eine Rolle spielen könnte. Die Datenpakete gehen nicht bzw. kommen gar nicht bis zum gateway (IP 134.3.212.1).

Die Frage ist doch, welche Art der Verbindung besteht _netzwerktechnisch_ betrachtet, zwischen deiner pfsense und deinem Modem?

 

[rv112]

Was genau meinst Du? Das Modem hängt direkt an der pfSense (re1). Aus der pfSense kommt dann via re2 der Switch. re1 ist dabei als WAN IPv4 DHCP konfiguriert, und re2 als LAN IPv4 Static 192.168.1.0/24.

 

[tq1199]

Was genau meinst Du?

Ich meine, dass zwischen deinem Modem (IP 192.168.100.1) und deiner pfsense (IP <WAN IP>), netzwerktechnisch auf die gleiche Art und Weise eine Verbindung zustande kommt wie z. B. in der FritzBox zwischen den Schnittstellen mit den IP-Adressen 192.168.178.1 und 192.168.180.1 (oder 192.168.180.2).
Es spielt keine Rolle welche IP-Adresse diesen Schnittstellen zugewiesen ist (... wenn diese IP-Adressen nicht mehrfach zugewiesen sind bzw. gültig sind).

 

[#DiRK]

Im ARP Table ist die 192.168.100.1 nicht aufgeführt.

Auch dann nicht, wenn Du unmittelbar vorher, von der pfsense einen erfolgreichen Ping auf die IP-Adresse 192.168.100.1 gemacht hast?

<i>
</i>[2.4.2-RELEASE][[email protected]]/root: ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=0.657 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.724 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.628 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=0.714 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=64 time=0.626 ms
^C
--- 192.168.100.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.626/0.670/0.724/0.042 ms
[2.4.2-RELEASE][[email protected]]/root: arp -a
? (10.0.0.1) at xx:xx:xx:xx:xx:xx on re2.100 permanent [vlan]
xxx (192.168.1.105) at xx:xx:xx:xx:xx:xx on re2 expires in 1144 seconds [ethernet]
xxxs (192.168.1.10) at xx:xx:xx:xx:xx:xx on re2 expires in 1196 seconds [ethernet]
xxx (192.168.1.1) at xx:xx:xx:xx:xx:xx on re2 permanent [ethernet]
xxx (192.168.1.60) at xx:xx:xx:xx:xx:xx on re2 expires in 1195 seconds [ethernet]
xxx (192.168.1.113) at xx:xx:xx:xx:xx:xx on re2 expires in 1170 seconds [ethernet]
xxx (192.168.1.17) at xx:xx:xx:xx:xx:xx on re2 expires in 1180 seconds [ethernet]
xxx (192.168.1.18) at xx:xx:xx:xx:xx:xx on re2 expires in 1173 seconds [ethernet]
xxx (192.168.1.53) at xx:xx:xx:xx:xx:xx on re2 expires in 20 seconds [ethernet]
xxx (192.168.1.20) at xx:xx:xx:xx:xx:xx on re2 expires in 90 seconds [ethernet]
xxx(192.168.1.150) at xx:xx:xx:xx:xx:xx on re2 expires in 1174 seconds [ethernet]
HSI-KBW-134-xxx-xxx-xxx.hsi14.kabel-badenwuerttemberg.de (134.xxx.xxx.xxx) at xx:xx:xx:xx:xx:xx on re1 permanent [ethernet]
HSI-KBW-134-3-212-1.hsi14.kabel-badenwuerttemberg.de (134.3.212.1) at xx:xx:xx:xx:xx:xx on re1 expires in 1192 seconds [ethernet]

Interessant. Kannst du bitte mal die Routing Tabelle deiner pfSense posten? Ich glaube, "netstat -rn"

Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 134.3.212.1 UGS re1
10.0.0.0/24 link#9 U re2.100
10.0.0.1 link#9 UHS lo0
127.0.0.1 link#4 UH lo0
134.3.212.0/22 link#2 U re1
134.xxx.xxx.xxx link#2 UHS lo0
192.168.1.0/24 link#3 U re2
192.168.1.1 link#3 UHS lo0
192.168.3.0/24 192.168.3.2 UGS ovpns1
192.168.3.1 link#10 UHS lo0
192.168.3.2 link#10 UH ovpns1

re1 ist WAN, re2 LAN.

Mit dem Ping Diagnosetool kann ich die Quelle auswählen. Setze ich dort WAN und pinge eine LAN IP, läuft dieser Ping ins Leere. Pinge ich die 192.168.100.1 erhalte ich Antwort. Demnach geht der Ping definitiv direkt ans Modem über die WAN Schnittstelle.

PING 192.168.100.1 (192.168.100.1) from 134.xxx.xxx.xxx: 56 data bytes
64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=0.769 ms
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.885 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.599 ms
--- 192.168.100.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.599/0.751/0.885/0.117 ms

Lt Routing Tabelle gehen alle Pakete für 192.168.100.0/24 an das Default Gateway beim ISP (134.xxx.xxx.xxx). Das Modem sollte das Paket transparent durchleiten und dann spätestens das Gateway beim ISP das Paket verwerfen. Vermutlich ist es so wie addicted erklärte hat: das Modem "fischt" sich die Pakete mit Zieladresse (192.168.100.0/24) raus und beantwortet sie.

 

[rv112]

Ja, das kann gut sein.

 

[Conan179]

Wieso wird eigentlich so ein Geheimnis um den Namen eines "anderen Modems" gemacht? Muss man das verstehen?

Verschwiegenheitserklärung :winken:

:glück: Ok du darfts nicht drüber reden, aber dauernd werbung dafür machen, ist erlaubt, muss ich mir merken

 

[tq1199]

Vermutlich ist es so wie addicted erklärte hat: das Modem "fischt" sich die Pakete mit Zieladresse (192.168.100.0/24) raus und beantwortet sie.

Das könnte man testen bzw. feststellen ob es so ist, in dem man temporär ein geeignetes Gerät, bei dem die default route gelöscht ist (... d. h. keine Angaben zum default gateway vorhanden sind) mit dem Modem verbindet und anschließend von diesem Gerät einen Ping auf die IP-Adresse 192.168.100.1 macht.

 

[MichaelBre]

:glück: Ok du darfts nicht drüber reden, aber dauernd werbung dafür machen, ist erlaubt, muss ich mir merken

Wer macht denn hier Werbung?
Kennst du den Hersteller oder den Namen des Produkts?
Nein, also wie kommst du auf die Idee mit der Werbung?
:kratz:

 

[Conan179]

Er sagt immer, "ich hab ein modem, darf aber nicht sagen vom wem und warum"
Wen man ihn dan fragt, was für eins, kommt er (richtiger weise) mit der "Verschwiegenheitserklärung".
was bringt es also ständig drauf rum zu reiten, das er ein modem (oder router) hat, wen er eh (angeblich) nicht reden darf?
darauf bezog ich mich.

 

[MichaelBre]

Zwischen drüber reden und Werbung machen ist aber ein ziemlich großer Unterschied.
Ich habe diese besagte Modem ebenfalls im Einsatz.
Habe ich jetzt Werbung gemacht? Nein.
Werbung ist eine Bekanntmachung für ein Produkt oder eine Dienstleistung.

Andreas hat nunmal als einziger unserer Testgruppe massive Probleme beim Einsatz des Modems erlebt. Diese Probleme könnten bei einem Marktstart auch bei zig anderen Anwendern auftreten.
Sowas sollte vor einem offiziellen Marktstart schon ausreichend getestet sein.

Sei doch froh das es einen Hersteller gibt der ernsthaft an einem deutschen Marktstart eines reinen Modem arbeitet.

 

[Conan179]

Habe ich jetzt Werbung gemacht? Nein.

tja , ich rede nicht von diesem ominösem modem sondern nur von der "Verschwiegenheitserklärung"

Andreas hat nunmal als einziger unserer Testgruppe

und der einziger der oft hier im forum was drüber fallen läst.

Na wer von eurer Testgruppe geht noch hausieren mit: "ich nutzte ein modem zu hause, darf aber nicht sagen welches ätsch"?

 

[why_]

Ist die IPv6 Adresse die ihr vom Modem bekommt von Außen erreichbar? Falls nicht wird das Modem eine Firewall haben und ist eigentlich nutzlos bis man die Zugangsdaten fürs Webinterface hat, ein ähnliches Problem gab es doch bei den Fritzboxen bei Prefix delegation auch (hier war allerdings ein Firmware update nötig weils ein AVM seitiger Bug war).

Hat das mal einer mit IPv6 und TC4400 getestet?

 

[Andreas1969]

Habe ich jetzt Werbung gemacht? Nein.

tja , ich rede nicht von diesem ominösem modem sondern nur von der "Verschwiegenheitserklärung"

Andreas hat nunmal als einziger unserer Testgruppe

und der einziger der oft hier im forum was drüber fallen läst.

Na wer von eurer Testgruppe geht noch hausieren mit: "ich nutzte ein modem zu hause, darf aber nicht sagen welches ätsch"?

Hallo Conan179, was ist Dir denn für ne Laus über die Leber gelaufen :kratz:
Hast Du vielleicht das Weihnachtsfest nicht verkraftet :winken:

Ich versuche hier lediglich Aufklärungsarbeit zu leisten :winken:
Was sollen die anderen Tester denn posten, wenn das "ominöse Modem" bei Ihnen ohne Ausfallerscheinungen läuft :kratz:
Sei froh, daß ich das tue, ansonsten wäre das Modem vielleicht schon längst im freien Verkauf.
Und wenn Du das dann kaufen würdest und hättest auch diese Probleme, dann wäre das Geschrei verdammt groß.
Ich bin bemüht, ein Modem zu finden, womit alle potentiellen Nutzer glücklich und zufrieden werden. :winken:
Und das TC 4400 sieht da momentan total vielversprechend aus. :super:

Ich bin an dieser Thematik schon seit einem Jahr dran, also erzähle mir da nichts von "Na wer von eurer Testgruppe geht noch hausieren mit: "ich nutzte ein modem zu hause, darf aber nicht sagen welches ätsch"?"

Na denn, Dir auch frohe Weihnachten

 

[rv112]

Der Hitergrund dass ihr sowas wie Produkttester für ein neues Modem seid, hat mir schon gereicht das zu erklären
warum man nichts sagen darf.

Das mit dem Defaultgateway werde ich testen!

Schöne und besinnliche Weihnachten :winken:

Nachtrag:

Vermutlich ist es so wie addicted erklärte hat: das Modem "fischt" sich die Pakete mit Zieladresse (192.168.100.0/24) raus und beantwortet sie.

Das könnte man testen bzw. feststellen ob es so ist, in dem man temporär ein geeignetes Gerät, bei dem die default route gelöscht ist (... d. h. keine Angaben zum default gateway vorhanden sind) mit dem Modem verbindet und anschließend von diesem Gerät einen Ping auf die IP-Adresse 192.168.100.1 macht.

Ich habe nun kein Defaultgateway mehr eingetragen, komme dennoch auf das Modem.