CODA-4582 - Open Issues for Investigation

[RogersDave]

*** This post was last edited May 2, 2017 ***

Good morning Community,

As I mentioned in a post two days ago, we have received the next firmware 2.0.10.20 from Hitron. We are currently running initial testing on this version and will push it out to participants in the firmware trial program as soon as it passes initial testing.

However, while running these tests, we discovered abnormal behavior with ICMP and are awaiting feedback from Hitron today to asses how this will be addressed. As soon as I this is confirmed, I’ll update the change log with the correct version information and start pushing it out.

In parallel, we are still working on the following high priority items. In some cases below, I requested affected customers to reach out to me via private message. If you do so, please include your modem MAC address in the subject line (even if we exchange messages daily) as there are a lot of you reaching out to me daily 🙂

UDP Packet Loss

The investigation for what has been reported as UDP packet loss is still ongoing. We have deployed a probe at one fellow forum member on both a CODA-4582 and a CGNM-3552 to collect additional data. We are actively working with Hitron and Intel on the results observed.

Based on what we know so far, in most instances UDP packet loss is coupled with higher uplink usage in the area. Although the impact is noticeable in specific logs (League of Legends), the root cause for the perceivable impact (while playing) is likely related to bufferbloat (see next issue).

Bufferbloat

When comparing the performance of a CODA-4582 to a CGNM-3552 in the same network conditions, the CODA-4582 consistently reports higher bufferbloat when tested on DSLReports.

Update April 12: The solution for this problem will come in two folds. It will require a change in software which will possibly be included in 2.0.10.27 but more likely in 2.0.10.28 and a change in network configuration.

The network configuration change is not compatible with the current firmware so this change will only come after a vast majority of the modems are running the new code. We are however looking at a way to make the change only for specific modems to support testing in the community.

Update April 22: This problem seems resolved in firmware 2.0.10.27

5 GHz WiFi Low range for channels 36 to 48

Lower WiFi channels on the modem have a much smaller range. This is due in part to the limit imposed by Industry Canada to maximum transmit power.

Furthermore, the current automatic channel selection (auto mode) tends to select the lower channels when in similar load conditions.

Workaround: manually select higher channels (149-153-157-161)

Update April 22: The channel selection algorithm has been improved in firmware 2.0.10.27

Loss of OFDM Channel Lock

Under some RF conditions, the modem fails to lock properly on the OFDM channel. This typically result in variable performance.

Update April 12: This problem is resolved in 2.0.10.26T2

List of connected device does not get fully populated

This is a known issue that has been tracked since firmware 2.0.10.13. We are making improvements at every firmware but it is not a perfect system.

The situation is worst after a reboot or firmware upgrade as the list gets reset and must be repopulated as devices renew their DHCP lease.

NAT Loopback not working for wired clients

When setting up port forwarding to an internal server, it is possible for a client on WiFi to reach the server using the external IP/port. If the client is on a wired interface, it doesn't work.

Update April 12: This problem is resolved in 2.0.10.26T2 (not confirmed)

LAN Counters not working

Some customers reported that LAN counters (especially in bridge mode) are reporting inaccurate values.

This problem has been reported to Hitron for investigation.

Unexpected modem reboot

Some customers reported their modem reboots unexpectedly. We have also seen this behavior in our lab.

Update April 12: This problem is resolved in 2.0.10.26T2

Missing SC-QAM Channels

After a reboot, some modems are missing SC-QAM channels. A fix has been implemented in 2.0.10.26T2 to address this behavior but it has not corrected all scenarios.

Investigation continues with Hitron.

WiFi Survey

The WiFi Survey functionality in firmware 2.0.10.26T2 (and possibly before) reports incorrect SSID names.

Guest Network

When connecting to the Guest Network, an error message is displayed "only allow DHCP client to use this wireless".  This has been reported in firmware 2.0.10.26T2.

Update April 22: This issue has been resolved in firmware 2.0.10.27

Update May 2: It seems this issue is not fully resolved and still experienced by some users

---

Future Planned Improvements

The following are items that we are working on in parallel of the above.

• Improvement in WiFi speeds
• Improvement in latency / bufferbloat

Dave

*Edited Labels*

[Mythen]

https://www.google.ca/amp/s/www.theregister.co.uk/AMP/2018/01/15/router_vendors_update_firmware_to_p...

Anyone know if the coda is susceptible to this bug? It could explain a few things

Mythen

[HughR]

@joelcyyz

I don't have answers, just questions.

What VPN protocol you are using?  There are so many!

Also, I don't quite understand your topology.  Are you saying that your notebook is acting as the VPN gateway for a bunch of nodes (eg. iPhone)?  How are packets routed?  iPhone <-> CODA <-> notebook <-> CODA <-> cloud... ?

I assume that your CODA is not in bridge mode (although that would make topology easier to understand and avoid the horrors of NAT).

VPN passthrough is often a joke.  What does it mean?  I think it usually applies only to IPSec (but I haven't paid attention to this aspect of the CODA).  At least many implementations I looked at broke IPSec.  Better to use the horrible NAT traversal hacks to IPSec.

[joelcyyz]

---

Hugh, appreciate your input.  Two things:

1. I have responded in-line and in red below; and

2. I am now more convinced than ever that it is a Rogers implementation that is specifically put in place.  Why, because when speaking to Rogers they specifically advised that they do not support end users installing servers (i.e. VPN, web servers, etc.) and therefore limit this capability.  I think this very unfair in that while I understand protecting against the use of high volume servers, how does my little VPN which only 2 or 3 people dial into create a bandwidth threat!

NOT COOL!



@HughR wrote:

@joelcyyz

I don't have answers, just questions.  Well perhaps your questions will lead to answers so here goes!

What VPN protocol you are using?  There are so many! L2TP

Also, I don't quite understand your topology.  Are you saying that your notebook is acting as the VPN gateway for a bunch of nodes (eg. iPhone)?  Yes, except only for 1 iPhone and 1 to 3 Laptops. I am running VPN server software on my MacBook. How are packets routed?  iPhone <-> CODA <-> notebook <-> CODA <-> cloud... ? Yes, you have it!

I assume that your CODA is not in bridge mode (although that would make topology easier to understand and avoid the horrors of NAT). Correct, it is NOT in bridge mode!

VPN passthrough is often a joke.  What does it mean?  I think it usually applies only to IPSec (but I haven't paid attention to this aspect of the CODA).  CODA has specific pass-through settings for EACH of IPSec, PPTP and L2TP At least many implementations I looked at broke IPSec.  Better to use the horrible NAT traversal hacks to IPSec.

---

[Datalink]

@joelcyyz when you were with Bell, did you run a speedtest thru the VPN and if so, what were your results and what was the internet plan that you were on (download & upload rates).  

I think there are a couple of problems here:

1.  Rogers uses IPV6 whereas Bell doesn't.  You didn't indicate in your post if you had IPV6 up and running, so, just bringing this up as a possible issue.

2.  VPN rates thru the Puma series modems are historically low, compared to the non-VPN rates and I don't believe that its a matter of Rogers throttling VPN rates.  This isn't a Rogers issue, its an Intel Puma chipset issue, personal opinion.  This problem  has been around for some time now and I have no idea if it will ever be addressed.  It may have originated in 2007/2008 when Texas Instruments first designed and built the Puma 5 chipset, and then just carried on to the Intel Puma 6 CGNxxxxx modems and now the Intel Puma 7 CODA-4582 modem.  Intel bought the Puma product line from Texas Instruments in 2010 and put their own spin on the chipset design.  

If you look at the following link:

http://communityforums.rogers.com/t5/Internet/FEEDBACK-Rogers-Rocket-Wi-Fi-Modem-Firmware-Trial/m-p/...

You will see this at the bottom of the post, along with a few other issues:

Known or reported issues

• Non TCP/UDP/ICMP traffic (such as ESP/IPSec without NAT-T) is slowed down below 25 Mbps

My personal opinion is that Hitron needs to take a very close look at VPN performance with the Puma 6 and 7 modems and persue the issue with Intel if necessary, or, if the firmware already exists within the modem to run VPNS at higher rates, then, get on with it and make it happen.  Its unfortunate that there are no performance specs which show the VPN rates thru the Puma 6 and 7 modems.  If there were, potential customers could decide if it was worth it or not to sign up for an ISP, given the throughput specs.  Remember that were talking about Puma 6 and 7 modems used worldwide, not just with Rogers. 

[joelcyyz]

---

Datalink, I thank you for your post and note that I have responded to your questions below in-line and in red.

Thanks!


@Datalink wrote:

@joelcyyz when you were with Bell, did you run a speedtest thru the VPN and if so, what were your results and what was the internet plan that you were on (download & upload rates).  No, I did not run a speedtest but do note that the throughput was sufficient such that the VPN connection was functional regardless of the application I was using (usually database applications, home automation, spreadsheets, etc.)

I think there are a couple of problems here:

1.  Rogers uses IPV6 whereas Bell doesn't.  You didn't indicate in your post if you had IPV6 up and running, so, just bringing this up as a possible issue. No, I am relying on IPV4 for Port Forwarding etc.  Do you think this will make a material difference as I can try using IPV6?

2.  VPN rates thru the Puma series modems are historically low, compared to the non-VPN rates and I don't believe that its a matter of Rogers throttling VPN rates.  This isn't a Rogers issue, its an Intel Puma chipset issue, personal opinion.  This problem  has been around for some time now and I have no idea if it will ever be addressed.  It may have originated in 2007/2008 when Texas Instruments first designed and built the Puma 5 chipset, and then just carried on to the Intel Puma 6 CGNxxxxx modems and now the Intel Puma 7 CODA-4582 modem.  Intel bought the Puma product line from Texas Instruments in 2010 and put their own spin on the chipset design.  Very interesting and thank you for the added inromation and insight.  I will most definitely read the below link later in the day!

If you look at the following link:

http://communityforums.rogers.com/t5/Internet/FEEDBACK-Rogers-Rocket-Wi-Fi-Modem-Firmware-Trial/m-p/...

You will see this at the bottom of the post, along with a few other issues:

Known or reported issues

• Non TCP/UDP/ICMP traffic (such as ESP/IPSec without NAT-T) is slowed down below 25 Mbps Well, I know it is WAY below 25 Mbps becuase I cannot even load a simple web page or my local printers web interface.  The performance is terrible!

My personal opinion is that Hitron needs to take a very close look at VPN performance with the Puma 6 and 7 modems and persue the issue with Intel if necessary, or, if the firmware already exists within the modem to run VPNS at higher rates, then, get on with it and make it happen.  I could not agree more.  This is -- for people like me -- a very serious limitation.  Its unfortunate that there are no performance specs which show the VPN rates thru the Puma 6 and 7 modems.  Indeed because had I known then I possibly would have stuck with Bell! If there were, potential customers could decide if it was worth it or not to sign up for an ISP, given the throughput specs.  Remember that were talking about Puma 6 and 7 modems used worldwide, not just with Rogers.  Point noted!

---

[HughR]

@joelcyyz

Slowing down VPN traffic violates any reasonable definition of net neutrality.  The CRTC supports net neutrality.

One possible cause is that your VPN packets are traversing WiFi too many times.  You confirmed the topology:

iPhone <-> CODA <-> notebook <-> CODA <-> cloud...

If three of those links are WiFi, that might explain the slowdown.  If so, does wiring the Mac to the CODA (eliminating two WiFi hops) improve performance significantly?

If the slowing down is due to the CODA, then that is just a defect / limitation.  What mechanism in the CODA could cause this?  Here are some things that come to mind:

• policy -- they (Rogers?) want to slow down VPNs.  That violates net neutrality.
• VPN pass-through requires the CODA's CPU to manipulate the packet in a way that normal packets don't require.  For example, for ordinary NATted packets, some routers have a fast-path hardware (does the CODA?) but that hardware probably cannot handle VPN pass-through.  I admit that I know little about L2TP and how the packets need to be mangled for pass-through.
• some unintentional firmware stupidity.  Hope for a fix but don't expect one.

If the problem is that the CODA is bad at VPN pass-through, consider trying bridge mode.  Then the CODA should not process any kinds of packets differently (more slowly).  This would require you to install your own router.  Choosing a router is tricky but is discussed somewhat in this thread.

We've recently been told that Rogers + CODA in bridge mode allows two devices directly on the internet, each with its own globally routable IPv4 address!  You could put your Mac-as-security-gateway directly on the net and the non-VPNed things in your house behind a 3rd party router directly on the net.  That would require making sure that your Mac is secure enough for the task.  I would hope that your Mac would be wired to the CODA and the devices you connect to the Mac-as-security-gateway would talk directly to it via WiFi.  The result is a much simpler topology than you currently have and less likely to have weird bottlenecks.

How are allowed to configure your network with a VPN is really constrained by your corporation's policies.  I know nothing of them but you should.  My router implements IPSec VPNs -- that's one of the reasons why I use a PC as my router; that's a fair bit of work.

[joelcyyz]

---

Hugh, as above, please see my in-line responses which appear in red below.

Thx!


@HughR wrote:

@joelcyyz

Slowing down VPN traffic violates any reasonable definition of net neutrality.  The CRTC supports net neutrality.  I would tend to agree with that!

One possible cause is that your VPN packets are traversing WiFi too many times.  You confirmed the topology:

iPhone <-> CODA <-> notebook <-> CODA <-> cloud...

If three of those links are WiFi, that might explain the slowdown.  If so, does wiring the Mac to the CODA (eliminating two WiFi hops) improve performance significantly? CODA<->Notebook<->CODA<->Cloud is wired...

If the slowing down is due to the CODA, then that is just a defect / limitation I may be incorrect in my conclusion but it is the only thing in the chain that has changed and, in addition, only VPN is impacted (i.e. TeamViewer is not impacted, Screen Sharing is not impacted, etc.).  What mechanism in the CODA could cause this?  Here are some things that come to mind:

• policy -- they (Rogers?) want to slow down VPNs.  That violates net neutrality.  Does not make it impossible.  The Rogers support person I spoke to told me that they specifically do not support servers so, assuming this is true, then slowing VPNs makes sense as it would be a way of achieving this.
• VPN pass-through requires the CODA's CPU to manipulate the packet in a way that normal packets don't require.  For example, for ordinary NATted packets, some routers have a fast-path hardware (does the CODA?) but that hardware probably cannot handle VPN pass-through.  I admit that I know little about L2TP and how the packets need to be mangled for pass-through.
• some unintentional firmware stupidity.  Hope for a fix but don't expect one.

If the problem is that the CODA is bad at VPN pass-through, consider trying bridge mode.  Then the CODA should not process any kinds of packets differently (more slowly).  This would require you to install your own router.  Choosing a router is tricky but is discussed somewhat in this thread.  I have thought about this and I have discussed this but would prefer not to!

We've recently been told that Rogers + CODA in bridge mode allows two devices directly on the internet, each with its own globally routable IPv4 address!  You could put your Mac-as-security-gateway directly on the net and the non-VPNed things in your house behind a 3rd party router directly on the net.  That would require making sure that your Mac is secure enough for the task.  I would hope that your Mac would be wired to the CODA and the devices you connect to the Mac-as-security-gateway would talk directly to it via WiFi.  The result is a much simpler topology than you currently have and less likely to have weird bottlenecks.

How are allowed to configure your network with a VPN is really constrained by your corporation's policies.  I know nothing of them but you should.  My router implements IPSec VPNs -- that's one of the reasons why I use a PC as my router; that's a fair bit of work. No corporation involved here.  It is just me -- as an individual -- wanting to dial in to home network at various points during the day, no more!

---

[unidisk]

It seems to me that you are terminating the VPN traffic in the CODA. This requires the CODA to encrypt and decrypt the L2TP packet payload. So a router that equipped with hardware encryption/decryption will help. I am not sure if CODA is capable of performing the hardware encryption/decryption. If it does the work in software then it will significantly slow down the throughput. You can follow the suggestion to put CODA in the bridge mode and use an external router. The Mikrotik 750G router that has hardware encryption with 470Mbps throughput.

https://mikrotik.com/product/RB750Gr3

I have been using it and it has been very stable.

[Datalink]

@unidisk, are you able to run a speedtest thru the VPN using the www.speedtest.net Toronto Rogers or Montreal Rogers server, or a high speed server at the termination point of your VPN?  I'm wonder what data rates you might see?  I'm assuming here that you have the white CODA-4582 modem? 

[joelcyyz]

---

@unidisk wrote:

It seems to me that you are terminating the VPN traffic in the CODA. This requires the CODA to encrypt and decrypt the L2TP packet payload. So a router that equipped with hardware encryption/decryption will help. I am not sure if CODA is capable of performing the hardware encryption/decryption. If it does the work in software then it will significantly slow down the throughput. You can follow the suggestion to put CODA in the bridge mode and use an external router. The Mikrotik 750G router that has hardware encryption with 470Mbps throughput.

https://mikrotik.com/product/RB750Gr3

I have been using it and it has been very stable.

I am surprised by your above comment but am happy to learn more.  Please explain why you wrote that I am terminating the VON traffic at the CODA because in my way of thinking I am terminating the VPN traffic on my laptop (which is hard wired to the CODA) because the VPN server / software sits on my laptop.

TIA!

---

[daveinsurgent]

I continue to have packet loss.

Edit: > This ONLY started to happen when I switched to the CODA-4582 modem.

Rogers Support has suggested that I need to come to this forum for further assistance because there's "nothing wrong with my modem" etc.

I have replaced my ethernet cables, and my router, and used the modem as a router or a bridge, and I have connected my PC directly to the modem in bridge mode with windows firewall off. This is NOT a NAT or port forwarding issue. It happens in multiple games (Rainbow Six: Siege, Battlefield 4 are what I tested). These games have an in-game overlay for "you're having network problems!" and specifically ones for packetloss which show up. My ping can randomly jump from 40ms to 150ms too.

Here's output from mtr which was running for a while:

Focusing on 174.114.112.1, which is not MY IP, I can ping this IP and it generally responds around 20-40ms.  If I introduce any kind of network traffic on my end, the pings to this IP spike dramatically and packet loss occurs. 

I am at work, and I started pinging 174.114.112.1, and it pinged fine. Then I SSH'd in to a machine at home, and ran ping again. Then I ran a speed test. Pings to that IP from my work terminal remained fine. Pings to that IP from my server machine spiked up like this.

I'm at a loss for what to do next.

[HughR]

@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).

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

[Datalink]

@daveinsurgent you have packet loss on the first and second hops in the trace.  Is that first hop your router?  If so, I'm assuming that the modem is in Bridge mode, which would make the second hop the CMTS.  You shouldn't have any packet loss in either case.  First step is to determine why you have packet loss to the first hop address, whether its the router or modem.

[MegnaGaming]

@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.

[daveinsurgent]

@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.

[joelcyyz]

---

@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!

---

[HughR]

@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.

[wayner92]

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.  

[HughR]

---

@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.

[joelcyyz]

---

@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!

---

[joelcyyz]

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?