XB7 FAILED 11/19/2024 CUT OFF INTERNET. Today after talki...

[SteelTown]

XB7 FAILED 11/19/2024 CUT OFF INTERNET.

Today after talking to the shaw online chat help, he reviewed everything and suggested to bump up the IPv4 firewall level to medium. how would ivp4 help 6, he says it defaults to 4 then goes to 6.

The 2 hours later the TV XiOne box made my TV go blank for 30 seconds each time, but this time with no error messages.

The tech also said to install the Shaw Phone app for better security, which I just did but it did not show anything NEW.

But a few minutes later in rechecking in the XB7 logs, have started to show MORE data and in the Event logs now these, show and 6 yesterday, and last week 40 entries

DHCPv6[8384]: 72001011-DHCPv6 - Missing Required Option 82 2024/11/19 13:00:36 Critical
DHCPv6[8384]: 72001011-DHCPv6 - Missing Required Option 24 2024/11/19 13:00:36 Critical

IN ADDITION TO THESE

FW.IPv6 INPUT drop , 45 Attempts, 2024/11/19 14:00:06 Firewall Blocked
FW.IPv6 INPUT drop , 6 Attempts, 2024/11/19 13:58:00 Firewall Blocked

FW.IPv6 FORWARD drop , 186 Attempts, 2024/11/19 13:10:02 Firewall Blocked

I see lots of ADDITIONAL reports on the XB7 shortcoming, if the units are soo good (cough, cough) why is there so much flack and users saying help me in the forums? Shaw Community fourms, Rogers Community fourms, Reddit r/home networking forums, Xfinity Community fourms, etc.

Overall, are these 24/82 errors a result of shaws upstream servers' communications fail. Some say it's shaws flaky dhcpv6 server lease binding times that can take upto 40 seconds cutting out your internet.

So what can i do in the meantime, hence in thinking, have increased my xb7's IPv4 lease time to 2 weeks instead of the default 2 days.

You pay 100 bucks a month for TV, held captive in a 2 year contact and TV craps out almost every day?

Signed Frustrated.

DHCP option 82 :
- You can use DHCP option 82, also known as the DHCP relay agent information option, to help protect supported Juniper devices against attacks.
- a remote identification protocol that allows ISPs to identify the user, device and location of any device on their network. It works by inserting an identifier into a DHCP packet that helps the ISP to uniquely identify the user, device and location. This identifier is called a sub-option.

[mdk]

@SteelTown wrote:

DHCPv6[8384]: 72001011-DHCPv6 - Missing Required Option 24 2024/11/19 13:00:36 Critical

Your computer is sending DHCP (Dynamic Host Configuration Protocol) requests to your cable-modem, asking the cable-modem to allocate an IP-Version-6 address to your computer, but your computer is not sending some REQUIRED information to the cable-modem. So, is your computer an Apple (notebook, iPad, iPhone, All-In-One desktop) or is it running Windows 10 or Windows 11?

Can you disable IPv6 on your device, and communicate via IPv4, to avoid those "critical" messages?

IN ADDITION TO THESE

FW.IPv6 INPUT drop , 45 Attempts, 2024/11/19 14:00:06 Firewall Blocked
FW.IPv6 INPUT drop ,   6 Attempts, 2024/11/19 13:58:00 Firewall Blocked

Your cable-modem is acting as a "firewall" -- thus preventing UNSOLICITED IPv6 packets from reaching any of the computers/devices within your home network.   This protects you from "hackers" on the Internet trying to attack your devices.

One way of getting this error-message is to connect your computer to some site on the Internet, to open a connection, such as a download of a large file, and then you close your app (or web-page) that is receiving the download. Compare to you telephoning somebody, and then hanging-up on them, while they are talking.  After a while, your colleague realizes that you have ended the call, and stops talking. Their words have been "dropped" -- you don't hear them.

So, having your cable-modem "drop" traffic is an entirely-normal situation, unless some hacker is trying to "flood" your cable-modem, sending you millions of bytes of unsolicited traffic, as part of a DOS ("Denial Of Service") attack on your cable-modem. But, only 186 packets is not a "flood".

EDIT: You wrote: Overall, are these errors a result of Shaw's upstream servers' communications fail?

No. Your excerpts from your log-file come from the cable-modem INSIDE your home -- not from any hardware anywhere "upstream". 

[SteelTown]

firewall logs are outside coming in. the xb7 logs are terrible, to what my dlink logs can show in/out.

I do not think that my computers are causing the problem, as this happens even at night when computers are turned off.  (2 windows 7, one windows 10) and android tablets and phone in standby. in this home, only the XiOne is directly connected to the XB7.

My Dlink router is behind the XB7 is configured with all ipv6 turned off and it is not used, only uses ipv4. All our electronics are behind the dlink router behind the XB7 and use the dlink.

it happened yesterday and this morning, so to reply to you turned on my on my old window 7 laptop connected directly to the xb7, the laptop even it says no ipv6 internet. 

I do notice that when the outages occur oddly the XiOne will jumps between 2.5g and 5g wifi, and its only 12 feet away from the XB7

i do say 928 attempts is an dos attack on the firewall.

also in forums the xb7 get their ip address from a shaw server, the xb7 ip address are not fixed not permanent, changing fluidly, each time cuts off the service to the home.  so now will record the ip addresss of the xb7 each time i notice it fails.

I NEVER, NEVER, EVER, HAD THIS PROBLEM WITH MY CISCO DOSSIS 3.0 GATEWAY DPC3825 IN PASS THROUGH MODE. 

If shaw cannot resolve this i may just cancel my TV programs return the xb7 and xione for terms of failure of lack of providing reliable service (wifi satisfaction guarantee) and use the old cisco at 50 meg speed just for internet. i have already returned and cancelled 2 other xione boxes because of this problem.

DHCPv6[8384]: 72001011-DHCPv6 - Missing Required Option 822024/11/20 13:00:36Critical

DHCPv6[8384]: 72001011-DHCPv6 - Missing Required Option 822024/11/20 13:00:36Critical

DHCPv6[8384]: 72001011-DHCPv6 - Missing Required Option 242024/11/20 13:00:36Critical

All logs from Yesterday    

FW.IPv6 INPUT drop , 9 Attempts, 2024/11/21 09:46:08	Firewall Blocked
FW.IPv6 FORWARD drop , 15 Attempts, 2024/11/21 09:46:08	Firewall Blocked
FW.IPv6 INPUT drop , 928 Attempts, 2024/11/20 02:50:37	Firewall Blocked

FW.IPv6 INPUT drop , 9 Attempts, 2024/11/21 09:46:08	Firewall Blocked
FW.IPv6 FORWARD drop , 15 Attempts, 2024/11/21 09:46:08	Firewall Blocked

[mdk]

@SteelTown wrote: 

1. firewall logs are outside coming in. 

True, but the log is also recording events originating from inside your network.

Note that DHCP-requests should not be coming "in" from the Internet. 

It would be a very "insecure" infrastructure if a DHCP-request from your neighbour's computer would reach your XB7. Their computer would then be "inside" your home network.  Ouch!

2. I do not think that my computers are causing the problem, as this happens even at night when computers are turned off. (2 windows 7, one windows 10) and android tablets and phone in standby. in this home, only the XiOne is directly connected to the XB7.

All our electronics are behind the D-ink router ... use the D-link.

In "standby" mode, your devices are still active, but in a low-power mode.  The DHCP-provided IP-address is still honouring the TTL (Time To Live) information within the DHCP-response. If this "lease" expires overnight (or even if the TTL drops to 50% of its original value), then your device will issue a DHCP-renew request to your D-Link router.  So, the devices still are "active".

All your devices should be receiving  DHCP-responses only from your D-Link router. None of the DHCP-requests should be going "through" the D-Link to the DHCP-server inside your XB7. Your D-link should be "answering" all the DHCP-requests from the devices on your network.

Check the IP-addresses being assigned to your computers -- they should be "192.168.xxx.yyy" -- as handed-out by your D-Link.

This is in contrast to the XiOne, which should have a "10.0.0.xxx" IP-address assigned by the XB7. Login to the XB7, to see the "active" IP-addresses, which should all be "10.0.0.xxx".

3.  The XiOne will jumps between 2.5g and 5g wifi, and its only 12 feet away from the XB7.

What other devices connect to the XB7, and receive DHCP-responses from the XB7? Only your D-Link router? Since you are looking at the log-files of the XB7, it is only the devices connected to it (wired or wireless) that could be sending those "bad" DHCP-requests.

4.  In forums, the XB7 get their IP-address from a Shaw server, the XB7 IP-address are not fixed not permanent, changing fluidly, each time cuts off the service to the home. so now will record the IP-addresss of the xb7 each time i notice it fails.

You are not correct. The WAN (Wide Area Network) adapter on the XB7 gets a "public" IP-address from a Rogers/Shaw DHCP-server in your city/town. However, when your XB7 restarts (maybe after you powered it off, or BC Hydro had an outage in your neighbourhood), the DHCP-request from the XB7 will send the same MAC-address, namely the MAC-address of the WAN-adapter. The DHCP-server will recognize that MAC-address as being "your" XB7, and will reuse the IP-address that it gave to your XB7 the very-first time that your XB7 connected to the Rogers/Shaw network. 

Go ahead and monitor that IP-address. It will almost never change. The only exception is if the Rogers/Shaw network engineers "split" their network segment in your area -- too many devices in one "segment" degrade everybody in your segment. So, 50% of the customers in your segment will get a different IP-address. Once the "split" is done, the IP-address will not change.

5. I NEVER, NEVER, EVER, HAD THIS PROBLEM WITH MY CISCO DOCSIS 3.0 GATEWAY DPC3825 IN PASS-THROUGH MODE.

Previously, did you have the XiOne adapter connected (wired or wireless) to that Cisco device? Probably not! Did you have a HDPVR, connected via coaxial-cable into your home network? The XiOne does not connect via coaxial-cable; it uses Ethernet or WiFi networking.

The hardware inside your home changed when you changed the router and the TV box.

So, those changes introduced the new events, as you correctly stated.

I will end with a quote from the 18th century.

[mdk]

@SteelTown wrote: when using my personal D-Link router behind the XB7 LAN, DNS set to OpenDNS, the XB7 won't pass through or allow my requests out to OpenDNS. ... the really wired

Wired? Weird?  🙂

Anyway, did you set the IP-addresses of the OpenDNS servers on your Windows 10 computer, and then try commands like :

$ ping -4 www.microsoft.com

Pinging e13678.dscb.akamaiedge.net [23.217.131.226] with 32 bytes of data:
Reply from 23.217.131.226: bytes=32 time=13ms TTL=58
Reply from 23.217.131.226: bytes=32 time=10ms TTL=58
Reply from 23.217.131.226: bytes=32 time=10ms TTL=58
Reply from 23.217.131.226: bytes=32 time=10ms TTL=58

so that the OpenDNS servers returned the IPv4 address of that site? Or, did you get some error-messages?

Another example:

$ tracert -4 www.fsu.edu

Tracing route to www.fsu.edu [146.201.111.62] over a maximum of 30 hops:

7 11 ms 10 ms 10 ms rc1wt-be40.wa.shawcable.net [66.163.68.18]
8 14 ms 14 ms 13 ms six.tr-cps.internet2.edu [206.81.80.77]
9 82 ms 84 ms 82 ms fourhundredge-0-0-0-19.4079.core1.seat.net.internet2.edu  [163.253.1.158]
10 85 ms 84 ms 86 ms fourhundredge-0-0-0-0.4079.core1.salt.net.internet2.edu [163.253.1.156]
11 80 ms 78 ms 79 ms fourhundredge-0-0-0-0.4079.core1.denv.net.internet2.edu [163.253.1.170]
12 77 ms 78 ms 78 ms fourhundredge-0-0-0-1.4079.core1.elpa.net.internet2.edu [163.253.2.103]
13 84 ms 85 ms 85 ms fourhundredge-0-0-0-0.4079.core1.hous.net.internet2.edu [163.253.2.39]
14 81 ms 80 ms 80 ms fourhundredge-0-0-0-0.4079.core1.houh.net.internet2.edu [163.253.2.24]
15 83 ms 79 ms 80 ms fourhundredge-0-0-0-0.4079.core1.pens.net.internet2.edu [163.253.2.35]
16 79 ms 80 ms 80 ms fourhundredge-0-0-0-0.4079.core1.jack.net.internet2.edu [163.253.1.0]
17 84 ms 82 ms 83 ms 198.71.47.198
18 92 ms 87 ms 88 ms tlh-flrcore-asr9010-1-hu0701-1.net.flrnet.org [108.59.31.158]
19 82 ms 82 ms 84 ms pen-flrcore-asr9010-1-te0021-200.net.flrnet.org
[108.59.31.50]
20 85 ms 84 ms 84 ms FSU-Campus-2-FLR-TLH-SF-v1903.net.flrnet.org [108.59.27.241]
21 81 ms 81 ms 81 ms po136-4000.bfs-dc.net.fsu.edu [128.186.248.2]
22 81 ms 81 ms 80 ms webvm.its.fsu.edu [146.201.111.62]

Trace complete.

This is a trace of IP-packets to "Florida State University". Note that the TRACERT command queries many DNS-servers, to find the names associated with the IP-address of each router along the path, with IP-packets passing across the Canada-USA border to: seat.net.internet2.edu  (Seattle) and then:

fourhundredge-0-0-0-0.4079.core1.salt.net.internet2.edu  (Salt Lake City)
fourhundredge-0-0-0-0.4079.core1.denv.net.internet2.edu  (Denver)
fourhundredge-0-0-0-1.4079.core1.elpa.net.internet2.edu  (???)
fourhundredge-0-0-0-0.4079.core1.hous.net.internet2.edu (Houston)
fourhundredge-0-0-0-0.4079.core1.houh.net.internet2.edu (Houston)
fourhundredge-0-0-0-0.4079.core1.pens.net.internet2.edu  (Pensecola?)
fourhundredge-0-0-0-0.4079.core1.jack.net.internet2.edu  (Jacksonville)
tlh-flrcore-asr9010-1-hu0701-1.net.flrnet.org  (Florida Net)
pen-flrcore-asr9010-1-te0021-200.net.flrnet.org (Florida Net)
FSU-Campus-2-FLR-TLH-SF-v1903.net.flrnet.org (Florida Net)
po136-4000.bfs-dc.net.fsu.edu (FSU)

Or, do you get error-messages, or do you NOT see those host-names?