Netgear LG 6100D Sprint LTE Gateway – Advanced Configuration

Man, oh man! I was getting frustrated with my new 6100D LTE gateway from Sprint. In fact, I posted a very long rant about it yesterday.

This post is all about solutions.

Really, it’s about one very big solution:

http://[Netgear 6100D Address]/index.asp

What is that? Oh, not much, just the native Netgear configuration GUI.

It has about ten times the feature set of Sprint’s half-baked GUI. Seriously.

Already have a problem?

This didn’t happen to me at first, but I must have triggered some state within the 6100D that causes this screen to appear when returning to the Netgear GUI after having used the Sprint GUI:

If you find yourself redirected to this utterly pointless landing page, just change the path of the URL to /adv_index.asp (I assume you want the advanced config page).

Clicking “Take me to the Internet” uselessly takes you to Netgear’s site.

The good…

What can it do that the Sprint branded GUI can’t?

• Static routes
• Ability to turn the DLNA server off (Sprint doesn’t even mention it, but it’s enabled by default)
• Multicast settings
• UPnP advertisement settings (as opposed to just on or off)
• Better port forwarding settings with port triggering
• Wireless repeater settings
• The ability to disable the WiFi radios Update: Though this option exists, hitting the “Apply” button on the page does nothing.
• FTP server settings
• Email notification settings (for alerts and logs)
• A DMZ server setting that lets you change all four octets
• VPN passthrough settings
• RIP settings
• QoS settings
• The menu system is generally organized in a logical fashion and it’s easy to navigate
• The ability to send and receive SMS messages (It doesn’t work for me, but that’s probably because my plan doesn’t include SMS)

…and that’s just what I found on my first quick look.

Sprint completely crippled this device.

…the bad and the ugly

• Sometimes the Netgear GUI redirects you to a page that asks if you want to use a wizard to configure the router or configure it manually. A minor annoyance.
• The interface has a very 90s look and feel (as opposed to the Sprint-branded interface which is cleaner)
• There’s a link to “documentation”, which opens up a window for the N600 Wireless Dual Band Gigabit Router*
• I still can’t find a place to turn off the telnet console
• Strangely the date and time settings only list “AU 2011-2012″ as a daylight savings time option.
• They really can’t get their timezone knowledge together. On the Sprint GUI it lists “EST (Central Standard Time)”, and in the Netgear GUI the timezone options are “EST”, “CST”, and “WST” (which should be PST).
• After using the Netgear web GUI and going back to the Sprint-branded GUI, it requires that you agree to the EULA again. This makes me think that at least one flag is getting wiped out when the Netgear GUI re-writes the config.

*Check out the N600 User Manual. It describes a lot of the 6100D settings in more detail than the Sprint documentation.

Major flaws

I don’t mean to harp on this, but it’s so significant that I can’t help it:

There is an an unprotected telnet server that cannot be turned off, requires no authentication, and lets anyone view and MODIFY the router’s config. This includes VIEWING THE ADMIN PASSWORD IN PLAINTEXT!

I’ve hit another bug twice now:

For no consistent reason that I can discern, the device will start flooding the LAN with IGMP (multicast) messages. For example:

15:25:09.027136 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [none], proto IGMP (2), length 36, options (RA))
    10.222.2.1 > 224.0.0.1: igmp query v3

It’s creating these messages as fast as it can; When this is happening igmpproxy uses around 75% CPU with the remainder used for IO. The GUI also becomes unresponsive. Fortunately BusyBox (via telnet) does not, so a remote reboot is possible.

This IGMP activity lasts a few minutes, but then refreshing the GUI causes (?) it to start again. I haven’t spent a lot of time testing this issue, but it is a PITA.

Then we have a nice one where the router seems use THE MAC ADDRESS for port forwarding regardless of the actual IP setting.

For example, let’s look at this composite of screencaps:

What’s going on here?

On the top is the active port forwarding configuration of the 6100D, after a save. On the bottom is a tcpdump of the traffic between the 6100D and my core router.

The 6100D is sending traffic to 10.222.2.3 even though I have it set to send traffic to 10.222.1.1.

Where is it getting the IP address 10.222.2.3? Well, it’s right there in the lower right of the device settings. But that option is NOT selected.

Why is it showing that IP? Without getting into too much detail, I have two core routers running in a master/backup configuration. They each have a “real” IP on the 10.222.1.0/16 network (last octets being 3 and 4 respectively, as well as a VIP (last octet of 1).

The routers are also my VPN servers, so I want VPN traffic (in this example) sent to the VIP, which is 10.222.1.1. This way it doesn’t matter if the backup router takes over; The VIP will be reassigned to it and traffic will continue to flow.

The address of 10.222.2.3 came from a misconfiguration (my fault). I forgot to change that when I changed the VIP. That is no big deal in this case, because this is a /16 (class B) network, and so 10.222.2.3 and 10.222.1.1 can coexist on it just fine.

My misconfiguration is not the cause of the problem, because even after I changed the “real” IP on the router to 10.222.1.3, it still sent traffic to that IP instead of the VIP!

However, both the “real” IP and the VIP have the same MAC address. This shouldn’t be a problem either, because we only need to use the ARP table to find the MAC address for the IP, and not the other way around. Here’s the ARP table on the 6100D:

For some reason it’s picking the first MAC address and forwarding traffic there; I have no idea why they designed it like that!

Let’s dig into the config file (located at /WFIO/current.cfg in the 6100D’s unsecured BusyBox environment):

table=FWPortRedirectionConfig;
columns=Enable;Nickname;Protocol;WANPortStart;WANPortEnd;LANIPAddress;LANPortStart;INSTNUM;isPredefined;isMore;portMapIndex;HostName;Permissions;Le
0;Westell Modem Service VoIP SIP;udp;5060;5060;MODEMREDIRECT;5060;1;1;0;0;;0;0;0;;
1;Westell Modem Service Envoy;tcp;6363;6363;MODEMREDIRECT;6363;2;1;0;0;;0;0;0;;
1;Westell Modem Service Rip;udp;520;520;MODEMREDIRECT;520;3;1;0;0;;0;0;0;;
1;VPN (SMR);tcp;1199;1199;10.222.1.3;1199;4;1;0;3;10.222.1.1;GUI, TR069;0;0;d4:ae:52:d4:62:02;

First of all, why does it have two services enabled by default and not listed in the GUI?

Secondly, the last line is my entry. You’ll see that it has 10.222.1.3 listed as well as 10.222.1.1. Well, looking at the column headers it decided to stick in 10.222.1.3 as the LANIPAddress, with a HostName of 10.222.1.1.

So the setting in the GUI for “Internal IP address” is actually the setting for the host name!?!?

The worst part is that if I go into the BusyBox environment and manually change the LANIPAddress field to the correct IP, upon reboot it changes it right back. There’s no way to win with this thing!

The problem arises that both of my core routers have different MAC addresses. So if this thing is basing its decisions on the MAC address, what’s going to happen when the master fails and the backup takes over? The master’s MAC address will be offline. The VIP will still be online, but this thing may just ignore it.

(By the way, this is a testing environment. That’s why you don’t see an entry in the ARP table for the backup router’s IP.)

I could remove the “real” IP address from the routers and just use a VIP, but that is irritating from an administrative perspective because the backup router will be unaddressable on this network. Also, it may not solve the problem because the MAC address of the VIP will of course change in the event of a failure.

I also can’t give the master and backup the same MAC address, because that would confuse any device connected to this network.

Sigh. This will require more testing.

SOLVED!

The solution is simple, obvious, and of course it took a couple of hours to think of it:

Put the 6100D on its own /24 and give the core routers a VIP in that /24.

In other words, the LAN configuration on the 6100D is now:

IP: 10.222.2.11
Mask: 255.255.255.0

And the core routers now share:

VIP: 10.222.2.1 with a mask of 255.255.255.0

For administrative purposes (and expansion, etc) the master core router still holds its “real” IP of 10.222.1.3, but it’s now masked as a /24, and it still has a VIP of 10.222.1.1/24.

Despite having yet another IP on that physical network, it’s fenced from the others by its subnet mask (so the 6100D isn’t just basing its decisions on the MAC address). Here we see the correct IP is detected for the core router’s MAC address:

Apparently the 6100D is a real slave to subnets.

Config diffs

Before fiddling with port forwarding and various other settings, I saved one setting in the Netgear GUI: I added a static route. That resulted in this snippet being added to the config file:

table=StaticNetworkConfig;
columns=Enabled;Nickname;InterfaceTable;InterfaceReference;RouteType;IPDestination;IPNetmask;IPGateway;Metric;RIPAdvertised;SaveToFlash;INSTNUM;
1;Test Route;;;Network;10.78.1.0;255.255.255.0;10.222.1.1;10;1;1;2;

The following entry was also added, even though I didn’t modify the NTP settings:

table=NTPConfig;
columns=Enabled;NTPServer;NTPServerSec;Interval;DayLightSavingsUsed;LocalTimeZone;BackoffIntervalMin;BackoffIntervalMax;TimeZoneName;DayLightSavingsStart;DayLightSavingsEnd;
0;time-b.netgear.com;time-a.netgear.com;3600;1;GMT+5;5;60;;M4.1.0/02:00:00;M10.5.0/02:00:00;

Otherwise it doesn’t look like anything else was altered, aside from some timestamps (phew). More importantly, the router still works!

That’s important because I was concerned that the Netgear GUI might wipe out or otherwise alter important settings that the Sprint GUI had added in.

I keep talking about the GUIs because the fact is that I don’t know if there is any difference between the two GUIs as far as configuration management on the back end goes. They may well use the same configuration management scheme, in which case of course they won’t conflict! But it’s possible that they manage the config differently, and could kill each other’s settings.

Disclaimer

I just found out about this roughly 30 minutes ago. I have no idea what undesirable consequences might arise from changing settings in the Netgear GUI. I don’t even know if all of them will work as intended. So use this information at your own risk!