A Gear-Swapping Flurry: Gratuitous Worry (?)

In preparation for my end-of-month fiber trial, and less than 24 hours after experiencing extreme networking angst, I'm proving that I'm a sucker for punishment; I've plunged back into the Ethernet fire and upgraded my LAN router. My faithful but archaic (and incredibly dusty!) Netopia R9100 is out, and replacing it is Linksys' dual-WAN RV042. At least for the moment, that is; I'd actually requested an RT042 from Linksys PR, and I'm tracking down what the differences between them are.

At first glance, the RV042 doesn't appear to have its sibling's QoS capabilities, but then again QoS is arguably unnecessary with a 50 Mbps downstream fiber pipe (but we'll have to see what SureWest's upstream bandwidth and latency end up being….), and I still have the Hawking HBB1 installed for the now-'slow' 1.2 Mbps DSL connection. I have ZyXEL ZyWALL 35 UTM and Hawking FR24 routers in-hand that I'll likely also test-drive; I fired up the RV042 first because its feature set (and price tag) seemed to be a better fit for a home-based office, versus in a more elaborate small office setup where the ZyXEL unit's capabilities would be more attractive (and its higher price would be more tolerable). The Hawking unit is labeled ‘legacy’ by its manufacturer, and its latest firmware release is almost two years old at this point.

Ahead of the router migration, I converted as many of my LAN's clients to DHCP assignments as possible. My Belkin access points only support static IP mode, so I moved their addresses outside of the default RV042 DHCP assignment range. Then, after offline-upgrading the RV042's firmware to the latest-available version, I powered down the R9100, swapped CAT5e cabling from it to the Linksys router, and powered it up. And….

….boom, I'm up, just like that. I punched in my DSL account's static IP WAN parameters, and I was immediately on the 'Net, with no noticeable speed degradation compared to the prior configuration:

One by one, LAN clients are receiving new DHCP assignments; I can monitor their progress via the router's log page. This is happening quite speedily, because the old router's DHCP lease time was set to 60 minutes; on the new router, it's 24 hours. Yes, it's kind of cool to watch (yes, I'm a geek). And I must confess that in comparison to the RV042's well-organized web server approach, I don't miss the R9100's telnet-based character mode configuration and status screens one bit

Happy weekend, all. And yes, I realize that I've just jinxed myself by publishing this writeup. Stay tuned for next Monday's edition, wherein I'll relay my weekend-from-hell as a pseudo IT administrator.

Followup: It's Sunday evening, and all's still well with the RV042. I've opened up firewall holes and set up NAT forwarding for Xbox Live (UDP port 88, and TCP/UDP port 3074), Internet Print Protocol (TCP/UDP port 631) and µTorrent (port number varies depending on client configuration, but both TCP and UDP ports must be open). I've only got four admittedly minor grumbles thus far:

1. While I can change the login password for web administration, the default login name 'admin' is user-unalterable
2. The router supports emailing log files and alert messages to the administrator, but since the SMTP port is unchangeable and the router also doesn't support authentication and SSL for outgoing email, I can't take advantage of the email features.
3. I can't define a single service that encompasses both TCP and UDP for a given port. If I have to open and/or forward a particular port, I have to create redundant services for both protocols, as well as redundant forwarding and firewall-opening definiitions.
4. The 'Logout' link doesn't seem to work under Firefox 1.5.0.11.

Followup: I'm running across one other notable idiosyncracy with this router. With the R9100, and once a LAN client had received its initial DHCP assignment, its information was retained in the router log. Any network traffic to or from it was sufficient to keep it active, and if (for example) I went on a few-day business trip, the log entry for my laptop would eventually turn into a 'last accessed' notation until I returned home.

With the RV042, things operate a bit different. Unless (it seems) a DHCP client explicitly requests a DHCP renewal, its entry in the DHCP assignment table eventually disappears. Once it does renew, it gets its former IP address assignment back (I think….I'm not completely sure about that) but until it renews, NAT forwards to it fail, etc. For example, I'm not able to print to my IPP-cognizant print server from the WAN right now, because apparently the print server hasn't done a DHCP renewal request, although I'm confident that the print server's still up and running.

My web research on this issue suggests that one way to fix it, which apparently the R9100 did by default, is to make explicit static DHCP assignments within the router for various LAN clients' MAC addresses. But I'm thinking that if I'm going to go to the trouble of doing this, I might as well instead directly set up appropriate LAN clients in static IP mode. This is what I'll probably do once I get home this evening, with the print server and anything else that I might want to 'touch' from the WAN (such as a computer running RealVNC Server). Stay tuned for more….