What's new

[Release] Asuswrt-Merlin 380.68 is available

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

(@routers: NAT Loopback not working): Works for me.

In my case, Merlin implementation does not work, while ASUS one does. RT-AC56U.

Also, I have noticed that WAN / Port forwarding setup "lost" the edit buttons. Now I can only remove an existing mapping and add another one from scratch, while previously I could click on "edit" button which deleted the mapping, but transferred all contents into edit fields for quick edit.

Additionally, login to router web interface still doesn't work when invoked by DNS name. It has to be router's IP entered into browser's URL bar.
 
In my case, Merlin implementation does not work, while ASUS one does. RT-AC56U.
Do you mean the NAT loopback? Do you have AiProtection/Adaptive QoS or Traffic Analyzer on? I remember that RMerlin says that we should use Asus NAT loopback if we have/had any of those features on.
 
@RMerlin
BUG: RT-AC68U: On 5GHz Wireless General page, if you keep Auto channel selection on and uncheck "Auto select channel including band 1 channels", then Apply, the option is not remembered, the box remains checked.

The NVRAM option seems to be acs_band1=1 but even if I set it to 0 and nvram commit, once you save something in the GUI it reverts back to 1.
 
On my 1900P I found a GUI bug when selecting the "parental controls" tab, see attached screenshots

 
On my 1900P I found a GUI bug when selecting the "parental controls" tab, see attached screenshots
I think post 418 has the same problem as you, and RMerlin replied here.
 
What does that achieve may I ask?
Adjusts the ACK timing in Atheros typical way based on the maximum distance in meters:

0 disables ACK timing completely
1 - 999999 adjusts ACK timing

The default is 2000 meters.

When a packet is sent out from the router, it waits for an "ACKnowledgement" frame from the other end. The router will wait for a response until a certain amount of time has elapsed, called the "ACK timeout" (or "window").

Conventional wisdom holds that should be set to the maximum distance in meters x 2 (doubled to account for round-trip). For example, if you roam with your laptop up to 50 meters from your AP, the setting would be 100.

Under nominal conditions (obstructions, power limitations, in-band interference, etc), the usable range of 802.11b/g is perhaps less than 100 meters, so it might seem that this setting should never exceed 200. However, if using a directional antenna that boosts range, timing needs would increase. Maximum theoretical ACK timeouts are approximately 744µs (11 km) for 802.11b, and 372µs (55 km) for 802.11g. There have been reports of experimental, assisted WiFi connections in excess of 40 kilometers plus.

Another use for ACK might be for restricting the distance at which people can connect. This could be useful for WDS access points or for minimizing the zone of connectivity.

Keep in mind, the higher the ACK timing, the lower the throughput will be. If set too high, packets could be lost as the router waits for the ACK window to timeout. Conversely, if ACK is set too low, the window will expire too soon and returning packets could be dropped, also lowering throughput.

A quick copy and paste from the DD-WRT guys. I've been trying out Merlin last couple of days and I'm coming from a Shibby build. On the Shibby build my Raspberry with external wifi dongle is able to receive streaming content without any problems, but after I switched to Merlin, the stream always locks up at some point (think 3min / 15min / 30 minutes). The strange thing is that using Merlin, the signal is way better compared to Shibby, so I've been comparing settings and one of the settings I'm missing is ACK Timing. Right now I've gone back to a later shibby build (Kille72) set the same config as the previous Shibby build (with ACK timing set to "0") and everything streams fine again. I've tried about every setting/combination in Merlin, but I just can't seem to get the streaming right.

update: I could stay on this build ofc, but I prefer the newer Merlin builds as I assume(...?) that these builds include more (recent) security fixes.
 
Last edited:
skillz, I don't recall which router chipset you have.
As you noted from the dd-wrt thread, the ack timings only seem to impact Atheros chipset based wifi.
That excludes the Broadcom based devices.
At one time there was a Broadcom forum thread discussion about tweaking the router for best performance and some folks were importing the Atheros settings for the Broadcom routers.
However as Kong had pointed out back then (I think that was a year or two ago), even though the setting was in there it was non-impacting on the broadcoms.
**update**
Re-reading the thread, Kong stated that the Broadcom driver did not respect the changes you could make so that may still be something you can tweak in Merlin. I am unable to determine the command for that though sorry.
**update**

I suggest maybe you try enabling/disabling the beamforming settings on the router (and any client that supports the feature)
Also, disable the lower data rates for the radios. 2.4ghz would be for G/N (possibly N only) clients only & 5ghz for AC/N clients only.
A combination of these changes might help your streaming client.
 
Last edited:
skillz, I don't recall which router chipset you have.
As you noted from the dd-wrt thread, the ack timings only seem to impact Atheros chipset based wifi.
That excludes the Broadcom based devices.
At one time there was a Broadcom forum thread discussion about tweaking the router for best performance and some folks were importing the Atheros settings for the Broadcom routers.
However as Kong had pointed out back then (I think that was a year or two ago), even though the setting was in there it was non-impacting on the broadcoms.
So if your like me and have the R7000 with the xVortex Merlin fork, the changes "shouldn't" make anything more than a placebo effect on the wireless clients.

I suggest maybe you try enabling/disabling the beamforming settings on the router (and any client that supports the feature)
Also, disable the lower data rates for the radios. 2.4ghz would be for G/N (possibly N only) clients only & 5ghz for AC/N clients only.
A combination of these changes might help your streaming client.
Thank you for your answer, I do have the R7000 with the fork, and thanks for telling the Ack settings don't work on that chipset. I'm still at loss why the streaming doesn't work properly when I'm using Merlin, and ofc I have tried everything you mentioned before I started thinking about the "missing" Ack setting. It might be that further enhancements were made on Shibby's releases, I just don't know.
 
I reverted to 380.68 and have had a stable router for over 5 days using the same configuration. I can’t see anything remotely suspicious in the change log for _2 but it seems to be where my problems have started.


Sent from my iPhone using Tapatalk
OK I take it all back - after 8 days it's rebooted itself on 380.68. I had turned QoS off earlier this evening. Nobody admitting any torrents.

For anyone smarter than me, the crash looks like this:

Aug 1 01:00:17 kernel: _ Reboot message ... _______________________________________________________
Aug 1 01:00:17 kernel: <1>Unable to handle �U�at virtual address 00000001
Aug 1 01:00:17 kernel: <1>p=00000000
Aug 1 01:00:17 kernel: <0>Internal error: Oopysfs file: /sys/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2:1.0
Aug 1 01:00:17 kernel: <4>module: ebtable_nat bf027000 1056
Aug 1 01:00:17 kernel: <4>module: ebtables bf01c000 15643
Aug 1 01:00:17 kernel: <4>module: ct_nodule: bw_forward bf7da000 9399190
Aug 1 01:00:17 kernel: <4>module: nf_nat_sip bf73b000 5031
Aug 1 01:00:17 kernel: <4>module: nf_conntule: nf_nat_h323 bf72b000 476nat_rtsp bf717000 3202
Aug 1 01:00:17 kernel: <4>moduf70b000 1144
Aug 1 01:00:17 kernel: <4>module: nf_con6000 934
Aug 1 01:00:17 kernel: <4>module: cdrom bf6c_mbim bf6d1000 3129
Aug 1 01:00:17 kernel: <4>moduleodule: cdc_wdm bf6c3000 7252
Aug 1 01:00:17 kernel: <4>module: cdc_ncm bf6bb000 8750
Aug 1 01:00:17 kernel: <4>module: rndis_host bf6b4000 4936
Aug 1 01:00:17 kernel: <4>module: cdc_ether bf6ae000 3187
Aug 1 01:00:17 kernel: <4>module: asi bf5a7000 188546
Aug 1 01:00:17 kernel: <4>module: e bf4d9000 21983
Aug 1 01:00:17 kernel: <4>module: scs484000 4494
Aug 1 01:00:17 kernel: <4>module: ip6tabldule: zlib_deflate bf456000 1dule: nf_nat_proto_gre bf44400module: emf bf021000 15225
Aug 1 01:00:17 kernel: <44>Modules linked in: ebtable_natntrack_proto_gre wl(P) igs(P) emment kernel
Aug 1 01:00:18 kernel: <4>Control: 10c53c7d Table: 9cec004a DAC: 00000017760: 0000075e cce54f30 c03c1794 8215f80 c8215f80 00000000 000000864 c03c1854 bf0049cc c03c1860 c00 c03c1880 00000001 c0164be8 c04604 c03c1854 bf0049cc c0227a04 bf0044c0 00000002 00000005 00000016
Aug 1 01:00:18 kernel: <0>1860: 776f6c46 20736920 20746f6e 70737573 65646e65 50000a0 00000000 00000000 00000000 00000000
Aug 1 01:00:18 kernel: <0>18a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Aug 1 01:00:18 kernel: <0>18c0: 00000000 00000000 00000000 00000000000 00000000 00000000
Aug 1 01:00:18 kernel: <0>19000000000 00000000 00000000 000000�^B0>19c0: 00000000 00000000 00000000000 00000000 00000000 00000000
Aug 1 01:00:18 kernel: <0>1a00: 00000000 00000000 00000000 00000000 00000000 00000000 00000051 00000000
Aug 1 01:00:18 kernel: <0>1a20: 0000030bd6d2 cec56620 d30bd6d2 bf7eeec 804d00be bf7dc9fc
Aug 1 01:00:18 kernel: <0>1a60: 00007e 550fc9dc 00000576
Aug 1 01:00:18 kernel: <0>1aa0: 000004f8 c0379b30 0000054e 00000011 62449dbb cdfda620 00000000 cd0 00000000 00000028 00000011 c03b60: c02e17d0 cecff000 00000000 e788 fffffe71 ccd8a000 00000000
Aug 1 01:00:18 kernel: <0>1be0: 00000000 cecff000 c0283a9c c037c30c c0283a9c c01b960c c8218620 ccd8a000
Aug 1 01:00:18 kernel: <0>1c00: 00000000 ccd8a000 cecff000 c0283a9c c03c1c4c 00000000 c041e788 c0223c8 c03c1c5c 0000000a
Aug 1 01:00:18 kernel: 28cc c03c0000 cbb8b000 bf7eef4c fffe71 c027f374 8a5a3e92 cdfda6e4 c0283a9c 00000000 c041e7a8 cec cecff000 00000000 00000000 cecfbc c041dabc cec56f08 00000000 ce23c88 00000000 c03c1d3c c0283a9c1d3c cf84b800 0000000a d5604040 0 cfa8d800 00000001 cec56ee0
Aug 1 01:00:18 kernel: <0>0>1dc0: 00000000 c03c0000 cec56e3c0000 00000001
Aug 1 01:00:18 kernel: <0>1de0: 00000000 c037afd8 c747111e c041e6c8 000b800 00000000 00000000 c02b7024 0000000 c01f7e18 cec56ee0 cec56
Aug 1 01:00:18 kernel: ____________________________________________________________________________
 
Thank you for your answer, I do have the R7000 with the fork, and thanks for telling the Ack settings don't work on that chipset. I'm still at loss why the streaming doesn't work properly when I'm using Merlin, and ofc I have tried everything you mentioned before I started thinking about the "missing" Ack setting. It might be that further enhancements were made on Shibby's releases, I just don't know.
if your using xwrx vortex you have to ask him this foum is for asus routers with merlin the R7000 is not supported.
 
I've spotted a minor bug in the QoS UI which I suspected was around for a while. I'm using RT-AC68U on 380.68_2 but I think it was present on 380.68 as well.

If I turn off QoS (and save) and then turn it back on again, even though the queue_discipline is set to fq_codel it actually saves as sfq. I then have to go back in to the QoS settings and set fq_codel a second time and save it to get the correct setting.

Fixed.
 
FYI: 380.68->380.68_2, reduced WAN speed from 150 mbps to 3 mbps on my AC66U.
Reverting to 380.68 gives me about 15-50 mbps.
 
Last edited:
I have a problem. In versions 380.67 and 380.68, the Blacklist does not work as expected. In version 66_6, everything is fine. When upgrading from version 380.66_6 to 67 or 68, the Blacklist blocks all traffic including icmp.

Works correctly for me. Blocking port 443 still allows me to reach websites that are only reachable over http, and blocks all https sites.
 

NKruQhM.png
 
hello. i want to update to this from 380.61 for my ac68-u, what's the best reccomend procedure to do this? just flash the firmware and then reset all settings ? I don't quite recall if there was any extra step for this. Is it worth to update from that version to this one or shall i wait for the next one?
thank you very much in advance
 
hello. i want to update to this from 380.61 for my ac68-u, what's the best reccomend procedure to do this? just flash the firmware and then reset all settings ? I don't quite recall if there was any extra step for this. Is it worth to update from that version to this one or shall i wait for the next one?
thank you very much in advance

Merlin has a Wiki just for you: https://github.com/RMerl/asuswrt-merlin/wiki/Installation
 

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