What's new

Linksys WRT1900AC, WRT1900ACS, WRT1200AC and WRT3200ACM Router Debian Implementation

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I thought that the most current Debian distro uses an older kernel than 4.4.16

Recently rebased off the 4.8.51 kernel (as of this weekend) along with moving to gcc 5.4.0... it's been interesting, but I think it'll be worthwhile... but we're also moving from glibc to musl - which is hella work here, as this impacts all userland stuff...

Previously, our marvell platform based was on 4.4 with gcc 4.9.2 with glibc 2.23

early builds are spooky and kinda crashy, but that's dev - stable is still old stuff...

Our moving walk-way is nearing it's end in any event - just wrapping things up and putting a BSP forward...
 
Apparently there's a weird issue with some Silicon Labs serial adapters and the WRT3200ACM. When I try to connect to the serial port, the router won't boot, but I read about this workaround: disconnecting the TX cable and plugging it in right after starting the router and then it works.

It's an odd thing with SiLab - just is... not so much different with older cables using FTDI or KLSI chips...

But true FTDI chips, probably the gold standard there... (be wary of cloned FTDI chips) - prolific is also really good here...
 
Finally got my serial adapter to work. Apparently there's a weird issue with some Silicon Labs serial adapters and the WRT3200ACM. When I try to connect to the serial port, the router won't boot, but I read about this workaround: disconnecting the TX cable and plugging it in right after starting the router and then it works.
I'll prepare the kernel upgrade and probably make next weekend's project to flash the WRT3200ACM and get SQM to work.
Thanks again!
I'm doing some QA on a McDebian 4.9.26 release that will be required for the WRT3200ACM. This McDebian version has kernel 4.9.26, mwlwifi driver version 10.3.4.0-20170421, hostapd 2.6 and wpa-supplicant 2.6.

The WRT3200ACM needs mwlwifi version 10.3.4.0-20170421 which isn't testing well with LEDE\OpenWRT or DD-WRT and IMO thats due to the hostapd and wpa-supplicant versions not being compatible with the new driver.
 
Last edited:
Recently rebased off the 4.8.51 kernel (as of this weekend) along with moving to gcc 5.4.0... it's been interesting, but I think it'll be worthwhile... but we're also moving from glibc to musl - which is hella work here, as this impacts all userland stuff...

Previously, our marvell platform based was on 4.4 with gcc 4.9.2 with glibc 2.23

early builds are spooky and kinda crashy, but that's dev - stable is still old stuff...

Our moving walk-way is nearing it's end in any event - just wrapping things up and putting a BSP forward...
Did you know that kernel 4.9 is a long term release?
 
Did you know that kernel 4.9 is a long term release?

It's a jump - for now, it's ok...

For our team - it's the userland, and other upstream stuff - drivers, device tree, and recall that we also locked down the gcc and libc - lots of stuff to sort out now...

why musl instead of glibc - it's smaller, and it works well - and with containers via docker/lxc, it makes sense here... Alpine Linux helps out here with containers

kinda like what I mentioned with dnsmasq vs isc-dhcp - solve as many problem as one can with in one code base...

fwiw - armv7-a - great performance with this chip, can't say much about Armada-XP, but Armada 38x is really stout stuff compared to others...

(XP and 38x are actually two separate architectures - WRT1900ac V1 is XP, the others are 38x)
 
Last edited:
I'm sorry I haven't responded sooner. I've been very busy.

I'm not sure about your point #6 "Making images" because I've always used the McDebian rootfs since I couldn't figure out how to get the
initrd.gz to work. It's awesome you are working on that because it has some advantages.

I recommend you make sure you have serial console access to the WRT3200ACM so you can experiment as much as you like without having to worry about bricking your WRT3200ACM.

OK... so, I successfully got Ubuntu 16.04 running on my WRT3200ACM, on linux kernel 4.11.0 with sch_ingress and sch_cake modules. I prefered Ubuntu over Debian due to some newer packages on Ubuntu repos. I just did the uImage merged with the DTB, no uInitrd.

I haven't had time to fix SQM-scripts for Debian/Ubuntu, but as soon as I get that working and some other services I want to run on the router, I'll share my progress.
 
OK... so, I successfully got Ubuntu 16.04 running on my WRT3200ACM, on linux kernel 4.11.0 with sch_ingress and sch_cake modules. I prefered Ubuntu over Debian due to some newer packages on Ubuntu repos. I just did the uImage merged with the DTB, no uInitrd.

I haven't had time to fix SQM-scripts for Debian/Ubuntu, but as soon as I get that working and some other services I want to run on the router, I'll share my progress.
Great and good job :D

I'm very interested in your sch_ingress, sch_cake modules and SQM-scripts development.
 
I've been using Ubuntu Xenial on the WRT3200ACM for a week or two now, and it works nicely.

About SQM, it's working like a charm. Minimal bufferfloat with sch_cake. The only thing I had to do differently is make available the IFB, NET_SCH_INGRESS and NET_SCH_CAKE modules (adding sch_cake source to the kernel as I previously explained) when compiling the kernel and getting the scripts from tohojo/sqm-scripts on github (https://github.com/tohojo/sqm-scripts).

The only trouble I've found so far is that interface indexes (ifindex) get screwed up when adding interfaces. I can use udev rules to rename interfaces according to their indexes, but if, for instance, I add a vlan interface on eth1 (eth1.10) and reboot, the indexes will change to something like:

Code:
eth0=3
eth1=2
eth1.10=4
wlan0=6
wlan1=7
mlan0=5

Instead of the default for the WRT3200ACM:

Code:
eth0=3
eth1=2
wlan0=5
wlan1=6
mlan0=4

I've been trying different approaches to solve this issue without any success.

I've made available Ubuntu Xenial rootfs and kernel image here:

Rootfs (http://www.mediafire.com/file/dzl1yxgdole9er2/wrt3200acm-ubuntu_xenial_armhf-4.11.3-rootfs.tar.bz2)
Kernel (http://www.mediafire.com/file/9f69ka0vdwtaf35/wrt3200acm-ubuntu_xenial_armhf-4.11.3.img)


You just need to flash the image to the router, format a USB thumb as ext4 and put the rootfs in there, and plug it in.

To ssh into the router, you have to do it as "root" with password "root".

Default SSID's are "Armada_2.4GHz" and "Armada_5GHz", with password "armada24" and "armada50", respectively.

The image has very similar software to McDebian, but with a BIND DNS server for the local network (bind to 192.168.1.1). Router will resolve on "armada.local" and every RFC1918 IP ranges are covered with empty zones, except for the 192.168 wich has it's proper zone and reverse lookup files for your customization.

SQM-scripts are installed and can be enabled with "systemctl enable sqm-scripts", but you'll need to set it up first. Check the example configuration file in "/etc/sqm".

I'll make a github repo for this development.

Please, if anyone knows how to fix the interface renaming issue, help would be greatly appreciated. I've worked around this issue by declaring interfaces in "/etc/network/interfaces", but bringing them up in "/etc/rc.local" with the "ifup" command. That way interfaces are properly mapped and once that's done, the rest of the interfaces are brought up at the end of the booting process.

IMPORTANT: THIS ONLY WORKS ON WRT3200ACM.
 
The only trouble I've found so far is that interface indexes (ifindex) get screwed up when adding interfaces. I can use udev rules to rename interfaces according to their indexes, but if, for instance, I add a vlan interface on eth1 (eth1.10) and reboot, the indexes will change to something like:

Take a look at this...

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

And between uboot and device tree, should fix that problem...
 
The only trouble I've found so far is that interface indexes (ifindex) get screwed up when adding interfaces. I can use udev rules to rename interfaces according to their indexes, but if, for instance, I add a vlan interface on eth1 (eth1.10) and reboot, the indexes will change to something like:

Code:
eth0=3
eth1=2
eth1.10=4
wlan0=6
wlan1=7
mlan0=5

Instead of the default for the WRT3200ACM:

Code:
eth0=3
eth1=2
wlan0=5
wlan1=6
mlan0=4

McDebian resolves this by using udev rules:
https://github.com/Chadster766/McDebian/blob/master/rootfs/etc/systemd/udev-network-interface-rules
 
The reason I request this test is because I'm wondering if setting eth0 txqueue to zero has the same effect.
Sorry I didn't reply earlier.
I'm getting A+ on bufferbloat with sqm-scripts layer_cake.qos script, with downlink and uplink set to about 90% of my actual bandwidth and ATM overhead set to 44 (ADSL).
That's the same I used to get with sqm-scripts on LEDE.
 
Sorry I didn't reply earlier.
I'm getting A+ on bufferbloat with sqm-scripts layer_cake.qos script, with downlink and uplink set to about 90% of my actual bandwidth and ATM overhead set to 44 (ADSL).
That's the same I used to get with sqm-scripts on LEDE.
Thanks for the information. I greatly appreciate it :)

My download and upload speeds don't seem to have any performance issues with using standard Debian networking even with the bufferbloat score of C+ with my ISP.

What performance increases do you see with these sqm\cake customizations?

I've tried to keep McDebian under a pure Debian networking scheme.

The reason for this is a few years ago I got tired of waiting for OpenWRT to fix all the bugs in their procd and uci systems. It's improved greatly but I still prefer the Debian networking system stability.
 
Thanks for the information. I greatly appreciate it :)

My download and upload speeds don't seem to have any performance issues with using standard Debian networking even with the bufferbloat score of C+ with my ISP.

What performance increases do you see with these sqm\cake customizations?

I've tried to keep McDebian under a pure Debian networking scheme.

The reason for this is a few years ago I got tired of waiting for OpenWRT to fix all the bugs in their procd and uci systems. It's improved greatly but I still prefer the Debian networking system stability.

Sqm-script uses tc (iproute2) to do the traffic shaping, reading your setup from a config file, but it just does that. No funny things as far as I've seen.

What I really appreciate about traffic shaping with sqm is that I see serious improvements when having multiple devices on the network struggling for bandwidth. For instance, if downloading a torrent on one device and streaming on another, I would normally get an awful quality on streaming and torrent will take most bandwidth. With sqm and cake, even though the torrent might take all the bandwidth, as soon as I start streaming, the latter will get prioritized and I will get great streaming quality.
 
Sqm-script uses tc (iproute2) to do the traffic shaping, reading your setup from a config file, but it just does that. No funny things as far as I've seen.

What I really appreciate about traffic shaping with sqm is that I see serious improvements when having multiple devices on the network struggling for bandwidth. For instance, if downloading a torrent on one device and streaming on another, I would normally get an awful quality on streaming and torrent will take most bandwidth. With sqm and cake, even though the torrent might take all the bandwidth, as soon as I start streaming, the latter will get prioritized and I will get great streaming quality.
Thank for the explanation on how those scripts work.

I use tc on my home network to make sure that that the kids have only enough bandwidth for HD streaming (8mbps) and gaming on a per device basis. The rest of the devices like the Apple TV are not throttled. I like having fine control over these types of configurations but I can see the attraction of having automated scripts to do the job. I just don't like not knowing what the scripts are doing on the network. I suppose a "tc qdisc show" would list what the scripts have configured.
 
Hi @cilix789

I was thinking, I could test your Ubuntu-WRT sqm setup and at the same time verify for you that it works on the other WRT models.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top