Hacker News Reader

Comment by jimrandomh | Hacker News Reader

tl;dr: The Intel Puma 6 and Puma 7 chipsets have a performance issue in a part of the packet processing that is specific to TCP/IP, which went undetected for awhile because "ping" packets are not TCP/IP. Modems that use the affected chipset will have high jitter under load (especially load consisting of many short connections), and will suffer denial of service when sent traffic with many different port numbers. Additionally, under a previous firmware (but according to a commenter on https://www.reddit.com/r/news/comments/7fjvvt/hundreds_of_mi... not on the most recent firmware), a timed process would briefly block throughput every 2 seconds, adding to jitter issues. DSLReports has created a tool which checks for this at http://www.dslreports.com/tools/puma6 .

View on HN

Does anyone here know why these modems even care about TCP/IP or ICMP or any other protocol higher than the network and physical layers? I could go read the DOCSIS spec in detail, but thought these operated at a similar layer to Ethernet (OSI layers 1 and 2.)

Maybe it does NAT in hardware.

Most modern networking chips for NICs implement TCP/IP checksum offload, sometimes segmentation/fragmentation offload/reassembly

They dont, This TLDR is wrong.

Puma 5 shipped with just enough resources for 8 downstream channels. Puma 6 has same resources, but 16 downstream channels. Bottleneck is in hardware accelerating packet decoding/assembly, queue/buffer is too shallow and more packets in flight result in stalls. You can disable this hardware block and magically modem stops being susceptible to DOS, but max throughput goes down to ~60Mbit (opposed to theoretical ~800Mbit with ~2Mbit DOS potential)

There are people with Puma 6 with ISP using only 6 downstream channels and their modems work just great. 8 is barely acceptable (even puma 5 has problems on the test and can be DOSed by ~10Mbit), 16 is just plan broken.

DOCSIS "modems" are layer 3 devices as well actually.

The DOCSIS standard requires filtering by IP address and port [1] built in to the modem, instead of at the CMTS. This is back-asswards, as a hacked modem can ignore the filtering, but it's part of the spec.

There are multiple sources of jitter in the puma 6/5: more channels = more jitter, more flows = more jitter/complete failure at ~2000 separate active flows in a 1 second period.

[1]: http://www.cable-europe.eu/wp-content/uploads/bsk-pdf-manage... - Annex F Protocol Filtering (Normative)

>>> Does anyone here know why these modems even care about TCP/IP or ICMP or any other protocol higher than the network and physical layers?

IP is the network layer. Can't route packets without it.

I was under the impression that most rigorous network measurement tests used TCP (e.g. traceroute -T) because it was well-known that routers and other network devices along the path often had a separate fastpath for ICMP traffic.

It initially affected TCP, UDP and ICMP. After a firmware "fix", it doesn't affect ICMP but still affects TCP and UDP.

> and will suffer denial of service when sent traffic with many different port numbers.

Yup, I've had this happen WAY to frequently with the DG1670 CableOne forced me to switch to (and I literally have no option for other equipment, they require this specific modem for anyone with a static IP). The modem will literally lose connection and reset itself when under load (which takes upwards of 10 minutes to boot), if I could put my old SBG6850 back in place I would do so in a heartbeat.

Reply on news.ycombinator.com