What's new

[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

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

I probably won't be putting out a formal release until after the New Year, but in case anyone wants to try out the latest I've uploaded a Beta release. (It's what I'm currently running :))
Note it's a different download location from the stable release location.

BETA RELEASE: Update-16B5
11-December-2015
Merlin fork 374.43_2-16B5j9527
Download http://1drv.ms/1sDtB1V
============================

Hi John,
Running 16B5 on both Main and AP, all appears to work well and MAC lookup is back! Thank you for your very, very fast response on this! Amazing! Here's wishing you and your fam a very Happy Holiday!
 
Hi John,
Running 16B5 (flashed from 15E5) on N66U and everything works well and stable as usual... Thanks !
 
I probably won't be putting out a formal release until after the New Year, but in case anyone wants to try out the latest I've uploaded a Beta release. (It's what I'm currently running :))
Note it's a different download location from the stable release location.

BETA RELEASE: Update-16B5
[...]
  • Fix router failure at boot if NFS is active - @ziolupo
[...]

Many thanks, John. I will give it a try on the next week-end and I will let you know!
 
Flashed the new beta and so far everything is running fine. Will update if anything changes. Thanks John and Merry Xmas! :cool:
 
I probably won't be putting out a formal release until after the New Year, but in case anyone wants to try out the latest I've uploaded a Beta release. (It's what I'm currently running :))
Note it's a different download location from the stable release location.

BETA RELEASE: Update-16B5
11-December-2015
Merlin fork 374.43_2-16B5j9527
Download http://1drv.ms/1sDtB1V
============================

Changelog
  • Updated OpenSSL to 1.0.2e
  • Did my own code review and closed multiple buffer overflow exposures
  • Updated e2fsprogs to latest Merlin level
  • Increased max Parental Controls to 32
  • Updated entware install script to entware-ng
  • Added support for igmpproxy customization
  • Fixed Smart Sync not syncing after start (ASUS binary updates) - @DocUmibozu
  • Fix router failure at boot if NFS is active - @ziolupo
  • Add valid ip address check/retries/logging to QoS start - @strangeluck
  • Add new option to System Log>Connections to display connection count summary - @UserEasy
  • Fix vendor lookup from the networkmap client status - @Wisiwyg
  • NTP Updates
    • Show successful NTP syncs in syslog by default
      The successful sync logs can be disabled in the gui in the Syslog options, failures will always be shown
    • Allow changing the alternate NTP server in the gui (the router already actually used 2 NTP servers, this just externalizes the second server)
    • Allow changing the time between NTP syncs in the gui
      Note: Setting the sync interval to '0' disables sync attempts and tells the router to accept as valid whatever time is set (useful when the router is not connected to the internet, and the time is set manually via the command line (use with caution) - @dasbrot)

John,
Running version 16B5 of the fork and have verified that lan wired ports still do not get QOS set properly with native iPv6. Found another recent post stating the same problem with Merlins most recent release 378.56.
When are you getting native iPv6?

http://www.snbforums.com/threads/speed-drop.29110/
 
John,
Running version 16B5 of the fork and have verified that lan wired ports still do not get QOS set properly with native iPv6. Found another recent post stating the same problem with Merlins most recent release 378.56.
When are you getting native iPv6?

http://www.snbforums.com/threads/speed-drop.29110/
Please look in the syslog for entries starting with qos: ....do you see any? I added some logging around what I thought may be the problem.

As for native IPv6 for me....who knows? Maybe first half 2016....
 
Please look in the syslog for entries starting with qos: ....do you see any? I added some logging around what I thought may be the problem.

As for native IPv6 for me....who knows? Maybe first half 2016....

Dec 31 17:00:21 kernel: Ebtables v2.0 registered
Dec 31 17:00:21 qos: using ipv4_lan_ipaddr 192.168.1.0/24
Dec 31 17:00:21 qos: ipv6_lan_ipaddr doesn't exist, retrying
Dec 31 17:00:22 qos: ipv6_lan_ipaddr doesn't exist, retrying
Dec 31 17:00:22 rdnssd[690]: Get IPv6 address & DNS from DHCPv6
Dec 31 17:00:22 rc_service: rc 740:notify_rc start_dhcp6c
Dec 31 17:00:22 rc_service: waiting "start_firewall" via udhcpc ...
Dec 31 17:00:23 qos: ipv6_lan_ipaddr doesn't exist, retrying
Dec 31 17:00:23 WAN Connection: WAN was restored.
Dec 31 17:00:23 dnsmasq-dhcp[549]: DHCPREQUEST(br0) 192.168.1.111 00:18:61:26:8f:23
Dec 31 17:00:23 dnsmasq-dhcp[549]: DHCPACK(br0) 192.168.1.111 00:18:61:26:8f:23 ooma
Dec 31 17:00:24 qos: ipv6_lan_ipaddr doesn't exist, retrying
Dec 31 17:00:25 dnsmasq-dhcp[549]: DHCPREQUEST(br0) 192.168.1.108 b8:3e:59:63:ea:4d
Dec 31 17:00:25 dnsmasq-dhcp[549]: DHCPACK(br0) 192.168.1.108 b8:3e:59:63:ea:4d NP-1GM35A076813
Dec 31 17:00:25 qos: ipv6_lan_ipaddr doesn't exist, retrying
Dec 31 17:00:26 kernel: xt_connbytes: Forcing CT accounting to be enabled
Dec 31 17:00:26 kernel: nf_conntrack_rtsp v0.6.21
 
Last edited:
Dec 31 17:00:25 qos: ipv6_lan_ipaddr doesn't exist, retrying
Well, I was right about the reason :) Unfortunately, just retrying didn't get it (It should retry 5 times before giving up , and it retried 4 of those even before rdnssd started to get the IPv6 address, don't understand why it did more). Let me think about this a bit.

EDIT: What router in case I'd like you to try a test build?
 
Last edited:
Well, I was right about the reason :) Unfortunately, just retrying didn't get it (It should retry 5 times before giving up , and it retried 4 of those even before rdnssd started to get the IPv6 address, don't understand why it did more). Let me think about this a bit.

EDIT: What router in case I'd like you to try a test build?

RT-AC68P so 68U works
 
Honestly what do you need QOS for ?

QOS makes all the difference on a congested link (90-100% usage)...it can either be horribly unusable or so smooth and responsive you won't even suspect it's actually totally loaded. Asus interface for classic qos is enough for this, just need a bit more exact classification rules in iptables if you want something more precise, below is doable with Asus web interface only.

For example my bandwidth rules are
  • Highest 3-10%, this is for ack, syn, icmp and dns only;
  • High 20-33% skype, radio, mail, web page load start 0-300kbyte, one privileged tablet;
  • Medium 20-33% default for all devices (computers, tablets etc);
  • Low 56-100% bulk transfers (torrent, ftp, identified 1mbyte+ size streams);
  • Lowest 1-10% guests, because as soon as they connect their phones practically ddos our connection updating

Guests means upper range of dhcp /24 block, i've set up dhcp to give out addresses from .129-.254 only, this corresponds to .128/25 which is easily defined as a qos rule. Own devices are with fixed dhcp reservations in .2-.126 range, corresponding to .0/25 , also easily defined.
 
Last edited:
RT-AC68P so 68U works
This should be a temporary workaround for you.....just go to the main QoS page with the bandwidth settings and just hit save without changing anything. If you then look in the syslog, you should have two messages from qos saying it found the ipv4 and ipv6 lan addresses.
 
  • Allow changing the time between NTP syncs in the gui
    Note: Setting the sync interval to '0' disables sync attempts and tells the router to accept as valid whatever time is set (useful when the router is not connected to the internet, and the time is set manually via the command line (use with caution) - @dasbrot)

Hi John, I installed the shiny new beta yesterday. Setting the NTP sync interval to '0' did the job for me. All quiet now in my logs.
Thanks for your great support, keep up the good work!
 
Hi John, I installed the shiny new beta yesterday. Setting the NTP sync interval to '0' did the job for me. All quiet now in my logs.
Thanks for your great support, keep up the good work!
Thanks for the feedback! Glad I could be of service.
 
This should be a temporary workaround for you.....just go to the main QoS page with the bandwidth settings and just hit save without changing anything. If you then look in the syslog, you should have two messages from qos saying it found the ipv4 and ipv6 lan addresses.

Looks like it schedules a full reboot when I do the save...followed by the missing iPv6 address retries


Dec 15 08:10:41 dnsmasq-dhcp[576]: DHCPACK(br0) 192.168.1.100 00:23:54:13:33:c9 HP-PC
Dec 15 08:14:56 HTTP login: login 'admin' successful from 192.168.1.100
Dec 15 08:15:11 rc_service: httpd 582:notify_rc reboot
Dec 15 08:15:11 radvd[934]: Exiting, sigterm or sigint received.
Dec 15 08:15:11 radvd[934]: sending stop adverts
Dec 15 08:15:11 radvd[934]: removing /var/run/radvd.pid
Dec 15 08:15:11 rc_service: dhcp6c-state 945:notify_rc start_httpd
Dec 15 08:15:11 rc_service: waiting "reboot" via httpd ...
Dec 15 08:15:12 dnsmasq[576]: read /etc/hosts - 9 addresses
Dec 15 08:15:12 dnsmasq[576]: read /etc/hosts.dnsmasq - 6 addresses
Dec 15 08:15:12 dnsmasq-dhcp[576]: read /etc/ethers - 10 addresses
Dec 15 08:15:12 dnsmasq[576]: using nameserver 8.8.8.8#53
Dec 15 08:15:12 dnsmasq[576]: using nameserver 8.8.8.4#53
Dec 15 08:15:12 dnsmasq[576]: using nameserver 2001:578:3f::30#53
Dec 15 08:15:12 dnsmasq[576]: using nameserver 2001:578:3f:1::30#53
Dec 15 08:15:12 stop_wan(): perform DHCP release


Dec 31 17:00:21 rc_service: waiting "start_firewall" via udhcpc ...
Dec 31 17:00:21 kernel: Ebtables v2.0 registered
Dec 31 17:00:21 qos: using ipv4_lan_ipaddr 192.168.1.0/24
Dec 31 17:00:21 qos: ipv6_lan_ipaddr doesn't exist, retrying
Dec 31 17:00:22 qos: ipv6_lan_ipaddr doesn't exist, retrying
Dec 31 17:00:22 rdnssd[690]: Get IPv6 address & DNS from DHCPv6
Dec 31 17:00:22 rc_service: rc 740:notify_rc start_dhcp6c
Dec 31 17:00:22 rc_service: waiting "start_firewall" via udhcpc ...
Dec 31 17:00:23 WAN Connection: WAN was restored.
Dec 31 17:00:23 dnsmasq-dhcp[537]: DHCPREQUEST(br0) 192.168.1.108 b8:3e:59:63:ea:4d
Dec 31 17:00:23 dnsmasq-dhcp[537]: DHCPACK(br0) 192.168.1.108 b8:3e:59:63:ea:4d NP-1GM35A076813
Dec 31 17:00:23 qos: ipv6_lan_ipaddr doesn't exist, retrying
Dec 31 17:00:24 qos: ipv6_lan_ipaddr doesn't exist, retrying
Dec 31 17:00:25 qos: ipv6_lan_ipaddr doesn't exist, retrying
Dec 31 17:00:26 dnsmasq-dhcp[537]: DHCPREQUEST(br0) 192.168.1.111 00:18:61:26:8f:23
Dec 31 17:00:26 dnsmasq-dhcp[537]: DHCPACK(br0) 192.168.1.111 00:18:61:26:8f:23 ooma
Dec 31 17:00:26 kernel: xt_connbytes: Forcing CT accounting to be enabled
Dec 31 17:00:27 kernel: nf_conntrack_rtsp v0.6.21 loading
Dec 31 17:00:27 kernel: nf_nat_rtsp v0.6.21 loading
 
Looks like it schedules a full reboot when I do the save...followed by the missing iPv6 address retries
Hmmm....it should only do a full reboot when turning QoS either on or off (so it can disable/enable CTF as necessary), otherwise it just regenerates the rules and restarts QoS. So it you turn it on and it reboots (or reboot with it already turned on), then go back to the QoS page, it should show On. At his point if you just hit save, it should just regen the rules and restart QoS.
 
Hmmm....it should only do a full reboot when turning QoS either on or off (so it can disable/enable CTF as necessary), otherwise it just regenerates the rules and restarts QoS. So it you turn it on and it reboots (or reboot with it already turned on), then go back to the QoS page, it should show On. At his point if you just hit save, it should just regen the rules and restart QoS.

OK, Went from QOS OFF to QOS ON followed by SAVE
automatic full router reboot
Went back to QOS page and did a SAVE

Dec 15 12:21:21 HTTP login: login 'admin' successful from 192.168.1.100
Dec 15 12:21:27 rc_service: httpd 561:notify_rc restart_qos
Dec 15 12:21:27 qos: using ipv4_lan_ipaddr 192.168.1.0/24
Dec 15 12:21:27 qos: using ipv6_lan_ipaddr 2600:8800:a880:9f::/64
Dec 15 12:21:28 kernel: HTB: quantum of class 10002 is big. Consider r2q change.
Dec 15 12:21:28 kernel: HTB: quantum of class 10060 is big. Consider r2q change.

Problem now is no ipv6 access only ipv4.....I think we have been down this road before
 

Sign Up For SNBForums Daily Digest

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