What's new

[Release 384/NG] Asuswrt-Merlin 384.5 is now 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!

I have a question, if the Asus Router BRT-AC828 has the Captive Portal functionality wouldn't it be possible to make that functionality also available for other Asus Routers ?

No. Different firmware code base.
 
I have a minor issue where on occasion when trying to access the GUI in Chrome it never loads and only a power off/power on reboot will restore the page. I don't know that it's specific to 384.5 or even to Merlin's firmware but as I'm running 384.5 I thought I'd ask here. I think it may happen when I leave the page loaded then work on other open browser tabs, then turn the monitor off(desktop computer) and then back on. I think it may be happening then but not always.

Any thoughts would be much appreciated, thanks!
384.5 here on an 86U - I've found if I leave the router page open for a "long" time, it inevitably becomes unresponsive. I figure it's a bug in the httpd version used, I've been thinking about trying the entware lighttpd, but that may be more time than I wish to spend at the moment. If you have ssh set up for your router you don't have to reboot the router, just ssh in and:
Code:
service restart_httpd
will do the trick.
 
384.5 here on an 86U - I've found if I leave the router page open for a "long" time, it inevitably becomes unresponsive. I figure it's a bug in the httpd version used, I've been thinking about trying the entware lighttpd, but that may be more time than I wish to spend at the moment. If you have ssh set up for your router you don't have to reboot the router, just ssh in and:
Code:
service restart_httpd
will do the trick.
I had this problem once but I disabled letsencrypt and reset to defaults and setup manually. There is something about letsencrypt and https access even if its set to not be accessed from the web.
 
Thank you all for such a swift response. I tried all your recommendation and within 45 minutes "SNAFU". What I did do though. Once the router completed its reboot, I rest it again using the rest button on the back (red button), reconfigured it manually (as you do) and for the past two hours, no issues.

So fingers crossed. I'll update tomorrow, unless it occurs again.

Nop. After 8+ hours I'm no longer able to connect to 2.4GHz. Back to scratching my head.
 
The Merlin firmware upgrade link in my signature will show you how to save and restore static DHCP assignments when performing firmware updates, or moving down versions.

Awesome! Thanks for that tip!

I exchanged for a new router and had almost 24 hours solid before another crash so I am stupified at what it could be. I reset the new router to defaults, flashed merlin, initialized to defaults again, and then setup manually. Not sure what else I can do. Hard to believe I got a second router that is bad as well. I did see in the logs there is a time warp that doesn't look normal and happens at the crash. Take a look... NTP server is set to pool.ntp.org.


<12>1 2018-05-20T15:29:50-05:00 192.168.1.1 kernel - - - kernel: ACCEPT IN=br0 OUT=tun11 MAC=2c:fd:a1:a1:e9:8d:e0:c7:67:62:cb:63:08:00 SRC=192.168.1.163 DST=52.51.118.243 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=64986 DPT=80 SEQ=3871193571 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303060101080A42C78CD40000000004020000)
<12>1 2018-05-20T15:29:50-05:00 192.168.1.1 kernel - - - kernel: ACCEPT IN=br0 OUT=tun11 MAC=2c:fd:a1:a1:e9:8d:e0:c7:67:62:cb:63:08:00 SRC=192.168.1.163 DST=52.51.118.243 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=64987 DPT=80 SEQ=3157725699 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303060101080A42C78CD50000000004020000)
<75>1 2018-05-20T15:29:53-05:00 192.168.1.1 crond 796 - - crond[796]: time disparity of 663629 minutes detected
<13>1 2018-02-13T18:00:21-05:00 192.168.1.1 kernel - - - kernel: ubi1: attaching mtd9
<15>1 2018-02-13T18:00:21-05:00 192.168.1.1 NAT_Tunnel - - - NAT_Tunnel: AAE Service is stopped
<15>1 2018-02-13T18:00:21-05:00 192.168.1.1 AAE - - - AAE: AAE Service is started
<13>1 2018-02-13T18:00:21-05:00 192.168.1.1 kernel - - - kernel: ubi1: scanning is finished
 
First & foremost I want to thank RMerlin & John9527 for all their personal time & work devoted to development. RMerlin's your custom f/w's are awesome & rock solid; also grateful for the continual f/w updates. John your NVRAM backup script is the best; turns 2-4 hours into 20 minutes, is migratable & turnkey. Additionally, I want to thank the Moderators, Regular Contributors & everyone else for all their contributions.

My AC87R & f/w 380.67 are both dated but rock solid w/ 3 VPN's w/ strict policy based routing, both 2.4Ghz & 5Ghz stable & fast and very few issues if any. A factory update ver 3.0.0.4.382.50010 was released 2018.1.25 w/ quite a few fixed CVE's, a few new features & bug fixes (but w/o any factory driver updates I think) and Merlin's f/w 384.5 is also now available with updated OpenVPN, Openssl, nano, miniupnpd & Dropbear. I know some of the factory fixes apply to my setup, but don;t use AICloud or remote management, however, I get lost in in the heap overflows, bug collisions, session tokens & such. There also always seems to be limitations imposed significant w/factory updates that inherently effect Merlin updated f/w builds. I read SNB's, Merlin's github & a few other sources frequently & am having a hard time deciding weather to update everything or "don't fix it if it ain't broke." I think I have read myself into a black hole with a side of the paradox the more one learns the less one realizes they know. Argh!

1.) NVRAM now have maximum lengths enforced... means some very long lists of settings might no longer be possible on 384.xx. What's "very long?"
2.) Removed Firewall setting... firewall rules now auto created but "postconf" can override. Does that mean the entire GUI Firewall setting & 5 tabs of sub-settings have been removed or...?
3.) Removed option to respond to DNS queries - enabling the option to Push DNS will also handle it? Does that mean enabling Push DNS will respond to DNS?
4.) I use Gibson Research to regularly scan for a few select vulnerabilities as well as nmap & one other i cant remember off the top of my head. Would that identify if the unfixed CVE's & bug fixes had been exploited?
5.) Added support for the RT-AC87U. :)

Cheers & Thanks
 
I had this problem once but I disabled letsencrypt and reset to defaults and setup manually. There is something about letsencrypt and https access even if its set to not be accessed from the web.
I don't use letsencrypt, but I do have access type set to "both". Not that I ever use https anyways. Right now I'm trying leaving the page open in Microsoft Edge to see if maybe it's some weird Chrome problem.
 
In case it helps anyone else. Looks like the dhcp issue i observed is what is causing the degredation of service on the 2.4ghz wireless network. Not sure why i'm only getting it on the ac88u and only on the 2.4ghz band. I pretty much isolated every device where i noticed the dhcprequest and dhcpack over and over and moved them to other ssid's. I updated the drivers in where they were available. In some instances like an older dell xps all in one i replaced the nic card, but the problem still occured. I'm going to see if I can get a network packet capture of the problem. Moving devices to other ssid and then back to the 2.4ghz ssid on the ac88u didn't make a difference either. Most of the devices are older n wifi adapters, but the one in the logs i attached is a newer intel ac adapter.

Here is what i found, I've moved off almost all of devices from the 2.4ghz ssid that has the issue. So far changing the 2.4 ghz settings doesn't make a difference, but this is the only thing that showed up in the debug logs right before the problem reoccurred right around 22:09 to 22:15 and kernel: br0: received packet on eth1 with own address as source address. Wireless speed on 2.4ghz went to less than 1mb/s. It's also very strange how many dhcp requests and acknowledgements are in the logs. Almost like a layer 2 broadcast storm.

May 18 20:20:33 kernel: nvram: consolidating space!
May 18 20:48:06 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.128 d0:52:a8:35:83:1e
May 18 20:48:06 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.128 d0:52:a8:35:83:1e st-D052A835887A0001
May 18 20:58:20 dnsmasq-dhcp[376]: DHCPDISCOVER(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 20:58:20 dnsmasq-dhcp[376]: DHCPOFFER(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 20:58:20 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 20:58:20 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 20:58:30 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 20:58:30 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 20:59:41 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 20:59:41 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 21:01:02 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 21:01:02 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 21:02:48 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 21:02:48 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 21:04:00 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 21:04:00 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 21:05:43 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 21:05:43 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 21:06:40 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 21:06:40 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 21:06:58 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 21:06:58 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 21:18:42 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 21:18:42 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 21:22:12 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 21:22:12 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 21:46:58 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 21:46:58 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 21:49:46 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 21:49:46 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
.
.
.

May 18 22:19:53 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:19:58 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:19:58 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:20:53 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:20:53 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:21:14 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:21:14 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:23:46 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:23:46 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:24:22 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:24:22 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:24:49 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:24:49 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:25:19 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:25:19 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:25:41 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:25:41 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:26:19 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:26:19 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:26:59 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:26:59 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:27:55 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.167 7c:7a:91:52:96:a3
May 18 22:27:55 dnsmasq-dhcp[376]: DHCPACK(br0) 192.168.1.167 7c:7a:91:52:96:a3 HP1040-LT
May 18 22:29:21 dnsmasq-dhcp[376]: DHCPREQUEST(br0) 192.168.1.200 44:85:00:11:29:02
 
I was seeing the same thing over and over in my ac3100 and my ac88. Not sure what i did that fixed it. I ended up wiping and re-configuring my devices and repeaters completely from scratch multiple times. I have to ask, did you do a full wipe?

So on my RT-AC3100 I am getting flooded in system log with these types of messages
May 19 03:36:24 kernel: device br0 left promiscuous mode
May 19 03:36:25 roamast: eth2: add client [YY:YY:YY:YY:YY:YY] to monitor list
May 19 03:36:48 kernel: br0: port 3(wds0.1) entering forwarding state
May 19 03:36:48 kernel: device wds0.1 left promiscuous mode
May 19 03:36:48 kernel: br0: port 3(wds0.1) entering disabled state
May 19 03:36:49 kernel: EMF_ERROR: Interface wds0.1 doesn't exist
May 19 03:36:49 kernel: Register interface [wds0.3] MAC: XX:XX:XX:XX:XX:XX
May 19 03:36:49 kernel: device wds0.3 entered promiscuous mode
May 19 03:36:49 kernel: br0: port 3(wds0.3) entering forwarding state
May 19 03:36:49 kernel: br0: port 3(wds0.3) entering forwarding state
May 19 03:37:03 crond[405]: time disparity of 661416 minutes detected
May 19 03:37:28 kernel: br0: port 5(wds0.2) entering forwarding state
May 19 03:37:28 kernel: device wds0.2 left promiscuous mode
May 19 03:37:28 kernel: br0: port 5(wds0.2) entering disabled state
May 19 03:37:29 kernel: EMF_ERROR: Interface wds0.2 doesn't exist
May 19 03:37:30 rc_service: rc 1399:notify_rc restart_wrs
May 19 03:39:13 kernel: br0: port 4(wds1.2) entering forwarding state
May 19 03:39:13 kernel: device wds1.2 left promiscuous mode
May 19 03:39:13 kernel: br0: port 4(wds1.2) entering disabled state
May 19 03:39:14 kernel: EMF_ERROR: Interface wds1.2 doesn't exist
May 19 03:40:45 roamast: eth1: add client [WW:WW:WW:WW:WW:WW] to monitor list
May 19 03:41:30 kernel: br0: port 3(wds0.3) entering forwarding state
May 19 03:41:30 kernel: device wds0.3 left promiscuous mode
May 19 03:41:30 kernel: br0: port 3(wds0.3) entering disabled state
May 19 03:41:30 kernel: EMF_ERROR: Interface wds0.3 doesn't exist
 
I'm still getting 2.4GHz issues on my RT-AC3200. Everything works fine initially, then after about 45 minutes to an hour, my devices can no longer connect to the 2.4 GHz Wifi. If I reboot the router I can connect again, but after a while devises start to drop off and can no longer connect. 5Ghz is not an issue. I think it all start from 384.4 but can't say for sure.

Each time I re-flash, I do the obligatory factory reset and manually reconfigure the router.

Any advice?

Can you enable debug logging and see what the logs show around when the time starts? I curios to see if you are having the same dhcp issues i was observing.

systemlog - enable debug logging for default message log and log only messages more urgent than click apply
 
Nop. After 8+ hours I'm no longer able to connect to 2.4GHz. Back to scratching my head.

First & foremost I would make a backups of all settings twice (that's 2 x backups of everything) on different media, regardless, just to be safe. 


What happens when you try and connect on router side and device side? Can you turn on debug &/or check what the standard system log?

1.) If so please locate the within the system log the exact time of failure to connect.
2.) Make mental note of that time or export/copy full log to text editor for convenience, so your can markup and keep a record.
3.) Next located 8 hours before failure to connect in syslog which I am assuming is last reboot, as well.
4.) See if you can spot the issue, anything unusual or a pattern in syslog between last reboot and failure to connect.

You could also try:

1.) Disable beam forming (explicit & universal). Disable airtime fairness.
2.) Manually plush DNS, Internet/Browser, etc cache's on your all devices.
3.) Unplug everything everything modem, router, NAS, & computers & turn off all phones/devices that can't be unplugged. Then unplug yourself (that's what i would do lol) grab a cup of coffee or wait a good 10 min. Everything off &/or unplugged.
4.) Boot up modem & wait until completely booted up; then wait another 60 sec.
5.) Boot up router & wait until completely booted up; then wait another 60 sec.
6.) Turn on only one of the device(s) or device that was unable to connect after 8 hours & wait until completely booted up; then wait another 60 sec.
7.) Logon to router check the wan connection, DHCP, syslog make sure everything is normal. Everything should be ok at this point.
8.) Depending on your networks demand and setup, if you can leave just that one device connected for 8+ hours (overnight maybe) come back and see if still connected.
9.) If so try to connect another device & while monitoring syslog. The culprit hopefully would reveal it's self by know.

Basically, anytime one is trouble shooting one must eliminate as many variables a possible; ideally down to 1 variable. Because it becomes exponentially more difficult to diagnose anything with just 2 or more variables.

NUCLEAR APPROACH: Clear NVRAM a few times, Factory reset, manually reconfigure (do not flash a backup unless using Johns NVRAM backup) or defeats the purpose.

Cheers
 
Installed 384.5 a few days ago,

While it works fine, my AC86-U now reboots by itself every day or so for unknown reason. My uptime with the previous firmware was 20 days +.

I have this constant error showing up in my logs.

Any input on how to fix this ?

Code:
May 21 10:51:39 Mastiff: init
May 21 10:52:16 kernel: pgd = ffffffc011d98000
May 21 10:52:16 kernel: [36223a2e] *pgd=00000000147d3003, *pud=00000000147d3003, *pmd=0000000000000000
May 21 10:52:16 kernel: CPU: 0 PID: 4293 Comm: mastiff Tainted: P           O    4.1.27 #2
May 21 10:52:16 kernel: Hardware name: Broadcom-v8A (DT)
May 21 10:52:16 kernel: task: ffffffc0192b00c0 ti: ffffffc011c98000 task.ti: ffffffc011c98000
May 21 10:52:16 kernel: PC is at 0xf6d6b218
May 21 10:52:16 kernel: LR is at 0x0
May 21 10:52:16 kernel: pc : [<00000000f6d6b218>] lr : [<0000000000000000>] pstate: 60010010
May 21 10:52:16 kernel: sp : 00000000ffc574a0
May 21 10:52:16 kernel: x12: 00000000ffc574c4
May 21 10:52:16 kernel: x11: 00000000f6e387a8 x10: 00000000f6e387d8
May 21 10:52:16 kernel: x9 : 0000000036223a22 x8 : 0000000000000018
May 21 10:52:16 kernel: x7 : 0000000000222820 x6 : 0000000000222808
May 21 10:52:16 kernel: x5 : 0000000000000070 x4 : 0000000000222798
May 21 10:52:16 kernel: x3 : 00000000f6007d22 x2 : 0000000000000131
May 21 10:52:16 kernel: x1 : 0000000000000000 x0 : 0000000000000000
May 21 10:52:40 rc_service: watchdog 854:notify_rc stop_aae
May 21 10:52:40 rc_service: watchdog 854:notify_rc start_mastiff
May 21 10:52:40 rc_service: waitting "stop_aae" via watchdog ...
May 21 10:52:40 NAT_Tunnel: AAE Service is stopped
May 21 10:52:40 NAT_Tunnel: AAE Service is stopped
May 21 10:52:40 NAT_Tunnel: AAE Service is stopped
May 21 10:52:40 AAE: AAE Service is started
May 21 10:52:40 Mastiff: init
May 21 10:53:17 kernel: pgd = ffffffc011c0f000
May 21 10:53:17 kernel: [36223a2e] *pgd=000000001444c003, *pud=000000001444c003, *pmd=0000000000000000
May 21 10:53:17 kernel: CPU: 0 PID: 4351 Comm: mastiff Tainted: P           O    4.1.27 #2
May 21 10:53:17 kernel: Hardware name: Broadcom-v8A (DT)
May 21 10:53:17 kernel: task: ffffffc0170ba180 ti: ffffffc012f8c000 task.ti: ffffffc012f8c000
May 21 10:53:17 kernel: PC is at 0xf7138218
May 21 10:53:17 kernel: LR is at 0x0
May 21 10:53:17 kernel: pc : [<00000000f7138218>] lr : [<0000000000000000>] pstate: 60010010
May 21 10:53:17 kernel: sp : 00000000ff8dcba0
May 21 10:53:17 kernel: x12: 00000000ff8dcbc4
May 21 10:53:17 kernel: x11: 00000000f72057a8 x10: 00000000f72057d8
May 21 10:53:17 kernel: x9 : 0000000036223a22 x8 : 0000000000000010
May 21 10:53:17 kernel: x7 : 000000000030fa68 x6 : 000000000030fa58
May 21 10:53:17 kernel: x5 : 0000000000000070 x4 : 000000000030f9e8
May 21 10:53:17 kernel: x3 : 00000000f7007d22 x2 : 00000000000000e9
May 21 10:53:17 kernel: x1 : 0000000000000000 x0 : 0000000000000000
May 21 10:53:40 rc_service: watchdog 854:notify_rc stop_aae
May 21 10:53:40 rc_service: watchdog 854:notify_rc start_mastiff
May 21 10:53:40 rc_service: waitting "stop_aae" via watchdog ...
May 21 10:53:40 NAT_Tunnel: AAE Service is stopped
May 21 10:53:40 NAT_Tunnel: AAE Service is stopped
May 21 10:53:41 NAT_Tunnel: AAE Service is stopped
May 21 10:53:41 AAE: AAE Service is started
May 21 10:53:41 Mastiff: init
May 21 10:54:17 kernel: pgd = ffffffc012f2b000
May 21 10:54:17 kernel: [36223a2e] *pgd=0000000011e5a003, *pud=0000000011e5a003, *pmd=0000000000000000
May 21 10:54:17 kernel: CPU: 1 PID: 4401 Comm: mastiff Tainted: P           O    4.1.27 #2
May 21 10:54:17 kernel: Hardware name: Broadcom-v8A (DT)
May 21 10:54:17 kernel: task: ffffffc01e022b80 ti: ffffffc011cac000 task.ti: ffffffc011cac000
May 21 10:54:17 kernel: PC is at 0xf6c7e218
May 21 10:54:17 kernel: LR is at 0x0
May 21 10:54:17 kernel: pc : [<00000000f6c7e218>] lr : [<0000000000000000>] pstate: 60010010
May 21 10:54:17 kernel: sp : 00000000ffcd0f10
May 21 10:54:17 kernel: x12: 00000000ffcd0f34
May 21 10:54:17 kernel: x11: 00000000f6d4b7a8 x10: 00000000f6d4b7d8
May 21 10:54:17 kernel: x9 : 0000000036223a22 x8 : 0000000000000018
May 21 10:54:17 kernel: x7 : 000000000017b820 x6 : 000000000017b808
May 21 10:54:17 kernel: x5 : 0000000000000070 x4 : 000000000017b798
May 21 10:54:17 kernel: x3 : 00000000f6007d22 x2 : 0000000000000131
May 21 10:54:17 kernel: x1 : 0000000000000000 x0 : 0000000000000000
May 21 10:54:42 rc_service: watchdog 854:notify_rc stop_aae
May 21 10:54:42 rc_service: watchdog 854:notify_rc start_mastiff
May 21 10:54:42 rc_service: waitting "stop_aae" via watchdog ...
May 21 10:54:42 NAT_Tunnel: AAE Service is stopped
May 21 10:54:42 NAT_Tunnel: AAE Service is stopped
May 21 10:54:43 NAT_Tunnel: AAE Service is stopped
May 21 10:54:43 AAE: AAE Service is started
May 21 10:54:43 Mastiff: init
 
Anyone know what this error is

May 21 14:24:51 odhcp6c[22917]: Failed to send DHCPV6 message to ff02::1:2 (Cannot assign requested address)

Actually nevermind.

When I view the IPv6 log it looks be to down there is no WAN IP address assigned.

Rebooting Cable modem solved this issue.
 
Last edited:
Hi folks!

Just one question: can I flash 384.5 over 380.67 on AC68 or do I have to go to any intermediate version before?

Tks!
 
Note: I don't know if it's a bug or that's how it supposed to look but I think it's a bug.

Hello, I have two routers, one is AC86u ( 384.5_0 ) which is a main router and second is AC68u (384.5_0) which I'm using as Access Point connected to main router via LAN.

The problem is on Access Point router ( AC68u ) the wireless log page under System Log doesn't show proper client's IP addresses and hostnames but only show <unknown> ( Picture below )

The AP router does show proper IP addresses when I check from Network MAP, the <unknown> error only present in Wireless Log page, furthermore if I directly connect the devices to my main router ( AC86u ) the wireless log page on that router shows proper IP addresses and hostnames for the devices so the issue is only on AP router.

I've tried after complete factory reset with Intialize and setting it up from scratch but the issue persists, I've even tried with firmware 384.4_2 and it's behaving same way on that firmware too so it's not 384.5 specific issue.

Any input from someone with a similar setup is highly appreciated.

5dc390c664573eec2170622e6f0e2c8b.png
 
Hi folks!

Just one question: can I flash 384.5 over 380.67 on AC68 or do I have to go to any intermediate version before?

Tks!

You can flash it over 380.67 directly but after that a complete factory reset with Intialize option and setting everything from scratch without using backups is recommended.


Sent from my iPhone using Tapatalk
 
  • Like
Reactions: LHF
Note: I don't know if it's a bug or that's how it supposed to look but I think it's a bug.

Hello, I have two routers, one is AC86u ( 384.5_0 ) which is a main router and second is AC68u (384.5_0) which I'm using as Access Point connected to main router via LAN.

The problem is on Access Point router ( AC68u ) the wireless log page under System Log doesn't show proper client's IP addresses and hostnames but only show <unknown> ( Picture below )

The AP router does show proper IP addresses when I check from Network MAP, the <unknown> error only present in Wireless Log page, furthermore if I directly connect the devices to my main router ( AC86u ) the wireless log page on that router shows proper IP addresses and hostnames for the devices so the issue is only on AP router.

I've tried after complete factory reset with Intialize and setting it up from scratch but the issue persists, I've even tried with firmware 384.4_2 and it's behaving same way on that firmware too so it's not 384.5 specific issue.

Any input from someone with a similar setup is highly appreciated.


5dc390c664573eec2170622e6f0e2c8b.png

I can confirm similar behavior of the Wireless Log on a AC66U setup as AP running 380.70 fw.

If it's supposed to be like that or not, I can't say. But I think it's been like that for quite a while in AP mode.
 
Last edited:
Not a bug, many times discussed ..
Did you try to reconnect the clients?

Done that too many times, and I know about the Network MAP issue and the discussions about it but I'm not talking about that, its for Wireless LOG page.

If you can point me to some discussions regarding Wireless Log page too I'll be grateful.
 

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!

Staff online

Top