5 min read
QA Cafe has been testing CPE routers since 2002 trying to test as many routers as we can find. During this time we have learned that the quality level of home and business routers/gateways on the market varies considerably. The following are some of the common problems that are exposed by testing with the CDRouter test suite.
The CDRouter test suite can force a router to renew its DHCP lease at short intervals. QA Cafe has found that some routers are unable to complete the DHCP renewal process without dropping packets. This packet loss can happen under very light traffic loads.
Most ISPs use a DHCP lease time of 24 hours or more, so tracking this problem down on a real network can be quite frustrating and time consuming. With the CDRouter test suite, this type of quality issue is uncovered quite easily.
Many routers on the market today do not have a robust version of PPPoE. If an unexpected PPPoE event happens, the router is often left in a state where the PPPoE link is down and never recovers. The CDRouter test suite includes several tests to verify the robustness of the router’s PPPoE implementation including PPPoE link termination from the ISP, authentication failures, PPP LCP renegotiation and more.
NAT implementations continue to improve, but there are still many NAT bugs lurking in home routers. The most general problem is corruption of a packet that has been NAT translated. The end result is that the packet will be transmitted with a bad IPv4, TCP, or UDP checksum, depending on where the corruption occurs. In the worst case, the corruption can also modify the IPv4 header, including address information. To the end user, these types of problems show up as packet loss on the WAN, often resulting in TCP retransmissions. These problems are mistakingly attributed to poor ISP performance.
The CDRouter test suite contains many NAT specific tests and forwarding verification tests. The CDRouter test suite detects packet corruption to help isolate the offending test cases.
Many routers probe the LAN side for existing hosts after rebooting. Usually, this is done by sending ARP requests out to each host in the configured DHCP IP address range. However, some routers do not interact well if a DHCP client request is received before the range has been checked. In some cases, routers still respond to DHCP clients and assign them an IP address from the range. However, when the router goes to probe the IP address, it finds an address and considers this IP address in use. Later when the DHCP client attempts to renew the DHCP lease, the router may reject the request since it considers this address in use by another system.
This type of problem is a good example of the subtle timing issues that can exist in a router. Without good tools to track this kind of behavior, it can be hard to uncover these problems.
UPnP support is common in home routers. However, many implementations have software bugs that result in several security holes. Common problems include leaving ports wide open even after they have been closed by an application using UPnP, failing to delete dynamic port entries after the port’s UPnP lease expires, and leaving ports open to any IP address even though the UPnP based application requests a port mapping for a specific IP address.
The CDRouter test suite addresses these problems through several UPnP port mapping tests which verify that dynamic UPnP port mappings are created and deleted properly.
The UPnP Forum’s Internet Gateway Specification provides a way for UPnP gateways to indicate a port conflict to a UPnP application. Two different computers behind a gateway can not share the same external port. However, many UPnP implementations let new port mapping requests from separate computers over ride the old port mapping entries with out indicating any errors.
Some UPnP enabled routers break down when the number of UPnP created port mappings exceeds some threshold. On some devices, this threshold can be as low as 10 port mappings. There are two common failure modes in this situation. The router rejects any new port mappings from the UPnP aware application. Or worse, existing port mappings stop working when new port mappings are created. CDRouter can determine how well the UPnP aware router scales by testing 1000s of port mapping entries created through UPnP.
Many routers on the market have bugs in their configuration system where the configuration parameters displayed in the web interface are not consistent with the parameters the router is sending on the wire. In most cases, when a router is configured from its factory defaults, the configuration works. However, over time as the configuration is changed, bugs in the configuration system can cause the display and actual values to diverge. For example, the router may have a PPPoE service name configured, but no service name is sent when the router initiates a PPPoE session.
The CDRouter suite is a powerful tool for tracking these types of problems since it makes it easy to cycle through different configurations of WAN protocols, virtual services, port triggers, etc. After each configuration change, you can use the CDRouter test suite to verify that the router is performing correctly.
Certain NAT ALG implementations do not correctly handle TCP retransmissions when the data contents of the TCP segment must be dynamically changed. A good example is the FTP PORT command. Some router’s do not detect retransmitted TCP packets and end up opening multiple ports on the WAN side for each TCP retransmission.
The CDRouter suite can test these type of difficult corner cases that are nearly impossible to test manually in the lab. Since CDRouter has complete control over the protocol stacks for the sender and receiver applications, it can easily create TCP retransmission scenarios and verify the router’s NAT ALG functionality.
