CODA-4582 - Open Issues for Investigation

Need Help?

That's what we're here for! The goal of the Rogers Community is to help you find answers on everything Rogers. Can't find what you're looking for? Just ask!
cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Highlighted
I Plan to Stick Around
Posts: 32

Re: CODA-4582 - Open Issues for Investigation

@daveinsurgent I have a big post about this coming soon (just need to find the time to write it) but for me, it had to (apparently) do with DOCSIS 3.1. Major packet loss (most noticeably for me while streaming) that caused my stream to drop frames constantly. 


Also, @Datalink the first hop is the router and I believe the second hop is the modem itself.

Highlighted
I Plan to Stick Around
Posts: 43

Re: CODA-4582 - Open Issues for Investigation

@Datalink - Yes, the first IP (192.168.1.1) is my Netgear X4S router. I agree it should not have packetloss, but 1.4% concerns me a lot more than 0.1%. I have an Netgear R7000 I can swap in, and I will also put the CODA back in to Gateway mode and see how that looks... 

 

Rogers technical support said the 174 is my modem, and the "modem IP" is not the same IP as my "whatismyip" IP. I guess that would mean 69.63.255.173 is the CMTS? I'm not sure if that's true.

 

They said the only reason to have packetloss at the modem IP (which, if they're wrong, is actually the CMTS IP) is faulty hardware, but they want me to do a factory reset on the modem before swapping it out.

 

Edit: @MegnaGaming I look forward to it. This has been a plague for a while.

Highlighted
I Plan to Stick Around
Posts: 9

Re: CODA-4582 - Open Issues for Investigation


@HughR wrote:

@joelcyyz

Since you are VPNing on your own, you get to choose the type of VPN.  I would choose IPSec over L2TP.  Many recommend OpenVPN (people other than I seem to find it easy to set up).  Hugh, I can most certainly give this a try!

 

If you are using the VPN to access your home LAN from outside, the topology we were talking about seems wrong.  Are you accessing your notebook-at-home from you iphone-on-the road?

notebook <-> CODA <-> cloud...iphone

Or maybe some other resource at home?

something<->notebook <-> CODA <-> cloud...iphone  The point was reaching for was that from te router back to my laptop is all gigabit hard wired so there are no wireless jumps from the router to the laptop and back!

 


 

Highlighted
I Plan to Stick Around
Posts: 43

Re: CODA-4582 - Open Issues for Investigation

@joelcyyz

OpenVPN does not require the CODA to know about it.  It uses TCP or UDP packets (I don't remember which) that go through NATing just like any other TCP or UDP packets (i.e. by playing with the port fields).  No need for "VPN passthrough".

 

IPSec normally uses IKE and ESP packets (or AH packet, but unlikely in your case).  Those cannot use normal NATing because there is no port field. Many routers IPSec passthrough option or something like it but more often than not, it just looks like enemy action to the IPSec implementation.  So there are subsequent IETF RFCs for IPSec "NAT Traversal".  The packets get encapsulated in UDP and thus can survive NAT.  You might find that this adds to the complexity of configuring IPSec or you might not.  If you use NAT traversal, you don't want the router to do VPN passthrough (but even if it were enabled, it would not see the encapsulated packets, so there would be no problem).

 

You probably don't need to know all that but it might help you deal with mysterious problems or terminology.

 

RANT:

 

NAT is a horrible.  The internet was designed to be a network of peers and you are not a peer if you are behind NAT.  One justification for NAT is IPv4 address scarcity.  Perhaps we'll escape from it with IPv6 but I keep hearing the ominous phrase "carrier grade NAT" which is even scarier (you would not even have one globally routable address reaching your house).

 

OLD-TIMER STORYTELLING:

 

I guess it could be worse.  When I first signed up with Roger (@Home), the contract (which I didn't sign) said you could only use the connection for one device!  And they gave customers a single PCI ethernet card.  This was before home routers so NAT was not well known, even to Rogers.  I used a PC running Linux as a router.  It did NATing, IPSec, and more for me.  I'm still using a PC as a gateway.

Highlighted
I'm a Reliable Contributor
Posts: 362

Re: CODA-4582 - Open Issues for Investigation

I know some folks don't agree (I think because they say that the problem won't occur if you have half a brain) with this but isn't NAT also an aid to security?

 

If we are in an IPv6 world and every device on your LAN has an externally addressable IP then isn't that a much riskier world?  Thinks of all of the devices like IP cameras that have terrible security practices and users who don't change default user/pass combinations.  Or even routers for that matter.  

Highlighted
I Plan to Stick Around
Posts: 43

Re: CODA-4582 - Open Issues for Investigation


@wayner92 wrote:

I know some folks don't agree (I think because they say that the problem won't occur if you have half a brain) with this but isn't NAT also an aid to security?

 

If we are in an IPv6 world and every device on your LAN has an externally addressable IP then isn't that a much riskier world?  Thinks of all of the devices like IP cameras that have terrible security practices and users who don't change default user/pass combinations.  Or even routers for that matter.  


If you have nothing else, logic says that NAT will make it harder to break in.  But how much harder?

 

The very logic that your gateway would use for NAT can easily be used to block traffic.  Typically: outbound-from-LAN traffic triggers a NAT table entry.  It can instead trigger the addition of an equivalent  firewall passthrough rule for the same flow.

 

Maybe routers should have a "Don't NAT, but give me NAT-like security" setting.  But since consumers don't even know how much security that even means, it is probably a useless idea.  I don't understand Window 10's settings for the security for a connection, but they do seem simple and they are likely fairly well thought out.  If I actually were a Windows user, I'd spend some time to figure out what the settings mean.

 

Historically, Windows has been a bad actor as far as firewalls.  Universal Plug and Play is bad and you should turn off support for it in your gateway.  As I understand it, router manufacturers enable UPnP by default, probably to reduce the support calls from confused but protected consumers.

 

One thing NAT does is aggregate all traffic from your LAN to the ethernet in a way that can make traffic analysis (a powerful and underrated surveillance technique) more difficult.  But that's usually not enough aggregation to matter.  If you aggregated a whole building complex, that would be more effective.  But unless you use TOR, traffic analysis of you is really really easy anyway.

 

Any device ought to have a firewall, including your gateway but not limited to your gateway.  Crispy on the outside and tender on the inside is not a good security model.

 

I have wired security cameras.  They are on their own LAN.  Not connected to the internet at all.  At some point I will probably change that but with a carefully engineered gateway.

Highlighted
I Plan to Stick Around
Posts: 9

Re: CODA-4582 - Open Issues for Investigation


@HughR wrote:

@joelcyyz

OpenVPN does not require the CODA to know about it.  It uses TCP or UDP packets (I don't remember which) that go through NATing just like any other TCP or UDP packets (i.e. by playing with the port fields).  No need for "VPN passthrough".  I would need to find new VPN Server Software for my MBA as the current software I am running -- which is reliable and simple -- only supports PPTP and L2TP.

 

You probably don't need to know all that but it might help you deal with mysterious problems or terminology. Yes, much appreciated and helpful!

 

 

 


 

Highlighted
I Plan to Stick Around
Posts: 9

Re: CODA-4582 - Open Issues for Investigation

CODA 4582 MAC ID Reserved DHCP IP Address Works Inconsistently...

 

I wanted to "carve out" my IP ranges as follows:

i)   O1 to 99 for static IP addresses

ii) 100 to 150 for DHCP assigned IP addresses

iii) 151 to 255 for DHCP MAC ID reserved IP addresses.

 

In so doing I set the DHCP range to 100 to 155 and went about assigning the MAC ID reserved IP addresses which for my purposes extended to 210.

 

The results were inconsistent (and very frustrating) in that:

i) MAC ID reserved IP addresses worked up until 199;

ii) MAC ID reserved IP addresses did nor work for 200 or beyond (i.e. these devices ended up with IP addresss in the 100 to 150 range).

 

This lead me -- out of complete frustration -- to extend the DHCP range to 100 to 254 and guess what, all of sudden all the MAC ID reserved IP addresses were properly assigned and sticking (yeah!)!  The morale of the story being that MAC ID reserved IP addresses must be within the DHCP range! 

 

What is confusing about this?  Why would a DHCP range of 100 to 150 allow MAC ID reserved IP addresses to work up til 199 but not for 200 and beyond?  While I am not a network engineer by any mans it seems -- because I constantly refreshed the  DHCP table -- that the CODA modem runs out of steam / time when checking / resolving IP addresses for devices which have MAC ID reserved IP addresses that are "far out" of the DHCP range?

 

Comments / thoughts?

Highlighted
I Plan to Stick Around
Posts: 9

Re: CODA-4582 - Open Issues for Investigation

Well it appears as though my gremlins / issues with MAC ID based reserved DHCP addresses are back.  Very frustarted at this point!

 

Would appreciate any input / insight anyone has to try to fix this once and for all.

 

Thx!

Highlighted
I Plan to Stick Around
Posts: 9

Re: CODA-4582 - Open Issues for Investigation

I am posting an update to my earlier posts in September concerning severe bandwidth loss on my CODA modem after loss of OFDM lock.  At that time, running Firmware .28, after a fresh boot the modem’s WAN status page shows OFDM locked on one receiver and it would run at about 150Mbps for a short while, then after a few minutes speeds decay to 2Mbps and WAN status shows OFDM lock is lost.  At that point, if you disconnect the cable without rebooting, when reconnected, the CM handshakes with the CMTS without OFDM on Docsis 3.0 and runs relatively stable at about 50Mbps.

 

RogersDave took note of my posting back then and enrolled my modem into a beta of Firmware .33 and this seemed to work well until about late December.  At that time, very similar symptoms reoccurred.  The modem runs at 150Mbps after a fresh boot and decays to 2Mbps after perhaps 10 minutes.  On Firmware .33 however, the WAN status shows OFDM receiver is locked (even though it appears as though it is not) and disconnection and reconnection does not restore any bandwidth.  It appears as though the CM is telling the CMTS it is OFDM locked and running 3.1, and it thinks it is locked and running 3.1, but it is not.

 

After several weeks of back and forth with the tech support call center, which included several diagnoses of signal noise or strength issues, several White Truck Link-On techs were dispatched who replaced pretty well every connector between my house and the stand down the street (which did move signal strength levels up but didn’t fix anything) they opened a ticket with “Maintenance”   Then the Red Rogers Truck guy showed up and opened all the neighbourhood stands checking for noise, which he attributed to a rogue modem somewhere on the segment, which he found and cut off the network.  Still the problem persisted, so a “Senior Tech” Link-On guy was sent out.  More minor cabling issues repaired, line tests done, and still no fix, so he swapped out the modem (yet again).

The new CODA loaded Firmware .28T2 and ran exactly as it did back in September.  150Mbps for a little while with OFDM lock, once lock lost, 2Mbps, and after cable disconnection/reconnection, it handshakes on Docsis 3.0 running at about 50Mbps stably.  A day later, they push the latest Firmware .33T3 to the modem and the December symptoms return.  150Mbps for a little while with OFDM lock, speeds decay to 2Mbps but CM thinks OFDM locked, cable disconnection/reconnection does nothing.

This appears to me to be so clearly a software issue that I cannot understand why they keep sending over on site techs.  These modems are very buggy and do not work properly with Rogers CMTS hardware.  It seems to be a basic modem handshaking issue and very old school.

 

The senior tech now plans to return and install the modem at the line tap down the street to test if the problem exists there (essentially to eliminate the whole cable run between the stand and the house) and I expect that it will since the entire line was tested by numerous techs already and my other services, ie. cable TV and telephone work fine.  Everyone has tried to be helpful, so that’s great, but the diagnoses and procedures seem to be missing the obvious.

 

Maybe the network architects on monitoring this board can fix it.  The field people cannot.