What's new

Asuswrt-Merlin 376.49 is out

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

It is also not the era of perfect software yet. Nor is there any important reason to have spaces in the SSIDs (visible names) of a wireless network. And there are dozens of places in the software stacks of dozens of networking modules, where having spaces in SSIDs makes your system unnecessarily vulnerable to problems caused by imperfect programming.

Consider how similar two identifiers appear when presented on a typical computer screen, when one is spelled "logon user name" and the other is spelled "logon user name" (second identifier here having more spaces in it). Those are "high risk identifiers".

Also Charlie2alpha, did you notice RMerlin ADVISING someone to remove spaces in identifiers, in this very thread? see http://forums.smallnetbuilder.com/showthread.php?t=21483&page=15

Nobody is recommending you avoid spaces in SSIDs "just to hassle you".

I love your post because I can learn so much from it, and the most important thing is... you keep your composure and are very kind and polite when responding. I know one of my posts in the past was nothing but annoying n00b question, but I am simply trying to learn as much as possible without having anyone around me to help me. Well, good thing is there are people like yourself, who are always ready to unselfishly assist other people when they are in need of help. Thank you for that!

PS. Oh, yes... I erased most of my annoying posts in another thread, that weren't actually tightly related to the subject of the thread. Well, kind of, since previous firmware release did not give me those problems, and new one was... but I easily made the whole thing drift in completely different direction. Again, I was in panic and didn't know where or whom to ask.

Anyway, nothing changes my opinion about you and many other good guys in this forum. Always ready to help, and while I know it's not much when it's only coming from nobody like I am, I want you to know that I appreciate your generous help you all provide in here. Thank you!
 
Anyone else having problems with the 2,4GHz radio dying on RT-N66U? Suddenly my 2,4GHz SSID disappears and I have to disable the radio and enable it again for it to appear.

I had same problem when I updated latest official ASUS fw (3.0.0.4.376.3657) but at 5GHz, resetting didn't help, but deleting that network from pc's known networks list and make new fixed that.
 
Just got home today from my pre-Christmas vacation and saw there was a new update.. I decided to take the chance even though Merlin moved the version to beta due to a boot loop. After the update everything looked ok until my DHCP hosts started to renew. The system log kept stating:

no leases left​

Well I took the plunge and deleted all the static leases and tested and the DHCP clients were correctly getting addresses from the pool. Then I stared to re-add the statistic leases and everything seems to reverted back to normal.

Very strange but just wanted to see if anyone else had DHCP issues when they did the update? So far everything seems to working fine after the DHCP issue. I will be testing out QOS later next week after this smokes in.

I am seeing the exact same behavior. I have about 20 static mac+ip in my DHCP-table and after some time I also got "no leases left". This on devices working for weeks with previous version (ie 376.48_3 (20-Nov-2014)).

A reboot solved the problem for half a day, but I got the problem back now around midnight.

Code:
Dec 27 00:13:32 gw dnsmasq-dhcp[551]: DHCPDISCOVER(br0) 192.168.1.21 00:04:20:17:3e:da
Dec 27 00:13:32 gw dnsmasq-dhcp[551]: DHCPOFFER(br0) 192.168.1.21 00:04:20:17:3e:da
Dec 27 00:13:33 gw dnsmasq-dhcp[551]: DHCPREQUEST(br0) 192.168.1.21 00:04:20:17:3e:da
Dec 27 00:13:33 gw dnsmasq-dhcp[551]: DHCPNAK(br0) 192.168.1.21 00:04:20:17:3e:da no leases left
Dec 27 00:13:34 gw dnsmasq-dhcp[551]: DHCPDISCOVER(br0) 192.168.1.21 00:04:20:17:3e:da
Dec 27 00:13:34 gw dnsmasq-dhcp[551]: DHCPOFFER(br0) 192.168.1.21 00:04:20:17:3e:da
Dec 27 00:13:35 gw dnsmasq-dhcp[551]: DHCPREQUEST(br0) 192.168.1.21 00:04:20:17:3e:da
Dec 27 00:13:35 gw dnsmasq-dhcp[551]: DHCPNAK(br0) 192.168.1.21 00:04:20:17:3e:da no leases left

This ethernet adress is in my static DHCP table.

I first noticed this erlier today when my Playstation got this behaviour and the DHCP req + nac got the CPU in my AC66U to do 100% until i disconnected the PS4.

Any clues? I do not want go back to the previous version just yet, because I rather help solving the problem (if my family do not complain to much).

Added note: I removed the ps4 from the static DHCP table and saw the same behavior from DHCP pool. A reboot of the router solved it temporarily.
 
Last edited:
I am seeing the exact same behavior. I have about 20 static mac+ip in my DHCP-table and after some time I also got "no leases left". This on devices working for weeks with previous version (ie 376.48_3 (20-Nov-2014)).

I am answering myself. I have made a discovery and possible found the issue...

I have about 25 static mac+ip in my DHCP table. I prefer to assign ip with DHCP, but keep a static table to have the devices always have the same ip over time.

Additionally to the 25 static ip numbers I have a pool of 10 ip for "temporary" devices (ie 192.168.1.90 - ...1.99).

I noticed that the number of ip in this pool was controlling this option:
Code:
file: /etc/dnsmasq.conf
...
dhcp-lease-max=10
...

I have the impression that this limits the number of DHCP leases to 10, and this is far less than my 25 static leases + the pool of 10 "dynamic" ip...

I expanded my pool to ...1.90 - ...1.129 and the value (dhcp-lease-max) increased to 40
After this change, the failing devices (with the "no leases left") got their ip number and started to work as expected!!!

Could this be the problem we have seen and is it supposed to work like this
I think I have just made a work-around and the real issue is how the dhcp-lease-max is assigned...

Comments?
 
First of all, thanks Merlin for all the hard work and the excellent firmware result of it.

Just upgraded from 48_3, did a Factory Reset and when configuring everything again I noticed that "Advertise DNS to clients" option is missing from OpenVPN Server settings.
Is this a bug (i think so) or was removed for some reason?

I was able to enable it manually in case anyone has the same problem by executing the following command:

Code:
nvram set vpn_server1_pdns="1"

Holy smokes, THANK YOU. I just came to this thread to try and figure out why the push "dhcp-option DNS x.x.x.x" option wasn't working right.

I added a second OpenVPN server (first on UDP, second on TCP), and I noticed the configs were different. It's because the DNS push option was missing from the GUI. Running that command worked for me. Thanks!

Code:
nvram set vpn_server1_pdns="1"
nvram set vpn_server2_pdns="1"

Same with "Compression" settings - there are "Disable" and "None". Any difference between them?

This is kind of a weird thing (that I'm guessing the OpenVPN people may change eventually), as one setting is possibly better than the other.

Compression = None sets "comp-lzo no" - specifically sets and disables compression. If this is how it is on the client, the server can push a different compression setting ("yes" or "adaptive").

Compression = Disable doesn't set "comp-lzo" at all. If this isn't set, compression is off plus the server cannot push a different setting.

Basically, if you don't want compression, you'd probably want "None", it disables it but allows you to re-enable it if needed without having to give the client a new ovpn file (just change and "push" it from the server).
If you set it to Disable, you'd have to give the client a new ovpn file to change it later.

In my speed tests, downloads were faster with compression disabled, so I keep it disabled with the None setting.
 
Hi Merlin,

All it is is the name disappears and just shows the mac address twice.

Perhaps if I were to factory reset and re enter the whole lot that may cure it, but it doesn't bother me if I dont look at it !
I'm sorry there is not much detail to add.

When I add a new name to filter either the whole list disappears and just shows mac ads where name should be. or some work and some dont.

Thanks
Reply With Quote

Having the same issue as above along with client status affected. Otherwise all is good. Thanks!Merlin:)
RT-AC66U & RT-N66U
 
Last edited:
Log Entry

Sorry if this has been covered somewhere else. Does anyone recognize what these log entries are:

Dec 27 06:50:14 dnsmasq-dhcp[1683]: DHCPADVERTISE(br0) 00:01:00:01:1c:2f:9b:84:4c:0b:be:17:67:c6 no addresses available\
Dec 27 06:50:15 dnsmasq-dhcp[1683]: DHCPADVERTISE(br0) 00:01:00:01:1c:2f:9b:84:4c:0b:be:17:67:c6 no addresses available\
Dec 27 07:32:44 dnsmasq-dhcp[1683]: DHCPADVERTISE(br0) 00:01:00:01:1c:2f:9b:84:4c:0b:be:17:67:c6 no addresses available\
Dec 27 07:32:44 dnsmasq-dhcp[1683]: DHCPADVERTISE(br0) 00:01:00:01:1c:2f:9b:84:4c:0b:be:17:67:c6 no addresses available\
Dec 27 07:32:46 dnsmasq-dhcp[1683]: DHCPADVERTISE(br0) 00:01:00:01:1c:2f:9b:84:4c:0b:be:17:67:c6 no addresses available\
}
 
I know NTP code was in flux recently, but were there any changes between .48 and .49? With .49 my AC66U is unable to set the system time via ntp. I have even changed my ntp server to an IP address.
 
Anyone with any idea why my AC68P will only get an IPv6 address if I clone a MAC address from another device to the router? When I do a MAC clone, v6 works fine. Otherwise, the built in MAC address of the router won't get a v6 address, no matter what combination of reboots and cable disconnects.

I updated from 376.48_1 and did a full reset, and manually loaded all settings. I've got Comcast and have native dual stack v6 with DHCP-PD enabled.

EDIT: If I connect a laptop directly to the cable modem/gateway, I get a v6 address just fine.
 
Last edited:
I know NTP code was in flux recently, but were there any changes between .48 and .49? With .49 my AC66U is unable to set the system time via ntp. I have even changed my ntp server to an IP address.

No, I still kept the older NTP code since people reported issues with Asus's 376_36xx NTP code.
 
I am answering myself. I have made a discovery and possible found the issue...

I have about 25 static mac+ip in my DHCP table. I prefer to assign ip with DHCP, but keep a static table to have the devices always have the same ip over time.

Additionally to the 25 static ip numbers I have a pool of 10 ip for "temporary" devices (ie 192.168.1.90 - ...1.99).

I noticed that the number of ip in this pool was controlling this option:
Code:
file: /etc/dnsmasq.conf
...
dhcp-lease-max=10
...

I have the impression that this limits the number of DHCP leases to 10, and this is far less than my 25 static leases + the pool of 10 "dynamic" ip...

I expanded my pool to ...1.90 - ...1.129 and the value (dhcp-lease-max) increased to 40
After this change, the failing devices (with the "no leases left") got their ip number and started to work as expected!!!

Could this be the problem we have seen and is it supposed to work like this
I think I have just made a work-around and the real issue is how the dhcp-lease-max is assigned...

Comments?

The range for the pool can effect the number of available IP's if your statics are assigned in the same range as the dynamics. What I have done was put the dynamic into 192.168.x.20-192.168.x.49. This gave a pool of 20 for adding new hosts to the network until I can assign a static. My statics are grouped as follows:

192.168.x.50-59 - Friends/Guests that I have over regular
192.168.x.60-79 - PC's and Tablets
192.168.x.80-99 - Cell Phones
192.168.x.100-119 - Entertainment Devices (Roku's Xboxes)
192.168.x.120-139 - VoIP and Network appliances
192.168.x.200-254 - Access Point and other misc network devices
 
Last edited:
Sorry if this has been covered somewhere else. Does anyone recognize what these log entries are:

Dec 27 06:50:14 dnsmasq-dhcp[1683]: DHCPADVERTISE(br0) 00:01:00:01:1c:2f:9b:84:4c:0b:be:17:67:c6 no addresses available\
Dec 27 06:50:15 dnsmasq-dhcp[1683]: DHCPADVERTISE(br0) 00:01:00:01:1c:2f:9b:84:4c:0b:be:17:67:c6 no addresses available\
Dec 27 07:32:44 dnsmasq-dhcp[1683]: DHCPADVERTISE(br0) 00:01:00:01:1c:2f:9b:84:4c:0b:be:17:67:c6 no addresses available\
Dec 27 07:32:44 dnsmasq-dhcp[1683]: DHCPADVERTISE(br0) 00:01:00:01:1c:2f:9b:84:4c:0b:be:17:67:c6 no addresses available\
Dec 27 07:32:46 dnsmasq-dhcp[1683]: DHCPADVERTISE(br0) 00:01:00:01:1c:2f:9b:84:4c:0b:be:17:67:c6 no addresses available\
}

Yes what this is stating is that your DHCP pool doesn't have any more addresses available to lend or that you used a static address for multiple devices and their first device grabbed the IP address. Can you describe how you setup your DHCP configuration in your router?
 
376.49_4 has been uploaded to Mediafire.

Code:
FIXED: WAN page error when entering a hostname, and broken UPNP FAQ link

FIXED: OpenVPN Server wasn't showing the Advertize DNS to Client option (regression from 3677 merge)

FIXED: bootloop when enabling Traditional QoS (or any other feature that forces CTF to be disabled) due to FA being left enabled (Asus bug) (AC87)
 
No, I still kept the older NTP code since people reported issues with Asus's 376_36xx NTP code.

I see. Oh well. I am unable to get time to sync up anymore which means I can't use dnscrypt anymore. Will work around and see if fixed in a future release. Thanks.
 
The range for the pool can effect the number of available IP's if your statics are assigned in the same range as the dynamics.

My static and dynamic range is not in the same range. They are strictly separated. But the dynamic range (in my case 10 ip numbers) is determining the value dhcp-lease-max=10 in /etc/dnsmasq.conf .

And this value blocked devices from getting ip numbers, dynamic and static. When I made the dynamic range bigger, my devices got their static ip numbers.

What I have done was put the dynamic into 192.168.x.20-192.168.x.49.
I have done the same. x.90 - x.99 is my dynamic range. 10 ip numbers. Separated from the static range.


I have now implemented a workaround with a script (ie /jffs/scripts/dnsmasq.postconf) that is setting the dhcp-lease-max=100 instead of 10 and all my devices get their static ip numbers as expected.

I still believe that the automatic calculation of the value is erratic...
 
Last edited:
376.49_4 has been uploaded to Mediafire.

Thank you!
No problem updating 376.49_3 to 376.49_4 without factory reset? Just updated to 376.49_3 yesterday and was coming from a very old build. Redid everything including vpn, optware/transmission and all my settings. Hope I can just flash this.

Sent from my LG-D802 using Tapatalk
 
I have now implemented a workaround with a script (ie /jffs/scripts/dnsmasq.postconf) that is setting the dhcp-lease-max=100 instead of 10 and all my devices get their static ip numbers as expected.

I still believe that the automatic calculation of the value is erratic...
Yes it does appear to be a bug.

The programmers are just subtracting the "IP Pool Starting Address" from the ending address (+1) without thinking that some people might be manually assigning IPs outside of the pool.

It would be pretty tricky to calculate an accurate number for dhcp-lease-max because some of the assignments might be within the pool and some might be outside it.

As most people use a subnet mask of 255.255.255.0 I think that always setting dhcp-lease-max to 253 (or 100) would be sensible. Or just delete the line completely and let it default to 1000.
-X, --dhcp-lease-max=<number>
Limits dnsmasq to the specified maximum number of DHCP leases. The default is 1000. This limit is to prevent DoS attacks from hosts which create thousands of leases and use lots of memory in the dnsmasq process.
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top