Cisco Wireless -N Home Router WRT120N

A common user interface is great once you've learned it. The problem is the initial learning curve. My guess(tm) is that there are perhaps

10 times as many options, checkboxes, and obscure features scattered among the various DD-WRT management pages. For some models, loading the firmware is an ordeal process, where a comatose router is the reward for failing to follow the instructions exactly.

Many useful features (such as being able to directly configure an attached cable or DSL modem), require command line incantations to configure. Another example is guest access on a separate subnet. That's a standard feature on most commodity routers made in the last 2 years. For dd-wrt, here's the procedure:

As for the defaults being sensible, there are a few that I would change. Saving the DHCP status (MAC address table), between reboots is useful, until you try it at a coffee shop which could easily see thousands of MAC addresses. Probably a few more I could complain about, but I don't want to look right now.

As for routers pre-loaded with DD-WRT, to the best of my knowledge, only Buffalo offers retail "powered by dd-wrt" products.

In comp.dcom.lans.ethernet miso wrote in part:

GPL violations are usually failure to publish source. Easy to cure, just give the source to anyone who legitimately has the device/binary and requests it. Not at all easy to figure out to whom you might pay a royalty. The Linux kernel has hundreds if not thousands of authors, all of whom would have to give you a separate licence. Virtually impossible, so delivering source is easier.

-- Robert

Just curious, can you give an example of a cable modem that can be configured by the user (versus the cable company)? I can't think of any modems, or modem features, that allow that.*

*Not without flashing the firmware, I mean.

Ok, I won't mention the cable modem hacking guide.

I shouldn't have used "configure" and cable modem in the same sentence. There's nothing that can be changed by the user as literally all the parameters and settings are performed via DHCP extensions from the CMTS. However, on Comcast, the user can connect to 192.168.100.254 and obtain connection status, signal levels, and other interesting info.

It's more useful with a DSL modem, where users actually have access to settings that they can change and screw up. Here's the setup for DD-WRT to create what I think is a static route to the WAN side of the router so that LAN users can talk to the modem.

It took me about an hour to decode the instructions, fix my errors, and make it work. It's now in all my DD-WRT installations.

So you think Cisco has some call it "sexy code" that they don't want to publish so they just completely pulled the firmware? But the firmware is out there, so wouldn't that mean the products in the field violate the GPL?

It would be interesting to go through the support website and see how many routers for which they won't supply the firmware. Obviously a tedious task.

I suspect the vast majority of contributors wouldn't want one's money anyway

- after all there's a reason they made their contributions under the GPL in the first place.

My guess it was written by an ODM and they don't have the source in the first place. Perhaps they've had to do some arm-twisting to get it subsequently.

No need, I'm quite familiar with that aspect.

IME, most cable modems seem to have followed the Motorola example and put their web server at 192.168.100.1. I've only seen the .254 address on some 2Wire DSL modems. No NAT router configuration is required to reach the 192.168.100.x subnet because it's outside of the LAN in every case I've stumbled across, although now that I've said that I suppose I'll encounter someone who has configured their LAN to be on the 192.168.100.x subnet and can't figure out why they can't see past their router to view their cable modem status.

Yuck. Happily, I've never run into that. Good to know there's a solution, just in case.

So much for my photographic memory.

Try it. I think you'll be surprised. What the router will do is assume that access to every IP address outside of the NAT address space is reached through the default gateway address. For example, if the NAT LAN side is at 192.168.1.xxx, and you try to view

192.168.100.1 with your web browser, the router will dutifully send the request to the ISP's default gateway. Note that this is the ISP's default gateway, not the router IP.

In order to avoid having everything outside of the NAT address block go out via the ISP default gateway, you need to setup a static route on the WAN side of the router. The ugly mess below is how DD-WRT does it.

Even if the user mis-configures their router to use 192.168.100.xxx as their NAT address space, it still won't work. The router has to decide which side of the router the 192.168.100.1 address is located. The assumption is that since it's in the NAT address space, it must be on the LAN side. It won't look on the WAN side. This is a problem with older DSL modems, that default to 192.168.0.1. This also explains why many newer routers now default to 192.168.2.xxx.

I've found very few consumer level routers that can successfully configure the modem through the router. The conglomerated devices, that have the modem and router in the same package, such as the 2wire

2700HG-B DSL modem/router, will do it. Since it's all in one box, a single management IP address is used to configure both the modem and the router, thus eliminating the need for elaborate routing.

You will run into it with most consumer router installation. One reason I use DD-WRT is that I can do such tricks. It's not often that I have to look at the modem config, but they do exist. For example, I have a situation where the DSL signal levels and SNR seem to be varying. I login remotely (using TeamViewer) to the customers PC, connect to the DSL modem at 192.168.0.1, and look at the numbers.

Well that is about 90% of the story I was looking for. Thanks. However, If Cisco published the source per the lawsuit, then why is the firmware off their website?

This router came out long after the Linksys buyout. It could have remnants of the old code, but you would think Cisco would have cleaned things up by then. The buyout was in 2003. The WRT330N came out around

2007 based on reviews.

I wonder if Cisco just paid enough to cover the FSF legal costs, or really made a significant contribution to the cause.

I'm not sure how to test what I think you're saying. With a live Internet connection, a traceroute to the modem's web interface shows the NAT router as the first hop, with hop 2 being the destination, the modem. No mention of the ISP gateway there, but I wonder if you're saying it happens but is silent. I'm not set up to do packet captures on the WAN side of the router so I can't tell. The router's routing table doesn't have an entry for 192.168.100.x so I suppose it does have to bounce off the ISP's gateway, after all.

Well, other than the modem traffic (perhaps), you'd *want* everything outside of the NAT block to hit the ISP default gateway, right?

No, I was saying the opposite. It always works *unless* the user misconfigures their router to use 192.168.100.x on the LAN side. If that happens, you have the scenario you described directly below, but I haven't run into that and if I ever do, it will be easy to identify and likely easy to fix.

I haven't seen a router that *can't* access a modem on the router's WAN side, so I assume you're limiting that statement in some way that I'm not aware of.

So far, I'm not understanding what triggers the requirement to set up this static route. I haven't run into it so I assume I've been lucky, but I hate to depend on luck, especially with (potentially) a customer looking over my shoulder.

Take a DSL or cable modem. If possible, set the DSL modem to "bridge mode" so that there isn't a 2nd set of IP addresses (double NAT) involved. Attach a consumer grade router to the modem. Configure as needed (i.e. PPPoE login/passwd). Make sure you can browse the internet.

For the test, try to connect to 192.168.0.1, 192.168.100.1,

192.168.100.254 or whatever the modem management interface uses. Most likely, it won't work.

I have about 4 assorted routers in my car. I'll try it later and report some results.

Using traceroute, my Buffalo WHR-HP-G54 router, configured with a static route to the entire 192.168.0.xxx subnet on the WAN side, as described in:

using:

returns:

Also, when I point my browser to: I'm able to see my DSL modem (Speedstream 4100) config page.

When I temporarily disable the static route by deleting the static route, I'm not able to connect to the DSL modem config page and traceroute shows:

Note that the packets are now going out via the default gateway to my ISP. Hmmm... that's odd. I can traceroute and ping 192.168.0.1 successfully, but I can't see anything with the web browser. Time for a reboot. To be continued...

[63.249.85.1]

Same thing after rebooting everything. The return from 192.168.0.1 is coming via the ISP (note the latency time) and not directly from the modem. However, my browser can't see the DSL modem. That means that my Speedstream 4100 is responding to 192.168.0.1 on the WAN side, but not allowing remote config on port 80 from the WAN side. However, it might work on a different port number. Very strange.

More later tonite after I do some more testing with other routers.

WRT120n is not listed.

My guess(tm) is that it's missing for the same reason that some firmware updates are missing for obsolete products from other vendors. The product, firmware, or both are known to be defective. Rather the propagate a known bad product, which tends to attract product liability attorneys, the vendor has simple removed all evidence that the product even existed. Since the WRT120n seems to have chronic and apparently incurable problems, I suspect that Linksys also removed all evidence of having produced a lemon.

I wonder if the key is to have the DSL modem in bridge mode. I realize that's a valid configuration, but I haven't personally seen it here. DSL isn't popular in my area to start with, and the few DSL implementations I've played with haven't been set up that way.

DSL in routed mode, and all cable modem implementations that I've seen, don't seem to need the explicit route table entries you mentioned. They just work.

Update to the "they just work" comment. It seems that my previous hypothesis might be correct in that the ISP's gateway (Comcast, anyway. Can't speak for DSL at the moment but it may be the same) has a static route pointing back to each modem, mostly eliminating the need for the static route to be set up in the NAT router.

What this means is that the modem's web GUI is reachable without any user configuration, but only if the modem has established a connection to the ISP's network. Without that connection being up, other accommodations need to be made, such as setting up a static route locally or placing the NAT router's WAN interface (or the PC, if directly connected) in the 192.168.100.x subnet.

You can test this by doing a continuous ping to 192.168.100.1 and then disconnecting the cable modem's coax. Not only is the target IP no longer reachable, the error message is "

Ummm... you're disconnecting both the outgoing and incoming route when you disconnect the cable modem's coax. Of course it will fail. However, it is proof that the pings are going out to the ISP's router, and not going to the local cable modem.

I just tried it with a Linksys E1000, and a WRT54G2 router. It did exactly the same thing as the Buffalo WHR-HP-G54 running DD-WRT, with one minor oddity. Note the increased latency. Traceroute looks like this:

Pointing the web browser to 192.168.0.1 (IP address of the DSL modem) still does not produce the config web page with either router.

I tried to setup a different modem for the default double NAT configuration. However, I ran into a problem. I have a static IP address which will only work with the DSL modem in bridging mode. So, I logged into a customers system, that's fairly close to stock except that they use a Motorola 2210 DSL modem setup in bridged mode:

I also tried it (remotely) from my palatial office:

Again, traffic to the DSL modem's IP address goes out to the ISP. As before, I was unable to access the modem config page through the router. However, all the above systems were setup by me, and I always use the bridged mode in the DSL modem. I'll see if I can find one that uses double NAT.

So, are you able to connect to your cable modem config page from the LAN side of a commodity router? (Not ping or traceroute, but by using a web browser). If so, what is the maker and model number of the cable modem and router? If not, do now you see why I need the static route to the modem?

Say what? I thought I was trying to determine whether traffic to

192.168.100.1 was hitting the ISP's gateway or not. It looks like it does, even though it doesn't show up in a traceroute. The other thing I thought I was determining was whether a static route needs to be configured locally, and it apparently does not.

Or more correctly, they are going through the cable modem to the ISP's default gateway, then back to the modem.

Yes, of course. I've been doing it since cable Internet came to the area in about 1996.

Router is any, including multiple models of all the common brand names: Linksys (stock firmware, Tomato, dd-wrt, etc.), Netgear, D-Link, Belkin, TrendNet, and a bunch I've probably only heard of once. Cable modems are the usual Motorola models, most typically the

5x00 series and 6x00 series, as well as some Thomsen's.

No, not really. From what I can tell, if the Internet connection is up the locally configured static route is completely unnecessary, and that is 100% of the cases for me. If the Internet connection is not up I wouldn't be able to remote in in the first place. The edge case is where I'm on site, the Internet connection is down, and I need to see what the modem can tell me. In that case, I'd probably just connect directly to the modem, bypassing the router and bypassing the need for a static route.

Bottom line, I'm still not sure when this static route is needed. Certainly not with cable systems, but also not with the DSL that I've seen, although my DSL experience is very limited.

I think I've solved the mystery, after giving it some thought. It has nothing to do with the make or model of router and nothing to do with the type of modem (cable or DSL) or how it's configured (router or bridge). It comes down to the ISP and whether they have a static route configured on their end to bring modem traffic back to the modem.

Fortunately for me, the 3 cable ISP's in my area, Comcast, Time Warner, and Surewest, and the single DSL ISP, at&t, all provide such a static route. This basically means I don't need to worry about configuring the route myself, except for a few fringe cases that don't really apply to me.

The ISP's in your area are apparently less customer friendly and require you to configure the route yourself. I have no explanation for that, other than possibly a we-don't-care attitude.

I just came from a customer with Comcast service. Arris TM502G modem and Netgear WGR614v6 router. I can see the modem config page at

192.168.100.1 the way you describe without any static route tricks. However, I'm not sure that the ISP has provided a route to the modem back from the ISP gateway router as you suspect. When I run traceroute, it shows up as two hops. Same as in the original static route example. Something like this:

Note that the gateway router is not on the route, that the response from the cable modem is quick, and that it does not include any additional delays I would expect if the packets were going the long way via the ISP. It's identical to what I got when I setup a static route to the modem. Something else is going on, but I don't know what.

I'll ask some of the local DSL ISP's and see how they respond. Might as well as in ba.internet and get a consensus. I don't think it's a conspiracy. Actually, it may have been a botched implementation. Without a static route, I can ping or traceroute to the modem interface. What I can't do is get a web page on port 80 which suggests a partial implementation.