In the past days, I bought a Netgear WNCE3001 wireless adapter to connect my pay TV decoder to the Internet. To configure it, you need to connect it to a PC Ethernet port, and use its configuration wizard to perform the initial configuration – which is just configuring which wireless LAN you want to connect to, and its encryption parameters. In my case, the wizard was unable to complete. It was able to find my WiFi SSID, it was recognizing the encryption type, but then was unable to connect to the network. The error returned was very generic. It just reported “Connection was not established to the selected network. Please move WNCE3001 closer to the selected network router. When ready, click try again”. Of course, trying again was useless. The device was less than a meter from the AP. Any other device I own connects without issue to the access point. I tried with a mobile WiFi/3G router, and this time it worked. Was the AP incompatible? No, it turned out it wasn’t.
Luckily, the AP has a network packet capture facility. A packet dump revealed the issue was not in associating with the access point. It was in obtaining an IP address from the DCHP server (the one in my ADSL router). The dump revealed Netgear uses udhcp 0.9.9, and a quick search revealed there could be issues if DHCP packets are larger than a given size. The router was sending out DHCP responses which contained an assigned host name too, triggering the “packet too large” issue.
I installed tftpd64, which not only offers a useful tftp server, but also a simple DHCP one. Using it, the device was able to obtain an IP address and the wizard completed, letting me to access the management pages, where a fixed IP could be set, and the device is now working.
This a good lesson why “luser-oriented” interfaces – oversimplified UI for fear the end user could have issue using a more complex ones – are a mistake, especially if error reporting is as lame as the interface. It took time to find what the problem exactly was. I had a chat with Netgear support that was not helpful. If the wizard had reported the true error – at least something alike “unable to obtain an IP address from the DHCP server” if not the full, real error, I would have tried another server.
I understand most home users don’t know what a “DHCP server” is, even an “IP address”. It’s OK to tell them “sorry, I can’t connect.” But add “Here below are the technical data of the error. You don’t have to understand them, just report them to support if needed.”. Because some user could understand them and find a solution, while your tech support would have all the data it needs to understand what isn’t working in your products, and makes users disappointed until a solution is found. Without any need to dump network packets and analyze them – this is something that really require some advanced network expertise.
Hiding the true cause of an error is always a big mistake, unless you have a good reason to do so for privacy or security reason. Still, you should log those information where one can retrieve them if needed. Otherwise, it just means non working products, disappointed users, and a lot of support wasted time in attempts to find the root cause – just because someone decided end users should not see real errors.
It doesn’t make products better, it makes them worse because problem resolution takes a lot of time. If I had not the skill to find the issue, I would have sent the device back, and bought from someone else.
Also, let advanced user configure a device without being forced to go through a wizard that may fail. If I could have set the IP address myself, I would have known the device worked – and the DHCP process was the issue.
There are some more issues too. One can’t change the WiFi password from the management UI – one needs to go through the configuration wizard again. Not user friendly at all, and without any good reason.