[Beta] Asuswrt-Merlin 382.1 Beta is available

[dr_lucas]

I noticed a very strange issue with the wifi yesterday.
I just received the router (AC86U) with the stock firmware, installed beta 2, restored to factory defaults, connected to the default SSID wifi network, setup through the wizard with my own internet and wifi SSID with WPA2 and restarted the router.
When it booted, I could only see and connect to the 2 default open SSIDs that I saw after factory reset, although the router pages showed the correct SSID names that I assigned during in the wizard.
Rebooted the router again, same results. The only available wifi signals were the default open ones.
I had to change some wireless settings on each 2.4 and 5GHz and Apply to get rid of the open default SSIDs and show my own.
Hope I explained it clear enough.

It's not a major issue, but still seem to be some kind of a bug.
Never tested beta1. Never had this issue on the .380 series on my previous routers.

 

[RMerlin]

My AC1900P has nothing on /tmp/resolv.dnsmasq, but AC86U has something.

The content will depend on your specific configuration. /tmp/resolv.conf will contain the DNS configured on your WAN interface except if you have an OpenVPN client started with its DNS mode set to Exclusive. In that case, resolv.conf is kept empty to prevent leaks (that's what the Exclusive setting is for), and the nameservers from the tunnel are configured differently. That behaviour is unchanged from 380.68.

 

[Odkrys]

What settings are you entering? I just checked, and the page I use is identical to what's in Asus's 382_16466, aside from one setting which I preserve/restore.

I tested it on 18219. I will wait next GPL merge.
IPTV port is under the same vlan with other ports on beta2, so I can't get public IP.

Can you elaborate? It starts correctly for me.

admin@Stargate86:/tmp/home/root# ps w | grep sd-idle
 4635 admin     1708 S    /usr/sbin/sd-idle-2.6 -i 300
 4690 admin     3124 S    grep sd-idle

You had fixed it but it broke again.

https://github.com/RMerl/asuswrt-me...5c73/release/src/router/sd-idle/sd-idle-2.6.c

 

[RMerlin]

You had fixed it but it broke again.

Please be more specific, what do you mean by "broke"? As I just showed you, it starts just fine for me.

 

[Odkrys]

The content will depend on your specific configuration. /tmp/resolv.conf will contain the DNS configured on your WAN interface except if you have an OpenVPN client started with its DNS mode set to Exclusive. In that case, resolv.conf is kept empty to prevent leaks (that's what the Exclusive setting is for), and the nameservers from the tunnel are configured differently. That behaviour is unchanged from 380.68.

I am using exactly same settings with ac1900p.
I solved it by setting wan dns as blank.

 

[Odkrys]

Please be more specific, what do you mean by "broke"? As I just showed you, it starts just fine for me.

my hard disk never goes to sleep mode.
So I revert the commit to your fixed version and it works now.

 

[RMerlin]

my hard disk never goes to sleep mode.
So I revert the commit to your fixed version and it works now.

The only change Asus did in 16466 versus my own code was to change the way debug output was sent (they directly use printf() instead of a custom_log() function). The kernel check code is still disabled, there has been zero functionality change to the code if you look at that commit. If your disk stops going to sleep then it's because something else is keeping awake - the sleep code is 100% identical between both versions.

 

[Odkrys]

The only change Asus did in 16466 versus my own code was to change the way debug output was sent (they directly use printf() instead of a custom_log() function). The kernel check code is still disabled, there has been zero functionality change to the code if you look at that commit. If your disk stops going to sleep then it's because something else is keeping awake - the sleep code is 100% identical between both versions.

Got it, I will test it again. Thanks.

 

[Pir8pete]

Based on the feedback I received from two different users when I implemented it, the value was getting ignored by the wireless driver when they used something higher than -70.

well I dunno but using this feature on HGGome's FW for my 1900P does make a difference, when I set it to -60 the router kicks the clients off when i dips pass the -60, it's works great. Not sure how he pulled it off.

 

[eclp]

Which I noticed with this firmware:

I have used two RT-AC88u, one as a router, the other as a repeater, both are running the 382.1 Beta 2. The following scripts are installed on the wireless device: AB-Solution and pixelserv (192.168.1.2, kk), as well as Skynet and the QoS-Script. First of all, on the repeater device there is no "spam" in the syslog, only on the wireless router.

wireless router:

repeater:

Why is "Spam" not displayed in the Syslog in repeater mode? And why does the repeater device use pixelserv-ip (192.168.1.2)?

 

[yk101]

@RMerlin, I just noticed the following lines in the log:

Oct 28 10:25:23 kernel: ERR[set_app_info_qos_meta:3361] It's a paid app, please assign a default bandwidth!
Oct 28 10:25:23 kernel: ERR[set_app_info_qos_meta:3361] It's a paid app, please assign a default bandwidth!

Don't believe I saw them before. Expected?
(382.1_beta2-gc21d7dd running on RT-AC88U)

 

[BMWDude49120]

@RMerlin, I just noticed the following lines in the log:

Oct 28 10:25:23 kernel: ERR[set_app_info_qos_meta:3361] It's a paid app, please assign a default bandwidth!
Oct 28 10:25:23 kernel: ERR[set_app_info_qos_meta:3361] It's a paid app, please assign a default bandwidth!

Don't believe I saw them before. Expected?
(382.1_beta2-gc21d7dd running on RT-AC88U)

I am seeing the same errors on my 88U running Beta 2.

 

[RMerlin]

well I dunno but using this feature on HGGome's FW for my 1900P does make a difference, when I set it to -60 the router kicks the clients off when i dips pass the -60, it's works great. Not sure how he pulled it off.

Could be model/driver/SDK specific. Could be that both users reporting issues with values higher than -70 didn't properly test it. In any case, I don't feel like randomly re-enabling this only to get mixed feedback about it.

there is no "spam" in the syslog

Please define "spam".

I just noticed the following lines in the log:

Do a forum search for that error message, been discussed multiple times before.

 

[eclp]

Please define "spam".

This...
And as written, in repeater mode (rt-ac88u) these entries do not exist.

Oct 28 22:48:32 kernel: CONSOLE: 284245.409 wl0: wlc_ampdu_tx_recv_delba: AMPDU OFF: tid 2 initiator 0 reason 39
Oct 28 22:49:22 kernel: CONSOLE: 284381.917 wl1.0: wlc_send_bar: seq 0x31 tid 0
Oct 28 22:49:25 kernel: CONSOLE: 284299.051 wl0.0: wlc_send_bar: seq 0xc3 tid 2
Oct 28 22:49:30 kernel: CONSOLE: 284304.096 wl0: wlc_ampdu_tx_recv_delba: AMPDU OFF: tid 2 initiator 0 reason 39
Oct 28 22:49:59 kernel: CONSOLE: 284418.191 ampdu_dbg: wl1.0 80:ea:96:cf:fb:62 scb:0033a3a4 tid:0
Oct 28 22:49:59 kernel: CONSOLE: 284418.191 ampdu_dbg: wl1.0 dead_cnt 2 tx_in_transit 1 psm_mux 0xfff0 aqmqmap 0x0x404 aqmfifo_status 0x0x4000 fifordy 0x0 cpbusy 0x0
Oct 28 22:49:59 kernel: CONSOLE: 284418.191 ampdu_dbg: ifsstat 0xaf nav_stat 0x0 txop 110756
Oct 28 22:49:59 kernel: CONSOLE: 284418.191 ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
Oct 28 22:49:59 kernel: CONSOLE: 284418.191 ampdu_dbg: txall 5 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Oct 28 22:49:59 kernel: CONSOLE: 284418.191 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 10 0 0 0 0 ifs_boff 0
Oct 28 22:49:59 kernel: CONSOLE: 284418.191 ampdu_dbg: again1 ifsstat 0xaf nav_stat 0x0
Oct 28 22:49:59 kernel: CONSOLE: 284418.191 ampdu_dbg: again2 ifsstat 0xaf nav_stat 0x0
Oct 28 22:49:59 kernel: CONSOLE: 284418.191 wl1: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
Oct 28 22:49:59 kernel: CONSOLE: 284418.191 wl1: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Oct 28 22:50:06 kernel: CONSOLE: 284424.837 wl1.0: wlc_send_bar: seq 0x52 tid 0
Oct 28 22:50:19 kernel: CONSOLE: 284352.433 wl0.0: wlc_send_bar: seq 0xc5 tid 2
Oct 28 22:50:24 kernel: CONSOLE: 284357.291 wl0: wlc_ampdu_tx_recv_delba: AMPDU OFF: tid 0 initiator 0 reason 39
Oct 28 22:50:24 kernel: CONSOLE: 284357.419 wl0: wlc_ampdu_tx_recv_delba: AMPDU OFF: tid 2 initiator 0 reason 39
Oct 28 22:50:25 kernel: CONSOLE: 284358.695 wl0.0: wlc_send_bar: seq 0xbde tid 0
Oct 28 22:50:41 kernel: dhd_prot_flow_ring_create: Send Flow Create Req flow ID 256 for peer b0:70:2d:88:eb:44 prio 0 ifindex 0
Oct 28 22:50:41 kernel: dhd_prot_flow_ring_create_response_process: Flow Create Response status = 0 Flow 256
Oct 28 22:50:41 kernel: CONSOLE: 284460.511 flow_create : bitmap_size=512  maxitems=512
Oct 28 22:50:41 kernel: CONSOLE: 284460.519 wl1.0: wlc_send_bar: seq 0x1 tid 0
Oct 28 22:50:59 kernel: dhd_flow_rings_delete_for_peer: ifindex 0
Oct 28 22:50:59 kernel: dhd_prot_flow_ring_delete: Send Flow Delete Req RING ID 261 for peer b0:70:2d:88:eb:44 prio 0 ifindex 0
Oct 28 22:50:59 kernel: dhd_flow_rings_delete_for_peer: ifindex 0
Oct 28 22:50:59 kernel: dhd_prot_flow_ring_delete_response_process: Flow Delete Response status = 0

 

[bubobih]

Hello i have ac86u and im notice that my upload speed is 20mbit over wifi, but over lan its 100... also download speed over wifi is 49mbit over lan 200mbit... before i have ac66u he have 50/50 more or less over wifi... i do factory reboot nothing help...

 

[Magnus33]

Not happy that they haven't ported it to the other routers yet

But the upside i guess is if they eventually do then the 68u will have a stable version quickly thanks to all this testing

 

[Vexira]

p

Not happy that they haven't ported it to the other routers yet

But the upside i guess is if they eventually do then the 68u will have a stable version quickly thanks to all this testing

just have to wait i think thier on national holiday still, so that will delay it.

 

[RMerlin]

And as written, in repeater mode (rt-ac88u) these entries do not exist.

That debugging output comes from the closed source driver, I have no control over it. Asus simply left debug logging enabled.

 

[dr_lucas]

Could be model/driver/SDK specific. Could be that both users reporting issues with values higher than -70 didn't properly test it. In any case, I don't feel like randomly re-enabling this only to get mixed feedback about it.

Just a suggestion.
Maybe can simply add a toggle/switch for users to be able to enable this with text such as "experimental/untested" or something similar...

 

[ckong]

Thanks, fixed.

That was fast! I look forward to testing the next beta.