Asuswrt-Merlin - custom build of the Asus RT-N66U firmware

[RMerlin]

Impressive. Subbed for future updates. Right now I am going to jump to .112 official, but looking forward to a custom build of the official .112

I'll skip .112. I compiled it when they released the source code a few weeks ago, and radvd support in it is broken, making it unusable for IPv6 tunnels.

Beta 114 also had the same problem. I haven't tried beta 116 yet.

 

[RMerlin]

I am still using the Tomato firmware, but one thing that continues to annoy me about the Asus firmware is the problem they have with correctly displaying the connected client list. Many times it hangs on certain connected clients. I had that same problem on the rt-n56u also. Yet the custom firmwares, or Tomato have no problem with it.

I haven't tried this firmware, but it probably has that problem seeing that's it's mostly made by Asus?

Correct. That part of the code is completely untouched in my builds, so it will have the same issues. I would take a look at it, but unless I could reproduce the problem, it would be hard for me to know what's wrong with their client detection code.

 

[jet45]

Nice work RMerlin.

How easy would it be for you to implement turning off both radios via the WPS button similar to DD-WRT and Tomato? I didnt see it in the stock firmware, if its not to much trouble would love to see this added to your firmware.

I also saw a video from Asus stating that they could control the brightness of the LED's, is that possible?

 

[RMerlin]

Nice work RMerlin.

How easy would it be for you to implement turning off both radios via the WPS button similar to DD-WRT and Tomato? I didnt see it in the stock firmware, if its not to much trouble would love to see this added to your firmware.

I also saw a video from Asus stating that they could control the brightness of the LED's, is that possible?

WPS button: Not sure, I'll have to see what it entails. I want to keep code-level changes down to a minimum, since I have to re-apply all those changes every time Asus releases a new version (which happens 1-2 times a month these days).

LEDs: I haven't had time to look at LED control stuff yet. Intensity control would surprise me, as I haven't seen any trace of such a thing so far in the code.

 

[TC777]

Correct. That part of the code is completely untouched in my builds, so it will have the same issues. I would take a look at it, but unless I could reproduce the problem, it would be hard for me to know what's wrong with their client detection code.

You probably don't have a device that causes it, but for me its any device that you can access by typing its IP in a browser, and view or change it settings.

Like a printer, or a media player (like a WD Live TV). Those are the connected clients that it has problems with. Although they display perfectly fine in the DHCP list of clients.

Asus had me test two different firmwares that they made for me, that had more detailed logs and I emailed the logs to them so they could see what was going on. But I haven't heard anything since.

 

[RMerlin]

You probably don't have a device that causes it, but for me its any device that you can access by typing its IP in a browser, and view or change it settings.

Like a printer, or a media player (like a WD Live TV). Those are the connected clients that it has problems with. Although they display perfectly fine in the DHCP list of clients.

The WRT320N I had plugged on my network while working on the RT-N66U last night does show on the client list as having a management web interface, but it didn't cause any issue for me while navigating between pages. However I do have a WDTV Live (I'm one of the developers of the WDLXTV homebrew firmware for it), so I'll try plugging it back to my network sometime and see if I can reproduce the issue. Will be tricky to debug for me however as I don't have a serial cable.

On the WPS button front: I'll add it to my ToDO list. I had a look at the button handling code, and it should be fairly simple to implement.

I wish I had more headroom in the already crowded nvram however. Adding config options such as this is quickly filling up space. I'm puzzled that Asus only uses 30 KB max when the mtd partition is 128 KB large...

 

[shantanugoel]

I wish I had more headroom in the already crowded nvram however. Adding config options such as this is quickly filling up space. I'm puzzled that Asus only uses 30 KB max when the mtd partition is 128 KB large...

Could you think about keeping a file in jffs for the config options added on top of stock fw instead of using nvram? Will that work?

 

[RMerlin]

Could you think about keeping a file in jffs for the config options added on top of stock fw instead of using nvram? Will that work?

JFFS can get wiped after a firmware upgrade if the new firmware is a different size.

 

[jet45]

On the WPS button front: I'll add it to my ToDO list. I had a look at the button handling code, and it should be fairly simple to implement.

Nice, looking forward to your next release.

 

[RMerlin]

Updated OP: Build 3.0.0.3.108.3 is now available. Enjoy

3.0.0.3.108.3:
- NEW: JFFS support (mounted under /jffs)
- NEW: services-start, services-stop, wan-start and firewall-start user scripts,
must be located in /jffs/scripts/ .
- NEW: SSHD support
- IMPROVED: Fleshed out this documentation, updated Contact info with SNB forum URL
- CHANGE: Removed wol binary, and switched to ether-wake (from busybox) instead.
- CHANGE: Added "Merlin build" next to the firmware version on web interface.

 

[morden]

Keep up the good work Merlin. Just a quick question in regards to flashing your custom firmware...should we clear the nvram between your builds? My current firmware is based on your last build (RM2)? Or should the nvram only be flashed if we upgrade from let's say....stock firmware to shibby's and vice-versa?

 

[shantanugoel]

Updated OP: Build 3.0.0.3.108.3 is now available. Enjoy

3.0.0.3.108.3:
- NEW: JFFS support (mounted under /jffs)
- NEW: services-start, services-stop, wan-start and firewall-start user scripts,
must be located in /jffs/scripts/ .
- NEW: SSHD support
- IMPROVED: Fleshed out this documentation, updated Contact info with SNB forum URL
- CHANGE: Removed wol binary, and switched to ether-wake (from busybox) instead.
- CHANGE: Added "Merlin build" next to the firmware version on web interface.

Awesome. will try it out as soon as I reach home tonight.

 

[RMerlin]

Keep up the good work Merlin. Just a quick question in regards to flashing your custom firmware...should we clear the nvram between your builds? My current firmware is based on your last build (RM2)? Or should the nvram only be flashed if we upgrade from let's say....stock firmware to shibby's and vice-versa?

No need to wipe nvram whenever you are going from either my previous builds or Asus'.

 

[morden]

Ok thanks! Once again keep up the good work

 

[shantanugoel]

I've created a git repository for this at https://github.com/shantanugoel/asus-rt-n66u-merlin

It contains the stock asus fw in master branch, Eric's builds in merlin branch and my changes in shantz branch.

Eric, you may want to look at my branch (and at your branch's last commit). I've made a few compilation related fixes, a fix for ssh starting when disabled, and updated dropbear to latest 2012.55 version. The code as well as compiled trx image is available in the repo (compiled images are in release/src-rt/image folder for anyone wanting to try out the images without compiling themselves)

 

[RMerlin]

Nice Can you PM me a login so I can do commits to my branch?

It will take some time for me to get used to it, as I have never used git before (I've only used SVN before).

I assume that as Asus releases new stable versions, you could commit them to the trunk, and start new branches for both of our variants (to which we'd then re-apply our changes)?

I'll take a closer look at it over the weekend.

 

[shantanugoel]

Nice Can you PM me a login so I can do commits to my branch?

It will take some time for me to get used to it, as I have never used git before (I've only used SVN before).

I assume that as Asus releases new stable versions, you could commit them to the trunk, and start new branches for both of our variants (to which we'd then re-apply our changes)?

I'll take a closer look at it over the weekend.

You'd need to make an account on github, then I can add you to the repo.

yes, as asus releases new code, we can first merge them to the master branch and then we can merge them to the other branches as well using git merge (might have to resolve some conflicts manually) but usually for my smaller projects merge has worked automagically, saving the time to reapply the changes.

I'm also not very good in git but it is easy to pick up (at least for basic tasks). Look at http://gitref.org for quick and dirty instructions.

 

[RMerlin]

You'd need to make an account on github, then I can add you to the repo.

yes, as asus releases new code, we can first merge them to the master branch and then we can merge them to the other branches as well using git merge (might have to resolve some conflicts manually) but usually for my smaller projects merge has worked automagically, saving the time to reapply the changes.

I'm also not very good in git but it is easy to pick up (at least for basic tasks). Look at http://gitref.org for quick and dirty instructions.

Account created. Username is RMerl.

 

[shantanugoel]

^^ Added

 

[RMerlin]

Think I got the basics worked out, already pushed a test change to my branch. Thank you for setting this up