Repurposing ADSL gear under NBN

Friday 26 June, 2020

Image by Stephen Phillips on Unsplash

What to do with your “old” ADSL gear once you’ve (finally!) been transferred to NBN? Landfill? You’ll likely have received a new “budget” device from your RSP (Retail Service Provider, the new name for your ISP) and certainly, it’s simplest to just use their device, that way you’ll be more easily supported by them and this is a good call if you’re not a tech-head. But what if you’ve invested in prosumer grade gear, sell or redeploy, and what to do with the new bundled device?

Some time ago I moved to an ASUS ADSL modem/router after the death of my old(er) Billion device, one which I’d purchased specifically to set up VoIP many years ago rather than building this on my Linux boxes. With the preponderance of smartphones there became little benefit or need for having home phone lines, the argument that they’re great in times of emergency falls down when telephone exchanges are connected to each other by wireless technologies and if the mobile network does go completely down we’ll likely have “bigger” problems to deal with and having home phone lines may be the very least of our concerns.

This time was also the start of my move away from having home based dedicated physical servers and moving towards cloud-based services and appliance type devices such as firewalls, storage and file sharing. Having a 19″ rack of gear filled with home built Linux firewalls (ipchains and iptables FTW!), running Bind services, Sendmail based SMTP messaging replete with SpamAssassin, NTP, VPN, security devices (Snort FTW!) and assorted hardware-based switches simply wasn’t needed anymore. Sure, it was fun to learn by building and configuring and fun to tinker with but it consumed a huge amount of time (and electricity!), and what to do with all of that once you’ve climbed the proverbial mountain? Repurpose, in this case via donation. Below is what the last incarnation of my physical infrastructure looked like in late 2003:

Image by Andrew Newbury

Final physical network config (pre virtualisation)

But enought of that trip down memory lane, back to the ASUS. Why ASUS? Let’s back up a bit and start with what it needed to do, the so called life purpose or use case and only then apply the vendor lens seeking out what would best fill that need. I wanted an appliance which was easy to manage and support, one which would undertake stateful packet inspection acting as an IPv4 firewall, network address translation and some basic support services like IP address assignment via DHCP, DNS resolution, and NTP time services. With the growing popularity of Linux (I’ve long been an advocate of free and open source software), devices were starting to come onto the market with this as their core operating system combined with a customised web based GUI for ease of management. Sampling reputable online reviews and needing the device in a hurry due to the failure of my previous unit, I went with the ASUS primarily based on the supportability, ease of use and having every network service that I needed back then AND importantly that it was in stock at my favorite hardware suplier 🙂

One of the greatest features of free and open source software is the concept of being able to build on top of the work of others, often with attribution, and mandating (under some free and open source software licenses) that any additions are also made freely available. Think of the example of a cake recipie, per Donkey from Shrek, “everyone likes cake”. You come up with a great cake recipie and publish this allowing your recipie to be freely used by anyone, someone else then comes across your recipie and improves it and then also too makes that freely available; through unfettered and uncopyrighted innovation we get better and better cake recipies which benefit the cake consumer, the reason a cake exists in the first place.

For the technically interested the GPL is one form of this type of free license allowing others to stand on the shoulders of giants before them.

Back to ASUS. The device I chose was (I’ll get to why it’s “was” in a minute) a DSL-AC68U. Ticking all the functionality and use case boxes plus being built on the Linux kernel and with frequent updates – a perfect device for my needs. And just like cake, some folks on the ‘net decided to improve on the core OS recipe. Two major series of changes are out there with the Tomato router project which covers many Broadcom based devices and the awesome Asuswrt-Merlin firmware project which is

a third party alternative firmware for Asus routers, with a special emphasis on tweaks and fixes rather than radical changes or collecting as many features as possible.

So that’s great, a great device with community-supported mods, but what about NBN support? Back in 2014 NBN was still a political football and this was in the heady days of the onset of the MTM (multi-technology mix) and the rise of the dreaded FTTN (fibre to the node). The DSL-AC68U is unit is both a VDSL (100 Mb/s max) and ADSL (24 Mb/s max) device so this would be a future proof device knowing that back then I’d very likely be going to VDSL as FTTP (fibre to the premises) was being phased out as too was HFC (hybrid fibre-coaxial).

So, what have we learned so far?

Buy the right gear from the onset, factor in any future changes that may affect what you’re buying and ideally buy into a product which has lots of support both from the vendor and in the community.

Enter stage left, HFC. Over a year ago I tracked down that HFC would be the NBN delivery path in my area and not FTTN which would use VDSL. Damn. To a degree. ASUS also sells basically the same device as the DSL-AC68U as a straight router without the ADSL/VDSL component, the RT-AC68U. And out there on the ‘net an enterprising soul worked out that you can flash the firmware for the RT onto the DSL device and turn it into a useable router for HFC.

As a quick aside, NBN’s HFC comes into your home as a thick piece of coaxial cable which terminates at an NBN supplied modem with an ethernet jack, similarly to FTTP while FTTN terminates in a piece of “phone line” just like ADSL.

Back to performing unnatural acts with a router: converting one model to another through flashing firmware and making changes to NVRAM (non-volatile random access memory). After some ‘net searching, I’d decided that I would benefit from flashing the Merlin firmware giving me increased configuration (think “more things to play with”) and that I’d then use this is my main router. Sometime later and my DSL-AC68U had undertaken a gender change to an RT-AC68U and was working perfectly at 100Mb/s on an NBN HFC connection.

Brilliant!

For the technically inquisitive here’s how I did the change:

Step by step conversion of an ASUS DSL-AC68U to an RT-AC68U

  1. Reboot router
  2. Reset router to factory defaults
  3. Power off router, remove ADSL phone cable
  4. Hold a pin against the reset switch while powering up the router and release when the power LED starts blinking
  5. Plug an ethernet cable into port 1
  6. Disable any other network interfaces on the laptop/PC
  7. Set the laptop/PC to 192.168.1.10/24
  8. Open a web browser session to 192.168.1.1
  9. Upload the Asusert-Merlin firmware
  10. Wait until the upload has completed
  11. Power cycle the router
  12. Login to the router on 192.168.1.1 and
    • Set an admin username/password
    • Skip the rest of the network set up wizard as you’ll be completing this later
    • LAN->IPTV – set “ISP profile” to “manual setting”, set “internet VID” to “2”, PRIO to “0” (this is required if you are on the TPG network which uses VLAN tagging with VLAN ID 2)
    • WAN->Internet Connection – set “wan connection type” to “PPoE”, set “enable WAN” to yes
    • WAN->Internet Connection – set the username/password to match your preconfigured and TPG supplied router (both my username and password were different from my ADSL settings)
    • WAN->Internet Connection – under “Special requirement from ISP” set “Enable VPN + DHCP Connection” to “no”
    • (you do not need to enable dual wan: when you convert the DSL-AC68U to an RT-AC68U the default WAN port becomes switch port 1)
    • Adminstration->Operation mode – set to “Wireless router mode”
    • Adminstration->System – set “Enable JFFS custom scripts and configs” to “yes”
    • Adminstration->System – set “enable ssh” to “LAN only” and set “Allow Password Login” to “yes”
    • Apply changes and wait for router to reboot
  13. On your laptop/desktop open an SSH session to 192.168.1.1 with the username/password you created at the start of step (12), if you’re on Windows 10 you can use the default command line SSH program that now comes with W10 (FTW!) eg.  ssh -l admin-name 192.168.1.1
    • move to the scripts folder with

      cd /jffs/scripts/

    • use nano to create a “services-start” file

      nano services-start

    • with these three lines

      #!/bin/sh
      touch /tmp/000vlanconfigured
      robocfg vlan 2 ports “1t 5t”

    • Make 100% sure the file is correct, then save and exit nano (this sets up the WAN to use port 1 with VLAN ID 2 which is needed by TPG, this is only needed if you are on the TPG network or your RSP uses VLAN tagging)
    • set the script to allow execution with

      chmod 755 services-start

    • You can test execute the script to make sure that it works by typing

      ./services-start

    • set the router name to “RT” instead of “DSL” by entering the following (use copy and paste)

      nvram set odmpid=”RT-AC68U
      nvram set asuscfeodmpid=”RT-AC68U”
      nvram set asuscfecommit=1
      nvram commit

    • Reboot the router
  14. Login to the router and set any other configurations that need for DHCP, NTP, etc
  15. Adminstration->System – set “enable ssh” to “no”
  16. Save the router config file with Administration->Restore/Save/Upload Setting, you might also want to “Backup JFFS partition”
  17. Reboot and connect the WAN cable from the HFC modem to port 1 (you might want to label this port as WAN)
  18. Test that your router is working A-OK

Enjoy your reinvigorated router!

Closing notes: if you’d been using the inbuilt ASUS OpenVPN client on ADSL/2+ etc with your favourite VPN provider you’ll now find that the router will only allow between 20-25Mbp/s with AES-256/128 encryption which was fine under ADSL2 but this is now a problem if you’re on a 100 Mb/s plan and the only solution is to get a more powerful modem: there simply isn’t enough grunt in the AC68U CPU to manage the en/decryption needed by OpenVPN at such a high bit rate. You could redeploy this unit to act as an ASUS AiMesh node to alleviate any low WiFi connectivity (and ASUS have an awesome mesh config with AiMesh). Without any doubt you’ve also voided your warranty, so only do this if you know what you are doing and or are OK with wearing any consequences.

In closing and to answer a question which I posed at the very start of this article? What to do with the “bundled” device you’ll often receive from your RSP? And what about VOIP? Unless you use the “bundled” unit you’ll likely have a lot of grief trying to get VOIP (your “new” replacement telephone line) working, but really, who typically needs VOIP when you have a mobile phone?

Sadly I did find a use for my TP-Link “bundled” modem: to act as a media converter for ADSL<->ethernet by acting as a network bridge. Why? That’s more complex, the Readers Digest version is that I’m not officially provisioned (I agree, how does that happen?) on HFC for the next two months and after seventeen days of flawless performance the HFC link went down and I was told that I’d be without HFC based Internet access for at least 24-48 hours and while the HFC is now working again it may well go down until I’m officially provisioned on the NBN :/

Image by Stephen Phillips on Unsplash

What to do with your “old” ADSL gear once you’ve (finally!) been transferred to NBN? Landfill? You’ll likely have received a new “budget” device from your RSP (Retail Service Provider, the new name for your ISP) and certainly, it’s simplest to just use their device, that way you’ll be more easily supported by them and this is a good call if you’re not a tech-head. But what if you’ve invested in prosumer grade gear, sell or redeploy, and what to do with the new bundled device?

Some time ago I moved to an ASUS ADSL modem/router after the death of my old(er) Billion device, one which I’d purchased specifically to set up VoIP many years ago rather than building this on my Linux boxes. With the preponderance of smartphones there became little benefit or need for having home phone lines, the argument that they’re great in times of emergency falls down when telephone exchanges are connected to each other by wireless technologies and if the mobile network does go completely down we’ll likely have “bigger” problems to deal with and having home phone lines may be the very least of our concerns.

This time was also the start of my move away from having home based dedicated physical servers and moving towards cloud-based services and appliance type devices such as firewalls, storage and file sharing. Having a 19″ rack of gear filled with home built Linux firewalls (ipchains and iptables FTW!), running Bind services, Sendmail based SMTP messaging replete with SpamAssassin, NTP, VPN, security devices (Snort FTW!) and assorted hardware-based switches simply wasn’t needed anymore. Sure, it was fun to learn by building and configuring and fun to tinker with but it consumed a huge amount of time (and electricity!), and what to do with all of that once you’ve climbed the proverbial mountain? Repurpose, in this case via donation. Below is what the last incarnation of my physical infrastructure looked like in late 2003:

Image by Andrew Newbury

Final physical network config (pre virtualisation)

But enought of that trip down memory lane, back to the ASUS. Why ASUS? Let’s back up a bit and start with what it needed to do, the so called life purpose or use case and only then apply the vendor lens seeking out what would best fill that need. I wanted an appliance which was easy to manage and support, one which would undertake stateful packet inspection acting as an IPv4 firewall, network address translation and some basic support services like IP address assignment via DHCP, DNS resolution, and NTP time services. With the growing popularity of Linux (I’ve long been an advocate of free and open source software), devices were starting to come onto the market with this as their core operating system combined with a customised web based GUI for ease of management. Sampling reputable online reviews and needing the device in a hurry due to the failure of my previous unit, I went with the ASUS primarily based on the supportability, ease of use and having every network service that I needed back then AND importantly that it was in stock at my favorite hardware suplier 🙂

One of the greatest features of free and open source software is the concept of being able to build on top of the work of others, often with attribution, and mandating (under some free and open source software licenses) that any additions are also made freely available. Think of the example of a cake recipie, per Donkey from Shrek, “everyone likes cake”. You come up with a great cake recipie and publish this allowing your recipie to be freely used by anyone, someone else then comes across your recipie and improves it and then also too makes that freely available; through unfettered and uncopyrighted innovation we get better and better cake recipies which benefit the cake consumer, the reason a cake exists in the first place.

For the technically interested the GPL is one form of this type of free license allowing others to stand on the shoulders of giants before them.

Back to ASUS. The device I chose was (I’ll get to why it’s “was” in a minute) a DSL-AC68U. Ticking all the functionality and use case boxes plus being built on the Linux kernel and with frequent updates – a perfect device for my needs. And just like cake, some folks on the ‘net decided to improve on the core OS recipe. Two major series of changes are out there with the Tomato router project which covers many Broadcom based devices and the awesome Asuswrt-Merlin firmware project which is

a third party alternative firmware for Asus routers, with a special emphasis on tweaks and fixes rather than radical changes or collecting as many features as possible.

So that’s great, a great device with community-supported mods, but what about NBN support? Back in 2014 NBN was still a political football and this was in the heady days of the onset of the MTM (multi-technology mix) and the rise of the dreaded FTTN (fibre to the node). The DSL-AC68U is unit is both a VDSL (100 Mb/s max) and ADSL (24 Mb/s max) device so this would be a future proof device knowing that back then I’d very likely be going to VDSL as FTTP (fibre to the premises) was being phased out as too was HFC (hybrid fibre-coaxial).

So, what have we learned so far?

Buy the right gear from the onset, factor in any future changes that may affect what you’re buying and ideally buy into a product which has lots of support both from the vendor and in the community.

Enter stage left, HFC. Over a year ago I tracked down that HFC would be the NBN delivery path in my area and not FTTN which would use VDSL. Damn. To a degree. ASUS also sells basically the same device as the DSL-AC68U as a straight router without the ADSL/VDSL component, the RT-AC68U. And out there on the ‘net an enterprising soul worked out that you can flash the firmware for the RT onto the DSL device and turn it into a useable router for HFC.

As a quick aside, NBN’s HFC comes into your home as a thick piece of coaxial cable which terminates at an NBN supplied modem with an ethernet jack, similarly to FTTP while FTTN terminates in a piece of “phone line” just like ADSL.

Back to performing unnatural acts with a router: converting one model to another through flashing firmware and making changes to NVRAM (non-volatile random access memory). After some ‘net searching, I’d decided that I would benefit from flashing the Merlin firmware giving me increased configuration (think “more things to play with”) and that I’d then use this is my main router. Sometime later and my DSL-AC68U had undertaken a gender change to an RT-AC68U and was working perfectly at 100Mb/s on an NBN HFC connection.

Brilliant!

For the technically inquisitive here’s how I did the change:

Step by step conversion of an ASUS DSL-AC68U to an RT-AC68U

  1. Reboot router
  2. Reset router to factory defaults
  3. Power off router, remove ADSL phone cable
  4. Hold a pin against the reset switch while powering up the router and release when the power LED starts blinking
  5. Plug an ethernet cable into port 1
  6. Disable any other network interfaces on the laptop/PC
  7. Set the laptop/PC to 192.168.1.10/24
  8. Open a web browser session to 192.168.1.1
  9. Upload the Asusert-Merlin firmware
  10. Wait until the upload has completed
  11. Power cycle the router
  12. Login to the router on 192.168.1.1 and
    • Set an admin username/password
    • Skip the rest of the network set up wizard as you’ll be completing this later
    • LAN->IPTV – set “ISP profile” to “manual setting”, set “internet VID” to “2”, PRIO to “0” (this is required if you are on the TPG network which uses VLAN tagging with VLAN ID 2)
    • WAN->Internet Connection – set “wan connection type” to “PPoE”, set “enable WAN” to yes
    • WAN->Internet Connection – set the username/password to match your preconfigured and TPG supplied router (both my username and password were different from my ADSL settings)
    • WAN->Internet Connection – under “Special requirement from ISP” set “Enable VPN + DHCP Connection” to “no”
    • (you do not need to enable dual wan: when you convert the DSL-AC68U to an RT-AC68U the default WAN port becomes switch port 1)
    • Adminstration->Operation mode – set to “Wireless router mode”
    • Adminstration->System – set “Enable JFFS custom scripts and configs” to “yes”
    • Adminstration->System – set “enable ssh” to “LAN only” and set “Allow Password Login” to “yes”
    • Apply changes and wait for router to reboot
  13. On your laptop/desktop open an SSH session to 192.168.1.1 with the username/password you created at the start of step (12), if you’re on Windows 10 you can use the default command line SSH program that now comes with W10 (FTW!) eg.  ssh -l admin-name 192.168.1.1
    • move to the scripts folder with

      cd /jffs/scripts/

    • use nano to create a “services-start” file

      nano services-start

    • with these three lines

      #!/bin/sh
      touch /tmp/000vlanconfigured
      robocfg vlan 2 ports “1t 5t”

    • Make 100% sure the file is correct, then save and exit nano (this sets up the WAN to use port 1 with VLAN ID 2 which is needed by TPG, this is only needed if you are on the TPG network or your RSP uses VLAN tagging)
    • set the script to allow execution with

      chmod 755 services-start

    • You can test execute the script to make sure that it works by typing

      ./services-start

    • set the router name to “RT” instead of “DSL” by entering the following (use copy and paste)

      nvram set odmpid=”RT-AC68U
      nvram set asuscfeodmpid=”RT-AC68U”
      nvram set asuscfecommit=1
      nvram commit

    • Reboot the router
  14. Login to the router and set any other configurations that need for DHCP, NTP, etc
  15. Adminstration->System – set “enable ssh” to “no”
  16. Save the router config file with Administration->Restore/Save/Upload Setting, you might also want to “Backup JFFS partition”
  17. Reboot and connect the WAN cable from the HFC modem to port 1 (you might want to label this port as WAN)
  18. Test that your router is working A-OK

Enjoy your reinvigorated router!

Closing notes: if you’d been using the inbuilt ASUS OpenVPN client on ADSL/2+ etc with your favourite VPN provider you’ll now find that the router will only allow between 20-25Mbp/s with AES-256/128 encryption which was fine under ADSL2 but this is now a problem if you’re on a 100 Mb/s plan and the only solution is to get a more powerful modem: there simply isn’t enough grunt in the AC68U CPU to manage the en/decryption needed by OpenVPN at such a high bit rate. You could redeploy this unit to act as an ASUS AiMesh node to alleviate any low WiFi connectivity (and ASUS have an awesome mesh config with AiMesh). Without any doubt you’ve also voided your warranty, so only do this if you know what you are doing and or are OK with wearing any consequences.

In closing and to answer a question which I posed at the very start of this article? What to do with the “bundled” device you’ll often receive from your RSP? And what about VOIP? Unless you use the “bundled” unit you’ll likely have a lot of grief trying to get VOIP (your “new” replacement telephone line) working, but really, who typically needs VOIP when you have a mobile phone?

Sadly I did find a use for my TP-Link “bundled” modem: to act as a media converter for ADSL<->ethernet by acting as a network bridge. Why? That’s more complex, the Readers Digest version is that I’m not officially provisioned (I agree, how does that happen?) on HFC for the next two months and after seventeen days of flawless performance the HFC link went down and I was told that I’d be without HFC based Internet access for at least 24-48 hours and while the HFC is now working again it may well go down until I’m officially provisioned on the NBN :/