[Release 382] Asuswrt-Merlin 382.1 is now available

[bluepoint]

How can I get 1000MB monitor on QoS? I only have the 100MB mark and my ISP is 400 / 200

It's a dynamic value. Mine shows 100M also at start when there is not much activity but when QOS senses a great amount of bandwidth more than 100M it changes to 1000M.

 

[Keenan]

Running 382.1.2 and I'm seeing what seems to be some odd behavior.

First I'm getting random wireless disconnects on devices such as WeMo smart plugs/switches and on a Lutron Caseta light controller. On my N66 this never happened, once in a great while maybe. The 2 to 3 days I've been running the current FW it's been happening a couple times per day. I should add that I'm running a Harmony Hub as well as two Amazon Echo Dots in the system. The Dots are used to control the WeMo and Lutron Caseta light controllers via voice commands(Alexa). When a lack of connection happens(a light will not turn off or on when I tell it to) I'll run the Alexa app device discovery procedure to 're-discover' devices that were already discovered before, and then it will usually work.

Also, when viewing the Client Status list it will display the names of the devices(TiVo, WeMo, Roku, etc), some that I've created and others just appear automatically, along with those devices where it won't take a manually created name which defaults to the MAC address. What I'm seeing is that sometimes an actual device name will display and other times it will be just a MAC address. This also is not something I observed with the N66. I know there's an issue with lack of character space to apply names to more than a handful of devices but the random naming and un-naming of devices seems like rather odd behavior.

I hope I'm being clear, I guess one way to put it is that I'm seeing random changes to the system that result in device names or lack of names and random disconnections with smart home devices(though it may not be limited to that class of device, I haven't noticed the disconnects on my iPhone for example). The iPhone is connecting at 5G along with just one of the Echo Dots(the other one is not even showing right now, exactly the behavior I'm talking about. And now, by using the Dot, it's back in the list. The WeMo switches are 2.4G and the Lutron controller is wired.

I'm well aware this is beta FW and issues are part of the game, I'm posting the above to further the project. I'm not complaining, just contributing.

Thanks,
Jim

Also, I can't say for sure it's even the FW as I did not run the router with the factory FW for more than a day before loading Merlin's goodness! Not very scientific behavior I know, but those are the facts!

 

[RMerlin]

For wifi, disable Airtime Fairness, MU-MIMO and implicit Beamforming.

For device naming, I no longer have control over these as networkmap is now closed source. I can no longer tie devices to DHCP leases like I used to do before.

 

[Keenan]

For wifi, disable Airtime Fairness, MU-MIMO and implicit Beamforming.

For device naming, I no longer have control over these as networkmap is now closed source. I can no longer tie devices to DHCP leases like I used to do before.

Okay, disabled those and I'll see how it goes, thanks.

And I know about the network map issue, I just thought it was strange that some would have actual names one day and then change back to a MAC address the next day, it's as if the router is changing what devices it give actual names to randomly. Could it be the order in which they are detected? Just guessing here...

Also, is 357MB of 512MB a normal amount of RAM usage? (RT-AC86U)

 

[armsAC3100]

I installed 382.1_2 as upgrade to 380.68_4
I did power on reset to AC3100 after update. I did not reset to factory default.
Two immediate problems.
1. 2.4Ghz network in/out. I did not take time to analyze - Wife was getting impatient! I was on 5Ghz without problem.
2. Unable to turn off VPN client - Router screen just cycled spinning dots. I re-booted router again and same issue. I was unable to change the VPN client until I went back to 380.68_4 (which has been very stable once I turned of MU-MIMO to "fix" 5Ghz stopping)
3. Screen issues when attempting to use Chrome. Unable to select 2.4 or 5 ghz wireless client when looking at network status. Microsoft Edge (Windows 10) was fine.

I'll try again when I have the house to my self!

Al

 

[scjr]

I installed 382.1_2 as upgrade to 380.68_4
I did power on reset to AC3100 after update. I did not reset to factory default.

I think you’ll need to do a reset to factory default moving from 380, to 382.

Merlin recommended to me in another thread to do this moving from 382 to 380. I would think it would be the same the other way around, but I’m just learning so the more experienced will chime in.

Hope you get everything squared away.

 

[skeal]

I installed 382.1_2 as upgrade to 380.68_4
I did power on reset to AC3100 after update. I did not reset to factory default.
Two immediate problems.
1. 2.4Ghz network in/out. I did not take time to analyze - Wife was getting impatient! I was on 5Ghz without problem.
2. Unable to turn off VPN client - Router screen just cycled spinning dots. I re-booted router again and same issue. I was unable to change the VPN client until I went back to 380.68_4 (which has been very stable once I turned of MU-MIMO to "fix" 5Ghz stopping)
3. Screen issues when attempting to use Chrome. Unable to select 2.4 or 5 ghz wireless client when looking at network status. Microsoft Edge (Windows 10) was fine.

I'll try again when I have the house to my self!

Al

A factory reset would probably most likely fix your problems. Its a recommend if you have any weirdness.

 

[Eric Lieb]

Am I going crazy? I can't find the AIMesh option anywhere in the menu under 192.168.1.1 ...

 

[JDB]

Am I going crazy? I can't find the AIMesh option anywhere in the menu under 192.168.1.1 ...

Are yo running the special Asus AiMesh firmware?

It is not included in Asus general release or Merlin yet.


Sent from my iPhone using Tapatalk

 

[Eric Lieb]

Are yo running the special Asus AiMesh firmware?

It is not included in Asus general release or Merlin yet.


Sent from my iPhone using Tapatalk

Well that makes a lot more sense now... I just flashed a TM-1900 to AC68 and installed 382 but not hte special one i guess. I cant flash the beta aimesh on my primary router because I need OpenVPN and Merlin hasn't released a AC68 version yet.

 

[doczenith1]

Also, is 357MB of 512MB a normal amount of RAM usage? (RT-AC86U)

I'm at 361 MB 71% with a minimal config and 1 vpn client entry. It started at 69% 3 days ago on the day that I installed the router. It's my understanding that Linux will use ram if it available and free it up if needed so I'm not all that worried.

 

[Keenan]

I'm at 361 MB 71% with a minimal config and 1 vpn client entry. It started at 69% 3 days ago on the day that I installed the router. It's my understanding that Linux will use ram if it available and free it up if needed so I'm not all that worried.

Yes, I just wanted to be sure it wasn't something out of the ordinary. Thanks.

 

[E Karlson]

If you have RA turned on, router is announsing itself as default router for clients, so pretty logical it provides itself as default DNS server.
Another reason is DHCP reservation list, DNS filter, possible guessing IPv6 client hostnames from SLAAC their addresses.
I'd treat no pissibility to set DNSS/DNSSL via WEB UI as a current limitation/underfunctionality, not as a bug. On Merlin FW you can add following to dnsmasq.conf

dhcp-option=option6:dns-server,[NS1],[NS2],[NS3]

, where NSes are static IPv6 addresses of the own DNS severs.
Regarding stale DNS records, isn't it what DNS TTL is all about? You can force any TTL for DNS records with dnsmasq as well.
Regarding DNS failures under heavy load - this can only be overriden with own full-blown DNS server that doesn't use router's DNS at all.
If it doesn't suit you, you can always turn RA off in WEB UI (and loose default route via it).


Same, add following into dnsmasq.conf

dhcp-option=option6:domain-search,"domain.tld"

Stateless is DHCPv6, what do you likely mean is pure SLAAC, which is unlikely good idea in wild, becasue lots of clients doesn't support DNSS option and therfore can't get IPv6 DNS server at all.


Right, seems the only change is additional control over dns servers and domain with enabled RA announcements.


This changes better be intoruced as public, why private?

In terms of the router announcing itself as the LAN's DNS server that does not always make sense in my book. The reason is that the router has no knowledge of LAN-local domains and therefore cannot resolve queries (this is, in fact, what brought this issue to my attention in the first place). One needs to be able to advertise the DNS server that knows about any local domains, etc present on one's LAN.

In terms of having a full-blown DNS server - that is exactly my point. When one has a full-blown DNS server (because one needed something like split-zone resolution) on one's LAN (and an associated DHCP server that performs DDNS back into the full-blown DNS server) one needs to be able to configure one's IPv6 router accordingly.

In terms of making manual changes to the dnsmasq.conf file, that is exactly what I did to work around some of these issues. The problem is that this solution only works with the Merlin firmware (as the ASUS firmware has no logic for preserving custom changes to config files). It also has the problem that it puts the system into a strange state where subsequent changes made in the UI are silently ignored. In fact, the entire thrust of the changes I am looking at making are to expose these options in the UI so that it will create an appropriate dnsmasq.conf file itself.

Regarding stateless config, we can argue the nuances of RFC 4862, but really the point here is irrespective of whether one wants to use DHCP with the stateless config protocol one needs to be able to control *where* the DHCP server runs. Running it on the router is not always the right choice. Sadly, I'm not sure that I can fix this as things stand today as the options that turn on the "O" bit in the RA generated by dnsmasq also turn on the DHCPv6 service within dnsmasq. But that is a battle for another day to take up with dnsmasq.

Really my whole point here is that in the IPv6 world the configuration mechanisms and parameters of one's IPv6 LAN is driven by the RA's that are sent out by the router(s). Therefore one needs to have as many knobs, bells and whistles exposed as possible in order to accommodate the specifics of one's networking situation. You want stateless config and you have devices that don't recognize the RDNSS parameter - no problem, turn on the "O" bit and setup a DHCPv6 server somewhere to deliver that information. You have a split-zone DNS server supporting a local domain - no problem, advertise the DNS server in the RA instead of the router.

In any event, I will go ahead and make the appropriate changes and then make the patch available to you for your consideration. The changes for constructing the dnsmasq.conf file are fairly straightforward. I just have to dig through all the WebUI files to figure out how to expose the options in the UI.

 

[JDB]

I tend to agree that a few more local options for IPv6 would be useful. I’ve been having to manually change the underlying config/odhcp6 cmd as well.
So long as the default options do as it does now I don’t see the risk of breaking anything.


Sent from my iPhone using Tapatalk

 

[hotsauce2007]

It's a dynamic value. Mine shows 100M also at start when there is not much activity but when QOS senses a great amount of bandwidth more than 100M it changes to 1000M.
View attachment 11152

Right here isant working, I did a test using a new device with no browser data and the valeu looks the same, I did a full speed test also and the value remains, any more idea?

 

[eric777]

Parental config does not work for me I had to return to 380 branch

 

[Rhialto]

I keep an eye on this thread from time to time meanwhile 1900P get supported and one thing I would like to be clear for proper decision as to upgrade or not is what features will be lost with this newer version vs previous 380.x. I see a post here and there saying this thing is now closed source, have no control, this feature is gone, etc. I don't want to go all 22 pages to collect the info but surely RMerlin can quickly write down all of it.

This could help avoid some frustrations later.

 

[Fitz Mutch]

This is my fault because I'm compiling directly from Github with some Asus' features turned off.

I compile 382.2-alpha2 for my RT-AC68U with BWDPI=n. I had to create a stub for the function dump_dpi_support() in httpd, just to get it to compile, like this:

// HACK: fix prebuilt web_hook.o
#if !defined(RTCONFIG_BWDPI)
int dump_dpi_support(int index)
{
    int retval = 0;
    logmessage("httpd", "dump_dpi_support(%d) called from $(TOP)/httpd/prebuild/web_hook.o, returning %d", index, retval);
    return retval;
}
#endif

Now I get these frequent log messages. Apparently my return value of zero does not satisfy the DPI check?

Dec  9 09:33:30 httpd: dump_dpi_support(1) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:30 httpd: dump_dpi_support(2) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:30 httpd: dump_dpi_support(3) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:30 httpd: dump_dpi_support(4) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:30 httpd: dump_dpi_support(5) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:30 httpd: dump_dpi_support(6) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:30 httpd: dump_dpi_support(7) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:30 httpd: dump_dpi_support(8) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:30 httpd: dump_dpi_support(9) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:37 httpd: dump_dpi_support(1) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:37 httpd: dump_dpi_support(2) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:37 httpd: dump_dpi_support(3) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:37 httpd: dump_dpi_support(4) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:37 httpd: dump_dpi_support(5) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:37 httpd: dump_dpi_support(6) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:37 httpd: dump_dpi_support(7) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:37 httpd: dump_dpi_support(8) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:37 httpd: dump_dpi_support(9) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:49 httpd: dump_dpi_support(1) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:49 httpd: dump_dpi_support(2) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:49 httpd: dump_dpi_support(3) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:49 httpd: dump_dpi_support(4) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:49 httpd: dump_dpi_support(5) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:49 httpd: dump_dpi_support(6) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:49 httpd: dump_dpi_support(7) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:49 httpd: dump_dpi_support(8) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:49 httpd: dump_dpi_support(9) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:53 httpd: dump_dpi_support(1) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:53 httpd: dump_dpi_support(2) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:53 httpd: dump_dpi_support(3) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:53 httpd: dump_dpi_support(4) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:53 httpd: dump_dpi_support(5) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:53 httpd: dump_dpi_support(6) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:53 httpd: dump_dpi_support(7) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:53 httpd: dump_dpi_support(8) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:53 httpd: dump_dpi_support(9) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:56 httpd: dump_dpi_support(1) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:56 httpd: dump_dpi_support(2) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:56 httpd: dump_dpi_support(3) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:56 httpd: dump_dpi_support(4) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:56 httpd: dump_dpi_support(5) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:56 httpd: dump_dpi_support(6) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:56 httpd: dump_dpi_support(7) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:56 httpd: dump_dpi_support(8) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:33:56 httpd: dump_dpi_support(9) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:04 httpd: dump_dpi_support(1) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:04 httpd: dump_dpi_support(2) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:04 httpd: dump_dpi_support(3) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:04 httpd: dump_dpi_support(4) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:04 httpd: dump_dpi_support(5) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:04 httpd: dump_dpi_support(6) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:04 httpd: dump_dpi_support(7) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:04 httpd: dump_dpi_support(8) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:04 httpd: dump_dpi_support(9) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:07 httpd: dump_dpi_support(1) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:07 httpd: dump_dpi_support(2) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:07 httpd: dump_dpi_support(3) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:07 httpd: dump_dpi_support(4) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:07 httpd: dump_dpi_support(5) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:07 httpd: dump_dpi_support(6) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:07 httpd: dump_dpi_support(7) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:07 httpd: dump_dpi_support(8) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:07 httpd: dump_dpi_support(9) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:09 httpd: dump_dpi_support(1) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:09 httpd: dump_dpi_support(2) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:09 httpd: dump_dpi_support(3) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:09 httpd: dump_dpi_support(4) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:09 httpd: dump_dpi_support(5) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:09 httpd: dump_dpi_support(6) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:09 httpd: dump_dpi_support(7) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:09 httpd: dump_dpi_support(8) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:09 httpd: dump_dpi_support(9) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:12 httpd: dump_dpi_support(1) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:12 httpd: dump_dpi_support(2) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:12 httpd: dump_dpi_support(3) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:12 httpd: dump_dpi_support(4) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:12 httpd: dump_dpi_support(5) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:12 httpd: dump_dpi_support(6) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:12 httpd: dump_dpi_support(7) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:12 httpd: dump_dpi_support(8) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0
Dec  9 09:34:12 httpd: dump_dpi_support(9) called from $(TOP)/httpd/prebuild/web_hook.o, returning 0

The function dump_dpi_support() is defined in libbwdpi.so. When this library is removed from the build with BWDPI=n, the linker cries.
$(TOP)/bwdpi_source/asus/prebuild_arm/libbwdpi.so

 

[bluepoint]

Right here isant working, I did a test using a new device with no browser data and the valeu looks the same, I did a full speed test also and the value remains, any more idea?

Do you have QOS enabled? When was the last time you cleared the NVRAM(reset)? That's probably what you need, reset to factory defaults.

 

[hotsauce2007]

Do you have QOS enabled? When was the last time you cleared the NVRAM(reset)? That's probably what you need, reset to factory defaults.

Yes, I have it on.
The last time that I did a full reset with Nvram was two weeks, maybe one week because I am using the AIMESH solution right now on the second ac68u