Some insights from someone with the same Problem (Germany/Vodafone).

[ELRabito]

Hello, to start, I have no professional IT background, I just had alot of time, was very angry about vodafones lies, and made something like you on a much simpler scale with iPerf3.

Since Vodafone also claims "Everything is fine" even tho 3 technicians in my house measured the problem (SNR of 25 for some upstream channels, RPI, BER errors and DQI dropping from 10 to 0 and back etc (And much more).
Vodafone still claimed everything is fine, so I went full nerd/rage mode with help of AI, but don't blame me too early and look at these findings for my issue. Since I have a Vodafone station I get much less info out of your docsight, and it says my connection is fine.

1. Verification Vectors (iPerf3)

I can immediately reproduce this defect with the following commands:

A. Reference Test (No Fragmentation)
Isolates reachability without stressing the reassembly logic.

iperf3 -c speed1.fiberby.dk -p 9201 -u -b 80M -R -l 1472
Expected Result: ~0% Packet Loss.

B. Breakpoint Test (Forced Fragmentation)
Proves the physical defect by adding a single payload byte, forcing the stack to fragment.

iperf3 -c speed1.fiberby.dk -p 9201 -u -b 80M -R -l 1473
Expected Result: >50% Packet Loss (Complete Reassembly Failure).

C. Real-World Stress Test (Standard UDP 8k)
Simulates modern web traffic load with multiple fragments.
iperf3 -c speed1.fiberby.dk -p 9201 -u -b 80M -R
Expected Result: Massive Loss (25–60%), often causing the stream to collapse.

Why this matters for DOCSight:

Current monitors often rely on small packets (Pings/TCP ACKs). Integration of an Active Fragmentation Probe (UDP packets over Standard MTU) would allow DOCSight to detect physical line degradation (Ingress/Bad Amps) long before the modem actually loses sync.

I uploaded my current version of my tests here: https://github.com/ELRabito/Dr.Docsis

What do you think?

[itsDNNS]

Thanks for sharing this, really impressive analysis! The fragmentation boundary test (1472 vs 1473 bytes) is a clever way to prove reassembly failures that normal ping/TCP monitoring completely misses.

DOCSight approaches this from the passive side: we monitor your modem's signal metrics (SNR, modulation, FEC errors) and can now automatically trigger a Speedtest Tracker run when degradation is detected (Smart Capture, just shipped). So the correlation you're building manually (signal event to bandwidth impact) is something DOCSight can do automatically for the metrics it has access to.

That said, active fragmentation probing like yours fills a gap that passive monitoring can't cover. Rather than building it into DOCSight core (which would add external dependencies and change DOCSight's scope), here are two ideas:

Option A: Docker Sidecar
Package Dr.Docsis as a Docker container with a simple REST API. We could offer it as an optional sidecar alongside DOCSight. The two containers communicate via shared APIs: DOCSight triggers your fragmentation probe via Smart Capture when it detects signal degradation, and your tool pushes findings back for DOCSight to display in the correlation timeline.

Option B: DOCSight Community Module
DOCSight has a plugin-based module system (docsight-modules). You could build Dr.Docsis as a community module that integrates directly into DOCSight with its own collector, settings panel, and correlation data. This would give users a native experience without running a separate container. The module system supports custom collectors, routes, settings templates, and i18n out of the box.

Either way, a simple REST API on your side (trigger probe, return results) would be enough to start. Would you be interested in exploring one of these directions?

[ELRabito]

Thanks for the answer, I will look into it, expecting another lie call from Vodafone today.

"DOCSight approaches this from the passive side: we monitor your modem's signal metrics (SNR, modulation, FEC errors) and can now automatically trigger a Speedtest Tracker run when degradation is detected (Smart Capture, just shipped). So the correlation you're building manually (signal event to bandwidth impact) is something DOCSight can do automatically for the metrics it has access to."

The problem is my Vodafone station (Vodafone Station (TG3442DE)) doesn't even show FEC errors, upstream SNR is also hidden since the CMTS would have to transmit that to the modem. I doubt it's different for the upstream with Fritzboxes (as far as I could tell from interface screenshots).

I didn't enable all features yet (speedtest &BQM), since I'm new to docker etc. And already invested way too much time because of Vodafail xD

[itsDNNS]

Good catch on the Vodafone Station limitations. The TG3442DE does not expose FEC error counters or upstream SNR through its web interface, so DOCSight can only work with what the modem gives us: downstream SNR, power levels, and modulation. That means the error spike trigger and upstream-specific modulation tracking are effectively blind on your hardware.

For your specific situation (upstream ingress that the modem does not surface), the most useful DOCSight path right now would be the Connection Monitor module. It runs continuous ICMP/TCP probes to targets you define (your gateway, a public DNS, etc.) and detects packet loss and outages independently of what the modem reports. Smart Capture can trigger a speedtest on packet loss events, so you get the same automatic evidence chain without relying on modem-reported metrics.

That said, this is exactly where your fragmentation probe adds real value. The Vodafone Station hides the problem, standard pings do not catch it, but your 1472 vs 1473 byte test does. If you get the Docker container + API going, it would complement DOCSight nicely for Vodafone Station users specifically.

For the Docker/Speedtest setup: both are straightforward docker-compose additions. The wiki has a step-by-step for Speedtest Tracker if you want to get that running.

[itsDNNS]

We put together a Docker container for Dr.Docsis with a REST API: ELRabito/Dr.Docsis#1

It ports the core test logic (TCP single/multi, UDP fragmentation 1473B vs 1472B reference) to a headless Python container with a simple API (POST /api/run to trigger, GET /api/results for latest). Runs as non-root, multi-arch (amd64/arm64), pinned dependencies.

With this in place, the DOCSight integration path we discussed would work: Smart Capture detects signal degradation, triggers Dr.Docsis via the API, results flow back for correlation.

[ELRabito]

Great stuff!

https://www.vodafone.de/media/downloads/pdf/VF-DOCSIS-Interface-Specification-v1.06.pdf

Might be useful for you, in case you didn't know.

[ELRabito]

Looks like Docker is hiding the issue somehow (Maybe because WSL2), it says it's fine while I can see the issue in ping plotter and Powershell/iPerf3 version.
Had to increase the packetsize to 8192B to get different Results but even then its totally random compared to iPerf and i know my connection is bad, like super bad.

So virtualization is not working for this kind of test, probably because:

"Virtual Segmentation Offloading: When iperf3 sends a 8192B packet in the Docker container, it sends it to Windows via the virtual network stack. Since the connection between Docker and Windows is purely virtual (in RAM), there is no 1500B limit (MTU) there. The package is handed over as a single large piece.

The host takes over the work: First Windows (the host) has to send this package to the real Internet. Windows breaks it down into fragments. If these fragments die on the line, Docker often does not get that at all. UDP has no back channel for errors. Docker reports: "Package successfully passed to Windows!" while Windows outside on the cable despairs."

[itsDNNS]

That points to two things at once:

1. Docker bridge / WSL2 can absolutely distort the observed breakpoint because the packet path, MTU handling, offloading, and fragmentation behavior are not the same as on the native host.
2. The host-side 1472 vs 1473 behavior is still strong evidence that there is a real fragmentation / reassembly problem somewhere near the client-to-router path. That part is not explained away by Docker.

So I would treat bridge-mode container results as useful for experimentation, but not as forensic-grade proof.

For anything you want to use against the ISP, native host tests are the stronger reference. If Dr.Docsis documents a container path, --network=host should be the recommended option where available, because it gets closer to the real interface path.

Small caveat: on Docker Desktop / WSL2, --network=host is still not the same as Linux host networking on bare metal, so that should be called out explicitly.

[itsDNNS]

Thanks for the spec link! We just updated our VFKD threshold profile to reference the official Vodafone pNTP Interface Specification v1.06 instead of the community forum values. Also added separate OFDM (DOCSIS 3.1) SNR thresholds and corrected the downstream power critical limits to match the spec's absolute maximums.

544e97a