[Release 382] Asuswrt-Merlin 382.1 is now available

[Keenan]

LAN performance is unaffected by the CPU. Switched Ethernet traffic will be at full gigabit regardless of the model, wireless traffic will depend on your wireless clients.

Thanks.

And based on your remarks about what Asus might be doing about the NVRAM issue there seems to be some reason for hope. It is understood of course, that nothing is guaranteed. I, like others I'm sure, are trying to be as sure as we can that our choice(the 86U) is as future-proofed as possible. And part of that is continued support by the wizardry of Merlin!

 

[XIII]

I see different DNS behaviour on my old AC-66U with 380.69 and my new AC-86U with 382.1:

https://www.snbforums.com/threads/m...86u-router-how-to-ddns-etc.42419/#post-363719

Is this expected behaviour? A bug? Or a user error?

 

[YzRacer]

I'm experiencing a very strange issue with my RT-AC88U on Merlin's 382.1_2 with my new Pixel 2 XL. The device has been factory reset after upgrading and no backup restored other than static clients and port forwards entered via ssh. It seems that whenever I would pick my phone up (and it reconnects after being asleep) my whole network would go haywire. Log is set to debug/all and shows nothing when these events occur other than occasionally dnsmasq-dhcp messages. CPU temp is usually around 85.

Initially:
Devices would drop off 5Ghz wifi (including the Pixel) and reconnect a moment later.
During this period the internet could not be accessed by any device on the lan.

After reading about others experience with 5Ghz I ended up disabling it. I'm currently running only 1 SSID on 2.4Ghz with 20Mhz width and set to channel 1.
The phone has been rebooted a couple of times as well as the router.

Now:
When I wake my phone all devices stay connected to wifi but the internet drops.
Cannot ping the router or Google during this period.
Cannot access the web gui during this period.
I CAN ping other devices on the lan but ping times increase during this period.

It's extremely consistent. I can kill the internet for at least 6 pings and sometimes up to 20 pings by waking my phone. Once the hiccup passes everything is fine including the Pixel.

For a fresh start I forgot the SSID on my phone and re-established the connection. On initial pairing with the router I got the same result as when waking from sleep.

Pixel 2 XL is running this month's update (8.1.1).

As I wrote this post I thought to reboot the phone to safe mode and test. I found here that the issue doesn't occur when the phone is running in safe mode so I suspect it could be some app causing the issue?

And fixed!? After rebooting out of safe mode the issue stopped happening. I did notice safe mode cleared my widgets and my default home screen choice so perhaps something was cleared in safe mode that resolved the issue. I'll continue to monitor. If it's stable maybe I'll even turn 5Ghz back on.

 

[RMerlin]

I see different DNS behaviour on my old AC-66U with 380.69 and my new AC-86U with 382.1:

https://www.snbforums.com/threads/m...86u-router-how-to-ddns-etc.42419/#post-363719

Is this expected behaviour? A bug? Or a user error?

The only change in 382 is Asus no longer uses resolv.conf, and also have no-resolv in the default config. Make sure you don't add it twice - dnsmasq might generate an error message then.

 

[Mark Taylor]

I'm experiencing a very strange issue with my RT-AC88U on Merlin's 382.1_2 with my new Pixel 2 XL. The device has been factory reset after upgrading and no backup restored other than static clients and port forwards entered via ssh. It seems that whenever I would pick my phone up (and it reconnects after being asleep) my whole network would go haywire. Log is set to debug/all and shows nothing when these events occur other than occasionally dnsmasq-dhcp messages. CPU temp is usually around 85. .......

I use the RT-AC88U on Merlin 382.1_2 and although I don't have a Pixel 2 I do have a Sony XZ Premium on Android Oreo 8.0.0. I have zero issues with the 2.4 GHz or 5 GHz wireless networks. I have 100/40 fibre and get 95/38 3ms consistently. I mainly use the 5 GHz range. I do find you need to fine tune the settings in the Wireless. My settings are below. I also have Wi-Fi analyzer setup on my MacBook Pro so I can see the various channels etc. around me. I don't use much 2.4 GHz as around me it is very crowded but if I do I use 20/40 range and channel 6 works for me. There is often some compatibility issues with various manufacturers chipsets on the access points/routers and the client devices and that can be difficult to solve so that could also be a factor and also drivers.

I would also recommend you do a Factory Reset and re-enter all settings manually if you did not already do that after upgrading from 380 etc. I did this as I had a few minor issues and mainly to do with OpenVPN which this resolved.

Your temps also sound quite high and I expect that if your temps are high for the wireless it will start to cause performance issues. I am in Perth Australia so we have quite high ambients this time of the year as it is summer here so can be inside 24-30 C or so and 30-38 outside. I have air conditioning but also have a laptop cooler under my RT-AC88 which lowers temps a lot. Currently ambient is probably around 23 and CPU = 77, 2.4 GHz = 49 and 5 GHz = 52 - turn on the laptop cooler for about 5 minutes and the temps are then 69, 46 & 50 respectively, after 10 minutes 44, 49, 66. I think you can easily see the factory cooling on this unit is not very good. My long term experience is to keep electronics cool which prolongs their life and also better performance. I bought a cheap eBay cooler for like $15 but it is a little noisy. I do not power it from the router as I think that is not a good idea and I have some of those power boards with USB outlets and use that instead.

http://www.ebay.com.au/itm/OZ-For-L...ith-USB-Hub-/252679936671?hash=item3ad4e5da9f

 

[RMerlin]

Also the jffs restore fails. Once i exported it I cannot restore it back.

Works for me.

 

[jay50n]

My device RT-AC88U is generating hell lot of logs after updating. A factory reset doesnt get rid of it either. the log are as follows:

Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: wl1.0 MAC CENSORED tid:0
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: wl1.0 dead_cnt 2 tx_in_transit 1 psm_mux 0xfff0 aqmqmap 0x0x101 aqmfifo_status 0x0x4 fifordy 0x2 cpbusy 0x0
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: ifsstat 0xa2 nav_stat 0x1 txop 109394
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: pktpend: 0 5 0 0 0 ap 1
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: txall 90 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 5 0 6 0 0 ifs_boff 9
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: again1 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: again2 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 wl1: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 wl1: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Dec 14 18:24:03 kernel: CONSOLE: 300063.104 wl1.0: wlc_send_bar: seq 0x9bf tid 0
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: wl1.0 MAC CENSORED tid:0
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: wl1.0 dead_cnt 2 tx_in_transit 1 psm_mux 0xfff0 aqmqmap 0x0x101 aqmfifo_status 0x0x4000 fifordy 0x0 cpbusy 0x0
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: ifsstat 0xa2 nav_stat 0x1 txop 109950
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: txall 51 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 12 0 0 0 0 ifs_boff 0
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: again1 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: again2 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 wl1: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 wl1: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Dec 14 18:24:32 kernel: CONSOLE: 300092.099 wl1.0: wlc_send_bar: seq 0x2b9 tid 0
Dec 14 18:24:32 kernel: CONSOLE: 300092.114 wl1.0: wlc_send_bar: seq 0x9c4 tid 0
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: wl1.0 MAC CENSORED tid:0
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: wl1.0 dead_cnt 2 tx_in_transit 1 psm_mux 0xfff0 aqmqmap 0x0x101 aqmfifo_status 0x0x4000 fifordy 0x0 cpbusy 0x0
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: ifsstat 0xa2 nav_stat 0x1 txop 110007
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: txall 44 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 8 0 0 0 0 ifs_boff 0
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: again1 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: again2 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 wl1: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 wl1: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Dec 14 18:24:46 kernel: CONSOLE: 300106.115 wl1.0: wlc_send_bar: seq 0x9cd tid 0

 

[Jack Yaz]

My device RT-AC88U is generating hell lot of logs after updating. A factory reset doesnt get rid of it either. the log are as follows:

Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: wl1.0 MAC CENSORED tid:0
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: wl1.0 dead_cnt 2 tx_in_transit 1 psm_mux 0xfff0 aqmqmap 0x0x101 aqmfifo_status 0x0x4 fifordy 0x2 cpbusy 0x0
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: ifsstat 0xa2 nav_stat 0x1 txop 109394
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: pktpend: 0 5 0 0 0 ap 1
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: txall 90 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 5 0 6 0 0 ifs_boff 9
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: again1 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 ampdu_dbg: again2 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 wl1: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
Dec 14 18:24:01 kernel: CONSOLE: 300061.098 wl1: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Dec 14 18:24:03 kernel: CONSOLE: 300063.104 wl1.0: wlc_send_bar: seq 0x9bf tid 0
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: wl1.0 MAC CENSORED tid:0
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: wl1.0 dead_cnt 2 tx_in_transit 1 psm_mux 0xfff0 aqmqmap 0x0x101 aqmfifo_status 0x0x4000 fifordy 0x0 cpbusy 0x0
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: ifsstat 0xa2 nav_stat 0x1 txop 109950
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: txall 51 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 12 0 0 0 0 ifs_boff 0
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: again1 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 ampdu_dbg: again2 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 wl1: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
Dec 14 18:24:25 kernel: CONSOLE: 300085.098 wl1: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Dec 14 18:24:32 kernel: CONSOLE: 300092.099 wl1.0: wlc_send_bar: seq 0x2b9 tid 0
Dec 14 18:24:32 kernel: CONSOLE: 300092.114 wl1.0: wlc_send_bar: seq 0x9c4 tid 0
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: wl1.0 MAC CENSORED tid:0
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: wl1.0 dead_cnt 2 tx_in_transit 1 psm_mux 0xfff0 aqmqmap 0x0x101 aqmfifo_status 0x0x4000 fifordy 0x0 cpbusy 0x0
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: ifsstat 0xa2 nav_stat 0x1 txop 110007
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: txall 44 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 8 0 0 0 0 ifs_boff 0
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: again1 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 ampdu_dbg: again2 ifsstat 0xa2 nav_stat 0x1
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 wl1: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
Dec 14 18:24:43 kernel: CONSOLE: 300103.098 wl1: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Dec 14 18:24:46 kernel: CONSOLE: 300106.115 wl1.0: wlc_send_bar: seq 0x9cd tid 0

Believe this is caused by Asus leaving debugging enabled on the wireless drivers.

 

[jay50n]

Believe this is caused by Asus leaving debugging enabled on the wireless drivers.

i suspected so, is there anyway i could stop those logs? i am not that savy

 

[Jack Yaz]

i suspected so, is there anyway i could stop those logs? i am not that savy

Other than a crude cron job that does an in place sed to remove the additional debug lines, I don't know of any fancier solutions!

 

[Stephen Harrington]

Note that I didn't remove the limitation, I merely extended it a bit, by no longer storing the extra hostname field in that variable.

The port forward is harder to fix. In the DHCP list case, I simply removed the extra hostname field from it, so the closed source parts can still access a complete lease list through the original variable, while the dnsmasq config part uses the extended, split version of it.

If I split the port forward list, it means that any closed source component relying on that variable will no longer be able to access it. So, making that change will require more planification to determine if any of the closed source components need to access it. If there are, then I can't change it.

Hi @RMerlin, does the above from you explain the following behaviour I am seeing?

I’m attempting to manually migrate/replug settings from my trusty AC68U running 380.69 to my new AC86U with 382.1_2 so it can replace my main house router and I have a large set of manual DHCP entries, around 60 or so. Once I got to entering around 31-32 the extra host name and change of default icon would not stick for all the following entries past this.

On that basis I aborted, unsure whether the 86U was ready for prime time. I assume this is a bug that Asus knows about and is also in the stock firmware? Loaded your firmware straight away so wouldn’t know ...

Together with the similar bug in the Port Fowards list, and maybe others, its caused me to pause what I thought would be a relatively painless changeover. Famous last words!

Is the 86U just too new and immature? Starting to regret the purchase despite all the good things I’ve read.

StephenH

 

[RMerlin]

I have a large set of manual DHCP entries, around 60 or so. Once I got to entering around 31-32 the extra host name and change of default icon would not stick for all the following entries past this.

Yes. Same for any list that's too long, like port forwards - the platform has a hard limit of 1000 characters per settings.

Wait for the next release, Asus has moved some of these settings to the jffs partition so they can break the 1000 characters limit. The new limit will be somewhere around 2500 characters I believe. You can alternatively move to Asus's latest stock firmware, which implements the change.

 

[YzRacer]

I use the RT-AC88U on Merlin 382.1_2 and although I don't have a Pixel 2 I do have a Sony XZ Premium on Android Oreo 8.0.0. I have zero issues with the 2.4 GHz or 5 GHz wireless networks. I have 100/40 fibre and get 95/38 3ms consistently. I mainly use the 5 GHz range. I do find you need to fine tune the settings in the Wireless. My settings are below. I also have Wi-Fi analyzer setup on my MacBook Pro so I can see the various channels etc. around me. I don't use much 2.4 GHz as around me it is very crowded but if I do I use 20/40 range and channel 6 works for me. There is often some compatibility issues with various manufacturers chipsets on the access points/routers and the client devices and that can be difficult to solve so that could also be a factor and also drivers.

I would also recommend you do a Factory Reset and re-enter all settings manually if you did not already do that after upgrading from 380 etc. I did this as I had a few minor issues and mainly to do with OpenVPN which this resolved.

Your temps also sound quite high and I expect that if your temps are high for the wireless it will start to cause performance issues. I am in Perth Australia so we have quite high ambients this time of the year as it is summer here so can be inside 24-30 C or so and 30-38 outside. I have air conditioning but also have a laptop cooler under my RT-AC88 which lowers temps a lot. Currently ambient is probably around 23 and CPU = 77, 2.4 GHz = 49 and 5 GHz = 52 - turn on the laptop cooler for about 5 minutes and the temps are then 69, 46 & 50 respectively, after 10 minutes 44, 49, 66. I think you can easily see the factory cooling on this unit is not very good. My long term experience is to keep electronics cool which prolongs their life and also better performance. I bought a cheap eBay cooler for like $15 but it is a little noisy. I do not power it from the router as I think that is not a good idea and I have some of those power boards with USB outlets and use that instead.

http://www.ebay.com.au/itm/OZ-For-L...ith-USB-Hub-/252679936671?hash=item3ad4e5da9f

Thank you for your suggestions on the settings, I will certainly check them out once I get to the point where I feel I can enable 5Ghz again. I'm in a rural area so interference is minimal. As for the temps it's just the CPU, wireless temps are around 48. I haven't seen the CPU above 86 and this morning it's a bit cooler at 78. The placement is a bit high in the room so it stays a little warm up there and I may consider a fan. I have it blocked up so air can move around.

I certainly spoke too soon on a hopeful fix. After 12+ hours without issue the behavior has returned. It seems odd that one device waking from sleep or connecting to the wifi can cripple the whole system. I had already performed a factory reset (using the GUI) and so I may go back to stock today just to narrow down possible causes. I just wish there was something I could monitor to get a clue. The syslog is silent during these events.

Here's another review of the issue:
Consistently happens when I wake my phone or when my phone connects to the wifi
Pings to 192.168.1.1 and google.com drop for 6-20 pings
No client can access the internet
Web GUI does not respond
Nothing is syslog
Pings to other lan clients increase in latency but remain connected

 

[Keenan]

What are normal operating temps?

Mine are:
2.4 GHz - 52 °C
5 GHz - - 55 °C
CPU - 72 °C

 

[Stephen Harrington]

Yes. Same for any list that's too long, like port forwards - the platform has a hard limit of 1000 characters per settings.

Wait for the next release, Asus has moved some of these settings to the jffs partition so they can break the 1000 characters limit. The new limit will be somewhere around 2500 characters I believe. You can alternatively move to Asus's latest stock firmware, which implements the change.

@RMerlin, thanks for confirming, I’ll wait for your next release, can’t bear the thought of going back to Stock ... the AC68U will have to cope a little longer!

StephenH

 

[YzRacer]

I certainly spoke too soon on a hopeful fix. After 12+ hours without issue the behavior has returned. It seems odd that one device waking from sleep or connecting to the wifi can cripple the whole system. I had already performed a factory reset (using the GUI) and so I may go back to stock today just to narrow down possible causes. I just wish there was something I could monitor to get a clue. The syslog is silent during these events.

Here's another review of the issue:
Consistently happens when I wake my phone or when my phone connects to the wifi
Pings to 192.168.1.1 and google.com drop for 6-20 pings
No client can access the internet
Web GUI does not respond
Nothing is syslog
Pings to other lan clients increase in latency but remain connected

And FML. I did a factory reset and the minimal setup and the problem remained so I flashed stock ASUS FW_RT_AC88U_300438218991 and the problem still existed! What I did not do was reboot the phone between flashes. Now that I'm on stock FW I rebooted the phone and the problem went away but I suspect this will be temporary.

 

[XIII]

The only change in 382 is Asus no longer uses resolv.conf, and also have no-resolv in the default config. Make sure you don't add it twice - dnsmasq might generate an error message then.

Where can I see the default config? (What file/path?)

Removing no-resolve from dnsmasq.conf.add (and restarting the dnsmasq service) did not help; the first two DNSleaktest.com runs seemed OK (only expected DNS server responding), but after that the others kicked in as well again.

I see this in the log file:

syslog.log:Dec 14 21:52:40 dnsmasq[7084]: using nameserver 208.67.222.222#53
syslog.log:Dec 14 21:52:40 dnsmasq[7084]: using nameserver 9.9.9.9#53
syslog.log:Dec 14 21:52:40 dnsmasq[7084]: using nameserver 127.0.0.1#65054
syslog.log:Dec 14 21:52:40 dnsmasq[7084]: using nameserver 127.0.0.1#65053

 

[RMerlin]

Where can I see the default config? (What file/path?)

/etc/dnsmasq.conf

Upstream servers are stored in /tmp/resolv.dnsmasq (which is a dnsmsaq config file, not a resolv.conf file, hence the use of the server= setting in that file).

 

[XIII]

# cat /tmp/resolv.dnsmasq
server=9.9.9.9
server=208.67.222.222

However, if I delete those from WAN DNS Settings (Server1 and Server2) DNS is not working at all...

The same configuration was fine on my old AC66U. What am I missing?

 

[saltyzip]

Has anyone else found the wifi no longer working (no longer detectable) after a few hours or days with the 382 branch?, I have had to power cycle my AC3100 twice thus far since updating (rebooting does not resolve it). I will do a factory default when I have time to see if it resolves it.

I've got this issue, but only with 2.4ghz. The 5ghz is working fine, my 2.4ghz gets slower and slower and then after around 10 to 20 minutes nothing will connect to it.

I am not sure if a factory reset will fix it, although I have performed one just now, followed by re importing previous settings. I am hoping this will clear the issue, but early signs aren't good.

I've got a couple of CCTV cameras on 2.4ghz and normally when streaming from home you can see the datetime stamp seconds tick up one after the other, it doesn't jump, however they are jumping already, up to about 5 seconds.

Update: I've given up with 382.1_2, don't have time to re-input all my settings and reissue VPN certs etc. and other people complaining on here about WiFi issue too, so I have gone back to RT-AC88U_380.68_4 and it is running sweet as before.