Bypassing and removing CenturyLink Fiber Modem

How to eliminate your Centurylink modem. In three easy steps.

I have CenturyLink gigabit fiber with a ZyXEL C2100T modem and a WRT1900AC router with LEDE Reboot 17.01.4 r3560-79f57e422d / LuCI lede-17.01 branch (git-17.290.79498-d3f0685)

Before you begin please ensure that you create backups of the settings for the router and the modem.

Step 1 - Software: Ensure that luci-proto-ppp, kmod-ppp and kmod-pppoe are installed. They came pre-installed on mine.

Step 2 - Enable PPPoE
Go to Network/Interfaces/Wan and change protocol to PPPoE and enter your DSL username and password (not your account password)
image

Step 3 - Enable VLAN tagging
Go to Network/Switch and change VLAN ID 2 to 201 and enable TAGGED for the LAN
image

That's it. Click Save and Apply. Move the cable going to the WAN port of your modem to WAN port of your router. Reboot and enjoy.

2 Likes

Wow, if only it was this easy with ATT. They use 802.1x with certificates and it requires you to do a lot of hassle proxying the EAPOL packets and fooling around.

:grinning:

It's easy when you know the answer. It was difficult (for me) to find. That's why I posted it.

Thanks LocalHoser. Your post helped me setup my router. I'll add some more info onto this thread for the next person.

You can find how to get your DSL username and password on other posts, like this one.

I'm using a Netgear WNDR3800, because of it's small size. It's sitting inside a patch panel in a wall of my house. The stock CenturyLink modem is too big and doesn't fit.

I'm running an ath79 build to get flow offloading.
image

For my router, the network/switch page doesn't list the wan port:
image

So I just typed in eth1.201 as a custom interface, and it worked!
image

My internet connection is gigabit fiber, but the router can't keep up. Before I enabled flow offloading, here's what I was getting for IPv4 speed tests:
image

And here's IPv6 (I'll explain how to enable it later)
image

I turned on software flow offloading under Network > Firewall > General Settings. I also turned on Hardware flow offloading, but that doesn't seem to make a difference in the performance tests.
image

After doing that, I was able to keep viewing most webpages. I immediately got much better download rates in speed tests, but for the upload test, it would hang at 0%. After a lot of trial and error, I figured out it was an MTU problem. Lowering the MTU to 1492 on my Linux machine fixed the upload. I added the mtu limit as a DHCP option. The Linux DHCP clients behind the router picked it up and it worked. However, the Roku boxes on my network couldn't reach Netflix. I'm guessing the Roku boxes didn't honor the MTU from the DHCP lease, but I didn't take sniffs to verify.

So instead of lowering the MTU on the clients, I raised the MTU on the router. I used ifconfig inside the router to temporarily adjust the MTU for eth1 and eth1.201. ifconfig could set the MTU up to 1516, but would return errors if I went any higher. I couldn't find any LuCI GUI way to permanently change the MTU, so I had to edit /etc/config/network directly and add this to the top:

config device
	option name 'eth1'
	option mtu '1516'

config device
	option name 'eth1.201'
	option mtu '1516'

I also overwrote the MTU on the WAN network interface page. Although I'm not sure if this set is required:
image

After rebooting the router so it would apply the network changes, I verified the MTU using ifconfig:

br-lan    Link encap:Ethernet  HWaddr 2C:B0:5D:7F:47:BB  
          inet addr:192.168.15.1  Bcast:192.168.15.255  Mask:255.255.255.0
          inet6 addr: fe80::2eb0:5dff:fe7f:47bb/64 Scope:Link
          inet6 addr: 2602:ae:1543:b900::1/60 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:63424002 errors:0 dropped:8 overruns:0 frame:0
          TX packets:49226878 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10756886892 (10.0 GiB)  TX bytes:31481200458 (29.3 GiB)

eth0      Link encap:Ethernet  HWaddr 2C:B0:5D:7F:47:BB  
          inet6 addr: fe80::2eb0:5dff:fe7f:47bb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:63424040 errors:0 dropped:0 overruns:201 frame:0
          TX packets:49226892 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3308591045 (3.0 GiB)  TX bytes:1613338330 (1.5 GiB)
          Interrupt:4 

eth0.1    Link encap:Ethernet  HWaddr 2C:B0:5D:7F:47:BB  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:63424002 errors:0 dropped:0 overruns:0 frame:0
          TX packets:49226878 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10756886892 (10.0 GiB)  TX bytes:31481200458 (29.3 GiB)

eth1      Link encap:Ethernet  HWaddr 2C:B0:5D:7F:47:BC  
          inet6 addr: fe80::2eb0:5dff:fe7f:47bc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1516  Metric:1
          RX packets:47277175 errors:0 dropped:0 overruns:1388 frame:0
          TX packets:61415432 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1623006881 (1.5 GiB)  TX bytes:3429836415 (3.1 GiB)
          Interrupt:5 

eth1.201  Link encap:Ethernet  HWaddr 2C:B0:5D:7F:47:BC  
          inet6 addr: fe80::2eb0:5dff:fe7f:47bc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1516  Metric:1
          RX packets:47241940 errors:0 dropped:0 overruns:0 frame:0
          TX packets:61415425 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:30835308933 (28.7 GiB)  TX bytes:11774108481 (10.9 GiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:851424 errors:0 dropped:0 overruns:0 frame:0
          TX packets:851424 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:71163376 (67.8 MiB)  TX bytes:71163376 (67.8 MiB)

pppoe-wan Link encap:Point-to-Point Protocol  
          inet addr:174.21.67.185  P-t-P:63.231.10.66  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1496  Metric:1
          RX packets:47237235 errors:0 dropped:0 overruns:0 frame:0
          TX packets:61410713 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:30457212707 (28.3 GiB)  TX bytes:10422930833 (9.7 GiB)

My internet connection has been stable after increasing the MTU like that. Although it still seems that only up to MTU 1492 works for devices behind the router:

[kyle@ryoko ~]$ ping -M do -s 1464 8.8.8.8 -c1 -w1
PING 8.8.8.8 (8.8.8.8) 1464(1492) bytes of data.
1472 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=2.73 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.735/2.735/2.735/0.000 ms
[kyle@ryoko ~]$ ping -M do -s 1466 8.8.8.8 -c1 -w1
PING 8.8.8.8 (8.8.8.8) 1466(1494) bytes of data.

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Here's my IPv4 performance with the flow offloading:
image

And IPv6
image

Based on the top output from inside the router,
I'm fairly certain I'm getting limited by the router's CPU, not the ISP. Here's top output from inside the router during the IPv4 download test:

Mem: 34848K used, 89352K free, 712K shrd, 2200K buff, 8248K cached
CPU:   0% usr   0% sys   0% nic   0% idle   0% io   0% irq  99% sirq
Load average: 0.55 0.19 0.11 2/39 8922
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
    7     2 root     RW       0   0%  98% [ksoftirqd/0]

I had to install some modules to get IPv6 exposed in Luci, and more to get it to work, but I don't remember exactly which ones they were. Here's what 6rd settings look like:
image

Here are my IPv6 DHCP settings for the LAN interface:
image

I added static leases for computers on my network. I can't get the IPv6 suffix option on the static lease to work, but the IPv6 suffixes seem to be stable anyway.

For IPv4, I forward external port 23 to port 22 of an internal computer, and port 24 to port 22 of an internal computer. I wanted to do the same port translation for IPv6. IPv6 is different because those internal computers have unique IPv6 addresses, which are directly accessible (not NAT'd) externally. So usually port translations are not done for IPv6. However, I found out that by installing kmod-nf-nat6 and kmod-ipt-nat6, I could do the port translation for IPv6 with iptables too.

I only want the 23 to 22 forwarding for one computer on my network. I don't want to open up port 22 to all IPv6 computers behind the router. This is tricky because the specific IPv6 address I want to allow changes as my ISP changes the IPv6 address prefix through DHCP. Fortunately I found out that I can use an IPv6 netmask that matches just on the suffix. So -d ::f0a/::ffff:ffff:ffff:ffff matches any IPv6 address that ends with 0:0:0:f0a.

I also open a few ports for some minecraft servers to just one physical machine behind my router.

Here are the ip6table rules I have:

ip6tables -t nat -A PREROUTING -i 6rd-wan6  -p tcp -m tcp --dport 23 -d ::f0a/::ffff:ffff:ffff:ffff -m comment --comment "!fw3: ssh to ryoko" -j DNAT --to-destination :22
ip6tables -t nat -A PREROUTING -i 6rd-wan6  -p tcp -m tcp --dport 24 -d ::527/::ffff:ffff:ffff:ffff -m comment --comment "!fw3: ssh to mihoshi" -j DNAT --to-destination :22

ip6tables -A zone_wan_forward -p tcp -m multiport --dports 25565,25567,25568,3000 -d ::527/::ffff:ffff:ffff:ffff -m comment --comment "!fw3: minecraft ports for mihoshi" -j ACCEPT
ip6tables -A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT

I put them in Firewall - Custom rules.
image

I'm also using dynu for dynamic DNS. The IPv4 dynamic DNS is straight forward, but the IPv6 is tricky, because I don't want the router to use its IPv6 address, I want it to upload the address of mihoshi, one of the computers behind the router.

Here's my IPv6 DDNS configuration in the GUI:
image
image

It calls a script I wrote to look up the IPv6 address of mihoshi. It does the lookup using nslookup, which polls the database updated by the dhcp server (odhcpd).

root@OpenWrt:~# cat /etc/mihoshi-ipv6.sh 
#!/bin/sh
address=`nslookup -q=AAAA mihoshi | sed -n -e 's/.*has.*address \(.*\)/\1/p'`
if [ -z "$address" ]; then
  exit 1
else
  echo "$address"
fi
root@OpenWrt:~# /etc/mihoshi-ipv6.sh 
2602:ae:1543:b900::527
1 Like

I tried an EspressoBin this time. I used the latest snapshot image.

On this router, I needed to use the wan.201 for the internet port. Unlike the previous router, switching the MTU settings around doesn't seem to have any effect.

image

I turned on the offloading:
image

The IPv4 speed varies between 700 and 830 download.
image

IPv6:
image

The router with the wall transformer is taking 7 watts.

However, the router is rebooting every hour to 10 minutes without any errors in the log.

I tried downgrading it to the 18.06.1 release. I didn't do the full pppoe test. I did reproduce the reboot problem by keeping a constant 100MB/s traffic through through it's nat to another computer on my network. I also ran a bunch of extra CPU stress from a shell prompt.

Even though its 3 main chips came with heatsinks, one of them gets really hot. I think that's what's causing the reboots. I took off the plastic case and turned the board around so the heat sinks were on top. It ran for 67 minutes that way, versus about 8 in the enclosure. I'm going to order the metal enclosure and see if it cools better than the plastic one.

Which version of the espressobin do you have. I've got a v5 and it seems to be stable and reasonably cool without any heatsinks

I tried leaving it idle with the case off. It still rebooted after an hour. I've tried 2 different power supplies too.

On the forum other people have reported the same problem.

It says ESPRESSObin_V7_0-2 on the bottom.

IMG_20190120_000122

IMG_20190119_235755

I'm glad my v5 doesn't have this problem it's running at only 800Mhz but still routes several hundred mbits with SQM. However I'm running Armbian on it. Perhaps the kernel has some power saving features that are helping keep it cool. I'll look what it says for cpufreq.

output of cpufreq-info on my v5 running Armbian;

analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 0.97 ms.
  hardware limits: 200 MHz - 800 MHz
  available frequency steps: 200 MHz, 267 MHz, 400 MHz, 800 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 250 MHz and 800 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 267 MHz (asserted by call to hardware).
  cpufreq stats: 200 MHz:0.05%, 267 MHz:99.66%, 400 MHz:0.01%, 800 MHz:0.29%  (1272)
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 0.97 ms.
  hardware limits: 200 MHz - 800 MHz
  available frequency steps: 200 MHz, 267 MHz, 400 MHz, 800 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
  current policy: frequency should be within 250 MHz and 800 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 267 MHz (asserted by call to hardware).
  cpufreq stats: 200 MHz:0.05%, 267 MHz:99.66%, 400 MHz:0.01%, 800 MHz:0.29%  (1272)

So perhaps some significant power savings come from cpufreq reducing frequency to 267 MHz during idle.

It must be something other than heat causing the reboots. I applied new heat sink compound and left the case off. It still reboots while it's idle. The chips are only warm with all that cooling.

OpenWRT is correctly doing CPU scaling:

root@OpenWrt:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
200000
root@OpenWrt:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 
200000
root@OpenWrt:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 
1000000

If it's rebooting while idle, and running cpufreq scaling, it's probably not from too high a cpu frequency, but you might try limiting the max frequency to 800 and see if it helps at all. Also, you might be able to clock back the RAM a bit and get better stability, but I'm not sure how.

Armbian creates their own uboot, and it's possible it sets up something before boot that improves stability etc. Not sure. They have a difft version for each board and goes by CPU and RAM speeds and chip counts.

you might also try using a remote system log (send via udp to rsyslogd running on another device) and see if you can figure out what it's doing just before the reboot.

I had the usb serial port attached. It doesn't report any errors. It just goes from having the command prompt to showing boot up messages.

You said yours is stable. What's the uptime? I think mine had 1GB of ram. How much ram does yours have. Some people say the 2GB model is stable.

Overall I've invested too much time into the espressobin. Even if some of its units are unstable, I can't recommend it to other people.

Mine is a 1GB v5 800MHz.

Try installing Armbian and its uboot. Or if you're done with it ship it my way and I'll experiment with it :wink:

I tried a Banana Pi R2. The software is a nightmare for it. Even though openwrt claims to have images for it, they don't work. The banana pi website's openwrt links actually point to forum posts. The links in those forum posts are broken.

One prebuilt OpenWrt image did install, but opkg refused to install any packages, because the kernel version didn't match.

I tried building this branch from source:

It did build and boot up. Even though most of the kernel version matched openwrt head, opkg still refused to install the packages from the openwrt repository. I ended up having to build all the packages too. When I finally booted it up, I was only getting 40MiB/s transfer between two computers in my house, when the router was doing a NAT between them.

I tried frank-w's Debian image. Again 40MiB/s transfer. Although sending all 0s or all 1s was faster. It doesn't make sense. I posted more details on their forum.

At this point, even if this gets fixed, I can't recommend the Banana Pi either, do to all the hassles in getting a working image.

1 Like

Any experience with the orange pi series?

I didn't buy one, because I couldn't find any with at least 2 gigabit ports.

Most consumer routers only have one Ethernet connection and a switch. You can plug an orange pi into a smarts switch and get the same basic setup.

That sounds like a really fragile setup. If everything was working, my computers would get half duplex speed to the Internet at best.

I ordered a used Linksys EA8500. I'm going to try it next.

If you have anywhere near 500Mbps you need an x86, and if you have less than that the duplex issue doesn't matter.

Hard to tell from online info but it looks like the EA8500 has exactly the same architecture. One ethernet connection to the CPU and two tagged vlans to provide the wan and LAN ports.