Neighbourhood upgraded, speed unchanged?

My neighborhood underwent maintenance on August 8, and since then my DOCSIS 3.1 modem (Arris S34) now shows an OFDMA upstream channel in addition to the SC-QAM upstream channels, so it appears my node has been upgraded.

However, I’m still only seeing approximately 41 Mbps upstream and ~420 Mbps downstream on a 1 Gig plan.

I’ve already power-cycled the modem after the maintenance so it could re-range and download a fresh configuration file.

Signal levels look healthy, with downstream MER around 41–43 dB and upstream transmit power around 38–40 dBmV.

Any idea of what to do next?

I contacted support (web chat) and they were just doing the most stupid tier 1 script asking the most basic things and the person on the other end probably didn't even know what DOCSIS was and kept asking me things like "if you open a web browser can you load a webpage eg. xfinity.com" ?

Like YES I CAN LOAD A WEB PAGE, my question is about the speed of connection (or lack thereof) since I never get close to 1gig down and my upstream is still molasses despite neighbourhood upgrades and now getting OFDMA upstream and OFDM PLC downstream channels that I did not used to get.

Do I just need to wait longer for mid-split/high-split upgrades to continue to roll out, or what?

Responses

Oldest First

Selected Oldest First

martinm1

Visitor

•

5 Messages

12 days ago

I've been getting IPv6 for like the 12 years I've been a comcast customer, and, for the past ~5ish years that i've had a Mikrotik router I've been able to get v6 but it recently stopped working. (Not 100% sure when, only noticed today when trying to test connectivity to a GUA v6 address.)

[admin@router.vp] /ipv6/dhcp-client> export terse
# 2026-08-11 18:40:04 by RouterOS 7.23.1
# software id = XZS1-LYCT
#
# model = C53UiG+5HPaxD2HPaxD
# serial number = REDACTED
/ipv6 dhcp-client add add-default-route=yes interface=ether1 pool-name=comcast-ipv6 pool-prefix-length=64 prefix-hint=::/60 request=address,prefix use-peer-dns=no
[admin@router.vp] /ipv6/dhcp-client> print
Columns: INTERFACE, STATUS, REQUEST
# INTERFACE  STATUS        REQUEST
0 ether1     searching...  address
                           prefix
[admin@router.vp] /ipv6/dhcp-client>

Anyone have any idea?

Note: This comment was created from a merged conversation originally titled Not getting v6 anymore?

martinm1

Visitor

•

5 Messages

RE IPv6 no longer working, it seems it WAS related to the neighbourhood upgrade and I figured it out.

Details:

# Heads up: DHCPv6 prefix delegation now comes from a global address, not link-local

Posting in case others lost IPv6 recently on a third-party router.

Residential Comcast, third-party router (MikroTik in my case, but this would hit anyone running OPNsense, pfSense, OpenWrt or similar). IPv6 had worked for years, then went dead sometime around Aug 8-12 with no change on my end. IPv4 stayed perfectly fine.

## What changed

DHCPv6 replies used to come from the CMTS relay's link-local address. Mine was `fe80::201:5cff:fe6f:9646`, an ARRIS S34.

They now come from a **global** address instead: `2001:558:4000:35::10`, arriving with hop-limit 63, meaning it was routed to me rather than delivered on-link. The relay behavior changed; the server itself is now answering me directly.

Packet capture, for anyone who wants to confirm on their own line:

    Solicit    ->  ff02::1:2
    Advertise  <-  2001:558:4000:35::10   (hop limit 63)

## Why that breaks things

Two ways.

**1. Firewall rules.** Lots of router firmware ships a default rule that only permits inbound DHCPv6 (udp/546) from `fe80::/10`, because that is where these replies have always come from. A reply from a global source does not match, gets dropped, and the DHCPv6 client never sees it. Symptom is the client stuck searching forever while a packet capture plainly shows Comcast answering. I lost about a week to this.

**2. Default route.** Many clients derive the IPv6 default route from the DHCPv6 server address, which works fine when that server is the on-link relay. Now it points at a remote global address that is not on-link, so the route installs but never becomes active. You get a delegated prefix and still no connectivity. The actual on-link gateway is whatever is sending router advertisements on the WAN, which for me is a different device entirely (`fe80::21c:73ff:fe00:99`, an Arista).

## Also worth knowing

Comcast hands back a prefix delegation only. No IA_NA, and no status code option saying why. If your router requests both an address and a prefix, it may reject the whole reply rather than take the prefix. Requesting the prefix only is the correct setting.

## Fixes

Both are on the customer side, since Comcast is not going to revert this:

- Allow inbound udp/546 from any source on the WAN interface, not just from link-local.
- Do not derive the default route from DHCPv6. Point it at the link-local of whatever is sending RAs on your WAN, or let the RA install it.

Everything works normally after that. Getting a /60, four /64s carved out of it, full connectivity.

Is this change intentional and permanent? Would be good to know before people start replacing hardware over it.

(edited)

10 days ago

XfinityEva

Official Employee

•

2.6K Messages

10 days ago

Hi and thank you for taking the time to reach out about these updates! It's exciting to have these new speeds as part of your plan. Construction, activation, provisioning, and speed-profile deployment don't always happen simultaneously so this may still be ongoing. Have you received a notification that the work has been completed?

We also recommend checking out and signing up for speed upgrade updates here.

Your Home Network

martinm1

Neighbourhood upgraded, speed unchanged?

martinm1

martinm1

XfinityEva

New to the Community?