RV042 Experiences

I haven't been able to find any extensive reviews on the RV042. I know it uses the same base as the RV082 but has half the number of ports. I'd like to get a feel for people's experience with this product and how it rates overall against other products with similar price points. One of the main things I'm interested in is active content filtering, which some of the more expensive ZyWall products support via Cerberian.

The RV042 works just fine for me with one exception: The DMZ port. When it is in DMZ mode (the reason I bought the RV042) packets from the WAN port do not get routed to the DMZ port. This makes the RV042 completely useless for me.

To make matters worse, Linksys tech support sent me a beta firmware to download to the router. Guess what? It completely killed the router.

Linksys won't tell me when the RV042's DMZ port will work. They won't give me my money back. And they won't give me credit to exchange it for an RV082 (which has the DMZ bug fixed).

My advice: If you want the DMZ port functionality get the RV082 instead.

I spent the better part of my Christmas vacation trying to set a VPN router up for a client. I tried the WRV54G (twice) which I, along with the 3rd level support guy at Linksys (Cisco), believe is a piece of crap. He was the one that recommended the RV042 to me and stated that it was "stable as cakes, man."

One thing you Must do if you use it is upgrade the firmware to at least the one release on Dec. 30, 2004. Btw, that was another reason I had issues.

I am still having problems with their quickVPN software as it disconnects after about two minutes of inactivity.

I really think Cisco/Linksys has been putting more attention on the RV082 and not the RV042. The RV042 does not come with a built-in PPtP server like the RV082. Nor does the RV042 have a section for Client Access so that QuickVPN client users can access the RV042. Many people have mentioned that they need the "HTTPS Service" enabled on the Firewall tab for QuickVPN, but there isn't one in the most latest firmware for the RV042 (v1.3.1).

All in all, I ended up going back to buying and using an RV082 to use with QuickVPN. The RV042 worked great as a gateway-to-gateway VPN for me (using a Symantec 200 Firewall/VPN Appliance) and seems to work great as a client-to-gateway VPN. Just don't expect the RV042 to be exactly the same as the RV082 with 4 less Ethernet ports....

The firmware Iâ€™m using is 1.3.6 there is also a 1.3.3 Iâ€™m still having problems with these routers and there should be no diff from RV042 and RV082 the firmwares are probably different because of the number of ports.
I am not very happy with this product at all.

It refuses to load balance.... just REFUSES!!! I works... sometimes... when it feels like... but most of the time, it just uses only one WAN port, nothing seems to make a different, I hate this thing. DIE DIE!!!

I've been struggling to get my rv042 vpn connections to work. Lots of interesting messages in the log about SIOCADDDV - No such device when I reboot or create a new VPN connection. Needless to say I have had random success with connecting remotely.

I've seen posts about 1.3.3 and 1.3.6 level firmware? Where is this available? Support requests to Linksys are pointless, either I get someone on the phone that's clueless or standard faq responses via email and then no response until the ticket is auto closed.

First off, I want to say that I really want to like this router.
Anyone that would put their electronic product in an aluminum case instead of a plastic one is alright by me!

However, . . . The software on the RV042 leaves a lot to be desired.

I have two of these connected over the internet in a VPN tunnel running what I thought was the latest firmware (1.3.1).
The first thing I noticed, was that the Dynamic DNS client was abusing the DYNDNS.ORG service, and shutting me out.
OK. . . no problem. I will just use their software client and disable the one on the router.
Then I noticed that when I enabled compression (under Advanced Settings), the largest packet to transverse the tunnel was 64 bytes!
Problem! Oh well, disable compression.

And lastly, . . . no matter how I tried, I could not see any of the workstations on the far side of the tunnel in Network Neighborhood. I could ping them all day long, just not see them in the GUI.
I have NetBIOS broadcast turned on on both sides, with no luck!

Contacting Linksys Tech Support is an exercise in frustration. The guy on the other end is on the other side of the globe, and very difficult to understand. I would not mind this, if he was somewhat technical, but he isn't.

I realize this is a new released product, but Linksys/Cisco should not release products at this price without SOME Quality Assurance testing!

I would try version 1.3.3 it is on this site somewhere also i agree the software needs some work on this router other than that it seems ok and for your vpn try maping the drives or manualy putting in the computer with the \\10.10.10.25(ip of remote vpn computer running netbios) and see if that works

I may work on making a firmware for this, please see my console mod about how to be able to log into the device via the console. I'll also be posting any findings I have.. In there or in another thread.

What a difference new firmware makes!
I contacted Linksys and was able to reach a backline guy and obtain the 1.3.6 firmware.

This fixed the DYNDNS client issue.

It kind of fixed the Compression issue. It allowed an increased in the size of the ping to 488 bytes instead of the 64.

I think it fixed the NetBios issue, as I can now see the NetBios name of a print server on the far end of the tunnel. I still can not see the rest of the dozen XP workstations and Windows 2003 server that are there. I would expect to at least see the domain.

I still want to like this product, but I am real nervous about some of the code (and fixes). Something Linksys did provide me was their revision history.

v1.3.0 2004/08/18
1. Support full-range remote management port setting
2. Support full-range configurable Load-balance bandwidth
3. Support the Network Service Detection functionality.
Purpose: It detects the connectivity between Router and specified host.
It will log messages or remove connection when connection dropped.
4. Support the Protocol Binding functionality. It allows users to specify IP or/and service passing through the specified WAN port.
5. Remove the Bandwidth Threshold options. Because it got hard to understand when it working together with the Protocol Binding.
6. Support the DNS Resolved functionality. It allows users to specify the IPSec Remote Security Gateway IP as a DDNS name.

I browsed around a bit and didn't find too much in the way of discussion about how much the Access Rules config interface sucks on the RV042 1.3.1

This is normally a reasonably straight forward interface in almost every brand of gateway I have messed with, from Xincom to various Linksys BEF series, etc.

On the RV042, the rules configuration interface does not allow selection of udp *and* tcp on the same rule, so you have to make two rules. Further more, in trying to port pinholes for PCAnywhere access on my tester, I have failed to get through on the default ports 5631 and 5632. I have successfully configured a tunnel using The Greenbow IPSec client software, and I can control the test machine through the tunnel via PCA, but I can't seem to get the WAN interface to let me in.

Hoping this and the ddns update flooding are fixed with 1.3.6

Software ddns is fine for single WAN installs or even for failover dual WAN installs, but if you want to keep a valid ddns name updated for both WAN connections, there is no simple way that I can think of to do it with software updaters. I was mulling over how I might set up custom port rules and put two software clients on different machines while I was taking a crap this afternoon, but then I remembered, I can't even open a straight pinhole in this thing.

Of course the guys at dyndns.org roll their eyes (virtually) when you ask about Linksys getting on their certified hardware list. There are only two devices on that list. Both are Sonys IIRC. It doesn't seem like this should be a very difficult piece of programming. I mean they go to the trouble of including dyndns.org in the firmware as an option, you'd think they might also program the app to comply with dyndnd.org's update policies. Either that or make the update rules user configurable.

I browsed around a bit and didn't find too much in the way of discussion about how much the Access Rules config interface sucks on the RV042 1.3.1

This is normally a reasonably straight forward interface in almost every brand of gateway I have messed with, from Xincom to various Linksys BEF series, etc.

On the RV042, the rules configuration interface does not allow selection of udp *and* tcp on the same rule, so you have to make two rules. Further more, in trying to port pinholes for PCAnywhere access on my tester, I have failed to get through on the default ports 5631 and 5632. I have successfully configured a tunnel using The Greenbow IPSec client software, and I can control the test machine through the tunnel via PCA, but I can't seem to get the WAN interface to let me in.

Hoping this and the ddns update flooding are fixed with 1.3.6

Software ddns is fine for single WAN installs or even for failover dual WAN installs, but if you want to keep a valid ddns name updated for both WAN connections, there is no simple way that I can think of to do it with software updaters. I was mulling over how I might set up custom port rules and put two software clients on different machines while I was taking a crap this afternoon, but then I remembered, I can't even open a straight pinhole in this thing.

Of course the guys at dyndns.org roll their eyes (virtually) when you ask about Linksys getting on their certified hardware list. There are only two devices on that list. Both are Sonys IIRC. It doesn't seem like this should be a very difficult piece of programming. I mean they go to the trouble of including dyndns.org in the firmware as an option, you'd think they might also program the app to comply with dyndnd.org's update policies. Either that or make the update rules user configurable.

Click to expand...

Look at the other forums, another user posted about where to get 1.3.6.

So far for me.. 1.3.6 is a big change from 1.3.3 and previous.
Dyndns support is alot better, I still remember before when the RV042 clobbered dyndns and i got blocked 3 times in one day just for updating the configuration.. Apparently it updated dyndns every time the configuration was updated.. At least the folks at dyndns understood and I got unblocked. That was with 1.3.1.

1.3.3 was better, but same time I couldnt update dyndns from the WAN0 port.

1.3.6 Fixes this, and so far even with configuration the router, it doesnt clobber the dyndns service.

HOWEVER.. Uptime is still an issue.

It seems to be better than 1.3.3.. But when I just checked the router (just now), I noticed its only been up for 4 hours. Before that, no idea. I could check my logs, but the point is..

The router seems to restart every once a while now, but with 1.3.3 / 1.3.1 - it restarted more than once a while.

It doesnt really give any error messages (even via console) when it restarts. So far it looks like a hardware thing (overheating) rather than a software thing. I may just hook up a fan and aim it at the CPU to see if that helps.

Thanks to the member who back channeled the 1.3.6 firmware to me. I'm loving it so far. I don't know if I have had the overheating/spontaneous rebooting issue you have seen. I have been doing configuration testing, so haven't kept an eye on it's uptime. I just noted it at 14 hours 44 min. I will keep it running and report what I experience. I too have noticed that it is more compliant with dyndns.org so far, although the thing that I worry about is if the ddns program is smart enough to send a keep alive update after 28 days if no change has been made. If not, the ddns account is at risk of being culled as inactive. I wish the firmware ddns program had some user configuration options.

Harware ddns client is especially appealing in these dual wan routers. With a software client, I don't know of an easy way to keep them both up to date with a reliable ddns name. I imaging some clever port triggering, etc might be possible, but seems wildly sketchy. Much better if each WAN port could just take care of itself.

Thanks to the member who back channeled the 1.3.6 firmware to me. I'm loving it so far. I don't know if I have had the overheating/spontaneous rebooting issue you have seen. I have been doing configuration testing, so haven't kept an eye on it's uptime. I just noted it at 14 hours 44 min. I will keep it running and report what I experience. I too have noticed that it is more compliant with dyndns.org so far, although the thing that I worry about is if the ddns program is smart enough to send a keep alive update after 28 days if no change has been made. If not, the ddns account is at risk of being culled as inactive. I wish the firmware ddns program had some user configuration options.

Harware ddns client is especially appealing in these dual wan routers. With a software client, I don't know of an easy way to keep them both up to date with a reliable ddns name. I imaging some clever port triggering, etc might be possible, but seems wildly sketchy. Much better if each WAN port could just take care of itself.

Click to expand...

Yeah. Thats why I'm toying with the idea of building a custom firmware for the router. Check out RV042 Information for all the research done to date.

The reason why I love hardware routers is for the same reason as you said - they are a hardware solution. They can be hacked but to date, its very hard to do that if the remote management feature is off. Plus, they dont use a hard drive, so I dont need to worry about hard drive life. However cooling is becoming a small concern for some of the more advanced non-commercial routers. The routers used in buisiness require more cooling because they're more advanced, but thats not the point here.

The point is that I can leave the router on, and it'll do its job without me having to worry about hard drive failure. If router fails, just replace it with another one.

However, theres some things in the RV042 that I would love to have more control over.

DDNS is one thing, as you said. There should be more control over it.

If you telnet into the router, and then do:
rg_conf_print ddns

It will return ddns information for each WAN. WAN0 (or WAN1) is ixp1, and WAN1 (or WAN2) is ixp2. You can see the response, the last update (not sure of the format of the number.. In seconds?) and so forth.

Another thing I want more control over is how load balancing is done.
I have to use my router in backup mode, because if I turn on load balancing mode, it screws up my internet access.

I know that the load balancing mode is primarly for people who have load balancing support from their ISP, but they should also include more advanced configuration for people who want to use two different ISP's. For example, I use Roadrunner Cable as primary, and FrontierNet DSL as secondary. Thats because Roadrunner can go down once a while from a thunderstorm (we live in the suburbs), but the phone service doesnt go down. If we have a storm thats truly bad, then I wouldnt expect either to stay up. But overall, DSL is more reliable than Cable in storms and etc since I live in the suburbs, but Cable is faster.

So if I use load balancing, well.. Half of the packets get sent via cable, half get sent via dsl. I lost part of my AIM buddy list because of this.

I want to be able to have a load balancing option that will watch the packets, and when a connection is made via tcp, it will sent all packets for that connection through the same WAN, no matter what. The only way I can think of to do that is via software, and thus the customized firmware research.

So far from that research, the backup/main is done in an "entity" of the main_task program. So either the ramdisk has to be expanded to few MB more, and programs copied over via tftp or nfs (and stored in ram) to do the task, or a totally customized firmware would have to be made. Yuck.

I'm happy with the router as is, just wish it had some extra features, so I'm not sure if its worth it to go out of the way to make a custom firmware for it yet.

It seems to be better than 1.3.3.. But when I just checked the router (just now), I noticed its only been up for 4 hours. Before that, no idea. I could check my logs, but the point is..

The router seems to restart every once a while now, but with 1.3.3 / 1.3.1 - it restarted more than once a while.

It doesnt really give any error messages (even via console) when it restarts. So far it looks like a hardware thing (overheating) rather than a software thing. I may just hook up a fan and aim it at the CPU to see if that helps.

I'll report back if it does.

Click to expand...

do you mean your router just can up about 4 hrs and then will auto restart?

But I had another problem... for some unknown reason, some time the pppoe will seems to be dead, but it say that it still connecting, I need to do a manual reconnect to fix it... I am still trying to figure out what is going on

My one RV042 (running 1.3.6) has been running almost 7 days now.
I did notice random reboots on my other RV042 after installing 1.3.6, but they are infrequent and I still can not narrow down the cause.

My one RV042 (running 1.3.6) has been running almost 7 days now.
I did notice random reboots on my other RV042 after installing 1.3.6, but they are infrequent and I still can not narrow down the cause.

I am still suspicious of the new code.

DrO

Click to expand...

I guess I was lucky but my router probably rebooted only once randomly. I've had uptimes of 40+ days on mine.

Basically, the only time I reboot is to upgrade the firmware or when we lose power.

I have 1.3.6 installed now (Thanks noaaah). The uptime is over 2 days now.

But, this is a refurbished one that I got when I the WRV54G wasn't doing what it claimed and I swapped it for a RV042. I'm happy that I did.

But a custom firmware would be really nice. Thanks to all who are working one this. I'd help but my programming skills are terrible.

I've been sending the RV042's log to a syslogd daemon for a while now - about two to three weeks. But the problem with that is - it doesnt record reboots. So I've been using mrtg (really more for its snmp part) to query the uptime of the router every minute. It doesnt put in a time stamp of when the router's uptime gets resetted, but by looking at the uptime before the reset, I can tell how long its up (to the minute) before it restarts.

Unfortunately I just setted up mrtg to do this recently - a day or two ago. The router hasnt been down since. So I'll leave it going and see what happens.

Maybe it wasnt a heating problem, maybe it was the 1.3.3 firmware. But at the same time, the best way to tell if its a heating problem or not is to attach a thermometer to the cpu and record cpu's temperature at 10 second or 30 second intervals along with the uptime. And then when it reboots, find the temperature. Then if it keeps rebooting at the same temperature, then it may be a temperature problem. I'm not going to do that just yet. :-P

It seems to be better than 1.3.3.. But when I just checked the router (just now), I noticed its only been up for 4 hours. Before that, no idea. I could check my logs, but the point is..

The router seems to restart every once a while now, but with 1.3.3 / 1.3.1 - it restarted more than once a while.

It doesnt really give any error messages (even via console) when it restarts. So far it looks like a hardware thing (overheating) rather than a software thing. I may just hook up a fan and aim it at the CPU to see if that helps.

I'll report back if it does.

Click to expand...

do you mean your router just can up about 4 hrs and then will auto restart?

But I had another problem... for some unknown reason, some time the pppoe will seems to be dead, but it say that it still connecting, I need to do a manual reconnect to fix it... I am still trying to figure out what is going on

Click to expand...

Ok.. i know its a long time that post hasn't been modified.. but i think now that uptime is not an issue anymore: