Unitymedia TC4400 ueber WebUI automatisiert beobachten

[sch4kal]

Das bekommt man doch auch schöner in Grafana hin...rrdtools ist so 90er-Style...

 

[Edding]

@sparkie

Das hier hatte ich mal gefunden DOCSIS-STATS

 

[sparkie]

ok, danke, das kenne ich schon. Aber ist noch etwas unvollstaendig... Irgendwie sollte es besser eine Komplettbeschreibung mit Installation der Treiber + Hardware sein. Durch den Modemwechsel funktionieren meine alten Scripte nur noch unvollstaendig. Deswegen dachte ich kann ich es gleich neu schreiben. Und anschliessend in den github kippen :smile:

 

[why_]

Es ist eigentlich dafuer vorgesehen demnaechst eine oeffentliche Version von Auslastung des eigenen Segments ansehen einzustellen. Nachdem es eine solche trotz vieler Ankuendigungen bis heute anscheinend nirgends gibt. Ich teste gerade schon eine Version mit einem Raspberry, einem Sundtek DVB-C USB Stick und natuerlich dem TC4400. Stay tuned :smile:

Ich habe auch schon mit dem Gedanken gespielt mir so einen Sundtek Stick zu holen, aber irgendwie scheint der nicht mit OFDM Kanälen zurecht zu kommen wenn ich das Richtig sehe und somit wäre nach DOCSIS 3.1 nutzlos? Hat da einer zufällig mehr Infos?

 

[sparkie]

am besten direkt hier nachfragen: Sundtek Support Forum - Treiber
die Entwicklung liest hier mit

 

[MartinP_Do]

Ich denke nicht, dass die USB-DVB-C Sticks für DOCSIS 3.1 nutzbar sein werden.

DOCSIS 3.0 ist so eng mit DVB-C verwandt - da überträgt man einen unveränderten Transportstream über mehrere komplett (was Kanalbreite und Modulation angeht) deckungsgleich mit DVB-C aufgebauten Kanäle. Der Inhalt des Transportstreams ist nur kein DVB-C Boucquet, sondern ein Docsis Datenstrom....

Der Aufbau der DOCSIS 3.1 Modulation unterscheidet sich so stark von aktuellem DVB-C, dass das nicht klappen wird, das in den Sticks rein per Treiber-Update abzufrühstücken ...

 

[Ool3eiV3aetooChu]

Hi,

ich hatte vor ein paar Tagen einen Nagios-Check geschrieben, der ähnlich wie hier im Thread beschrieben die Informationen des Modems auswertet.
Dabei wird geprüft:

• Connectivity, Boot, Configuration auf "OK"
• Security auf "Enabled"
• SNR pro channel
• receive level pro channel
• transmission level pro channel
• Verhältnis von Corrected Codewords zu Unerrored Codewords
• Verhältnis von Uncorrectable Codewords zu Unerrored Codewords

und als perfdata pro channel zurückgegeben:

• SNR
• receive level
• transmission level
• unerrored codewords
• corrected codewords
• uncorrectable codewords

Mir fehlen jetzt nur noch sinnvolle Werte für warn/crit.
Angedacht hatte ich:

• SNR: warn bei 31.5dB, crit bei 30dB
• receive level: warn bei 6dBmV, crit bei 9 dBmV
• transmission level: warn bei 36 dBmV, crit bei 30 dBmV
• corrected codewords zu unerrored codewords: ???
• uncorrectable codewords zu unerrored codewords ratio: ???

Meine Modemwerte sind sicherlich nicht repräsentativ:

• SNR zwischen 37.4dB und 39.1dB
• receive level zwischen 2.1dBmV und 7.2dBmV
• transmission level zwischen 51dBmV und 52dBmV
• corrected codewords … ratio zwischen 1.05% und 498.70%[1]
• uncorrectable codewords… ratio zwischen 0.00% und 0.02%

Was meint Ihr, könnte man hier sinnvoll monitoren?

Wenn der check fertig ist, geht's zu github o.ä.

- Philippe

___________________________________________________________
[1] ja, wirklich knapp 5x soviele corrected wie unerrored codewords:
channel 15: 150%
channel 16: 437%
channel 17: 669%
channel 18: 108%
channel 19: 498%
(edit: so nach reiflicher Überlegung glaube ich eher, daß hier ein Überlauf stattfand. Vielleicht ist es doch nicht so sinnvoll, das Verhältnis zu prüfen)

 

[Wechseler]

[No message]

 

[robert_s]

Mir fehlen jetzt nur noch sinnvolle Werte für warn/crit.
Angedacht hatte ich:

Besser nicht selbst etwas ausdenken, sondern die offiziellen Grenzwerte verwenden:

http://abload.de/image.php?img=cmwertepbkbz.jpg

Wobei Vodafone Kabel für den Upstream schon engere Grenzen gesetzt hat, für den Einsatz von DOCSIS 3.1 (bei unitymedia zwar derzeit nicht aktuell, aber dennoch):

Bei OFDM mit 256+ QAM (DOCSIS 3.1) im Upstream sind die Grenzen sogar noch enger: min. 103(43) bis 108(48) im Upstream-Pegel; manuelle Provi. bis max. 106(46).

 

[Ool3eiV3aetooChu]

Super, danke!

Das Feld mit den codewords läßt sich leider nicht so sinnvoll überwachen, weil hier offenbar ein 32bit counter überläuft (die Werte sehen verdächtig danach aus), und hacks mit Sichern der vorherigen Werte sind gruselig.
Dann gibt's hier halt keine warn/crits.

 

[sparkie]

zu einer ersten (pre alpha) Version habe ich es immerhin schon gebracht :zwinker:

docsis-cable-load-monitor: tool to monitor downstream load on docsis cable networks

man sieht die 2 Peaks, die entstehen, wenn ich mit meinen (noch) duerftigen 120Mbits/s einen Download starte. Aber man hat ja bald die 400Mbits/s so Pyur will

 

[rv112]

Respekt. Bin mal gespannt was Du noch so alles hin bekommst.

 

[Ool3eiV3aetooChu]

Ahoi,

wie versprochen sind der nagios-/icinga-/check_mk-/shinken-/younameit-check sowie das pnp4nagios-template jetzt auf github.

Viele Grüße

Philippe

 

[sparkie]

vielen Dank schon mal! Ich werde das heute abend testen :smile:
muss aber vorher noch ein kleines Problem in meinem 'cable load monitor' fixen..

 

[Benqer]

Kann man das dann noch irgendwie als Plugin für OPNsense machen?

https://github.com/opnsense/plugins

 

[sch4kal]

Kann man das dann noch irgendwie als Plugin für OPNsense machen?

https://github.com/opnsense/plugins

da würde es mehr Sinn machen, Grafana und Influx für OPNsense anzubieten, der Rest sind eig. nur Shellskripte.

 

[Benqer]

Okay, kann man ja mal bei Github als Vorschlag einreichen