The WNCE2001 is a wireless bridging device. If you don’t have equipment that supports WPS, you will need to manually configure it. The device’s function is very handy – it can be used to link ethernet-only devices to your wireless network, such as a certain games console that’s official wireless adapter is sold at an extortionate price. For a similar price to a single wireless adapter that functions for one client, you can attach the WNCE2001 to a switch and share the bridge with several clients. In my case, it was simply to attach an ethernet-only printer to the wireless network.

The default IP for the device is 192.168.1.251. This can be changed later. Be warned that the device initially broadcasts a DHCP signal, so you may wish to at first plug the device into a NIC on a disconnected machine, instead of the network. You can safely ignore the DHCP signal if you wish, and manually configure an address for your NIC and access the device’s IP. It will then automatically redirect you to the host ‘www.mywifiext.com’ via Javascript.

If you opted to have the DHCP server on the device configure your machine, it will have attempted to configure its current IP as the single DNS nameserver for your machine. This is presumably so it can bind the host mentioned earlier with the correct IP address (its own). However, the host is still bound to that IP without configuring the device as a nameserver. I’m guessing this is due to DNS requests being hijacked by the device’s routing layer.

If you plug the device into an existing network anyway, it does have DHCP client enabled, which should configure itself pending instruction from your DHCP server. I’m guessing that since the default IP under these circumstances could change, the DNS was introduced to make this process easier for the end-user.

Despite this array of ‘features’, if you have plugged the device into your network, and are trying to access its IP, you’ll find that the host it redirects to is not bound (the device’s DNS request hijacking won’t work if your DNS requests aren’t actually going through it), and you therefore cannot actually use the web interface. A workaround is to either manually (and temporarily) configure the device’s IP as your nameserver, or bind the IP and host using your hosts file (/etc/hosts on UNIX machines, for anything else Google it).

After all that, you should have gotten yourself to the web interface for configuring – at which stage you should manage with Netgear’s guidance. After changing the IP of the device, I found that accessing it directly didn’t result in a redirect to that .com host. It’s worth noting also that the device has a DHCP client too, so you can get it to pull info straight from your router.

Ultimately the device works a treat, and I recommend it. Though despite attempting to cover a multitude of installation scenarios, none of the routines seem to actually be flawless. After trying to rationalise what was actually going on, this thing took me 20 minutes to get set up. I’m all for advancing installation procedures by adapting them for different scenarios, but the routines need to be tested and bug-free before implementation – or they achieve the exact opposite of their original goal.