Multiple times daily connection drop - CMSTATUS:DS_Diplexer_Mode_Change_Ignored

Hello, @user_a316b8 Thank You for taking the time to reach out to Xfinity Support, here on the Community Forum. If you are still experiencing this issue, please send our team a direct message with your full name and full address. Thanks!

To send a "Direct Message" message:

• Click "Sign In" if necessary

• Click the "Direct Messaging" icon at the top of the page (looks like a text bubble)

• Click the "New message" (pencil and paper) icon

• Type "Xfinity Support" in the "To:" line and select "Xfinity Support" from the drop-down list which appears. The "Xfinity Support" graphic replaces the "To:" line

• Type your message in the text area near the bottom of the window

• Press Enter to send it

I am having the exact same issue.  Support is telling me the only thing they can/will do is send a tech to check my home (wiring, etc) and the time will be billable.

This is not an issue in my home;  my modem is not able to pull an IP address from Comcast's DHCP server(s) when the dropouts are occurring.  The outside interface on my modem is getting the address 192.168.100.10 while the problem is happening.

I'm near Lancaster, PA.

Sorry in advance for the wall of text that follows. I am interested in this because I also have a Motorola MB8611 and noticed numerous posts from other MB8611 owners with sudden reboot issues. I've been an Xfinity customer now for 3 whole weeks! (Before that, I was a Verizon Fios customer for over a decade.) I am using that modem and my own Linux-based router. My concern was when or if this was going to happen to me. After some research, I am sure it's a matter of when rather than if.

First, some disclaimers. I am not a networking engineer or expert. I have bachelor's and master's degrees in software engineering, four decades of software development experience, and three decades of home networking, starting with dial-up, DSL, Fios, and now, cable. All of the home network experience uses a Linux-based firewall of some sort. That said, I know some network engineering experts (who claim not to be, but are). I understand roughly 20% of what they say when talking about a complicated network strategy, so I know I am not one of them.

I started to dig into this a bit more to see what I could find. First, I tried to demystify the log messages. I was surprised by how much there was to find. There is a whole lot that goes on inside a DOCSIS cable modem. Most documents relating to the DOCSIS standards can be found on CableLabs website. My first question was, what does something like "CMSTATUS:US_Diplexer_Mode_Change:Fixed Initial, 5-42MHz" mean? CMSTATUS is pretty easy - Cable Modem Status. The first two characters in US_Diplexer_Mode_Change can be broken down as US for upstream and DS for downstream. The diplexer in the cable modem is the component that provides frequency-division multiplexing. That divides frequency bands into channels like the ones on the Connection status page. The diplexer is reconfigurable as to which frequency ranges are in use and which are assigned as channels for downstream and upstream. "Mode_Change" probably means those are in the process of being changed. The only thing I could find about what "Fixed Initial" means is that it likely refers to the dynamic contention algorithm in use. (That determines how the cable modem behaves if it attempts to send data upstream that collides with another cable modem's attempt to do the same. Only one cable modem can send upstream data at a time.) Finally, "5-42MHz" sets the 5-42MHz range for the upstream channels. That is older DOCSIS settings for upstream, which is what I believe is being replaced. Newer upstream settings would have 5-85MHz (or more). 

Interestingly, other messages in the event log have "CMSTATUS:US_Diplexer_Mode_Change:TLV-21.1, 5-85MHz" in them, which seems to refer to the newer upstream settings. Therefore, my next question was, what does "TLV" mean? A search for those led me to the Cable Modem Operations Support System Interface Specification CM-SP-CM-OSSIv3.1-I23-220819, which is available on the CableLabs website. In addition to TLV-21.1, I saw things like TLV-21.2, TLV-21.3, and TLV-84.2 in the event log you initially published. I thought they were something like power settings, but they are not. TLV stands for Type, Length, and Value (or Tag, Length, and Value). The explanation proves I'm not a network expert, as that's the basis for every message sent on the Internet. (The types being TCP, UDP, ICMP, etc., the length is part of the header, and the value is the data itself.) The DOCSIS specification (since the original 1.0) uses TLV "encoded" values for configuring and managing network equipment.

The document Data-Over-Cable Service Interface Specifications (CM-SP-MULPIv3.1-I24-221019), Section 6.4.28.1.20, Diplexer Band Edge, describes TLV-21.1 as having a one-byte code that defines the upstream upper band edge (and lists what the values equate to in MHz), 21.2 for specifying the downstream lower band edge, and 21.3 for specifying the downstream upper band edge. (I assume the upstream lower band edge is always "fixed" at 5 MHz, so no configuration is needed to set it.) Those are in relation to sending the configuration in a MAC Domain Descriptor (MDD) message. Those messages are sent periodically on all downstream channels. As long as the cable modem can lock onto one downstream channel after rebooting/power cycling, it should get those messages (about every 200 Msec). What's also interesting is that this functionality seems to be duplicated by TLV-84.1, 84.2, and 84.3 found in Section C.1.2.23, Diplexer Band Edge. I believe the difference is that the 84.x TLVs are specific to initializing a cable modem using a configuration file. (Section C.1.2 is Configuration-File-Specific Settings.) I think that occurs when the cable modem is initially powered on or rebooted. The analogous settings in the MDD message could make adjustments later -- maybe.

The "maybe" comes from the following sentences in Section C.1.2.23, Diplexer Band Edge, where "CM" is the abbreviation for Cable Modem.

"If the Diplexer Band Edge TLVs are included in the configuration file, the CM MUST use these TLVs to configure its diplexer settings. If present in the configuration file, the Diplexer Band Edge TLVs are used instead of the Upstream Frequency Range TLV or the Diplexer Band Edge TLVs in the MDD message. If the Diplexer Band Edge TLVs are not included in the configuration file, the CM configures its diplexer setting based on the values in the MDD message."

The problem is that we don't have the configuration file, nor do we likely have a good way to get it. It probably does not traverse the CM.

With that out of the way, we look at your log. It starts off with lines like the following (I added the row numbers):

1. Time Not Established   Critical (3)   SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=[Edited: "Personal Information"];CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.1;

2. Time Not Established   Critical (3)   CMSTATUS:DS_Diplexer_Mode_Change_Ignored:TLV-21.2, 258MHz.

3. Time Not Established   Critical (3)   CMSTATUS:DS_Diplexer_Mode_Change_Ignored:TLV-21.3, 1002MHz.

4. Time Not Established   Critical (3)   CMSTATUS:US_Diplexer_Mode_Change:TLV-21.1, 5-85MHz.

5. Time Not Established   Critical (3)   CMSTATUS:DS_Diplexer_Mode_Change_Ignored:TLV-84.2, 108MHz.

6. Time Not Established   Critical (3)   CMSTATUS:DS_Diplexer_Mode_Change_Ignored:TLV-84.3, 1002MHz.

7. 01:43:19 Mon Dec 26 2022 Critical (3)   CMSTATUS:US_Diplexer_Mode_Change:TLV-84.1, 5-42MHz.

8. 01:43:19 Mon Dec 26 2022 Critical (3)   CMSTATUS:DS_Diplexer_Mode_Change_Ignored:TLV-21.2, 258MHz.

9. 01:43:19 Mon Dec 26 2022 Critical (3)   CMSTATUS:DS_Diplexer_Mode_Change_Ignored:TLV-21.3, 1002MHz.

10. 01:43:19 Mon Dec 26 2022 Critical (3)   CMSTATUS:US_Diplexer_Mode_Change_Ignored:TLV-21.1, 85MHz.

11. 01:43:22 Mon Dec 26 2022 Critical (3)   UCD invalid or channel unusable;CM-MAC=[Edited: "Personal Information"];CMTS-MAC=[Edited: "Personal Information"];CM-QOS=1.1;CM-VER=3.1;

12. 01:43:23 Mon Dec 26 2022   Critical (3)   No Ranging Response received - T3 time-out;CM-MAC=[Edited: "Personal Information"];CMTS-MAC=[Edited: "Personal Information"];CM-QOS=1.1;CM-VER=3.1;

13. 01:43:33 Mon Dec 26 2022 Critical (3)   CMSTATUS:DS_Diplexer_Mode_Change_Ignored:TLV-84.2, 108MHz.

14. 01:43:33 Mon Dec 26 2022 Critical (3)   CMSTATUS:DS_Diplexer_Mode_Change_Ignored:TLV-84.3, 1002MHz.

The general consensus I found when looking into SYNC Timing Synchronization failure, is that it is almost always an issue on the cable modem/customer side. It could be wiring issues that keep the CM from syncing with the Xfinity time server. It could also be an improper configuration. It looks to me like a lot of configuration changes are being attempted. Many are ignored. I'm leaning toward bad configuration as the issue. Lines 2 and 3 indicate updates from the MDD that were ignored. If the CM is behaving properly and got a configuration from a file at startup, it should be ignored, according to the statement above. However, in line 4, the upstream diplexer mode change appears to have been accepted, and the upstream range was set to 5 - 85 MHz. Lines 5 and 6 indicate changes from the configuration file were ignored. Since these come from a configuration file (the 84.x TLVs indicate this), the CM was probably restarted. Without a time reference, it is hard to tell. In this case, I wonder if the updated values were ignored because that is what they were already set to use. Just because 2, 3, 5, and 6 all say "ignored" doesn't mean they were ignored for the same reason.

It would be nice if the MB8611 log displayed the time, even if not "official," instead of "Time Not Established." It would be helpful, even if it starts at Unix epoch time to have an idea of the time between messages. The official time comes from a time server on Xfinity's network. Since only one cable modem can send data upstream at a time, it's important that each CM knows when it is time to do so. That requires precise timing, or there will be upstream collisions, and the traffic has to be retransmitted. I get that, but the MB8611 must have an onboard real-time clock. (The Arris S33 appears to do this. There are messages in that CM's error log with times of 31/12/1969 17:00:24. It's wrong, but at least it's a running time.)

Line 7 shows the upstream upper band edge set to 5-42MHz - the older upstream settings. Lines 8, 9, and 10 show the MDD band edge settings for upstream and downstream being ignored as the specification says they should be if the values had been previously set in a configuration file delivered when the CM started up.

Lines 11 and 12 are generally caused by issues with the CM communicating upstream. The configuration of the CM is probably not what Xfinity was expecting, so the messages either don't arrive or are dropped. Lines 13 and 14 looks like the issues have started to repeat.

Another thing I found when looking into this is that the issue is not only with the MB8611. I saw posts for Arris SB33 and Netgear CM1100 with similar issues. 

If you read any documents, you might run across Cable Modem Termination System or CMTS. This is Xfinity's hub site or headend. As an end user, it is Xfinity.

I was also curious about what log levels there are. Section 8.1.2.3 of the Cable Modem Operations Support System Interface Specification (CM-SP-CM-OSSIv3.1-I23-220819) has those. It goes into detail, but the basic list is as follows:

8.1.2.3 Standard DOCSIS events for CMs

The DOCS-CABLE-DEVICE-MIB [RFC 4639] defines 8 priority levels and a corresponding reporting mechanism for each level.

Emergency event (priority 1)
Reserved for vendor-specific 'fatal' hardware or software errors that prevent normal system operation and cause
the reporting system to reboot.

Every vendor may define their own set of emergency events. Examples of such events might be 'no memory
buffers available', 'memory test failure', etc.

Alert event (priority 2)
A serious failure, which causes the reporting system to reboot, but it is not caused by hardware or software
malfunctioning.

Critical event (priority 3)
A serious failure that requires attention and prevents the device from transmitting data, but could be recovered
without rebooting the system. Examples of such events might be configuration file problems detected by the
modem or the inability to get an IP address from the DHCP server.

Error event (priority 4)
A failure occurred that could interrupt the normal data flow, but will not cause the modem to re-register. Error
events could be reported in real time by using the trap or syslog mechanism.

Warning event (priority 5)
A failure occurred that could interrupt the normal data flow, but will not cause the modem to re-register.
'Warning' level is assigned to events that both CM and CMTS have information about. To prevent sending the
same event, both from the CM and the CMTS, the trap and syslog reporting mechanism is disabled by default
for the CM for this level.

Notice event (priority 6)
The event is important, but is not a failure and could be reported in real time by using the trap or syslog
mechanism. For a CM, an example of a Notice event is any event from 'SW UPGRADE SUCCESS' group.

Informational event (priority 7)
The event is of marginal importance, and is not failure, but could be helpful for tracing the normal modem
operation.

Debug event (priority 8)
Reserved for vendor-specific non-critical events.

I don't think anything is wrong with your modem or wiring. I think the following is occurring:

• Xfinity notes that the updated and additional upstream channels have not yet been applied to this modem.
• Xfinity attempts to reconfigure the upstream channels to add the new channels via MDD.
• The configuration file Xfinity sends to the modem via MDD conflicts with the configuration file's configuration.
• The modem is not updating to the new configuration because the specification says it should not.
• The CMTS (Xfinity) commands the modem to restart because the CMTS assumes the changes were applied (or notices they were not and wants to restart it to try again).
  • (I think this because the CM should log if it is restarting because of a configuration change, however, if this is considered to be a notice-level event, it might not be preserved)
• The CM initializes with the old configuration settings applied from a configuration file.
• Xfinity notes that the updated and additional upstream channels have not yet been applied to this modem. Rinse. Repeat.

This is a long wall of text, so if you made it this far, great. As I mentioned initially, I'm not a network expert, so my conclusion may be far from reality. It does seem to fit the observed events.

Additional Thoughts

I thought of a few more things, believe it or not.

I think Xfinity is trying to add additional upstream channels to double your upload speed. That's a good thing. To do that, they need to "slide" the downstream channels' lower and upper-frequency ranges to higher frequencies to make some room for the wider upstream channel frequencies. They also set the upstream channels' upper frequency to 85Hz (from 42MHz). That's more than double the previous upstream frequency range, but there must be guard bands between the channels, of which there will be twice as many. The issue may be that the configuration the modem receives during initialization hasn't been updated correctly for the new upstream channels. (They might have to leave it so that older modems that run DOCSIS 3.0 and lower can still initialize properly.) Then they try to make the updates after the initialization, but some modems (e.g., MB8611, SB33) won't accept the changes because the DOCSIS 3.1 specification states that change is not allowed.

When the Internet is out, try to log into the MB8611 and capture the Connection status. You can copy and paste it into Microsoft Word with good results in preserving the formatting. (Set the page to landscape mode with narrow margins) The status pages I've seen have all been captured after the Internet is up again, so they aren't a snapshot of what's going on when the service is down.

IIRC, Xfinity started this rollout using only the XB7 modem/router. That makes sense because they could test that thoroughly in a lab environment before trying it with customers. It will be some trial and error for most other modems.

I am having the SAME ISSUE and have the MB8611 cable modem. Past week we have been getting disconnects at least 1x per hour.. event logs look the same as mine. T3 timeouts and diplexer warning/errors. 

Whatever Comcast is doing is causing issues. We work from home and it's quite unacceptable that we pay a lot of money each month for a service that is being disrupted HOURLY. 

FIX IT. 

Hello NoGoodNames - thanks for the detailed analysis.  Do you have any recommendations for how to fix this?  Seems like a reasonable hypothesis.

Very similar pattern here. 3 outages in past 24 hours related to "UCD invalid or channel unusable."

I also have an MB8611 in the Lancaster, PA area. My internet connection has been randomly dropping 5-6 times per day for 1-3 minutes at a time. My partner and I work from home and this is completely unacceptable.

We reported our down internet problem to customer support and they scheduled a tech to visit us. The tech said that there was nothing wrong with the wires and that the issue likely resided in our customer owned (MB8611) modem.

Now that I have read this thread and checked my modem's event log -- we have almost identical errors, in almost the exact sequence. It seems to me that the problem is not with our unique modem (which is just 1 month old!) but with Xfinity's ability to support this modem in this area. This is completely unacceptable since it was listed under Xfinity's table of 'compatible modems' when I selected my internet package.

They need to either release a public statement, release a fix, or both -- and do it soon. This is a completely unacceptable state of affairs and borders on misinforming customers about what modems they support. FIX THE PROBLEM NOW.

---

Update: after another internet drop in the last hour, the modem software reverted from 8611-21.3.7 to 8611-19.2.18. 

The latest error event log is different:

Same issue here...so are at least 2 other neighbors next to me. 

Multiple service interruptions throughout the day (not always the same time between the three of us). 
Service tech came out, didn't find anything...said he would schedule a bucket truck. 
Truck came out - but the tech never talked to me....left after a few hours with no update. 
After hours trying to get an update from Xfinity, they told me the ticket was closed and had no notes in it. 

Had to restart the process all over again...still having issues...

I'm also having this problem. I just bought the modem (because we upgraded our internet speed), but disconnected several times a day is very frustrating when we work from home. 

Is this issue fixed/when will it be fixed for me? 
Why is this modem listed as verified for xfinity when it doesn't work 100% of the time?

I am curious what version of the firmware is the MB8611 running for people having these problems? Mine had 8611-19.2.20 installed when I unboxed it, and our Xfinity service started in December 2022. In January 2023, the firmware was upgraded to 8611-23.3.7. I had no issues with disconnections with either of those two versions. On February 22, 2023, the firmware on my MB8611 was downgraded to 8611-19.2.18, which is what it is still at today. That's a bit of a predecessor to the firmware version installed when I got it. I've had no issues with that version, either. My modem has been up for 40 days, 20h:00m:45s. 

Most of those having issues with the MB8611 started having them after the upgrade to 8611-23.3.7. The number of people with issues seems to have dropped as well, which I believed happened because most of the MB8611's have been upgraded (or rather, downgraded) to 8611-19.2.18. I'm curious if some people are receiving modems that have firmware versions > 8611-19.2.18 (or 8611-19.2.20) when they take them out of the box.