Asuswrt-Merlin 3.0.0.4.374.32 is out

[Mick Mickle]

The other thing that you can try is to "forget" the old wifi networks, and then re-join them, giving your wifi password. This may also help.

Nope. Forgetting then rejoining on my phone didn't fix it. For example, I can open Google News once or twice, then close it. Try to open again and it stalls, eventually saying that the webpage is not available (even though Internet is fine with wired access). The last time, my phone got bounced off the wireless router connection onto 4G.

 

[RogerSC]

Nope. Forgetting then rejoining on my phone didn't fix it. For example, I can open Google News once or twice, then close it. Try to open again and it stalls, eventually saying that the webpage is not available (even though Internet is fine with wired access). The last time, my phone got bounced off the wireless router connection onto 4G.

Sorry that didn't help you, it has worked for me.

Have you tried the new Asus firmware, 374.720? Curious if that helps you, different wireless driver, might help.

 

[Mick Mickle]

Sorry that didn't help you, it has worked for me.

Have you tried the new Asus firmware, 374.720? Curious if that helps you, different wireless driver, might help.

A different wireless driver might help, but I understand that this 374.32 has the same driver that 270 has. I didn't have this problem of web pages not loading on Android devices with 270.26**. So I'm thinking the problem is caused by something other than the wireless driver.

Instructions for the Asus 374.720 look like another reset is necessary. Is that true? Upgrades are getting more demanding.

Edit: Actually, I recall correctly now that I did have the same problem with 270.26. That's when an Android disconnect problem started after I moved up from v. 266. Connections would jump between 2.4 & 5 GHz bands. That problem did seem to go away for the 374.31 version only.

 

[RogerSC]

A different wireless driver might help, but I understand that this 374.32 has the same driver that 270 has. I didn't have this problem of web pages not loading on Android devices with 270.26. So I'm thinking the problem is caused by something other than the wireless driver.

Instructions for the Asus 374.720 look like another reset is necessary. Is that true? Upgrades are getting more demanding.

Yes, when you change wireless drivers, a reset is necessary. But this new firmware is worth a try, it has a good chance of working for you, it is a major change. Not all firmware upgrades require a reset, but when things change enough, like changing wireless drivers and their associated defaults, then yes, resetting and manually re-entering your settings really is required.

RMerlin should be putting out his firmware based on this new Asus firmware, so if the Asus version works for you, you'll have his added functionality soon (I hope). Has to wait until Asus publishes the source, though.

 

[Mick Mickle]

Yes, when you change wireless drivers, a reset is necessary. But this new firmware is worth a try, it has a good chance of working for you, it is a major change. Not all firmware upgrades require a reset, but when things change enough, like changing wireless drivers and their associated defaults, then yes, resetting and manually re-entering your settings really is required.

RMerlin should be putting out his firmware based on this new Asus firmware, so if the Asus version works for you, you'll have his added functionality soon (I hope). Has to wait until Asus publishes the source, though.

Thanks for the encouraging tip. It worked to stabilize my Android connections with no loss of speed (actually faster). I posted results in the "RT-N66U firmware 3.0.0.4.374.720 released" thread.

(Now that I think about it, I've been having this web freezing issue on Android devices for awhile. But previously, I had both 2.4 and 5 GHz SSIDs remembered on the devices, so they were jumping to whichever connection would work in versions after 266. If I hadn't had the 5 GHz remembered, the Internet connection probably would have hung then, too.)

 

[RMerlin]

There's a lot of factory default reset involved in upgrades lately because of the numerous wireless driver changes.

FW 270-276 used driver 5.100
FW 3xx from Asus used 5.110
FW 374.257 from Asus used a newer 5.110
FW 374.720/724 from Asus uses 6.xxx

FW 270.26b uses 5.100
FW 354.xx uses 5.110
FW 374.xx uses 5.100
FW 374.32-SDK6 uses 6.xx

So when switching FW version with a wireless version change, you usually need a factory default reset to ensure that you are using the proper settings appropriate to the driver version you are using.

Thankfully, the switch to SDK6 on the N66U should greatly reduce the amount of factory default resets required, as things should stabilize now.

 

[shrike4242]

There's a lot of factory default reset involved in upgrades lately because of the numerous wireless driver changes.

So when switching FW version with a wireless version change, you usually need a factory default reset to ensure that you are using the proper settings appropriate to the driver version you are using.

Thankfully, the switch to SDK6 on the N66U should greatly reduce the amount of factory default resets required, as things should stabilize now.

So, since I just made the change from .270.26b to .374.32, with the factory reset before the FW upgrade, I shouldn't have to make another factory reset before going to any other version as long as we don't jump major version numbers?

Since you're now using the SDK6 wireless driver in .374.32 (.xxx.34, perhaps), would we likely be done with future factory resets before FW upgrades for a while?

 

[RMerlin]

So, since I just made the change from .270.26b to .374.32, with the factory reset before the FW upgrade, I shouldn't have to make another factory reset before going to any other version as long as we don't jump major version numbers?

Since you're now using the SDK6 wireless driver in .374.32 (.xxx.34, perhaps), would we likely be done with future factory resets before FW upgrades for a while?

Hard to tell for sure because it will depend on Asus, but the situation should certainly be more stable.

 

[jlake]

So, since I just made the change from .270.26b to .374.32, with the factory reset before the FW upgrade, I shouldn't have to make another factory reset before going to any other version as long as we don't jump major version numbers?

Since you're now using the SDK6 wireless driver in .374.32 (.xxx.34, perhaps), would we likely be done with future factory resets before FW upgrades for a while?

I think you'll find it more beneficial to do a factory reset "after" a firmware update.

Possibly I misread your post, but resetting "before" you do the update won't help you much.

 

[Mick Mickle]

There's a lot of factory default reset involved in upgrades lately because of the numerous wireless driver changes.

FW 270-276 used driver 5.100
FW 3xx from Asus used 5.110
FW 374.257 from Asus used a newer 5.110
FW 374.720/724 from Asus uses 6.xxx

FW 270.26b uses 5.100
FW 354.xx uses 5.110
FW 374.xx uses 5.100
FW 374.32-SDK6 uses 6.xx

Thanks - very helpful details. I think I'll give your 374.32-SDK6 a whirl since the latest Asus firmware is working for me (although the experiences of others on that thread are sure mixed).

I've seen some commands referenced in the past to export and import settings into NVRAM. I wonder if there's a safe way to use that method to transfer some basic settings (SSIDs, port forwards, static IP addresses, etc.) between versions.

 

[RMerlin]

Thanks - very helpful details. I think I'll give your 374.32-SDK6 a whirl since the latest Asus firmware is working for me (although the experiences of others on that thread are sure mixed).

I've seen some commands referenced in the past to export and import settings into NVRAM. I wonder if there's a safe way to use that method to transfer some basic settings (SSIDs, port forwards, static IP addresses, etc.) between versions.

Those settings should be safe to transfer using the same method. Be more careful about settings related to wireless however. For instance, SDK6 uses a different nvram setting to store channel and channel width.

 

[jsmiddleton4]

Around the DHCP list?

Using this firmware now. Saw the evaluation that its probably the most stable so want to try it.

This wording was in the other firmwares as well and now that I'm looking at it I'm not sure exactly what it means.

"Manually Assigned IP around the DHCP list (Max Limit : 128)"

Does that mean to assign IP addresses outside the DHCP pool? I select IP addresses around the DHCP IP address pool?

Does that mean to assign IP addresses at various IP addresses within the DHCP pool?

I want to have static IP's but let DHCP assign them. What do I select for "Enable Manual Assignment"?

I'm not manually assigning them, I'm reserving them.

Going to search some more but didn't find any answer yet.

 

[RMerlin]

Using this firmware now. Saw the evaluation that its probably the most stable so want to try it.

This wording was in the other firmwares as well and now that I'm looking at it I'm not sure exactly what it means.

"Manually Assigned IP around the DHCP list (Max Limit : 128)"

Does that mean to assign IP addresses outside the DHCP pool? I select IP addresses around the DHCP IP address pool?

Does that mean to assign IP addresses at various IP addresses within the DHCP pool?

I want to have static IP's but let DHCP assign them. What do I select for "Enable Manual Assignment"?

I'm not manually assigning them, I'm reserving them.

Going to search some more but didn't find any answer yet.

Manually assigning is the same as reserving. You enter the MAC address and the IP you wish to dedicate to that MAC. Whenever a DHCP request comes in from that MAC address, it will get assigned the IP you entered there.

This is the exact same functionality as in the original firmware, except I increased the number of allowed reservations.

 

[jsmiddleton4]

Thanks. I noted the verbiage is the same across the firmwares. Also found a couple of threads lamenting that same wording as being a bit confusing.

I take it IF you want, and I can imagine reasons why I'd want to, I could manually assign IP's outside a defined range of DHCP automatically assigned IP's?

Limit the available IP range via DHCP server setting and then assign IP's not in that set of available IP's.

Have a handful of available IP's the router gives out and then I manage the known and regular client IP's by manually assigning them.

If I don't check "Manually Assign" does that limit the router to the IP's I say are available in DHCP server setting?

I know, pesky questions.....

 

[RMerlin]

Thanks. I noted the verbiage is the same across the firmwares. Also found a couple of threads lamenting that same wording as being a bit confusing.

Unfortunately, the English translation of the webui is a bit rough in quite a few places. I really think Asus should hire a native speaker to do the English strings rather than rely on a Chinese speaker who happens to know English. That would save us from translations such as "You have logined out".

I take it IF you want, and I can imagine reasons why I'd want to, I could manually assign IP's outside a defined range of DHCP automatically assigned IP's?

If I don't check "Manually Assign" does that limit the router to the IP's I say are available in DHCP server setting?

I know, pesky questions.....

If you don't enable; Manually assign, then the router will most likely ignore any entry you put below. I never actually checked if that's how the code worked, but I suspect that's the case.

 

[jsmiddleton4]

So the manually assign and the list don't "look" to see if the assigned IP's in the manually assigned table are in the DHCP configured pool one way or the other?

I guess it would not really need to. End up at same place either way. Why put in code that might cause issues when you end up at same place?

Sorta makes sense.

I can try it and see. I'll limit the DHCP available pool and see what happens to the assigned IP's.

 

[RMerlin]

I can try it and see. I'll limit the DHCP available pool and see what happens to the assigned IP's.

Just compare the generated dnsmasq.conf file with different settings. After that, see what the dnsmasq documentation states. All DHCPD functionality should be handled by dnsmasq.

 

[jsmiddleton4]

IP addresses assigned as expected based on DHCP pool and manually assigned.

If I have DHCP pool range set outside the range of the manually assigned IP's, any DHCP assigned addresses get one from the narrow pool.

The other clients with manually assigned IP's, get the manually assigned ones despite not being in the DHCP pool range.

Not earth shaking but is a small way to manage available DHCP addresses vs. managing regular known consistent client IP's.

"Guests" only have few IP's available from the DHCP assigned pool.

 

[PrivateJoker]

Unfortunately, the English translation of the webui is a bit rough in quite a few places. I really think Asus should hire a native speaker to do the English strings rather than rely on a Chinese speaker who happens to know English. That would save us from translations such as "You have logined out".

You got that right...UI, documentation, and marketing materials would be significantly more useful than their current setup by using translation and/or proof reading by a native speaker.

Not earth shaking but is a small way to manage available DHCP addresses vs. managing regular known consistent client IP's.

"Guests" only have few IP's available from the DHCP assigned pool.

@jsmiddleton4 FWIW, I assign all the MACs I want to in groups between IPs of 192.168.1.2:200. Then for any guest/random additions, they will be auto assigned from 192.168.1.201:254.

It just makes if easier for me to label, segregate, monitor, and troubleshoot my devices. But lots of people have their own methods that work fine for them.

I've never had a situation where two days in a row 14 new devices needed automatically assigned IP addresses, so my method is ok for me. But you could also change your 86400 value (eg seconds, =24 hrs) for lease time under LAN DHCP setup to 28800 (eg 8 hrs) to help expedite it in certain situations where a quicker lease would be valuable I suppose(?).

 

[verbovet]

RMerlin,

I use rt-ac56u with the Russian ISP Beeline-Moscow, which uses l2tp with dual access.
Versions 3.0.0.4.374.32 and 3.0.0.4.372.31_2 don't work, log reads:
Unable to connect PPPoL2TP socket

Version 3.0.0.4.372.30_2 and current stock version 3.0.0.4.374.37 work perfectly.

I'll try to reproduce a similar test setup next week to see if I can reproduce the problem on an RT-AC56U (last time I tested it was on an RT-N66U).

I tried 3.0.0.4_374.33_beta1. Unfortunately, with the same negative result.