Cisco Wireless -N Home Router WRT120N

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

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

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

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

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,

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

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

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

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

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.

Modem and router are irrelevant, but continue.

Yes, I pointed that out earlier in this thread. That's what ultimately prompted me to generate traffic and then disconnect the modem's coax, revealing that router-to-modem traffic was indeed hitting the ISP's gateway. Note that routers can be configured NOT to decrement the TTL, thereby becoming invisible to traceroute. That's what's happening here.

You can test it yourself like I did, or if you have a hub you can insert it between the router and modem and watch the outgoing 'modem' traffic. You'll see that it's destined for the default gateway, not the modem. It's the default gateway that either forwards the traffic back to the modem or drops it. (Until you configure a static route, of course.)

It looks like standard IP behavior to me.