The Zyxel C3000Z DSL modem/router (at least one I lease from CenturyLink) is able to be placed in transparent bridging mode by going to Advanced => WAN settings => ISP Protocol and selecting Transparent Bridging. This turns off the router and wireless functionality and makes it function like “just a modem”. After doing this, I can use my own OpenWRT-based router/access point to connect with the WAN port set to PPPoE. It’s been quite a stable configuration for a while now, but I just experienced an afternoon of connection problems leading me to want to inspect the modem’s system log.
After enabling transparent bridging on the DSL modem, it will no longer run a DHCP server, meaning that plugging into it via Ethernet will no longer give you instant connectivity to its web-based administration interface. However, it will keep its old IP address and be accessible if you manually set your IP address to be in the same subnet. In my case the modem came set to 192.168.0.1, so I gave myself the address 192.168.0.2 and browsing to http://192.168.0.1 got me to the admin interface. If you don’t know the IP address of the DSL modem, it may be printed on a sticker somewhere on its case.
You can do a similar thing without having to physically plug in a new cable by adding a virtual interface to your own router using the same physical port that you use for the WAN connection. Assign this virtual interface an IP address in the same subnet and you should be able to browse to the C3000Z modem admin page. Just be sure to firewall it correctly.
I have an OpenWRT router that I use to privately share a connection to a public hotspot. In other words, I use one of the Wi-Fi interfaces to connect to the internet via a hotspot, and share it to my own devices via another Wi-Fi interface. This is pretty easy to accomplish with OpenWRT and simply requires switching the Wi-Fi interface to client mode and setting the network interface to something in the WAN firewall zone (typically wwan).
This post isn’t going to cover the basics of that configuration, but instead cover a problem I’ve had with hotspots that associate but then fail to respond to DHCP requests. That essentially kills my internet connection for a while until udhcpc times out (sometimes it doesn’t) and a new association attempt is made with a different access point. Each hotspot has its own BSSID, which is the MAC address of the access point. You can find this address either from the Wireless section of the web frontend, or from watching the association attempts from the system log (e.g.
logread -f). There is no obvious way to blacklist a particular access point by MAC address in client mode from Luci (OpenWRT’s web frontend). It is pretty easy to accomplish from the command line. First, determine which radio you are using for the client mode connection, e.g. radio0, radio1, etc. and then find its configuration “section” name, e.g. “wifinet1”, “wifinet2”, etc.
You can also get this information another way using the uci command:
uci show wireless
Once you have found the configuration section for the radio device you are using, it’s as simple as adding the blacklist value. Here we will assume the configuration section ‘wifinet1’ and set the blacklist to include the fake MAC address values ‘xx:xx:xx:xx:xx:xx’ and ‘nn:nn:nn:nn:nn:nn’:
uci set wireless.wifinet1.bssid_blacklist='xx:xx:xx:xx:xx:xx nn:nn:nn:nn:nn:nn'
As you can tell, the MAC addresses are separated by spaces.
Now write the changes to the system configuration:
Finally, restart the wireless interface. We’ll assume radio0 as an example:
wifi up radio0
This will prevent the wireless client interface from connecting to the access points in the blacklist. This works because the
bssid_blacklist value is passed through from uci to wpa_supplicant via hostapd.sh. Note that this value may get clobbered if you touch the wireless interface configuration from the Luci frontend since it is not included there.