Asuswrt-Merlin 374.40 ALPHA 4 builds now available

[RMerlin]

Howdy folks,

As I'm getting flooded with queries on both Email and Twitter, and I don't have everything needed yet to make an official 374.40 release (missing the time to work on it, and also missing some GPL bits from Asus as well), I just uploaded alpha builds of the firmware to Mediafire.

These builds are merged with the 4422 GPL, which includes the new Setup Wizard that won't default to AnonFTP access by defaults, and various security fixes around AiCloud and Samba. IMPORTANT: the Samba security issue specific to the AC56/AC68 is NOT fixed in Asus's 4422, HOWEVER my own fix from 374.39 is still present in 374.40. Asus have been notified that their fix wasn't properly implemented (it's a coding error, not because they had ignored it), so I would expect them to resolve this in their next release.

Be ware of the following caveeats:

• They received VERY LIMITED testing (aside from the AC68U which has been running for 24 hours on my main router)
• The AC56/AC68 builds are still using the older 583 kernel, driver and other binary blobs, as Asus hasn't released the GPL for this one yet (explanation below). DFS might or might not be working due to this.
• I won't be offering any kind of support for these builds, since they are alpha builds. If you are having any kind of issue with it, then you will have to revert back to 374.39
• 4422 has compatibility issues with IE and the new notification system (to be addressed by Asus with their next release).
• Still no RT-N16 build, since I don't have any recent enough GPL for this specific model. Mixing the older wireless driver with the current FW code results in a crash during boot. So for now, RT-N16 users should make sure that FTP isn't set to allow anonymous connections, and to be safer also keep AiCloud disabled, or revert to Asus's original FW.

Asus are planning to have another FW release this week, which is why I did not ask them for the missing 4422 GPL for the AC56 and AC68, and also why I didn't spent the last weekend testing things out like I usually do as I knew it would have to be done all over again once they released this next version.

I included the (mostly complete) changelog in the archive. And as a free bonus, DNSFilter users will be able to start playing with the new custom filter setting.

 

[applesnowleo]

GPL 4422 Code for AC68U is avaliable now.

 

[RMerlin]

GPL 4422 Code for AC68U is avaliable now.

Thanks for the info.

I will wait a bit for more people to post feedback on the original firmware before merging the AC68 binary blobs, because I've seen quite a few AC68 owners mention having random reboots with Asus's 4422.

 

[TeMpL]

We will wait until weekend for updated code ...
Need stable connection during Winter Olympics

 

[jim769]

Yes I think I will wait for a final 40 build. Using 39 on my AC68U and it's working good. Also I have had the 68U up now for 4 days and it has not lost its ipv6 address one time so maybe that issue is in the n66u only using 39em. I will keep an eye on it.

 

[vdemarco]

Howdy folks,

As I'm getting flooded with queries on both Email and Twitter, and I don't have everything needed yet to make an official 374.40 release (missing the time to work on it, and also missing some GPL bits from Asus as well), I just uploaded alpha builds of the firmware to Mediafire. ....

I just installed it on my RT-AC66u. so far so good. I am not using the DNSFilters etc, but everything seems good.

Thanks.

 

[bluepoint]

Howdy folks,

As I'm getting flooded with queries on both Email and Twitter, and I don't have everything needed yet to make an official 374.40 release (missing the time to work on it, and also missing some GPL bits from Asus as well), I just uploaded alpha builds of the firmware to Mediafire.

.

Is the Alpha build for N66U the EM version?

 

[lancer73]

Is the Alpha build for N66U the EM version?

Yes. The changelog states that starting version 40 the EM version is standard (so no non EM builds any more)

 

[bluepoint]

Yes. The changelog states that starting version 40 the EM version is standard (so no non EM builds any more)

Can you share the change log? It doesn't say it from the Alpha firmware's release note.

Update: Just re-read the Release Note(Readme) and sure enough he stated that EM version is now standard.

 

[sofent]

Thanks for the info.

I will wait a bit for more people to post feedback on the original firmware before merging the AC68 binary blobs, because I've seen quite a few AC68 owners mention having random reboots with Asus's 4422.

I met the random reboot problem after i upgraded to 4422,so i flash back to 374.39 merlin

 

[HeadBanger]

Hi Merlin,

I am unable to flash this onto AC66U and each time I try the route reports a different old firmware (354.28). This has happened to me previously on the 374.38.

I can assure you that I have downloaded 374.40 and I do not have 354.28 in my download folder. I tried to flash 3 times with same result and have flashed 374.39 again with no problems.

Is the 354.28 some sort of inbuilt recovery firmware or do the routers perhaps revert back to original shipped firmware in the event of an error during the flash?

 

[L&LD]

HeadBanger,

did you try to remove all connections (Ethernet or USB) from the router except for the controlling computer?

Did you try resetting the router to defaults before you flashed the new version?

Do you clear the nvram at any stage?

Did you unzip the downloaded file and point the router to that directory?

Have you cleared your browser cache lately?

Just suggestions of what may help you flash it properly.

 

[SpOuK3]

smb error using VPN

Hi,

I'm a new user with the RT-AC66U + Merlin firmware (Alpha version) and I have an issue with samba and VPN.

1) Credentials are always rejected when going thru a VPN.

2) Here's the logs:

Feb 20 10:26:18 smbd[1309]: [2014/02/20 10:26:18, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:26:18 smbd[1309]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:28:37 smbd[1316]: [2014/02/20 10:28:37, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:28:37 smbd[1316]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:28:37 smbd[1317]: [2014/02/20 10:28:37, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:28:37 smbd[1317]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:28:37 smbd[1318]: [2014/02/20 10:28:37, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:28:37 smbd[1318]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:29:07 smbd[1319]: [2014/02/20 10:29:07, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:29:07 smbd[1319]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:29:22 smbd[1322]: [2014/02/20 10:29:22, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:29:22 smbd[1322]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:29:22 smbd[1323]: [2014/02/20 10:29:22, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:29:22 smbd[1323]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:29:44 smbd[1327]: [2014/02/20 10:29:44, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:29:44 smbd[1327]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.



I checked the issue on google and found two solutions and they are not working...

--> Add "security = USER" to smb.conf (already there by default)
--> Change to "yes" : client use spnego = no

It's still not working ... I'm connecting to the VPN with my Nexus 5 device and I use Astro File Manager to access smb share...

Also, credentials are working from a local PC using Windows 8.1.


Thanks for your input on this one!


EDIT: there's a weird line in smb.conf by default: --> "use spne go = no" is this generated by the firmware? this line is there after a reboot of the router...

2nd EDIT: removing the "use spne go = no" from smb.conf fix the issue .... Maybe thats a bug? Can RMerlin have a look at it?

 

[krum]

Hi,

I'm a new user with the RT-AC66U + Merlin firmware (Alpha version) and I have an issue with samba and VPN.

1) Credentials are always rejected when going thru a VPN.

2) Here's the logs:

Feb 20 10:26:18 smbd[1309]: [2014/02/20 10:26:18, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:26:18 smbd[1309]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:28:37 smbd[1316]: [2014/02/20 10:28:37, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:28:37 smbd[1316]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:28:37 smbd[1317]: [2014/02/20 10:28:37, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:28:37 smbd[1317]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:28:37 smbd[1318]: [2014/02/20 10:28:37, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:28:37 smbd[1318]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:29:07 smbd[1319]: [2014/02/20 10:29:07, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:29:07 smbd[1319]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:29:22 smbd[1322]: [2014/02/20 10:29:22, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:29:22 smbd[1322]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:29:22 smbd[1323]: [2014/02/20 10:29:22, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:29:22 smbd[1323]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.
Feb 20 10:29:44 smbd[1327]: [2014/02/20 10:29:44, 0] smbd/sesssetup.c:reply_sesssetup_and_X(1265)
Feb 20 10:29:44 smbd[1327]: reply_sesssetup_and_X: Rejecting attempt at SPNEGO session setup when it was not negoitiated.



I checked the issue on google and found two solutions and they are not working...

--> Add "security = USER" to smb.conf (already there by default)
--> Change to "yes" : client use spnego = no

It's still not working ... I'm connecting to the VPN with my Nexus 5 device and I use Astro File Manager to access smb share...

Also, credentials are working from a local PC using Windows 8.1.


Thanks for your input on this one!


EDIT: there's a weird line in smb.conf by default: --> "use spne go = no" is this generated by the firmware? this line is there after a reboot of the router...

2nd EDIT: removing the "use spne go = no" from smb.conf fix the issue .... Maybe thats a bug? Can RMerlin have a look at it?

From Merlin's quote
I won't be offering any kind of support for these builds, since they are alpha builds. If you are having any kind of issue with it, then you will have to revert back to 374.39

 

[Kris404]

Hi Merlin,

I am unable to flash this onto AC66U and each time I try the route reports a different old firmware (354.28). This has happened to me previously on the 374.38.

I can assure you that I have downloaded 374.40 and I do not have 354.28 in my download folder. I tried to flash 3 times with same result and have flashed 374.39 again with no problems.

Is the 354.28 some sort of inbuilt recovery firmware or do the routers perhaps revert back to original shipped firmware in the event of an error during the flash?

Try through a different browser as well.

 

[SpOuK3]

From Merlin's quote
I won't be offering any kind of support for these builds, since they are alpha builds. If you are having any kind of issue with it, then you will have to revert back to 374.39

Good point, I read that ... But i'm not sure it's related to this build... Let me rollback and try...

 

[HeadBanger]

HeadBanger,

did you try to remove all connections (Ethernet or USB) from the router except for the controlling computer?

Did you try resetting the router to defaults before you flashed the new version?

Do you clear the nvram at any stage?

Did you unzip the downloaded file and point the router to that directory?

Have you cleared your browser cache lately?

Just suggestions of what may help you flash it properly.

No to resets and clearing NVRAM and disconnecting all Ethernet except PC.
Unzipped file as normal and placed in folder.
I do not have the firmware it flashes on my PC anywhere - that's the weird thing. Also, v39 flashes just fine.

I will try some of your other suggestions though - many thanks.

 

[SpOuK3]

From Merlin's quote
I won't be offering any kind of support for these builds, since they are alpha builds. If you are having any kind of issue with it, then you will have to revert back to 374.39

Still present in .39 build ... I'll move my post in the build topic...

 

[bluepoint]

FYI Updating without resetting NVRAM from .39, the NTP server didn't update the clock. Going to Admin-->system, the NTP server I used was in place and then tried to sync the clock by clicking "apply", it didn't correct the time. Changing the NTP server to another server then apply did the trick. This is the first time in the long time the time didn't sync properly after a firmware upgrade.

RT-N66U

 

[nagle3092]

No issues here, moved over from the latest asus build. Using the DNS Filtering (works great) with PIA openvpn. No random reboots here. Thanks for the great work Merlin, looking forward to the final release.