What's new

[Beta] Asuswrt-Merlin 384.14 Beta 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.
Wow both Amazon and FedEX out to get you, must have done something they really don't like :)
What can Brown (UPS) do for you? ;):p (silly attempt at a joke...if not funny I blame it on sleep deprivation.)
 
Wow both Amazon and FedEX out to get you, must have done something they really don't like :)

I guess! Incredible. You can't interact with these businesses anymore without getting hit by a DNS-Rebind attack. Crazy!
 
are there plans to include the RT-AC5300 with the new Version 3.0.0.4.384.81219 if a GPL is released?
 
are there plans to include the RT-AC5300 with the new Version 3.0.0.4.384.81219 if a GPL is released?

I can't answer that until I have seen the GPL code. There's no guarantee that the 81219 components will be compatible with the 81116 code used by this release.
 
Good question and, yes, one of us has the iPhone Fedex app. But it's rarely used, so if it's communicating on its own accord, that really bugs me.

I don't think it's a big deal. My spouse uses an iPhone app related to her preferred Gas Station; and sometimes I see "possible DNS rebind attack" related to the domain associated with that gas station company. Mobile apps tend to have background activity.
 
I guess! Incredible. You can't interact with these businesses anymore without getting hit by a DNS-Rebind attack. Crazy!

They're PROBABLY not actually attacking you. It's just some funky way the network stuff was coded so it looks that way.

A few years back, the streaming company PLEX added some features to their media server/app which resulted in dnsmasq throwing DNS-rebind attack warnings too. They had to add a page to their knowledge base telling users how to configure dnsmasq so it would ignore certain Plex-related domains.
 
I setup this Beta after a full reset. worked fine, but today i started having issues with Internet status disconnected messages.
I had DNS over TLS setup pointing to Cloudflare.
After reading through the threads here: https://www.snbforums.com/threads/internet-status-disconnected.59830/
I chose to disable DNS over TLS. Am back online, not sure if this is a Bug or not...

Note: you should do a full reset to factory defaults followed by a minimal and manual configuration, after flashing the firmware you want to use/test. Not before. ;)
 
Note: you should do a full reset to factory defaults followed by a minimal and manual configuration, after flashing the firmware you want to use/test. Not before. ;)
Yes i Followed your nuclear guide. Should have been clearer on it. The Error i see in the router config is : Nov 13 17:13:27 WAN_Connection: ISP's DHCP did not function properly.
 
Hi,

I'm trying to upgrade RT-AX88U_384.13_0 -> RT-AX88U_384.14_beta1, but failed.

First steps with installed 384.13_0:

1. Factory reset
2. Upload 384.14_beta1
3. Factory reset

Result:

cd /jffs & ls -la -> empty jffs folder
cd /jffs && touch 1.txt -> jffs is read-only

That I've been trying:

- Multiply rebooting
- Factory reset
- Uploading 384.14_beta1 again without factory reset

/jffs always empty

Another steps:

1. Upload 384.13_0 -> jffs is good
2. Factory reset -> jffs is good
3. Upload 384.14_beta1 -> jffs is good
4. Rebooting or Factory reset -> jffs is empty

Checkbox in admin webui about Formatting JFSS always unchecked.

If enabled Formatting JFFS on reboot and reboot multiply times -> nothing changed, jffs is empty.

Next steps:

1. Upload 384.13_0 -> jffs is good
2. Factory reset -> jffs is good
3. nvram erase && cd /jffs && rm -fr *
4. Reboot or Factory reset -> jffs is good

So the bug is in 384.14_beta1 version.

P.S> Nothing critical wrong about jffs in dmesg on booting 384.14_beta1
 
Hi,

I'm trying to upgrade RT-AX88U_384.13_0 -> RT-AX88U_384.14_beta1, but failed.

First steps with installed 384.13_0:

1. Factory reset
2. Upload 384.14_beta1
3. Factory reset

Result:

cd /jffs & ls -la -> empty jffs folder
cd /jffs && touch 1.txt -> jffs is read-only

That I've been trying:

- Multiply rebooting
- Factory reset
- Uploading 384.14_beta1 again without factory reset

/jffs always empty

Another steps:

1. Upload 384.13_0 -> jffs is good
2. Factory reset -> jffs is good
3. Upload 384.14_beta1 -> jffs is good
4. Rebooting or Factory reset -> jffs is empty

Checkbox in admin webui about Formatting JFSS always unchecked.

If enabled Formatting JFFS on reboot and reboot multiply times -> nothing changed, jffs is empty.

Next steps:

1. Upload 384.13_0 -> jffs is good
2. Factory reset -> jffs is good
3. nvram erase && cd /jffs && rm -fr *
4. Reboot or Factory reset -> jffs is good

So the bug is in 384.14_beta1 version.

P.S> Nothing critical wrong about jffs in dmesg on booting 384.14_beta1
PromPom,
I have similar experience of empty /jffs and it being Read Only after I factory reset, after flashing 834.14.beta1. My workaround is to flash 384.13, factory reset, configure .... followed by dirty flashing 384.14_beta1. Things seem to work ...

I am still monitoring a strange WiFi issue, the 2.4GHz LED turn OFF for one of my AiMesh Node in about 2-3 days (happened twice already) ... my devices (over WiFi) around this AiMesh node then experience connectivity issue. My workaround is simply power OFF/ON the offending AiMesh Node to resolve the issue. I am using stock firmware for my AiMesh nodes ... I am planning to switch to Merlin's FM for my AiMesh Node the next time it happen again.
 
PromPom,
I have similar experience of empty /jffs and it being Read Only after I factory reset, after flashing 834.14.beta1. My workaround is to flash 384.13, factory reset, configure .... followed by dirty flashing 384.14_beta1. Things seem to work ...

I am still monitoring a strange WiFi issue, the 2.4GHz LED turn OFF for one of my AiMesh Node in about 2-3 days (happened twice already) ... my devices (over WiFi) around this AiMesh node then experience connectivity issue. My workaround is simply power OFF/ON the offending AiMesh Node to resolve the issue. I am using stock firmware for my AiMesh nodes ... I am planning to switch to Merlin's FM for my AiMesh Node the next time it happen again.

Had something similar. Updated my router from A2 to B1. Node completly lost all connection. Had to update node to B1 via cable and then reset it to be able to reconnect to router.
 
Last edited:
I don't think it's a big deal. My spouse uses an iPhone app related to her preferred Gas Station; and sometimes I see "possible DNS rebind attack" related to the domain associated with that gas station company. Mobile apps tend to have background activity.
any chance that's Esso, and the Extra app rather than SpeedPass (which I don't use)?
 
For any reason it seems that Apple AirPlay is broken in this release (RT-AC86U). Reverted to 384.13 and it's working fine.
 
I have RT-AC68U I updated from 13 to 14_beta1. About every 15-30 minutes the router becomes unresponsive. Requiring me to reboot/power-off the router. I have downgraded to 13 again. So far, everything looks good. Is anyone else seeing this? Thanks,
 
I am also having issues where the internet is dropping randomly (AiMesh setup) on the Main (which has been reported a few times here already) which is running this Beta. A check of the log shows nothing. I have tried a refresh/initialize/manually config install again, but the problem appears again with no indication of any errors again in the log. Have switched back to 384.13 which was rock solid, other than the occasional reboot hang problem, (known) with the 86U.
 
I'm not using the WiFi on the Asus Router. I'm using the just the router function, DHCP, Cache DNS (DoT) and NTP Service. I have a security device in front of the Asus and Unifi behind it serving up WiFi. I have stripped down as far as I want it to go.
 
I have RT-AC68U I updated from 13 to 14_beta1. About every 15-30 minutes the router becomes unresponsive. Requiring me to reboot/power-off the router. I have downgraded to 13 again. So far, everything looks good. Is anyone else seeing this? Thanks,
I would consider flashing the Beta 1 again and RTFD after. Start from scratch, eliminate the possibilities.
 
On VPN (PPTP) the option for edit users and passwords don't work. The subform is changed with subform for IP and netmask.
upload_2019-11-15_1-25-56.png
 
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