Asuswrt-Merlin 3.0.0.4.374.33 Beta 5 available

[RMerlin]

Howdy folks,

This should be the last beta in this series. This build fixes a couple of issues that were introduced by the 374_720 code merge, and brings a few new improvements as well. The most notable points:

Option to control 802.11d and 802.11h support. The option can be found under Professional -> Wireless. Some mac users might want to set this to 802.11d+h if they experience connectivity issues. For more details as to what these two extensions do, please check a site such as Wikipedia.

I cannot confirm whether these really work or not, as this setting is directly accessed by the wireless driver, but in the past some users confirmed resolving issues by enabling this option.

More OpenSSL performance boosts I backported more ASM optimization code from OpenSSL 1.0.2, this time making the MIPS code use MIPS32r2 instructions. This leads to a major performance boost for SHA1, and code downsizing for AES.

Various bugfixes:

• DLNA scanning with large collections would crash
• Various NTP-related issues resolved (one of the most visible symptoms being the NTP warning appearing after you changed your Wireless settings)
• Crash with large OpenVPN keys
• Wireless key field being automatically focused
• IPv6 client list being incorrectly formatted if you had a device with a static IP (and possibly other scenarios also triggering this issue)

As usual, make sure you read the changelog for all the details.

You can directly flash this on top of beta 3, unless you are switching between SDK5 and SDK6 builds, which will require a factory default reset.


What I mostly need tested with this build:

• Things that rely on the router clock: wireless schedule, parental control, etc... I suspect the various fixes I did surrounding NTP might resolve other issues people were experiencing where timed tasks weren't working properly.
• DLNA and AiCloud access
• 802.11d and 802.11h settings. See if you can notice any difference when playing with these settings

RT-N66U: Thank you for the past feedback. At this point, I no longer need any additional feedback regarding wireless connectivity or performance. Asus told me they would look into it, so maybe they'll be able to improve things out in the future. This is something I cannot do anything about, so simply use the SDK5 build if you are having too many wireless issues with the regular RT-N66U build.

When posting feedback, make sure you report which router model you are using. I appreciate any feedback, but if I don't know which router you are talking about, then it's pretty much a waste.

 

[bill1228]

Won't install on my rt-n66u b1. Get message that not correct version and installing could cause failure of router. Downloaded twice just in case there was a download issue. Same message both times. --bill

 

[GoNz0]

DLNA is still causing AICloud to fail to open attached USB devices. A66u b1

 

[GoNz0]

Won't install on my rt-n66u b1. Get message that not correct version and installing could cause failure of router. Downloaded twice just in case there was a download issue. Same message both times. --bill

when i had that i was trying to restore settings instead of updating firmware (doh) then the other time i tried to upload a zip instead of extracting it 1st.

 

[PrivateJoker]

Option to control 802.11d and 802.11h support. The option can be found under Professional -> Wireless. Some mac users might want to set this to 802.11d+h if they experience connectivity issues. For more details as to what these two extensions do, please check a site such as Wikipedia.

I cannot confirm whether these really work or not, as this setting is directly accessed by the wireless driver, but in the past some users confirmed resolving issues by enabling this option.

Thank you for the update Merlin! Look forward to loading it soon and checking it out.

FWIW, in my experience with Macs and the 802.11d flags, it is most relevant when unboxing and connecting a new Mac (and potentially iOS device) for the first time and powering it up. It will configure it's own Airport adapter's channel availability based on the 802.11d info exposed to it from surrounding/connected APs. As I found out anecdotally the other day (and you immediately diagnosed) once configured, it seems not to be an issue even when connecting to subsequent APs that do not identify themselves. This could be something for users that travel abroad w/ a Mac then return to their home wifi might also be able to test.

And in my past experience w/ 802.11h, it can sometimes alter the 5ghz channel it auto selects, sometimes taking the first available double digit channel (that have different power regulations, at least in US) than the triple digit 5ghz channels.

So if reporting feedback to Merlin on 802.12d/h providing some background on channel in use, selection method, and whether or not your client device is making it's first ever wifi connection to the Asus AP might be relevant info for bug/performance/connectivity feedback.

Thanks again Merlin, the Asus user community is very thankful & appreciative for all of your work on this project and the amazingly helpful guidance your presence in forums such as these provides.

 

[Quiller]

DLNA is still causing AICloud to fail to open attached USB devices. A66u b1

+1

I think Merlin actually forgot to implement the corrected version of minidlna.

Other than that, great work Merlin

 

[NightOwl326]

Still can't switch channels either band... rt-n66u SDK5

 

[RMerlin]

+1

I think Merlin actually forgot to implement the corrected version of minidlna.

Other than that, great work Merlin

No, it's there:

root@ubuntu-dev:~/asuswrt/release/src/router# git log minidlna
commit b8d6dc7ee452e3d79b7d9c4bed8ee60ea4bee164
Author: Eric Sauvageau <rmerl@lostrealm.ca>
Date:   Wed Sep 25 00:58:23 2013 -0400

    Reverted Asus changes in an attempt to fix malloc() failures on large collections

 

[RMerlin]

Won't install on my rt-n66u b1. Get message that not correct version and installing could cause failure of router. Downloaded twice just in case there was a download issue. Same message both times. --bill

Double-check what you are trying to flash, on which page you are, and that you did unzip it first. My RT-N66U flashed just fine here.

 

[Martineau]

Still can't switch channels either band... rt-n66u SDK5

+1



regards

 

[RMerlin]

Still can't switch channels either band... rt-n66u SDK5

Thank you for specifying the build.

I see the SDK5 build is still using an older version of the wireless page. I removed the download for now, will re-upload a fixed build later tonight once I can confirm that it was indeed the reason for the problem.

 

[elzounet]

Hi Merlin,

I've flashed the beta5 on my RT-N16 and RT-N66U, and the jffs partition seems to be formatted at each reboot on both . Impossible to keep a file on it.
It was working fine with beta3.

Thx for your hard work.

 

[RMerlin]

Hi Merlin,

I've flashed the beta5 on my RT-N16 and RT-N66U, and the jffs partition seems to be formatted at each reboot on both . Impossible to keep a file on it.
It was working fine with beta3.

Thx for your hard work.

There's some old size check code from Tomato still lingering around, and I suspect it's causing issues with the N16 and N66 whenever you flash a firmware that resizes the JFFS2 partition.

Try unsetting the size variable through ssh/telnet:

nvram unset jffs2_size
nvram commit

Then reboot a first time. Store something in the jffs2 partition, then reboot a second time to check that this content is still there.

So far I've been unable to reproduce it, but I suspect it's related to that size code (the AC66/AC56 are unaffected since their jffs partition never changes size). I will probably end up pulling out that piece of code if it's too buggy.

 

[RMerlin]

I re-uploaded beta5b-sdk5 for the RT-N66U, with the correct version of the wireless pages. This one resolved the inability of changing channel on the wireless settings page for me.

 

[Quiller]

No, it's there:

root@ubuntu-dev:~/asuswrt/release/src/router# git log minidlna
commit b8d6dc7ee452e3d79b7d9c4bed8ee60ea4bee164
Author: Eric Sauvageau <rmerl@lostrealm.ca>
Date:   Wed Sep 25 00:58:23 2013 -0400

    Reverted Asus changes in an attempt to fix malloc() failures on large collections

Sorry, but the error is still here. If it is the same code as you made available last week as a separate runtime module, than I don't know why I'm getting the same error.

 

[RMerlin]

Sorry, but the error is still here. If it is the same code as you made available last week as a separate runtime module, than I don't know why I'm getting the same error.

Try erasing your existing minidlna database (if it's stored on disk), see what happens then.

It's possible that the two issues (the crash and the share access) are totally separate.

Unfortunately I've been unable so far to reproduce the issue here, so it's kinda hard to troubleshoot. At least are the crashing issues during scan still resolved?

 

[RMerlin]

And in my past experience w/ 802.11h, it can sometimes alter the 5ghz channel it auto selects, sometimes taking the first available double digit channel (that have different power regulations, at least in US) than the triple digit 5ghz channels.

I know that 802.11h has (amongst other things) to do with DFS, which is required to connect to some of the double-digit channels. I'm not sure however if the wireless driver actually supports DFS or not.

Even the channel availability enumeration seem a bit odd in the driver. The wireless driver was showing me a handful of available channels. After re-applying the US region to it, it suddenly started listing me a much larger selection of channels (and it was regardless of whether I had 802.11h enabled or not). Even weirder was that this was on the N66 - the AC66 would always remain with the same limited list of channels. I suspect this might be related to the regulation revisions (that number that you can see specified in addition to the country, for example US/63). It's possible that a certain revision is required to gain access to these additional channels.

This is something that would require a fair amount of researching, or the input from a wireless expert most likely. Probably best left for a separate debate, in a separate thread tho.

 

[GoNz0]

Try erasing your existing minidlna database (if it's stored on disk), see what happens then.

It's possible that the two issues (the crash and the share access) are totally separate.

Unfortunately I've been unable so far to reproduce the issue here, so it's kinda hard to troubleshoot. At least are the crashing issues during scan still resolved?

nope, i deleted my database and all the hidden files, turned DLNA on and still can't connect to the drives.

 

[Quiller]

Try erasing your existing minidlna database (if it's stored on disk), see what happens then.

It's possible that the two issues (the crash and the share access) are totally separate.

Unfortunately I've been unable so far to reproduce the issue here, so it's kinda hard to troubleshoot. At least are the crashing issues during scan still resolved?

This is my minidlna log:
[2013/09/29 21:57:59] minidlna.c:1201: warn: Starting MiniDLNA version 1.1.0.
[2013/09/29 21:57:59] minidlna.c:386: warn: Creating new database at /tmp/mnt/Mediadb/minidlna/files.db
[2013/09/29 21:58:00] scanner.c:721: warn: Scanning /tmp/mnt/MyBook/Music
[2013/09/29 21:58:00] minidlna.c:1245: warn: HTTP listening on port 8200
[2013/09/29 22:10:02] image_utils.c:419: warn: malloc failed
[2013/09/29 22:11:45] scanner.c:803: warn: Scanning /tmp/mnt/MyBook/Music finished (8071 files)!
[2013/09/29 22:11:53] playlist.c:125: warn: Parsing playlists...
[2013/09/29 22:11:53] playlist.c:256: warn: Finished parsing playlists.

That "malloc failed" popped up in beta 3 as did the inability to browse my files on the usb disks with AiCloud. I'll see what happens when I manually erase the database. Normally that's erased when the server rescans my music folder, but I'll give it a shot.

I do have the same behavior though. As soon as I switch of the Media Server, I can browse the files on my usb drives with AiCloud.

 

[bill1228]

Double-check what you are trying to flash, on which page you are, and that you did unzip it first. My RT-N66U flashed just fine here.

Yup. unzipped file name is RT-N66U_3.0.0.4_374.33_beta5.trx. So I have the correct file for the RT-n66U router I have. Have flashed many of your versions before without issue.
Windows properties reports file size 25.3 MB (26,550,272 bytes).
--bill