What's new

[384.8_Alpha - builds] Testing all variants.

  • 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 can try that later this week
Try this.
Turn off air protection with use a lot of memory, reboot, then have this comment before you flash.
sync; echo 1 > /proc/sys/vm/drop_caches

Another thing I experience, use wired LAN to access via http instead of https when flashing firmware.
 
Just got a reboot from my 86U router. Latest alpha 3 build.

May 5 01:05:10 kernel: usb3 reseting..........
May 5 01:05:10 kernel: jffs2: notice: (1) check_node_data: wrong data CRC in data node at 0x02d077ac: read 0x7d46eb7c, calculated 0x91a9fef4.
May 5 01:05:10 kernel: _ Reboot message ... _______________________________________________________
May 5 01:05:10 kernel: Unable to handle kernel paging request at virtual address 30303078302c3870pgd = ffffffc014a06000[30303078302c3870] *pgd=0000000000000000, *pud=0000000000000000Internal error: Oops: 96000004 [#1] PREEMPT SMPModules linked in: ip_set_list_set init_addr( (null) - (null)), core_addr(ffffffbffc150000 - ffffffbffc151600) ip_set_hash_ip init_addr( (null) - (null)), core_addr(ffffffbffc30b000 - ffffffbffc30ee10) ip_set_hash_net init_addr( (
May 5 01:05:10 kernel: (null)), core_addr(ffffffbffc9aa000 - ffffffbffc9f68b0) tfat(PO) init_addr( (null) - (null)), core_addr(ffffffbffc954000 - ffffffbffc983f78) usb_storage init_addr( (null) - (null)), core_addr(ffffffbffc93d000 - ffffffbffc9409c8) sg init_addr( (null) - (null)), core_addr(ffffffbffc930000 - ffffffbffc934448) sd_mod init_addr( (null) - (null)), core_addr(ffffffbffc922000 - ffffffbffc926b78) scsi_m
May 5 01:05:11 kernel: ____________________________________________________________________________
May 5 01:05:12 nat: apply redirect rules
 
just got this 68u alpha 3 ... media bridge mode. why is that happening? also had it some times before.

Nov 15 11:13:05 kernel: Interface wl1.1 doesn't exist
Nov 15 11:13:05 kernel: Interface wl1.2 doesn't exist
Nov 15 11:13:05 kernel: Interface wl1.3 doesn't exist
Nov 15 11:13:05 kernel: Interface wl1.2 doesn't exist
Nov 15 11:13:06 rc_service: psta_monitor 268:notify_rc restart_wlcmode 0
Nov 15 11:13:06 FTP_Server: daemon is stopped
Nov 15 11:13:06 Samba_Server: smb daemon is stopped
Nov 15 11:13:06 kernel: gro disabled
Nov 15 11:13:07 avahi-daemon[280]: Interface br0.IPv4 no longer relevant for mDNS.
Nov 15 11:13:07 avahi-daemon[280]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.0.212.
Nov 15 11:13:07 avahi-daemon[280]: Withdrawing address record for 192.168.0.212 on br0.
Nov 15 11:13:07 kernel: br0: port 3(eth2) entering forwarding state
Nov 15 11:13:07 kernel: br0: port 2(eth1) entering forwarding state
Nov 15 11:13:07 kernel: br0: port 1(vlan1) entering forwarding state
Nov 15 11:13:15 avahi-daemon[280]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.0.212.
Nov 15 11:13:15 avahi-daemon[280]: New relevant interface br0.IPv4 for mDNS.
Nov 15 11:13:15 avahi-daemon[280]: Registering new address record for 192.168.0.212 on br0.IPv4.
Nov 15 11:13:15 avahi-daemon[280]: Withdrawing address record for 192.168.0.212 on br0.
Nov 15 11:13:15 avahi-daemon[280]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.0.212.
Nov 15 11:13:15 avahi-daemon[280]: Interface br0.IPv4 no longer relevant for mDNS.
Nov 15 11:13:15 avahi-daemon[280]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Nov 15 11:13:15 avahi-daemon[280]: New relevant interface br0.IPv4 for mDNS.
Nov 15 11:13:15 avahi-daemon[280]: Registering new address record for 192.168.1.1 on br0.IPv4.
Nov 15 11:13:15 kernel: br0: port 3(eth2) entering forwarding state
Nov 15 11:13:15 kernel: br0: port 3(eth2) entering forwarding state
Nov 15 11:13:15 kernel: br0: port 2(eth1) entering forwarding state
Nov 15 11:13:15 kernel: br0: port 2(eth1) entering forwarding state
Nov 15 11:13:15 kernel: br0: port 1(vlan1) entering forwarding state
Nov 15 11:13:15 kernel: br0: port 1(vlan1) entering forwarding state
Nov 15 11:13:15 RT-AC68U: start httpd:80
Nov 15 11:13:29 rc_service: psta_monitor 268:notify_rc restart_wlcmode 1
Nov 15 11:13:29 FTP_Server: daemon is stopped
Nov 15 11:13:30 Samba_Server: smb daemon is stopped
Nov 15 11:13:30 kernel: gro disabled
Nov 15 11:13:30 avahi-daemon[280]: Interface br0.IPv4 no longer relevant for mDNS.
Nov 15 11:13:30 avahi-daemon[280]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Nov 15 11:13:30 avahi-daemon[280]: Withdrawing address record for 192.168.1.1 on br0.
Nov 15 11:13:30 kernel: br0: port 3(eth2) entering forwarding state
Nov 15 11:13:30 kernel: br0: port 2(eth1) entering forwarding state
Nov 15 11:13:30 kernel: br0: port 1(vlan1) entering forwarding state
Nov 15 11:13:38 avahi-daemon[280]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Nov 15 11:13:38 avahi-daemon[280]: New relevant interface br0.IPv4 for mDNS.
Nov 15 11:13:38 avahi-daemon[280]: Registering new address record for 192.168.1.1 on br0.IPv4.
Nov 15 11:13:38 kernel: br0: port 3(eth2) entering forwarding state
Nov 15 11:13:38 kernel: br0: port 3(eth2) entering forwarding state
Nov 15 11:13:38 kernel: br0: port 2(eth1) entering forwarding state
Nov 15 11:13:38 kernel: br0: port 2(eth1) entering forwarding state
Nov 15 11:13:38 kernel: br0: port 1(vlan1) entering forwarding state
Nov 15 11:13:38 kernel: br0: port 1(vlan1) entering forwarding state
Nov 15 11:13:38 RT-AC68U: start httpd:80
Nov 15 11:13:42 kernel: Interface wl1.3 doesn't exist
Nov 15 11:13:44 rc_service: udhcpc_lan 2623:notify_rc stop_httpd
Nov 15 11:13:44 rc_service: udhcpc_lan 2623:notify_rc start_httpd
Nov 15 11:13:44 rc_service: waitting "stop_httpd" via udhcpc_lan ...
Nov 15 11:13:45 RT-AC68U: start httpd:80
Nov 15 11:13:45 avahi-daemon[280]: Withdrawing address record for 192.168.1.1 on br0.
Nov 15 11:13:45 avahi-daemon[280]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.1.
Nov 15 11:13:45 avahi-daemon[280]: Interface br0.IPv4 no longer relevant for mDNS.
Nov 15 11:13:45 avahi-daemon[280]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.0.212.
Nov 15 11:13:45 avahi-daemon[280]: New relevant interface br0.IPv4 for mDNS.
Nov 15 11:13:45 avahi-daemon[280]: Registering new address record for 192.168.0.212 on br0.IPv4.
Nov 15 11:13:45 rc_service: udhcpc_lan 2623:notify_rc start_dnsmasq
Nov 15 11:13:45 rc_service: waitting "start_httpd" via udhcpc_lan ...
 
This latest a3 build seems to have issues with my wife's and my iPhone. Keeps signing on to wifi and signing off monitor list.

Nov 15 09:10:47 roamast: eth5: add client [ac:1f:74:18:d7:b0] to monitor list
Nov 15 09:11:27 roamast: eth6: add client [ac:1f:74:18:d7:b0] to monitor list
Nov 15 09:17:37 roamast: eth5: add client [ac:1f:74:18:d7:b0] to monitor list
Nov 15 09:18:27 roamast: eth6: add client [ac:1f:74:18:d7:b0] to monitor list
Nov 15 09:23:02 roamast: eth5: add client [ac:1f:74:18:d7:b0] to monitor list

It seems somebody mentioned iOS issues recently? Is this a problem and should I be concerned?

Is roamast part of AiMesh? Merlin does not use AiMesh so this is not an issue?
 
Last edited:
Just a newbie with this stuff. With @skeal helping, I set up Cloudflare in my router and rebind protection. I’ve seen this pop up in the my logs periodically. Anything to worry about? On Alpha 3.

Nov 15 12:41:27 dnsmasq[1293]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Nov 15 12:42:40 dnsmasq[1293]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

Thank you!
 
Just a newbie with this stuff. With @skeal helping, I set up Cloudflare in my router and rebind protection. I’ve seen this pop up in the my logs periodically. Anything to worry about? On Alpha 3.

Nov 15 12:41:27 dnsmasq[1293]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Nov 15 12:42:40 dnsmasq[1293]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

Thank you!


https://www.snbforums.com/threads/what-is-the-best-way-to-configure-dns.49883/#post-443718
 
Thank you, @Treadler. I have all those settings like you, except I haven’t done anything with DNS Filter.

After Cloudflare log messages, I tried Quad9 and suffered a DHCP not functioning error in log. Even though status showed it was disconnected, I was still connected?

I then re-entered Cloudfare servers and this time rebooted the router. It’s been almost 2 hours and no errors. I didn’t reboot after I made the initial changes, so maybe this contributed to the issue? I’m not sure, but everything is running fine now. I’ll update if something shows up in the log again.
 
Just an update for RMerlin - the Alpha3 build for the AC-86U is the best firmware I have used to date for my router - thank you!
 
Nov 15 12:41:27 dnsmasq[1293]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Nov 15 12:42:40 dnsmasq[1293]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

Thank you!
Just to update. This message showed up again I’m my log, while using Cloudflare. After doing some research, this message seems to be an issue with Cloudflare and changes to DNSSEC to make it more secure.
 
Uptime - 4 days 1 hours 42 minute(s) 30 seconds for alpha 3, no issues so far, still a dirty upgrade from alpha 2, and NOT requiring a cold reboot yet.
 
Same for me, 4 days 0 hours 6 minutes on a dirty upgrade and it’s running very well.
It’s been running really great here as well. My uptime was over 3 days, before rebooting to turn on DNSSEC. My internet speeds have been solid too.
 
This latest a3 build seems to have issues with my wife's and my iPhone. Keeps signing on to wifi and signing off monitor list.

Nov 15 09:10:47 roamast: eth5: add client [ac:1f:74:18:d7:b0] to monitor list
Nov 15 09:11:27 roamast: eth6: add client [ac:1f:74:18:d7:b0] to monitor list
Nov 15 09:17:37 roamast: eth5: add client [ac:1f:74:18:d7:b0] to monitor list
Nov 15 09:18:27 roamast: eth6: add client [ac:1f:74:18:d7:b0] to monitor list
Nov 15 09:23:02 roamast: eth5: add client [ac:1f:74:18:d7:b0] to monitor list

It seems somebody mentioned iOS issues recently? Is this a problem and should I be concerned?

Is roamast part of AiMesh? Merlin does not use AiMesh so this is not an issue?

My RT-AC86U is running solid with a3. Three days uptime.
 
Try this.
Turn off air protection with use a lot of memory, reboot, then have this comment before you flash.
sync; echo 1 > /proc/sys/vm/drop_caches

Another thing I experience, use wired LAN to access via http instead of https when flashing firmware.


the beta that came out today flashed just fine for me. all good to go
 
You have posted in alpha build thread..... :confused:
I know if you look up a few posts I wasnt able to i stall alpha 3. I quoted someone helping me get it installed. The update was the new beta works for me. You wouldnt be confused if you read the previous responses.
 
I know if you look up a few posts I wasnt able to i stall alpha 3. I quoted someone helping me get it installed. The update was the new beta works for me. You wouldnt be confused if you read the previous responses.
Okej, post 297 on page 14 is not a few post up. But okej.
 

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