Master repository for the Asus BRT-AC828 firmware
ce3fe17d — Diederik de Haas 8 months ago
Add HTML version of translated review
e4ba4761 — Diederik de Haas 8 months ago
Add translated review by redeszone.net of the BRT-AC828
1362e561 — Diederik de Haas 9 months ago
Rename from License to LICENSE


browse  log 



You can also use your local clone with git send-email.

#Asus BRT-AC828 router firmware

This is the master repository for the source code for the Asus BRT-AC828 router firmware.
Several parts of that source code are or will be split out to their own repository and linked to this one via git submodules.


The firmware for the BRT-AC828 router, like many other Asus routers, is composed of various Free Software components. And Asus actually honors their obligation to provide the source code of their (derived) product. When Asus released version of their firmware, I noticed the corresponding source code was not available (it was for a previous 380 version), so I wrote them an email requesting the source code and they put it online the next day! :-D


  1. Because I can.
  2. Security. Several userspace programs are quite dated and it uses kernel version 3.4.103, which is dated and unsupported upstream.
    I don't know when/if Asus will provide new firmware versions but it's extremely unlikely they'll upgrade the kernel to f.e. a SLTS release.
  3. Show the power of Free/Libre and Open Source Software. Because the source code is provided I am able to do this at all.
    My previous router was also from Asus, but I used the custom firmware made by RMerlin and thought it was magnificent. Asus used various improvements from that project themselves. Getting the source code of the firmware was a big part of the reason I bought an Asus router again. If/when I run into a problem, I don't have to rely on an outside party to be willing to provide a fix. No more planned obsolescence as I can fix things myself, because I have the source code :)
    I have previously benefitted from RMerlin's work and his work will also help me in this project. And hopefully my work will help others as well. Or other people contribute to this project. It's not a guarantee that'll happen, but with FLOSS, it is at least possible.
    I've also deliberately chosen Sourcehut to host my project as that is also (fully) FLOSS.
  4. It provides for a great learning opportunity.
    While I am an experienced software engineer, I'll have to learn a LOT of new things to realize my goals for this project. There's a very good chance that some things will be unattainable. And I'll likely make several 'rookie' mistakes. And I plan to document it all :) So that not only I learn from it, but others can too.
    Even if I only succeed in a fraction from what I hope to achieve, I'll still have learned a lot of new things.
  5. Because it sounds interesting and fun.

#Repository structure

So I downloaded the archive (GPL_BRT-AC828_3. which is 778.5 MiB in size and after extraction it's a whopping 2.9 GiB. While git can technically manage that, it's unpractical. So I'll split the project up in this main repo and various git submodule repos, linked into this repo.
The reason it's so large is that it contains the source code of all the components from which the firmware is build. From the archive you can built firmware for a number of different Asus router models by giving the proper argument to make. As they not all use the same versions of the components, you'll end up with multiple copies of f.e. Samba.
It also includes a (heavily) modified copy of the Linux kernel (393.9 MiB) that is used by this router. And also what seems like a repository (468.7 MiB) to install additional software on the router.

#Repository split up and clean up

Logically that means we can split the archive/repo in several sections, like kernel, router software, a router software repo and possibly more. That means that each separate repo would become better manageable (and/because it's smaller).
Getting rid of f.e. the multiple copies of the same software also seems useful. Such a task is best done under (git's) version control. Once I've determined all the things that can be thrown away, I can then create a new and clean git repo with only the software I need and change the submodule of the main repo to point to the clean version. The old repo could then be deleted, but I'll probably keep it as it could contain useful info for when someone else wants to embark on a similar journey.
I may also try to convert the Linux repo into a style used by Debian, which contains only the (infrastructure and) modifications and configuration of the upstream kernel, but not the kernel code itself.

#Git submodules

Here is a list of the git submodules used in this project: