What's new

Beta Asuswrt-Merlin 386.1 Beta (stage 2) 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!

Status
Not open for further replies.
On the mailing list, Simon was lamenting the risks of implementing security fixes in secret before public disclosure, and the lack of a beta period. I see his point. They're on the right trail now, so it won't be long.
Actually, this was just a bad decision IMHO. My understanding is that the fix causing the problem was a performance enhancement. Shouldn't mix those with a high visibility security update.

EDIT: Additional reading on my part, shows there may be some value for this fix. But given it's implementation, it was a high risk without a pretty good test in multiple environments.
 
Last edited:
That jpg file is not readable.

Use the Insert 'Code' tool to copy the contents of the pdf instead.

Thanks for the idea...

I have the txt file, tried that and still get an "Oops something went wrong" so maybe a link to a Dropbox will work Link to Log file
 
Actually, this was just a bad decision IMHO. My understanding is that the fix causing the problem was a performance enhancement. Shouldn't mix those with a high visibility security update.
I believe it was in response to this vulnerability, but I don't want to pretend I know what I'm really talking about when we get to this level of detail.
CVE-2020-25686: Dnsmasq does not check for an existing pending request for the same name and forwards a new request thus allowing an attacker to perform a "Birthday Attack" scenario to forge replies and potentially poison the DNS cache
 
I believe it was in response to this vulnerability, but I don't want to pretend I know what I'm really talking about when we get to this level of detail.
Me neither....if my understanding is wrong, I stand corrected.
To me the problem fix is related to eliminating work on returned responses, not trying to eliminate invalid responses...

EDIT: I reread the fix and description and I guess I can see some value for preventing a recursive attack. Not sure how you would implement the attack though where it would have a high level of success.
 
Last edited:
I use 6rd on Centurylink and I can not configure it on the current beta 4b. When I enter, "2602::", under IPv6 Prefix, I get a popup saying "2602:: is not a valid IP address!". It worked on every other previous version prior to beta4. Beta4 and 4b are broken as well as the current Asus firmware 41700.
Screenshot from 2021-01-22 15-46-54.pngScreenshot from 2021-01-22 15-45-49.png
 
I use 6rd on Centurylink and I can not configure it on the current beta 4b. When I enter, "2602::", under IPv6 Prefix, I get a popup saying "2602:: is not a valid IP address!". It worked on every other previous version prior to beta4. Beta4 and 4b are broken as well as the current Asus firmware 41700.
View attachment 29760View attachment 29761

That prefix and the prefix length don't seem to match to me.
 
Just had an interesting issue with my AX88u on beta4b. My internet seemed to drop out, and doing a ping to 8.8.8.8 from the router was dropping packets (~75% dropped). after looking around a bit I decided to reboot the router and then the system seemed to be stuck in boot loop, where it would boot, I would have internet for 15 seconds or so, and then the system would reboot.

Crash logs:
May 5 01:05:04 crashlog: 000
May 5 01:05:04 crashlog: <1>Unable to handle kernel NULL pointer dereference at virtual address 0000005c
May 5 01:05:04 crashlog: <1>pgd = ffffffc02c750000
May 5 01:05:04 crashlog: <1>[0000005c] *pgd=000000002c7b9003, *pud=000000002c7b9003, *pmd=000000002c7ae003, *pte=0000000000000000
May 5 01:05:04 crashlog: <0>Internal error: Oops: 96000007 [#1] PREEMPT SMP
May 5 01:05:04 crashlog: <4>CPU: 1 PID: 2109 Comm: mcpd Tainted: P O 4.1.51 #14
May 5 01:05:04 crashlog: <4>Hardware name: Broadcom-v8A (DT)
May 5 01:05:04 crashlog: <4>task: ffffffc02bc72ac0 ti: ffffffc02bd28000 task.ti: ffffffc02bd28000
May 5 01:05:04 crashlog: <4>PC is at fc_mcast_activate_hw.constprop.20+0x60/0x118 [pktflow]
May 5 01:05:04 crashlog: <4>LR is at fc_mcast_activate_hw.constprop.20+0x84/0x118 [pktflow]
May 5 01:05:04 crashlog: <4>pc : [<ffffffbffc3d16a0>] lr : [<ffffffbffc3d16c4>] pstate: a0000145
May 5 01:05:04 crashlog: <4>sp : ffffffc02bd2b850
May 5 01:05:04 crashlog: <4>x29: ffffffc02bd2b850 x28: ffffffc030389000
May 5 01:05:04 crashlog: <4>x27: 00000000fffffffc x26: 0000000000000002
May 5 01:05:04 crashlog: <4>x25: 00000000fbffffef x24: ffffffc0301b8980
May 5 01:05:04 crashlog: <4>x23: 0000000000000000 x22: 00000000ffffffff
May 5 01:05:04 crashlog: <4>x21: ffffffc0301b8980 x20: ffffffc031c0c700
May 5 01:05:04 crashlog: <4>x19: 0000000000000000 x18: 0000000000000000
May 5 01:05:04 crashlog: <4>x17: 0000000000000000 x16: ffffffc0004009d8
May 5 01:05:04 crashlog: <4>x15: 0000000000000000 x14: 0000000000000000
May 5 01:05:04 crashlog: <4>x13: 0000000000000000 x12: 0000000000000001
May 5 01:05:04 crashlog: <4>x11: 0000000000000000 x10: ffffffbffc2c8528
May 5 01:05:04 crashlog: <4>x9 : ffffffc00bd67ec0 x8 : 0000000000000000
May 5 01:05:04 crashlog: <4>x7 : 0000000000067ec0 x6 : ffffffbffc13fd7c
May 5 01:05:04 crashlog: <4>x5 : 0000000000000000 x4 : ffffffc030280c70
May 5 01:05:04 crashlog: <4>x3 : ffffffc030280000 x2 : 0000000000000000
May 5 01:05:04 crashlog: <4>x1 : ffffffbffc3f3040 x0 : 00000000ffffffff
May 5 01:05:04 crashlog: <4>
May 5 01:05:04 crashlog: <0>Process mcpd (pid: 2109, stack limit = 0xffffffc02bd28020)
May 5 01:05:04 crashlog: <4>Modules linked in: ip_set_list_set init_addr( (null) - (null)), core_addr(ffffffbffcaf4000 - ffffffbffcaf55d0)
May 5 01:05:04 crashlog: <4> ip_set_hash_ip init_addr( (null) - (null)), core_addr(ffffffbffcaeb000 - ffffffbffcaeee00)
May 5 01:05:04 crashlog: <4> ip_set_hash_net init_addr( (null) - (null)), core_addr(ffffffbffcae1000 - ffffffbffcae5d18)
May 5 01:05:04 crashlog: <4> xt_set init_addr( (null) - (null)), core_addr(ffffffbffcadb000 - ffffffbffcadc050)
May 5 01:05:04 crashlog: <4> ip_set init_addr( (null) - (null)), core_addr(ffffffbffcacd000 - ffffffbffcad0c38)
May 5 01:05:04 crashlog: <4> tun init_addr( (null) - (null)), core_addr(ffffffbffcac2000 - ffffffbffcac554c)
May 5 01:05:04 crashlog: <4> nf_nat_ftp init_addr( (null) - (null)), core_addr(ffffffbffcabe000 - ffffffbffcabe2c8)
May 5 01:05:04 crashlog: <4> nf_conntrack_ftp init_addr( (null) - (null)), core_addr(ffffffbffcab8000 - ffffffbffcab8c30)
May 5 01:05:04 crashlog: <4> thfsplus(O) init_addr( (null) - (null)), core_addr(ffffffbffca95000 - ffffffbffcaa2494)
May 5 01:05:04 crashlog: <4> tntfs(PO) init_addr( (null) - (null)), core_addr(ffffffbffca08000 - ffffffbffca54488)
May 5 01:05:04 crashlog: <4> tfat(PO) init_addr( (null) - (null)), core_addr(ffffffbffc9b3000 - ffffffbffc9e4368)
May 5 01:05:04 crashlog: <4> sr_mod init_addr( (null) - (null)), core_addr(ffffffbffc9ab000 - ffffffbffc9ad308)
May 5 01:05:04 crashlog: <4> cdrom init_addr( (null) - (null)), core_addr(ffffffbffc99e000 - ffffffbffc9a2cb0)
May 5 01:05:04 crashlog: <4> uas init_addr( (null) - (null)), core_addr(ffffffbffc995000 - ffffffbffc997138)
May 5 01:05:04 crashlog: <4> usb_storage init_addr( (null) - (null)), core_addr(ffffffbffc97c000 - ffffffbffc97fc18)
May 5 01:05:04 crashlog: <4> sg init_addr( (null) - (null)), core_addr(ffffffbffc96f000 - ffffffbffc9734a8)
May 5 01:05:04 crashlog: <4> sd_mod init_addr( (null) - (null)), core_addr(ffffffbffc961000 - ffffffbffc965bd0)
May 5 01:05:04 crashlog: <4> scsi_mod init_addr( (null) - (null)), core_addr(ffffffbffc923000 - ffffffbffc933960)
May 5 01:05:04 crashlog: <4> cdc_mbim init_addr( (null) - (null)), core_addr(ffffffbffc91e000 - ffffffbffc91eb48)
May 5 01:05:04 crashlog: <4> qmi_wwan init_addr( (null) - (null)), core_addr(ffffffbffc913000 - ffffffbffc913728)
May 5 01:05:04 crashlog: <4> cdc_wdm init_addr( (null) - (null)), core_addr(ffffffbffc90c000 - ffffffbffc90d8c8)
May 5 01:05:04 crashlog: <4> cdc_ncm init_addr( (null) - (null)), core_addr(ffffffbffc902000 - ffffffbffc9041e0)
May 5 01:05:04 crashlog: <4> rndis_host init_addr( (null) - (null)), core_addr(ffffffbffc8fc000 - ffffffbffc8fcb10)
May 5 01:05:04 crashlog: <4> cdc_ether init_addr( (null) - (null)), core_addr(ffffffbffc8f6000 - ffffffbffc8f6750)

Managed to get the system up after:
- hard power - still bootloop
- pull USB - hard power - still bootloop
- re-add just enteware ssd USB (not second USB in front), system booted and stays up

Will dig some more, but looking to share.
 
Better crashlog...
May 5 01:05:04 crashlog: <1>Unable to handle kernel NULL pointer dereference at virtual address 0000005c
May 5 01:05:04 crashlog: <1>pgd = ffffffc02d6e7000
May 5 01:05:04 crashlog: <1>[0000005c] *pgd=000000002bf09003, *pud=000000002bf09003, *pmd=000000002bf82003, *pte=0000000000000000
May 5 01:05:04 crashlog: <0>Internal error: Oops: 96000007 [#1] PREEMPT SMP
May 5 01:05:04 crashlog: <4>CPU: 3 PID: 2079 Comm: mcpd Tainted: P O 4.1.51 #14
May 5 01:05:04 crashlog: <4>Hardware name: Broadcom-v8A (DT)
May 5 01:05:04 crashlog: <4>task: ffffffc02fe920c0 ti: ffffffc02d6ec000 task.ti: ffffffc02d6ec000
May 5 01:05:04 crashlog: <4>PC is at fc_mcast_activate_hw.constprop.20+0x60/0x118 [pktflow]
May 5 01:05:04 crashlog: <4>LR is at fc_mcast_activate_hw.constprop.20+0x84/0x118 [pktflow]
May 5 01:05:04 crashlog: <4>pc : [<ffffffbffc3d16a0>] lr : [<ffffffbffc3d16c4>] pstate: a0000145
...
May 5 01:05:04 crashlog: <0>Call trace:
May 5 01:05:04 crashlog: <4>[<ffffffbffc3d16a0>] fc_mcast_activate_hw.constprop.20+0x60/0x118 [pktflow]
May 5 01:05:04 crashlog: <4>[<ffffffbffc3d3114>] fc_config+0x57c/0x988 [pktflow]
May 5 01:05:04 crashlog: <4>[<ffffffc0003fab08>] blog_activate+0x60/0xa8
May 5 01:05:04 crashlog: <4>[<ffffffbffc52d0f4>] bcm_mcast_blog_process+0xa3c/0x1010 [bcmmcast]
May 5 01:05:04 crashlog: <4>[<ffffffbffc529884>] bcm_mcast_igmp_add+0x484/0x6d8 [bcmmcast]
May 5 01:05:04 crashlog: <4>[<ffffffbffc526734>] bcm_mcast_netlink_process_igmp_snoop_entry+0x1b4/0x4a8 [bcmmcast]
May 5 01:05:04 crashlog: <4>[<ffffffbffc5252c8>] bcm_mcast_netlink_rcv_msg+0x30/0x50 [bcmmcast]
May 5 01:05:04 crashlog: <4>[<ffffffc000420e24>] netlink_rcv_skb+0xc4/0xf8
May 5 01:05:04 crashlog: <4>[<ffffffbffc5252f8>] bcm_mcast_netlink_rcv_skb+0x10/0x20 [bcmmcast]
May 5 01:05:04 crashlog: <4>[<ffffffc000420708>] netlink_unicast+0x150/0x228
May 5 01:05:04 crashlog: <4>[<ffffffc000420bd0>] netlink_sendmsg+0x2f0/0x350
May 5 01:05:04 crashlog: <4>[<ffffffc0003bf608>] sock_sendmsg+0x18/0x58
May 5 01:05:04 crashlog: <4>[<ffffffc0003c017c>] ___sys_sendmsg+0x26c/0x280
May 5 01:05:04 crashlog: <4>[<ffffffc0003c2a38>] __sys_sendmsg+0x40/0x80
May 5 01:05:04 crashlog: <4>[<ffffffc0004009e8>] compat_SyS_sendmsg+0x10/0x18
May 5 01:05:04 crashlog: <0>Code: b4000301 f9400e60 b40002c0 12800016 (39417262)
May 5 01:05:04 crashlog: <4>sched: RT throttling activated
May 5 01:05:04 crashlog: <4>---[ end trace e9f7b4be96a7046b ]---
May 5 01:05:04 crashlog: <0>Kernel panic - not syncing: Fatal exception in interrupt
 
Better crashlog...

The crash occured in the daemon that handles multicasting. Check that you don't have something flooding your network with broadcasts or something. Nothing more that can be done about it, that daemon is part of the Broadcom SDK.
 
The crash occured in the daemon that handles multicasting. Check that you don't have something flooding your network with broadcasts or something. Nothing more that can be done about it, that daemon is part of the Broadcom SDK.
So I thought and have been reading online. Found a similar log here (https://www.snbforums.com/attachments/syslog-txt.28070/) but cannot find the original post on the site for it.

But I know when router reboots, the google homes in the house go big time with broadcasts, so likely that. Odd that it doesn't happen if SSD isn't connected after a single crash. Must be a timing issue.

Perhaps I will hobble along until the new GPL build drops.

Edit: same crash can be reproduced with 41700 GPL build. I made it myself just to validate. I guess this in ASUS handles. It seems to be related to my the MDNS traffic on the network.
 
Last edited:
Was reading all about it on GitHub. :)
 
I currently have 384.19 on my routers. Is it still safe to go straight from 384.19 to the 386 beta4?

Or would I be better off waiting for the release of 386 as non beta version?
 
I currently have 384.19 on my routers. Is it still safe to go straight from 384.19 to the 386 beta4?

Or would I be better off waiting for the release of 386 as non beta version?
I upgraded from 384.19 to the beta with no issues. Just backup your current config in case you experience any issues. You can always go back.
 
I currently have 384.19 on my routers. Is it still safe to go straight from 384.19 to the 386 beta4?

Or would I be better off waiting for the release of 386 as non beta version?

I would wait. There is a major security issue that is waiting on a patch to fix. All current firmwares including all the beta have the problem. Wait for Beta 5. Just my 2 cents.
 
I currently have 384.19 on my routers. Is it still safe to go straight from 384.19 to the 386 beta4?

Or would I be better off waiting for the release of 386 as non beta version?
Here's my take on beta software. It's fun to give it a spin and be part of the early crowd, but don't install beta software on a system you're not prepared to do a nuclear reset on and go back to something that worked before. If you can handle that and can take an outage, then fill your boots. Both me and my wife work from home now and our teenage daughter is doing on-line school at home so consistent net access is key or else I'm in the dog house. I'll upgrade a few APs but keep my primary router on a stable platform. FWIW, the 4b Beta has been solid and fine for me so far on my APs. I have not used it on any device in a router mode yet.
 
Status
Not open for further replies.

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