[Release] Asuswrt-Merlin 384.7 is now available

[loveleeyoungae]

Might be a security measure taken by the miniupnpd author to reject UPNP forwards where the WAN side of thing is a LAN IP. I don't know.

@RMerlin: I think I should say sorry for wasting our time as I hadn't really performed the tests carefully. So yesterday I decided to perform the tests more thoroughly, this time wrote out every step. (The tests made me exhausted which in turn made me realize how much effort and time you put into the firmware, really appreciate that!). I found things that are 100% reproducible, I think they may be useful and worth mentioning, so please bear with me and suggest more troubleshooting steps if possible.

I tested using:
- an AC68U
- firmwares: 384.5, 384.6, 384.7
- an IP Camera (limited test as it was being used in the house)
- a laptop running Plex and Emby (installed them for testing, so no configuring or setups, just defaults)

To be clear, these are steps I did to ensure a successful factory-reset (flash) of any firmware:
1. Ssh'ed into the router to erase nvram (and write firmware):
admin@RT-AC68U-11C8:/tmp/home/root# mtd-erase2 nvram
admin@RT-AC68U-11C8:/tmp/home/root# nvram erase
(admin@RT-AC68U-11C8:/tmp/home/root# ls
RT-AC68U_384.5_0.trx
admin@RT-AC68U-11C8:/tmp/home/root# mtd-write2 RT-AC68U_384.5_0.trx linux
linux: CRC OK)
admin@RT-AC68U-11C8:/tmp/home/root# mtd-erase2 nvram
admin@RT-AC68U-11C8:/tmp/home/root# nvram erase
2. Turned off the router at this step for 5 seconds.
3. Hold the WPS button and turned on the router. Released it when the power led started blinking.
4. Waited for the router boot up to access welcome page: set Router mode, automatic IP, change SSIDs names & passwords, changed admin password.

A. When the router was offline (i.e. no cable plugged into WAN port, no WAN IP)
On all tested firmwares:
- Right after setting things on welcome page and logging in the webgui, checked the system log and saw no sign of miniupnpd.
- Changed something on the Administrator - System page (I usually enabled jffs and ssh, but during the tests, I found out changing auto-logout time was enough)
- That was when log for miniupnpd showed up, stating the service started running!
- Connect the laptop to the router, log showed miniupnpd worked properly. (Well, as the router was offline, that might not be considered "worked" - but iptables rules were created, the System Log - Port Forwarding page also listed the uPnP forwards nicely). You can see the screenshot I took on 384.7 below.

B. When the router was online (got WAN IP 192.168.5.237 from ISP modem)
B.1. On all tested firmwares:
- Right after settings things on welcome page, checked the system log and saw log show up for miniupnpd (note: different from offline mode)
B.2. On each firmware:
- 384.5: IPCamera, Plex, Emby always worked
- 384.6: Only IPCamera needed to be restarted before it would work. Everything else was fine. -> that was why I thought the issue started from 384.6 but indeed it was not. Big mistake on me, sorry!
- 384.7: uPnP didn't work. System log didn't show any lines related to the IPCamera & Emby server, only for Plex server was "Failed to add NAT-PMP..."

So, unless 384.7 requires an actual external WAN IP for miniupnpd to work, I wonder if there was still some conflicts here. Hope you can suggest some things else I can try to make it work.

 

[Jack Yaz]

@RMerlin: I think I should say sorry for wasting our time as I hadn't really performed the tests carefully. So yesterday I decided to perform the tests more thoroughly, this time wrote out every step. (The tests made me exhausted which in turn made me realize how much effort and time you put into the firmware, really appreciate that!). I found things that are 100% reproducible, I think they may be useful and worth mentioning, so please bear with me and suggest more troubleshooting steps if possible.

I tested using:
- an AC68U
- firmwares: 384.5, 384.6, 384.7
- an IP Camera (limited test as it was being used in the house)
- a laptop running Plex and Emby (installed them for testing, so no configuring or setups, just defaults)

To be clear, these are steps I did to ensure a successful factory-reset (flash) of any firmware:
1. Ssh'ed into the router to erase nvram (and write firmware):
admin@RT-AC68U-11C8:/tmp/home/root# mtd-erase2 nvram
admin@RT-AC68U-11C8:/tmp/home/root# nvram erase
(admin@RT-AC68U-11C8:/tmp/home/root# ls
RT-AC68U_384.5_0.trx
admin@RT-AC68U-11C8:/tmp/home/root# mtd-write2 RT-AC68U_384.5_0.trx linux
linux: CRC OK)
admin@RT-AC68U-11C8:/tmp/home/root# mtd-erase2 nvram
admin@RT-AC68U-11C8:/tmp/home/root# nvram erase
2. Turned off the router at this step for 5 seconds.
3. Hold the WPS button and turned on the router. Released it when the power led started blinking.
4. Waited for the router boot up to access welcome page: set Router mode, automatic IP, change SSIDs names & passwords, changed admin password.

A. When the router was offline (i.e. no cable plugged into WAN port, no WAN IP)
On all tested firmwares:
- Right after setting things on welcome page and logging in the webgui, checked the system log and saw no sign of miniupnpd.
- Changed something on the Administrator - System page (I usually enabled jffs and ssh, but during the tests, I found out changing auto-logout time was enough)
- That was when log for miniupnpd showed up, stating the service started running!
- Connect the laptop to the router, log showed miniupnpd worked properly. (Well, as the router was offline, that might not be considered "worked" - but iptables rules were created, the System Log - Port Forwarding page also listed the uPnP forwards nicely). You can see the screenshot I took on 384.7 below.

B. When the router was online (got WAN IP 192.168.5.237 from ISP modem)
B.1. On all tested firmwares:
- Right after settings things on welcome page, checked the system log and saw log show up for miniupnpd (note: different from offline mode)
B.2. On each firmware:
- 384.5: IPCamera, Plex, Emby always worked
- 384.6: Only IPCamera needed to be restarted before it would work. Everything else was fine. -> that was why I thought the issue started from 384.6 but indeed it was not. Big mistake on me, sorry!
- 384.7: uPnP didn't work. System log didn't show any lines related to the IPCamera & Emby server, only for Plex server was "Failed to add NAT-PMP..."

So, unless 384.7 requires an actual external WAN IP for miniupnpd to work, I wonder if there was still some conflicts here. Hope you can suggest some things else I can try to make it work.

Would this happen to be a converted T-Mobile by any chance?

 

[Vexira]

Would this happen to be a converted T-Mobile by any chance?

I've had upnp be sketchy on my 88u, usually on Alpha firmware.

 

[Jack Yaz]

I've had upnp be sketchy on my 88u, usually on Alpha firmware.

It was the mtd-write2 process that sent up a red flag for me. I could be wrong of course.

 

[Vexira]

It was the mtd-write2 process that sent up a red flag for me. I could be wrong of course.

Im still trying to determine why sometimes upnp is flaky at time is in some times a forward works some times it doesn't, I guess it's my PC and Xbox lol.

 

[Jack Yaz]

Im still trying to determine why sometimes upnp is flaky at time is in some times a forward works some times it doesn't, I guess it's my PC and Xbox lol.

Is that an issue new to your environment in this release?

 

[loveleeyoungae]

It was the mtd-write2 process that sent up a red flag for me. I could be wrong of course.

No. Don't those TM converted ones use mtd-write and wasn't mtd-write2 on AC68U since forever? IIRC, Merlin himself said mtd-write was for older type routers (I got N66U) and mtd-write2 was for newer routers.

 

[Jack Yaz]

No. Don't those TM converted ones use mtd-write and isn't mtd-write2 was on AC68U since forever? IIRC, Merlin himself said mtd-write was for N66U (which I also got) and mtd-write2 was for newer routers.

Fair enough. Most people use the GUI so seeing a CLI install is unusual. Just doing my due diligence

While it doesn't solve the problem you could manually port forward for now.

 

[loveleeyoungae]

Fair enough. Most people use the GUI so seeing a CLI install is unusual. Just doing my due diligence

While it doesn't solve the problem you could manually port forward for now.

Yeah, I saw many posts mentioning about troubles using the GUI, I myself got troubles several times too. So I turned to the CLI method, especially for the tests to be 100% reproducible.

 

[Vexira]

Is that an issue new to your environment in this release?

Not quite, I might just mean I need to factory reset, which I haven't for a while.

 

[AntonK]

The version I mentionned is right on their support page.

That is deeply weird. The image attached to this post is from here: https://www.asus.com/us/Networking/RTAC3200/HelpDesk_Download/

 

[Grisu]

jpg

What do you want to tell with your picture?
I got different one ... dont know why everything is black on black today without highlightning you would see only a black box!
Never had this before, they're running completely crazy?!?

 

[AntonK]

What do you want to tell with your picture?
I got different one ... dont know why everything is black on black today without highlightning you would see only a black box!
Never had this before, they're running completely crazy?!?

View attachment 14818

I was just trying to show RMerlin the page where I see the age of the latest GPL release, which says 2016, not the 2018 he sees. Nothing too important, just weird. And yes, I'm seeing Asus's black "halloween" pages today too

 

[DonnyJohnny]

What do you want to tell with your picture?
I got different one ... dont know why everything is black on black today without highlightning you would see only a black box!
Never had this before, they're running completely crazy?!?

View attachment 14818

Lol. Black Thursday!

 

[Grisu]

Lol. Black Thursday!

Thursday got same brightness like all others here , you shouldn't

I was just trying to show RMerlin the page where I see the age of the latest GPL release, which says 2016, not the 2018 he sees. Nothing too important, just weird. And yes, I'm seeing Asus's black "halloween" pages today too

I see, you're choosing Win10, I use "others" and see last GPL.

 

[Ditch]

Hi guys,

@RMerlin Any idea why /tmp/bwdpi/qosd.conf is missing in my router?
grep qosd doesn't output anything

admin@DSL-AC68U-C848:/tmp/home/root# sh /jffs/scripts/FreshJR_QOS -debug

cat: can't open '/tmp/bwdpi/qosd.conf': No such file or directory

 

[AntonK]

Thursday got same brightness like all others here , you shouldn't


I see, you're choosing Win10, I use "others" and see last GPL.

Ah! Yes, thanks.

Anton

 

[GC70]

Hi & THANKS to everybody! I need help!

My Synology NAS DS718+, worked properly on my RT-AC87U under the 380.69_2 firmware and stopped to communicate on the network just after the directly upgrade to the 384.7, made after scratch to factory values and several reboots, manually applying the old configuration, new WiFi SSIDs and the DHCP entries....

I'm experiencing this issue either connecting it in bond aggregate (L1 to LAN1 & L2 to LAN2), as in the original previously untouched configuration running on nas, then when i tried to change using the single L1 or L2 link to AC87.
Sometimes I can configure L1 or L2, through Synology Assistant, using a direct cable connection from the win10 pc, always with static IP, and sometimes I can recover it with the DSM Web interface and play with it , but at the next reboot it doesn't communicate anymore, doesn't respond to ping, even if in the client list inside the asus router web interface still there!

Other strange issue, the scheduled reboot doesn't work...

Didn't tested other so far...

Where I am wrong?

 

[RMerlin]

Hi guys,

@RMerlin Any idea why /tmp/bwdpi/qosd.conf is missing in my router?
grep qosd doesn't output anything

No idea, I don't support the DSL-AC68U for starter.

 

[blueshark]

@RMerlin, any advantage to enable nat acceleration when using vpn client