Unitymedia TC4400 + pfSense nur < 30 Mbit download

[Andreas1969]

Habe mal ein neues Modem geordert - mal sehen ob das besser funktioniert.

Wo hast'n das geordert :kratz:
Es gibt doch keine mehr

 

[w00t]

Ich wollte eh zwei haben und habe daher schon am 07.01. bestellt und gestern wohl noch eins erwischt. Sorry ist noch früh, war etwas komisch formuliert.

 

[Andreas1969]

Ich wollte eh zwei haben und habe daher schon am 07.01. bestellt und gestern wohl noch eins erwischt. Sorry ist noch früh, war etwas komisch formuliert.

Na, da haste aber noch Schwein gehabt

 

[tobsen]

<i>
</i> "Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities r..." "TLV-11 - unrecognized OID;" "DHCP WARNING - Non-critical field invalid in response ;"

Der TLV-11 kommt von irgendeinem Held bei UM, der in die Configs eine OID eingetragen hat, die es in dem Baum vom TC gar nicht gibt und dann wird die ID einfach verworfen. Das ist nix schlimmes.
Die DHCP-Warning sollte eigentlich auch nicht das Problem sein. Deine pfSense wird im DHCP-Request irgendwas mitschicken, was dann dann als Invalid zurückkommt.. Hatte auch die Fehler bei den v6 Requests im Modem log.
Hatten ja schon festgestellt, dass IPv6 nicht so der beste Freund der deutschen KNBs ist :winken:

Wenn du schreibst, dass die Verbindung abbricht, bedeutet das dann, dass die Internetverbindung einbricht oder verliert das Modem den kompletten Sync?
Passiert der Internet-Einbruch bei bestehender und offener Verbindung?
Wenn ja, dann könnte es daran liegen, dass bei dir eine Node-Überlastung vorliegt und durch ein komisches Load-Balancing deine Verbindung auf einen anderen Node verschoben wird.. Naja dann brechen halt alle bestehenden Verbindungen weg..
Das Problem gabs bei mir 2013/2014 mal, wo es nur noch möglich war Emails mit Anhängen kleiner 200kb zu verschicken :wut:

 

[Andreas1969]

Der TLV-11 kommt von irgendeinem Held bei UM, der in die Configs eine OID eingetragen hat, die es in dem Baum vom TC gar nicht gibt und dann wird die ID einfach verworfen.

Die OID wird's aber im Baum von AVM geben :winken:
Denn UM führt / provisioniert das TC4400 ja als Fritzbox :zwinker:

 

[sch4kal]

Wenn ich deutsche KNB so mit US-amerikanischen vergleiche kommen unsere nicht so gut weg...ich mein wie viele CMs gibt es in den USA ? Für fast alle erhältlichen Geräte müssen Comcast, Roger Cable, Time Warner Cable etc. entsprechende Firmwarefiles inkl. DOCSIS MIBs vorhalten, und bei uns schaffen sie es gerade einmal 3 freie Modelle und eine handvoll Providergeräte zu managen :wand:

 

[Andreas1969]

Der TLV-11 kommt von irgendeinem Held bei UM, der in die Configs eine OID eingetragen hat, die es in dem Baum vom TC gar nicht gibt

Kannst ja mal schauen, was der Held da an falscher OID eingetragen hat.

Als Beispiel mal die "cust-own_200000_10000_dslite_sip_wifi-on.bin" welche UM auf kundeneigene Geräte schickt :zwinker:

eRouter_Operation_Mode eRouter_Initizalization_Mode_Encoding = 2
Maximum_Number_of_CPE's = 1
Network_Access = 1
SNMP_MIB_Object: docsDevSwAdminStatus [0] = 2
Baseline_Privacy Authorized_Wait_Timeout = 10 Re-Authorized_Wait_Timeout = 10 Authorized_Grace_Timeout = 600 Operational_Wait_Timeout = 10 Re-key_Wait_Timeout = 10 TEK_Grace_Time = 3600 Authorization_Reject_Wait_Timeout = 10 Sa_Map_Wait_Timeout = 1 Sa_Map_Max_Reties = 4
Privacy_Enable = 1
Upstream_Classification_Encoding Classifier_Reference = 5 Service_Flow_Reference = 3 Rule_Priority = 254 Classifier_Activation_State = 1 IPv6_Pack_Classif_Encodings IPv6_Destination_Address = 2A02:0908:000A:1000:0000:0000:0000:0000 IPv6_Destination_Prefix_Len = 64
Downstream_Classification_Encoding Classifier_Reference = 8 Service_Flow_Reference = 4 Rule_Priority = 254 Classifier_Activation_State = 1 IPv6_Pack_Classif_Encodings IPv6_TC_Range_&_Mask = 0x68 0xB8 0xFF IPv6_Next_Header_Type = 17
Downstream_Classification_Encoding Classifier_Reference = 10 Service_Flow_Reference = 4 Rule_Priority = 254 Classifier_Activation_State = 1 IP_Classification_Encoding Dest_Port_End = 5060 Dest_Port_Start = 5060 Source_Port_End = 5060 Source_Port_Start = 5060 IPv6_Pack_Classif_Encodings IPv6_Next_Header_Type = 17
Upstream_Service_Flow_Encoding Service_Flow_Reference = 1 QoS_Parameters_Set_Type = 0x07 Traffic_Priority = 0x00 Upstream_Maximum_Tarffic_Rate = 10496000 Max_Traffic_Burst = 8160 Max_Concatenated_Burst = 8160 Service_Flow_Scheduling_Type = 2 Request_Transmission_Policy = 0x00 0x00 0x00 0x00 IP_TOS_Overwrite = 0x00 0x00
Downstream_Service_Flow_Encoding Service_Flow_Reference = 2 QoS_Parameters_Set_Type = 0x07 Traffic_Priority = 0 Downstream_Maximum_Traffic_Rate = 225280000
Upstream_Service_Flow_Encoding Service_Flow_Reference = 3 QoS_Parameters_Set_Type = 0x07 Service_Flow_Scheduling_Type = 4 Upstream_Maximum_Tarffic_Rate = 358400 Max_Traffic_Burst = 3044 Max_Concatenated_Burst = 1522 IP_TOS_Overwrite = 0x00 0xB8 Request_Transmission_Policy = 0x00 0x00 0x00 0x1F Nominal_Polling_Interval = 20000 Tolerated_Poll_Jitter = 2000
Downstream_Service_Flow_Encoding Service_Flow_Reference = 4 QoS_Parameters_Set_Type = 0x07 Traffic_Priority = 5 Downstream_Maximum_Traffic_Rate = 358400 Max_Traffic_Burst = 3044
SNMP_MIB_Object: docsDevNmAccessIp [1] = 0.0.0.0
SNMP_MIB_Object: docsDevNmAccessIpMask [1] = 0.0.0.0
SNMP_MIB_Object: docsDevNmAccessCommunity [1] = 50.61.47.31.6A.33.39.4D.61.59.45.78.41.73.6C.35
SNMP_MIB_Object: docsDevNmAccessControl [1] = 3
SNMP_MIB_Object: docsDevNmAccessInterfaces [1] = 40
SNMP_MIB_Object: docsDevNmAccessStatus [1] = 4
SNMP_MIB_Object: docsDevNmAccessCommunity [2] = 38.72.4E.33.76.44.70.71.30.6D.38.4D.37.79.69.41
SNMP_MIB_Object: docsDevNmAccessControl [2] = 2
SNMP_MIB_Object: docsDevNmAccessInterfaces [2] = C8
SNMP_MIB_Object: docsDevNmAccessStatus [2] = 4
SNMP_MIB_Object: docsDevFilterLLCUnmatchedAction [0] = 1
SNMP_MIB_Object: docsDevFilterLLCIfIndex [1] = 0
SNMP_MIB_Object: docsDevFilterLLCProtocolType [1] = 1
SNMP_MIB_Object: docsDevFilterLLCProtocol [1] = 34525
SNMP_MIB_Object: docsDevFilterLLCStatus [1] = 4
SNMP_MIB_Object: docsDevFilterLLCIfIndex [2] = 0
SNMP_MIB_Object: docsDevFilterLLCProtocolType [2] = 1
SNMP_MIB_Object: docsDevFilterLLCProtocol [2] = 2048
SNMP_MIB_Object: docsDevFilterLLCStatus [2] = 4
SNMP_MIB_Object: docsDevFilterLLCIfIndex [3] = 0
SNMP_MIB_Object: docsDevFilterLLCProtocolType [3] = 1
SNMP_MIB_Object: docsDevFilterLLCProtocol [3] = 2054
SNMP_MIB_Object: docsDevFilterLLCStatus [3] = 4
CM_MIC = 0x16 0xC7 0xAC 0xC2 0xC1 0x54 0x97 0x8A 0xBA 0x90 0xCE 0xC5 0x0E 0x15 0xD4 0x09
CMTS_MIC = 0xC0 0x9B 0xF6 0xE2 0x25 0xAB 0x6E 0xFB 0xCF 0xCB 0x1C 0x28 0x30 0x44 0xC8 0x00

 

[w00t]

Wenn du schreibst, dass die Verbindung abbricht, bedeutet das dann, dass die Internetverbindung einbricht oder verliert das Modem den kompletten Sync?

Nur die Internetverbindung bricht ein.

Passiert der Internet-Einbruch bei bestehender und offener Verbindung?
Wenn ja, dann könnte es daran liegen, dass bei dir eine Node-Überlastung vorliegt und durch ein komisches Load-Balancing deine Verbindung auf einen anderen Node verschoben wird.. Naja dann brechen halt alle bestehenden Verbindungen weg..
Das Problem gabs bei mir 2013/2014 mal, wo es nur noch möglich war Emails mit Anhängen kleiner 200kb zu verschicken :wut:

Das passierte leider auch Nachts bei nur sehr geringer Nutzung der Leitung.

Was mich aber verwundert ist, wieso es mit der ConnectBox funktioniert...

 

[rv112]

Ich hab diese Fehler auch immer im Log. Ist normal.

 

[un1que]

Wenn du schreibst, dass die Verbindung abbricht, bedeutet das dann, dass die Internetverbindung einbricht oder verliert das Modem den kompletten Sync?

Nur die Internetverbindung bricht ein.

Schau mal ins Log der pfSense => DHCP und filter mal nach dhclient bei Prozessen. Wenn EXPIRE Einträge vorkommen und zu den Zeiten der Internetverbindungseinbrüche passen sollten, dann hätte ich womöglich eine Lösung.

 

[rv112]

Das habe ich auch. Wenn die IP expired werden ein paar Pakete gedropt. Denke dagegen ist nichts zu machen.

 

[un1que]

Nicht ganz bzw. offiziell (noch) nicht. Es gibt hier aber einen Patch und wenn ihr mal testet möchtet, nur zu (Feedback ist willkommen!):
https://forum.netgate.com/topic/121939/verbindungsabbr%C3%BCche/62

Dort hat @Rico eine gepatchte dhclient Datei zur Verfügung gestellt und damit sollte es (hoffentlich) funktionieren. Die dhclient kommt nach /sbin (Backup der originalen Datei nicht vergessen!) und dann müsste man noch die Rechte anpassen (555). Weiterhin beim WAN-Interface in der pfSense GUI "Advanced Configuration" anhaken, dann kommt bei "Option modifiers" noch folgendes rein: "supersede dhcp-server-identifier 255.255.255.255" (ohne Anführungszeichen). Zum Schluss das System rebooten.

Das Problem ist einfach, dass UM wohl auch beim DHCP Server was vermurkst hat und es nur mit diesem zusätzlichen Parameter funktionieren dürfte. Leider ist dieser kein Bestandteil bei FreeBSD und funktioniert somit nicht ohne weiteres bei pfSense. Hier ist es noch etwas genauer erklärt:
https://forum.netgate.com/topic/112869/dhclient-on-wan-occasionally-fails-to-renew-lease-with-cable-isp

 

[rv112]

Habe es mal getestet, aber ohne Reboot. Normal müsste es ja klappen nachdem der Service und WAN neugestartet wurden. Möchte die Sense ungern neustarten aktuell. Ich berichte, danke! :winken:

 

[rv112]

Also bei mir scheint es zu funktionieren. Bekomme nun keinen EXPIRE mehr.

Jan 19 06:15:49	dhclient	78299	bound to 37.49.xxx.xxx -- renewal in 1800 seconds.
Jan 19 06:15:49	dhclient	Creating resolv.conf
Jan 19 06:15:49	dhclient	RENEW
Jan 19 06:15:49	dhclient	78299	DHCPACK from 10.124.224.1
Jan 19 06:15:49	dhclient	78299	DHCPREQUEST on igb0 to 255.255.255.255 port 67

 

[addicted]

Joa, klappt, weil der UM DHCP-Server nicht auf Unicast reagiert bzw. diese Pakete nicht zu ihm vordringen.
Mit der Multicast-Adresse geht es durch.
Ich hatte das damals mit ebtables (für ethernet multicast) und iptables mangle gelöst.

 

[sch4kal]

Laut RFC 2131 ist es dem DHCP-Server gestattet, mit der Interface-IP zu antworten, über die die Anfragen des DHCP-Relay rein gekommen sind.
Nach 4.3.6 ist eine DHCPREQUEST-Nachricht des Clients im RENEW-State grundsätzlich eine Unicast-Nachricht, zumindest bis T2 abläuft. Meine Vermutung: der Relay verhält sich falsch, denn der antwortet nicht auf Unicast-Anfragen, die laut RFC so ankommen müssen:

At time T1 the client moves to RENEWING state and sends (via unicast)
a DHCPREQUEST message to the server to extend its lease.[...]The
client MUST NOT include a 'server identifier' in the DHCPREQUEST
message.[...]

aus Abschnitt 4.4.5 Reacquisition and expiration

D.h., der o.g. Patch verletzt eig. die RFC, genauso wie das Verhalten des Relays nicht RFC-Konform ist.

Auf Seite 35 des Standards sieht man übrigens genau anhand des State-Transition Diagramms wie lange eure Internetverbindung weg ist, nämlich solange, bis T2 abläuft.

 

[rv112]

UM verletzt öfters mal die RFC, war ja bei IPv6 bei mir auch so bis sie es wohl gefixt haben indem mir das Prefix entzogen wurde und nur durch ändern der DUID wieder zugeteilt.

 

[un1que]

Hört sich ja super an, dass es bei euch läuft! Meine ist jetzt auch seit knapp über 3 Tagen online und ohne expired Einträge.

Joa, klappt, weil der UM DHCP-Server nicht auf Unicast reagiert bzw. diese Pakete nicht zu ihm vordringen.
Mit der Multicast-Adresse geht es durch.
Ich hatte das damals mit ebtables (für ethernet multicast) und iptables mangle gelöst.

Ist bei dir auch eine pfSense im Einsatz, addicted?

Ich frage deshalb, weil diese Problematik eigentlich schon vor fast 2 Jahren lokalisiert wurde und an pfSense gemeldet wurde. Da sie aber das meiste von FreeBSD unverändert übernehmen, wurde man entsprechend dorthin verwiesen. Daraufhin wurde die Problematik auch an FreeBSD gemeldet und es gab auch einen Patch.
Da es jedoch so wenig Feedback gab, wurde die Sache wohl nicht mit entsprechend hoher Priorität behandelt und wie ihr seht, ist bis heute nichts passiert.

Ich würde vorschlagen, dass wir mal bei FreeBSD etwas mehr Schwung in den Bugreport bringen und den von @Rico aus dem pfSense Forum bereitgestellten Patch einbringen, sowie unsere positiven Erfahrungen kundtun sollten, in der Hoffnung, dass die Sache bald auch offiziell übernommen wird. Da würde ich mich insbesondere bei dir @addicted freuen, wenn du mitmachst, da du sehr viel Ahnung und technisches Verständnis hast.

 

[addicted]

Nee, ich habe nen selbstgebauten Linux-Router. Da gibt's kein Webinterface und ich kann meinen DHCP-Client selbst bestimmen
Ich habe leider aktuell auch keinen Zugriff auf einem UM-Anschluss mehr, so dass ich keine pcaps bereitstellen könnte, an denen man das Verhalten genauer analysieren kann. Ich kann gerne meine Einschätzungen hier im Forum dazu schreiben, aber darüber hinaus nicht weiterhelfen.

 

[sch4kal]

Hört sich ja super an, dass es bei euch läuft! Meine ist jetzt auch seit knapp über 3 Tagen online und ohne expired Einträge.

Joa, klappt, weil der UM DHCP-Server nicht auf Unicast reagiert bzw. diese Pakete nicht zu ihm vordringen.
Mit der Multicast-Adresse geht es durch.
Ich hatte das damals mit ebtables (für ethernet multicast) und iptables mangle gelöst.

Ist bei dir auch eine pfSense im Einsatz, addicted?

Ich frage deshalb, weil diese Problematik eigentlich schon vor fast 2 Jahren lokalisiert wurde und an pfSense gemeldet wurde. Da sie aber das meiste von FreeBSD unverändert übernehmen, wurde man entsprechend dorthin verwiesen. Daraufhin wurde die Problematik auch an FreeBSD gemeldet und es gab auch einen Patch.
Da es jedoch so wenig Feedback gab, wurde die Sache wohl nicht mit entsprechend hoher Priorität behandelt und wie ihr seht, ist bis heute nichts passiert.

Ich würde vorschlagen, dass wir mal bei FreeBSD etwas mehr Schwung in den Bugreport bringen und den von @Rico aus dem pfSense Forum bereitgestellten Patch einbringen, sowie unsere positiven Erfahrungen kundtun sollten, in der Hoffnung, dass die Sache bald auch offiziell übernommen wird. Da würde ich mich insbesondere bei dir @addicted freuen, wenn du mitmachst, da du sehr viel Ahnung und technisches Verständnis hast.

Nochmal, laut den Infos die hier im Thread zugänglich sind verhält sich pfSense standardkonform, der UM DHCP-Relay jedoch nicht. Der Patch macht aus deinem ISC dhclient einen unkonformen Klumpen Software.

 

[Andreas1969]

Ich habe leider aktuell auch keinen Zugriff auf einem UM-Anschluss mehr, so dass ich keine pcaps bereitstellen könnte, an denen man das Verhalten genauer analysieren kann.

Glasfaser ha'ste ja erst im Herbst :zwinker:
Mmh, ich frage mich gerade, wie Du aktuell Online bist :kratz:

 

[addicted]

Krüppel-DSL natürlich. Ab Februar angeblich Vectoring. Abwarten.

 

[Andreas1969]

Krüppel-DSL natürlich.

Vermutlich bei der Telekom :kratz: :mussweg:

 

[addicted]

Anschluss ja, aber Zugang über einen Reseller, weil kürzere Vertragslaufzeit.

 

[un1que]

Nee, ich habe nen selbstgebauten Linux-Router. Da gibt's kein Webinterface und ich kann meinen DHCP-Client selbst bestimmen
Ich habe leider aktuell auch keinen Zugriff auf einem UM-Anschluss mehr, so dass ich keine pcaps bereitstellen könnte, an denen man das Verhalten genauer analysieren kann. Ich kann gerne meine Einschätzungen hier im Forum dazu schreiben, aber darüber hinaus nicht weiterhelfen.

Alles klar, danke für die Rückmeldung.

Nochmal, laut den Infos die hier im Thread zugänglich sind verhält sich pfSense standardkonform, der UM DHCP-Relay jedoch nicht. Der Patch macht aus deinem ISC dhclient einen unkonformen Klumpen Software.

Ich bin mir jetzt gerade nicht sicher, ob ich dich richtig verstehe, aber ich meine, dass mit dem Patch selbst nichts kaputtgemacht wird. Es soll lediglich dem Nutzer die Möglichkeit gegeben werden den Parameter "server identifier" nutzen zu können. Der Parameter wird mit dem Patch ja nicht automatisch gesetzt, sondern das erledigen die betroffenen Nutzer über das pfSense GUI selbst.
Im Moment ist es halt so, dass dieser Parameter seitens pfSense nicht gedeutet werden kann, da eben keine Funktionsweise im dhclient hinterlegt ist.