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!

No factory reset required from the 376.49_3 to 376.49_4, especially if you already did a factory reset when upgrading to 376.49_3.
 
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.

Ouch....must be something that was recently added it used to be set to 255 in other versions to account for the /24 subnet max. Nice find.

Here is what I added to my dnsmasq.postconf script:

Code:
sed -i 's|^dhcp-lease-max.*|dhcp-lease-max=255|' /etc/dnsmasq.conf
 
Last edited:
Ouch....must be something that was recently added it used to be set to 255 in other versions to account for the /24 subnet max. Nice find.
To be honest I've not found that actual code that makes that calculation. I'm just inferring it from what has been reported. :eek:


UPDATE: I think I've found it. The change in behaviour was introduced on 27th September in ./rc/services.c


Code:
if ((i = nvram_get_int("dhcpd_lmax")) > 0)

changed to (plus other associated code changes):

Code:
if ((i = get_dhcpd_lmax()) > 0)
 
Last edited:
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?



Please see attachment.
 

Attachments

  • config pdf.pdf
    132.5 KB · Views: 282
Please see attachment.

Ok...can you check the dnsmasq.conf file and see the value of this parameter:


dhcp-lease-max=​

You will have to telnet/ssh into the router, the file is located in the /etc directory.

If you look back in the posts in this thread there appears to be a defect where the calculation of this configuration setting has changed which has been experienced by a myself and another with our static assignment.
 
376.49_4 has been uploaded to Mediafire.

It's a very good release :), but:
-there is a typo in hxxp://192.168.1.1/AdaptiveQoS_WebHistory.asp on header "Adaptive QoS - Web Histroy"
- OpenVPN Connection Status - doesn't show actually connected user if he is a main admin.
- hxxp://192.168.1.1/Main_TrafficMonitor_realtime.asp - ethernet WAN graph doesn't work - runs flat all the time.

Over this, everything work fine - even wireless stability and performance are great. thx a lot !
 
Originally Posted by RMerlin View Post
376.49_4 has been uploaded to Mediafire.

RT-AC66U is still duplicating double mac addresses, only on the 5ghz band (mac filter list).:(

Working just fine on my RT-N66U though.:D
 
Ok...can you check the dnsmasq.conf file and see the value of this parameter:


dhcp-lease-max=​

You will have to telnet/ssh into the router, the file is located in the /etc directory.

If you look back in the posts in this thread there appears to be a defect where the calculation of this configuration setting has changed which has been experienced by a myself and another with our static assignment.

I can telnet in, however I don't know the commands well enough to find that information.
 
I can telnet in, however I don't know the commands well enough to find that information.

type this command:

cat /etc/dnsmasq.conf​

This will list the contents to your terminal session.
 
type this command:

cat /etc/dnsmasq.conf​

This will list the contents to your terminal session.


-Merlin RT-N66U_3.0.0.4 Tue Dec 23 05:30:19 UTC 2014
admin@RT-N66U-9C50:/tmp/home/root# cat /etc/dnsmasq.conf
pid-file=/var/run/dnsmasq.pid
user=nobody
bind-dynamic
interface=br0
interface=ppp1*
no-dhcp-interface=ppp1*
resolv-file=/tmp/resolv.conf
servers-file=/tmp/resolv.dnsmasq
no-poll
no-negcache
cache-size=1500
min-port=4096
dhcp-range=lan,192.168.1.2,192.168.1.254,255.255.255.0,86400s
dhcp-option=lan,3,192.168.1.1
dhcp-option=lan,252,"\n"
ra-param=br0,10,600
enable-ra
quiet-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
dhcp-option=lan,option6:23,[::]
dhcp-lease-max=253
dhcp-authoritative
quiet-dhcp
quiet-dhcp6
admin@RT-N66U-9C50:/tmp/home/root#
 
ra-param=br0,10,600
enable-ra
quiet-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
dhcp-option=lan,option6:23,[::]
dhcp-lease-max=253
dhcp-authoritative
quiet-dhcp
quiet-dhcp6
admin@RT-N66U-9C50:/tmp/home/root#

I see you have IPv6 enabled. Does your network need IPv6? If not I would recommend turning it off. Then re-verify the log.

Based on comments from Merlin ASUS has changed the methods of supporting IPv6 and implemented DNSMasq as the DHCP host for IPv6.
 
Last edited:
Regarding dhcp-lease-max the history for 376.49 (21-Dec-2014) mentions

- CHANGED: Reverted to Asus's max-lease number calculation
for dnsmasq

The commit is
https://github.com/RMerl/asuswrt-merlin/commit/1c1eaaa7b1a6410ea0e8cec57e2876b2f139e7c5
It looks like the code was reverted in 376.49 without an actual fix being applied. Here is the original work around from 376.48_1 :

"dhcpd: temporary fix since Asus's max-lease calculation introduced in 2769 is broken - hardcoding 253 for now to replicate previous releases, will be properly fixed later."

https://github.com/RMerl/asuswrt-merlin/commit/08e71a334150226bb7ac8ccfae701bacb99b5ee8
 
Last edited:
Thank you!
No problem updating 376.49_3 to 376.49_4 without factory reset?

You'll be fine, there was no major change between the two.
 
I still believe that the automatic calculation of the value is erratic...

The calculation is fine. It looks at the range you defined on the DHCP page to determine the maximum number of lease.

The real problem is, a lot of users got used to allocating static leases outside of the scope, which is wrong. People are mixing up reservations with static IPs.

A static IP is something you configure on the computer's network interface, and which must be outside of the DHCP range.

A DHCP reservation is an IP you reserve within your DHCP scope, so the DHCP server will always allocate the same IP.

In other words: any IP allocated by the DHCP server *must* be within the DHCP range, regardless of whether it's static or dynamic. The fact that the DHCP server can allocate an IP from outside its defined scope is a quirk/bug in itself.

Sadly, a lot of routers (including Asuswrt) allow the definition of a reservation outside the defined scope, which leads to issues such as encountered here.

The correct fix is to either enlarge your DHCP scope to include your reservations, or change your reservations to be within the defined scope. And if your goal is for an IP to be outside of the DHCP range, then you must configure it manually and not rely on the DHCP server to allocate an IP from outside its defined range.
 
Last edited:
Ouch....must be something that was recently added it used to be set to 255 in other versions to account for the /24 subnet max. Nice find.

It used to be hardcoded to 253, which could be wrong if you were using a different subnet size, or a more limited scope.
 
It's a very good release :), but:
-there is a typo in hxxp://192.168.1.1/AdaptiveQoS_WebHistory.asp on header "Adaptive QoS - Web Histroy"

The language dictionary files are filled with typos, awkward grammar and what not. Since editing them would make it impossible to keep them in sync with Asus, I chose not to change anything in them.

- hxxp://192.168.1.1/Main_TrafficMonitor_realtime.asp - ethernet WAN graph doesn't work - runs flat all the time.

That's caused by NAT acceleration, which causes a good portion of the traffic to bypass the router's network stack.
 
It looks like the code was reverted in 376.49 without an actual fix being applied. Here is the original work around from 376.48_1 :

"dhcpd: temporary fix since Asus's max-lease calculation introduced in 2769 is broken - hardcoding 253 for now to replicate previous releases, will be properly fixed later."

https://github.com/RMerl/asuswrt-merlin/commit/08e71a334150226bb7ac8ccfae701bacb99b5ee8

That was not a fix, that was a flat out revert to the original hardcoded value, which was wrong.

The calculation in the latest GPL was correct, so I merged it back in.
 

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