What's new

[384.12_Alpha - builds] Testing all variants.

  • 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!

Status
Not open for further replies.
Is there a way to alter the router's default dhcp lease time for LAN clients of 24 hours to something less?
 
Hi, most likely by altering one of the NVRAM variables: lan_lease / lan1_lease/dhcp_lease or dhcp1_lease that, at least in my rt-ax88u are initialized to 86400 (number of seconds in 24h) with 'nvram set variable=value' command. Do not forget the 'nvram commit' to make the change permanent.
 
no_name, do you have the WAN: Use local caching DNS server as system resolver set to 'Yes'? You may want to change that to 'No'. :)


@RMerlin was right (of course!) when he made the WAN: Use local caching DNS server as system resolver default to 'No'.
Why should the local caching of DNS server be set to 'No'?

Having WAN: Use local caching DNS server as system resolver set to 'No'? created an issue for me in 384.12 alpha. If I specified a domain name, say pandora.com, in an ipset directive inside of dnsmasq (e.g. ipset=/pandora.com/MY_LIST), the ipset list would not get populated with the IP address of the domain name when performing an nslookup. Once I set WAN: Use local caching DNS server as system resolver set to 'Yes', the ipset list would get updated with the IP address when performing an nslookup on the domain name.
 
Last edited:
Thanks @Jack Yaz !! It was staring me right in the face! :oops::oops::rolleyes::rolleyes:
If you use the dnsmasq entry for lan clients, you can specify time. In this example, 1440 min or 1440 min/60 =24 hours

dhcp-host=11:20:AE:5E:86:63,Security-Camera-DVR,192.168.2.200,1440
 
If you use the dnsmasq entry for lan clients, you can specify time. In this example, 1440 min or 1440 min/60 =24 hours

dhcp-host=11:20:AE:5E:86:63,Security-Camera-DVR,192.168.2.200,1440
Cool!! I have a burning question now. When using dnsmasq.conf.add populated with devices and their host names, and now possibly lease times, do I need the caching setting set to yes or no?
 
It shouldn't make any difference unless you need to use the names you've given them in scripts on the router itself.

Wan: Use local caching DNS server as system resolver (default: No)
No:
  • The router will not be able to resolve client host names. This has no effect on clients themselves (they can always resolve them if using the router for dns).
  • The router will use ISP DNS servers. Essential for setting system time if using DoT. Clients will use whatever dnsmasq is set to use.
Yes:
  • The router may be unable to set the time if DoT is enabled. DoT will not work without the time being set. Everything may be horribly broken.
  • The router can resolve host names set by dnsmasq (some-pc.lan etc). Once again, no effect on clients themselves (they can always resolve them if using the router for dns).
So it's mostly a choice between stuff working and having the router able to use client host names. If you really need both, it's possible to set dnsmasq to use the ISP DNS servers for the time servers only (That'd be "Yes" with dnsmasq.conf.add entries like server=/pool.ntp.org/8.8.8.8).
 
It shouldn't make any difference unless you need to use the names you've given them in scripts on the router itself.

Wan: Use local caching DNS server as system resolver (default: No)
No:
  • The router will not be able to resolve client host names. This has no effect on clients themselves (they can always resolve them if using the router for dns).
  • The router will use ISP DNS servers. Essential for setting system time if using DoT. Clients will use whatever dnsmasq is set to use.
Yes:
  • The router may be unable to set the time if DoT is enabled. DoT will not work without the time being set. Everything may be horribly broken.
  • The router can resolve host names set by dnsmasq (some-pc.lan etc). Once again, no effect on clients themselves (they can always resolve them if using the router for dns).
So it's mostly a choice between stuff working and having the router able to use client host names. If you really need both, it's possible to set dnsmasq to use the ISP DNS servers for the time servers only (That'd be "Yes" with dnsmasq.conf.add entries like server=/pool.ntp.org/8.8.8.8).
Thanks for the explanation. I have no scripts that use host names specifically, so I'm good with the default setting of "no." :)
 
I'd like to throw out two scripts that I have somehow inherited to see what the sharper minds here think about them with regards to this 'No' or 'Yes', option. :)

I'll put them in different posts so that we can easily know which one is being talked about. ;)

This first one will only place the NTP via DNS route into dnsmasq if I'm understanding this properly.

Code:
#!/bin/sh
append_on_demand () {
  TARGET="$1"
  shift
  for LINE in "$@"; do
    if [ -z "`grep -F \"$LINE\" $TARGET`" ]; then
      (
      echo "$LINE" >> $TARGET
      logger -t "SCRIPT_$(basename $0)" "$LINE have been added to $TARGET successfully"
      )
    else
      logger -t "SCRIPT_$(basename $0)" "$LINE is already located inside $TARGET"
    fi
  done
}
case $1 in
  /etc/dnsmasq.conf)

     if [ "$(nvram get dns_local_cache)" = "1" ]; then
       {
           NTPSERVERS=""
           for VAR in 0 1; do
               NTP="$(nvram get "ntp_server$VAR")"
               [ -n "$NTP" ] && NTPSERVERS="$NTPSERVERS/$NTP"
           done
           [ -z "$NTPSERVERS" ] && NTPSERVERS="/pool.ntp.org"
           for DNS in $(nvram get wan_dns); do
               append_on_demand $1 "server=$NTPSERVERS/$DNS"
           done
           for VAR in 1 2 3; do
               DNS="$(nvram get "ipv6_dns$VAR")"
               [ -n "$DNS" ] && append_on_demand $1 "server=$NTPSERVERS/$DNS"
           done
       }
     fi
     if [ `nvram get ntp_ready` -eq 1 ]; then
       {
         if ping -w 1 -c 1 1.1.1.1 > /dev/null 2>&1
           then
               for VAR in 0 1; do
               NTP="$(nvram get "ntp_server$VAR")"
               /usr/sbin/ntpd -q -n -p $NTP
               logger -t "SCRIPT_$(basename $0)" "Time synced from $NTP"
           done
           else
               logger -t "SCRIPT_$(basename $0)" "FAILED to sync time from $NTP"
         fi
       }
     fi
   ;;
esac
 
This second script will allow the NTP via DNS route to be added and will also test for a ping to 1.1.1.1 and if successful it will set the clock with the NTP servers.

It seems like the only flaw with this script is that it tells ntpd to be skipped so it will leave 'nvram get ntp_ready' at 0 this can be avoided by changing the value back to 1 this will allow it to only sync time after the first initial clock has been set, it is still good for keeping your time updated. All you may have to do is a service restart_dnsmasq.

Code:
#!/bin/sh
append_on_demand () {
  TARGET="$1"
  shift
  for LINE in "$@"; do
    if [ -z "`grep -F \"$LINE\" $TARGET`" ]; then
      (
      echo "$LINE" >> $TARGET
      logger -t "SCRIPT_$(basename $0)" "$LINE have been added to $TARGET successfully"
      )
    else
      logger -t "SCRIPT_$(basename $0)" "$LINE is already located inside $TARGET"
    fi
  done
}
case $1 in
  /etc/dnsmasq.conf)

     if [ "$(nvram get dns_local_cache)" = "1" ]; then
       {
           NTPSERVERS=""
           for VAR in 0 1; do
               NTP="$(nvram get "ntp_server$VAR")"
               [ -n "$NTP" ] && NTPSERVERS="$NTPSERVERS/$NTP"
           done
           [ -z "$NTPSERVERS" ] && NTPSERVERS="/pool.ntp.org"
           for DNS in $(nvram get wan_dns); do
               append_on_demand $1 "server=$NTPSERVERS/$DNS"
           done
           for VAR in 1 2 3; do
               DNS="$(nvram get "ipv6_dns$VAR")"
               [ -n "$DNS" ] && append_on_demand $1 "server=$NTPSERVERS/$DNS"
           done
       }
     fi
     if [ `nvram get ntp_ready` -eq 0 ]; then
       {
         if ping -w 1 -c 1 1.1.1.1 > /dev/null 2>&1
           then
               for VAR in 0 1; do
               NTP="$(nvram get "ntp_server$VAR")"
               /usr/sbin/ntpd -q -n -p $NTP
               logger -t "SCRIPT_$(basename $0)" "Time synced from $NTP"
           done
           else
               logger -t "SCRIPT_$(basename $0)" "FAILED to sync time from $NTP"
         fi
       }
     fi
   ;;
esac
 
@RMerlin or @thiggins. If the above two posts are not in the appropriate thread to discuss here, please move them to a more appropriate thread. Thank you.
 
In regards to the above posts by @L&LD : I don't understand the need for either of these scripts to be honest. What would the real world scenario look like to require either script?
 
As @Marin also finds, when set to 'Yes' I find the whole network faster, but as I found out when I was using OpenVPN, it would drop that connection and so I'm now using 'N0'.

https://www.snbforums.com/threads/dns-security.56784/page-2#post-494351

Will either of these scripts with possible further adjustments allow me to keep the setting to 'Yes' and my faster network?

@RMerlin @Adamm @thelonelycoder @Jack Yaz @ColinTaylor and everyone else that I can't recall right now from the top of my head. Your expertise in looking at these scripts would be very much appreciated.

Thank you to all who can help and contribute one way or another.

For completeness, this is the 'Yes' setting I'm referring to here. :)

WAN: Use local caching DNS server as system resolver default to 'No'

https://www.snbforums.com/threads/384-12_alpha-builds-testing-all-variants.56639/page-16#post-494084
 
Last edited:
In regards to the above posts by @L&LD : I don't understand the need for either of these scripts to be honest. What would the real world scenario look like to require either script?

If they solve the issue of the OpenVPN server being dropped, it would make the 'Yes' setting stable and my network responsiveness (and @Marin's, it seems) better than when it is set to 'No'. :)
 
If they solve the issue of the OpenVPN server being dropped, it would make the 'Yes' setting stable and my network responsiveness (and @Marin's, it seems) better than when it is set to 'No'. :)
These are the settings I use, and the feature in question set to "no." I have included a screen shot of my router's system page where the network monitor settings are. What I noticed and captured in the shot is; the drop down for ping target has domains not IP's, yet the tool tip clearly says the target is an IP. A close look shows mine set to 1.1.1.1 and this works with OVPN server and client startup. Please see attached screen-shot.
Screenshot from 2019-05-30 10-14-31.png
 
Last edited:
These are the settings I use, and the feature in question set to "no." I have included a screen shot of my router's system page where the network monitor settings are. What I noticed and captured in the shot is; the drop down for ping target has domains not IP's, yet the tool tip clearly says the target is an IP. A close look shows mine set to 1.1.1.1 and this works with OVPN server and client startup. Please see attached screen-shot.
View attachment 17911

I don't use the firmware's NTP server. I am using @Jack Yaz' ntpMerlin script instead.
 
I don't use the firmware's NTP server. I am using @Jack Yaz' ntpMerlin script instead.
The use of the firmware's built in ntp server isn't relevant. If the ntp script of @Jack Yaz requires the use of host names then simply set the caching setting to yes. I don't understand the complexity here. Sorry. o_O:confused:
 
Status
Not open for further replies.

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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