The reason for this post will become clear in a few days when a review I've written is posted on another site: It's an occupational hazard for someone who writes Wi-Fi Networking News to, you know, work with Wi-Fi. Which means that I'm regularly put in the position of being sent a loaner router for review--or, when the company is recalcitrant, buying a unit at retail--and trying to put it through its paces. I'm no Tim Higgins, but I've been working with networked hardware and Ethernet since the late 1980s, so I sort of know what parameters to test.

But I've been stymied in a few instances in testing, and I finally isolated the factor. My network is a bit weird.

Let me break it down. All Wi-Fi gateways designed for homes and small offices have at least two Ethernet ports: one is the wide area network (WAN) port that connects the router to a larger network, such as an office network, or to the local area network (LAN) port on a DSL or cable or other broadband modem.

The other one or more Ethernet ports are LAN ports. Most gateways now--since Apple finally caved in to the trend--have three or four Ethernet ports in a switched configuration. An Ethernet switch can dedicate full capacity in each direction for each combination of ports. So you should get full Ethernet speed between any two connected devices in both directions.

Now here's where a problem comes up. If you pass traffic at Ethernet speeds between the LAN side of a Wi-Fi gateway (either a directly connected Ethernet device or a wirelessly connected adapter) and the WAN side, you typically see a slowdown. Why? Because either the hardware or software can't keep up with pushing traffic between LAN and WAN.

In the case of hardware, it's when the gateway is designed to have a physically separate WAN port and the bridge between the built-in LAN and Wi-Fi service and the separate WAN port can't route at full Ethernet speeds. With software, this problem occurs when you have Network Address Translation (NAT) turned on, and the translation from a public IP address to the private addresses is unable to keep up with the network demands.

Now most people don't bit by this particular flaw, which I've now found in multiple gateways, for three reasons.

First, home users typically don't have a WAN that's faster than the restricted throughput on the WAN port. That may change as fiber pushes out.

Second, most larger networks, such as in businesses and college campuses, don't use NAT on the gateway. They might even use dedicated access points, which have no DHCP or NAT, and which have a single WAN Ethernet plug. If they do use a gateway they turn off NAT. In my "weird" network, I have static IPs on the larger network, and typically in testing plug my larger network into the WAN port, and use NAT on the LAN side. When the WAN limitation is in software, you don't see the throttling because the full Ethernet speed can be achieved.

Third, only recently have we seen Wi-Fi that exceeds 20 to 40 Mbps, typically the restricted LAN-to-WAN speed. And we've only recently seen gigabit Ethernet (1000 Mbps) added as a feature to high-end Wi-Fi gateways. So even on networks which are configured in my weird way, the limitation wasn't visible.

Thus, it's unlikely that most users and offices will get bit by this glitch.

My new testing regime, to avoid hours of effort I spent recently to figure out this problem, is as follows:

Situation A: DHCP/NAT turned on. Test intra-router connections: wireless to LAN and back, LAN to LAN on the Ethernet switch. Extra-router connections: wireless to WAN, LAN to WAN, and back again.

Situation B: DHCP/NAT turned off. Retest same parameters.

It'll become clear in a couple days why I posted this analysis. I advise all manufacturers to revisit their testing regime and make sure that they are testing the "weird" case of throughput from wireless to WAN and LAN to WAN. You might find something interesting.