I have the same problem. I couldn't figure out what was wrong and spent many hours troubleshooting, before coming to the conclusion that it must be a bug in the router firmware (as I can't think of anything else it might be)

Is anyone else experiencing this? Is it just the Linksys RT31P2? The firmware I have seems to be version 1.28.00

DHCP will only work if NAT is enabled. The reason being, if NAT is disabled, the router becomes a bridge, and your ISP will be handing out the IPs. Most ISPs only hand out single IPs for residential accounts, so you will need to use NAT if you want to have more than one device connected to your ISP's connection. Maybe you can get the router to hand out IPs with that configuration, but with NAT disabled, it's not going to route packets.

My ISP authenticates using PPPoA. My ADSL modem/router, in this instance an old but reliable Netgear DG814, does this. This means it has two interfaces -- the external DSL interface gets one public IP from the ISP whereas the internal LAN interface gets a static IP in private address space, in this case, 192.168.0.1

In this instance, the ISP is only ever going to serve one public IP. This is going to be allocated only to the external Netgear interface. This is the only interface that the ISP can actually see. It is this Netgear router that runs NAT and therefore any packets going out to the Internet are going to be NATted to that one public IP address. NAT should NEVER be disabled on this device.

Now, I can have the Netgear run DHCP or I can have DHCP disabled. The end result is the same -- if I have DHCP enabled on it, again it will allocate one and one only IP and that will be given out to the Linksys RT31P2 router's "WAN" interface. Again, this will be a private address and it is 192.168.0.2. If DHCP is disabled, then the Linksys's WAN interface needs to be statically assigned.

Now, here's the important part:

With NAT enabled on the Linksys (which is the default), you effectively have the situation where you are NATting the same packet twice on its way out to the Internet. This is both unnecessary and actually breaks things sometimes (Hotmail is a prime example of this -- it can cope fine with single NAT, but double NATting kills things). So, the correct setup in this situation is to do two things:

1. Disable NAT on the Linksys router2. Add a static route to the Netgear router directing 192.168.15.0/24 traffic to the Linksys 192.168.0.2 address.

In this situation, the Linksys is acting as a router, not a bridge. This is because it has two different subnets, 192.168.0.0/24 on one interface and 192.168.15.0/24 on the other, and routes packets between the two.

This also means that any DHCP requests for 192.168.15.0/24 should be broadcast only on that subnet and be made only on that one specific interface. So I don't see any reason why DHCP should not work, except that it may be deliberately disabled in software to prevent it running when, as VonageTPA rightly points out, it is acting solely as a bridge. It's just that in my situation, it's not acting as a bridge, it's a router. My concern is that it's being disabled in software unnecessarily, or that there is simply a bug in the firmware.

Incidentally, I'm still trying to get the firmware upgraded from 1.28.00, despite trying reset procedures and even uploading the binary via the web interface, which a Vonage Tier 2 technical support person kindly emailed me. For some reason, the upgrade just doesn't want to take, so I will wait and see what the technical support people suggest next. They have been nothing but helpful and to be fair, I'm not dead in the water -- the only thing not working for me right now is DHCP, so it just means statically assigned IP addresses for now, which is a minor inconvenience, but not a major issue at all. I can certainly live without it for a couple of weeks.

Oh well. It looks like I'm getting a replacement RT31P2. Not really anything to do with the DHCP/NAT issue, but it won't take a firmware upgrade, and Tier 2 support are saying that on that basis alone it will need swapping out, otherwise they will never be able to upgrade it in future.

The router swap isn't going to help the DHCP/NAT issue, as the new firmware doesn't fix that issue. So, for now, I guess I have the following options:

1. Live with the existing configuration as it is, and accept that all home laptops and other computers will need to use static IP addresses

2. Bridge the LAN and WAN interfaces by plugging them both into the ADSL router, but then I'm not convinced QoS will work properly -- it depends if QoS for voice upstream is controlled at interface level or at the individual port level.

3. Configure it in the "alternate setup" and have the computers connect out of the ADSL router instead, in which case, definitely no QoS.

4. Buy a better ADSL router with inbuilt QoS functionality.

Option 1 seems my best bet. I have no idea why the lack of DHCP is bugging me so much. It just is! I suppose I could run a DHCP server on a desktop computer somewhere...

This arrangement basically turns the router into a bridge by means of physically bridging the two interfaces.

In theory, plugging the WAN interface into the DSL router creates a redundant link and shouldn't be necessary. In practice, I've found no way of telling the Linksys router to route voice traffic via the LAN interface, despite trying to convince it with a static route. Therefore, it must be connected in this manner.

2. Disable NAT and DHCP on the Linksys. NAT should not be used in a bridging arrangement. Also, by disabling DHCP, I'm ensuring two things: . (i) I don't have competing DHCP servers on a single subnet . (ii) DHCP leases are served by the DSL router, which means the rest of the computers get the correct gateway to use! This means that the Linksys doesn't actually end up routing any Internet traffic, which is just as well, because the way I'm configuring it will break its routing ability anyway.

3. The Linksys WAN Interface receives a 192.168.0.* address from the DHCP server on the DSL router

4. Assign the Linksys LAN interface a static IP of 192.168.0.254 and, although highly unlikely, exclude that from the DHCP lease pool on the DSL router to be extra thorough.

5. Enable the QoS feature for the LAN ports and set all three ports to Low priority, flow control enabled and ingress rate capping disabled.

Step 5 is important. If you don't do that, then you may as well just have the computers running off of the DSL router. By enabling QoS, albeit not in the manner that it was intended, it gets around the issue of prioritising voice traffic.

I've tested this by uploading a large file via ftp and simultaneously making a voice call. It works beautifully.

I thought I'd post my workaround on this board, in case anyone else runs into a similar issue.