Ok, there's something definitely off with that trace, none of it belongs to Rogers network. Are you running a VPN by any chance?
The first part of the trace 45.xxx.xxx.xxx belongs to https://www.linode.com/
The second part belongs to google.
With the Residential Gateway Function enabled, the modem is running in Gateway mode. That means that you have a double NAT situation on the go where the modem and google's wifi are providing a Network Address Translation from external address to internal address. That's not going to stop you from connecting to the internet from the mesh network, its just not very efficient. Now, if the Google wifi is running in a Bridge mode or Access Point mode, then there is no double NAT and the modem is running the network in terms of providing LAN IP addresses.
I have a VPN installed, but it is not currently in use, nor was it used during any of the testing. The VPN is 100% off, with the program closed and off. Should I run it again to be sure?
With the Residential Gateway Function enabled, the modem is running in Gateway mode. That means that you have a double NAT situation on the go where the modem and google's wifi are providing a Network Address Translation from external address to internal address. That's not going to stop you from connecting to the internet from the mesh network, its just not very efficient. Now, if the Google wifi is running in a Bridge mode or Access Point mode, then there is no double NAT and the modem is running the network in terms of providing LAN IP addresses. Within the Google Wifi app, it indicates it's running in Mesh mode, however, the main Access point (a TP-Link On-Hub) says it's in NAT (standard) mode, while the pucks are all in bridge mode. Could this be causing the problems?
I put the CODA in Bridge Mode and ran the trace again: same results. Thoughts?
It wouldn't necessarily cause problems, more an issue of confusion at the present time. The modem and TP-Link configuration also depends on what you need from the modem and router. If you don't need an ethernet connection to the modem at all, you can simply run the modem in Bridge mode and let the TP-Link run in NAT mode, running the network for the house.
If you need the modem for its ethernet ports, then the more efficient way to run the network is to run the TP-Link router in Bridge mode.
Fwiw, the TP-Link router will most likely have a far better choice of user settings that you can use. The drawback of running the router in Bridge mode is that you would lose those settings.
So, there are a few considerations here, including your ethernet requirements for the modem if any, and requirements for the TP-Link router and the potential loss of functionality if the router is running in Bridge mode.
CODA in Bridge Mode: same result. did you run the trace from a device connected to the Google wifi?
I need to do some quick reading here, don't have time at the moment. I'll get back to this after supper.
Edit: one caveat. If you're going to run the modem in Bridge mode, you have to ensure that the TP-Links IPV4 and IPV6 firewalls are up and running. It might be a single setting, there might be two settings. You'll have to look thru the user settings to determine that.
Thanks so much for your time, I didn't mention it before. Appreciate it.
I ran the trace from a computer plugged directly into the CODA modem. I switched over the Bridge mode in the CODA, and now I cannot access the web interface to change it back to Gateway mode. Is there another way to access the modem's settings page?
Yup, connect the TP-Link to the modem and then connect to the TP-Link.
Use 192.168.100.1 thru the router. You can also use that with a direct connection to the modem when its in Bridge mode.
I don't encourage a direct connection to the modem when its in Bridge mode due to the constant port scanning by various miscreants scattered across the internet, probing for open ports or mis-configured firewalls.
With V184.108.40.206T6, in the modem as indicated on the status page, you can use 192.168.01. or 192.168.100.1 when the modem is in Gateway mode. When its in Bridge mode you can only use 192.168.100.1, which will normally work thru any connected router. There are exceptions but they are few and far between, so to speak.
With V220.127.116.11 loaded you can only use 192.168.0.1 when the modem is in Gateway mode and only use 192.168.100.1 when the modem is in Bridge mode.
@MD83 there are a few ways to do this.
1. connect directly to the modem, even though I'm not a huge fan of this.
2. As soon as the pc/laptop gains an IP address, log into the modem using 192.168.100.1 I'm assuming that the modem is stuck in Bridge mode.
3. kick the modem back into Gateway mode when you've managed to log in.
Call tech support and ask the CSR to switch your modem back into Gateway mode
Reset the modem. Ugh. Depress the recessed reset button at the back of the modem for at least 15 seconds. It should reset the modem, at which point the modem will reboot into Gateway mode. Unfortunately you would have to set the modem up from scratch.
With the modem in Bridge mode, if you rebooted the TP-Link router it should pick up its assigned external address from the modem and you should be able to use 192.168.100.1 to access the modem's login page. If you can't, then the TP-Link is blocking the path out to the modem. Usually thats taken care of by defining a route out to the modem, but, I don't know if the TP-Link will let you do that.
This menu displays general information of the device
Hardware Version 1A
Software Version 18.104.22.168T6
System Time Wed, 18 Mar 2020 01:40:55
Time Zone UTC+00:00 Greenwich Mean
Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID Signal noise ratio (dB)
1 591000000 256QAM 9.800 7 38.605
2 597000000 256QAM 9.800 8 38.605
3 603000000 256QAM 9.700 9 38.605
4 849000000 256QAM 7.100 2 37.356
5 855000000 256QAM 6.500 3 36.610
6 861000000 256QAM 5.800 4 36.387
7 579000000 256QAM 9.700 5 38.605
8 585000000 256QAM 9.800 6 38.605
9 279000000 256QAM 7.000 1 37.636
10 609000000 256QAM 9.600 10 38.605
11 615000000 256QAM 9.800 11 37.636
12 621000000 256QAM 9.800 12 38.605
13 633000000 256QAM 9.600 13 38.605
14 639000000 256QAM 9.500 14 37.636
15 645000000 256QAM 8.900 15 37.636
16 651000000 256QAM 8.800 16 37.636
17 657000000 256QAM 8.800 17 38.605
18 663000000 256QAM 8.700 18 37.636
19 669000000 256QAM 8.500 19 37.356
20 675000000 256QAM 8.700 20 38.605
21 681000000 256QAM 8.400 21 38.605
22 687000000 256QAM 8.400 22 37.636
23 693000000 256QAM 8.700 23 37.636
24 699000000 256QAM 8.700 24 38.258
25 705000000 256QAM 8.800 25 37.636
26 711000000 256QAM 8.700 26 37.636
27 717000000 256QAM 8.600 27 37.636
28 723000000 256QAM 8.400 28 37.636
29 825000000 256QAM 7.300 29 36.610
30 831000000 256QAM 7.400 30 36.610
31 837000000 256QAM 7.000 31 37.356
32 843000000 256QAM 7.200 32 37.356
OFDM Downstream Overview
Receiver FFT type Subcarr 0 Frequency(MHz) PLC locked NCP locked MDC1 locked PLC power(dBmv)
0 NA NA NO NO NO NA
1 4K 275600000 YES YES YES 9.000000
Will get you trace route soon as I log on my laptop
@savuser12 can you delete the HFC MAC Address data as it shouldn't be posted to an open forum. Can you also post the upstream channel data that sits below the OFDM channel data. There should be three or four upstream channels running.
Got it up and running again. We'll see if the problem still persists, as I assume it will. Any further ideas before the tech comes to check things out. Again, I really appreciate the time and effort given here.