Asuswrt-Merlin 384.8 is now available

[oso2276]

[QUOTE = "DOspital, post: 448419, miembro: 58763"] Intenté una actualización de mi RT-AC68U de 384.5 a 384.8 y mi enrutador se restableció a la fábrica y, después de reiniciar, se mantuvo en la versión 384.5. Sin leer ninguna documentación, pensé que tal vez se trataba de una actualización progresiva, luego probé la actualización 384.7_2 y sucedió lo mismo. No estoy preocupado, solo es extraño ya que este es un comportamiento que nunca he tenido antes desde este enrutador. [/ QUOTE]

El mismo problema que tengo, funciona sin problemas, pero solo estoy en 384.5 sin poder actualizar a la próxima versión.

Si el router es un T-Mobile TM-AC1900, ya no se puede actualizar a las nuevas versiones. Asus agregó código de validación que previene la actualización

Transalation:
If the router is a T-Mobile TM-AC1900, it will no longer accept newer version of the firmware. Asus added logic that will prevent the update.

Enviado desde mi Moto Z2 Play mediante Tapatalk

 

[unsynaps]

Known problem with fix for next release....
https://www.snbforums.com/threads/asuswrt-merlin-384-8-is-now-available.50189/page-9#post-447744

ICK.

Oh well back to USB booting for a little while.

 

[rassi]

Update from 384.5 to .8 port forwards lost and when trying to set the, again -> no success. I was not able to set port forwards with the latest, Back to the 384.5 and all good.

 

[RMerlin]

Asuswrt-Merlin 384.8_2 has been released. Changedlog:

384.8_2 (8-Dec-2018)
  - CHANGED: Updated miniupnpd to 20181205.
  - CHANGED: Push LAN domain to OpenVPN clients as DNS suffix
             for the connection.
  - FIXED: Cannot save custom settings on OpenVPN server page
           on non-HND models.
  - FIXED: Some webui pages fail to load properly in French
  - FIXED: dnsmasq fails to start when certain options are
           configured (themiron)
  - FIXED: Non-functionnal Show Password option on OpenVPN/PPTP
           server page for RT-AX88U (removed)
  - FIXED: Persistent SSL cert was wiped at boot time in
           some specific scenarios.

 

[bandit8623]

384.8 was up for a week. today i cant get to login page just hangs. i will reboot here and update to the latest now. just wanted to report that.

 

[scjr]

Smooth upgrade here to 384.8_2. Thank you, Eric!

 

[kck]

Noticed this change:
- CHANGED: Push LAN domain to OpenVPN clients as DNS suffix for the connection.

Can anyone tell me the import of this. I currently run 2 AC88U routers that run a "permanent" VPN between our 2 houses, with appropriate config adds to dnsmasq at each end to allow cross network DNS naming of nodes on the two separate LANs. Just want to make sure that this change won't impact how that works.

Thanks.
(and as a first post here a big thanks to Eric for the great effort in doing all this, sometimes in the face of some rather "entitled" sounding posts)

 

[loveleeyoungae]

Noticed miniupnpd in the changelog. Did the dev got another fix for double NAT environment?

 

[consorts]

ac3100 dirty update from 384.8 to 384.8_2 seems to be smooth

no obvious issues, only yellow ! keeps flashing

 

[FauDrei]

Strange... I got this:



...anyone else with this problem?

 

[Gar]

ac3100 dirty update from 384.8 to 384.8_2 seems to be smooth

no obvious issues, only yellow ! keeps flashing

same

Thanks for this update RMerlin! As always.

 

[DroidST]

Experienced an issue on 2.4GHz this morning. I have a temperature monitoring system with 4 sensors for our Coach which is parked next to our house (need to keep an eye when <freezing temps outside). It connects whenever a sensor reports a change (minimum one minute between) or approx every 3-5 minutes (if no change reported by the sensor) on the 2.4GHz band, then it disconnects. I use an app on my Samsung S7 for status and getting alerts. This is how I noticed the issue so quickly, around 9:20am.

Around 9am this morning I saw an update (there have been regular updates 24/7 since updating the 86U to the initial Beta2 and putting it into service) but after that, there were no updates. I had to leave for errands (4-5 hours). When I got back home, I tried to connect to the 2.4GHz band on my S7. It would not connect. I tried 2 laptops at 2.4GHz, could not connect. These clients normally connect on 5GHz and any other client that supports that band.

I copied the General Log and saved it. Didn't see anything special though unfortunately I have 'more urgent than debug selected currently'.

It seemed a wifi laser printer was connected on 2.4GHz still according to the wireless log but I didn't test it.

I power cycled the 86U and all back to normal.

The only change I made yesterday afternoon was to change QOS Type to fq_codel (from sfq) and then I rebooted the router.

I'll keep an eye one this, if it happens again, I'll set General Log to All though I am not sure that will help.

Happened again today around noonish. some 2.4GHz clients including my Samsung Galaxy S7's can't connect to 2.4GHz. A 68U setup as Repeater is connected to the 2.4GHz still and a printer.

Not much in the log except at around that point I get a lot of these entries (though this occasionally shows up before in the log):

Dec  8 13:05:59 kernel: br0: port 5(eth5) neighbor 8000.00:xx:xx:xx:ca:b4 lost
Dec  8 13:05:59 kernel: br0: topology change detected, propagating

The ~xx.ca:ba is a old linksys G unit running DD-WRT in client bridge mode ethernet connected to a camera. It connects to the 68U repeater though and is still connected.

I had no issues for days, only started after switching QOS mode.

I can't reboot the router now, but I will be changing the QOS type back to default before rebooting.

EDIT: The 68U Repeater could not reconnect to the 86U on 2.4GHz either after reboot. It appears once this 2.4GHz issue starts, a client that remains connected will stay but cannot re-connect if disconnected.

 

[RMerlin]

Can anyone tell me the import of this. I currently run 2 AC88U routers that run a "permanent" VPN between our 2 houses, with appropriate config adds to dnsmasq at each end to allow cross network DNS naming of nodes on the two separate LANs. Just want to make sure that this change won't impact how that works.

If the server's LAN domain is myhome.lan. then the clients at the other end of the tunnel will be able to resolve "pcathome" without having to append the full domain (pcathome.myhome.lan).

Noticed miniupnpd in the changelog. Did the dev got another fix for double NAT environment?

No, just a bugfix where a buffer could potentially be read past the end.

no obvious issues, only yellow ! keeps flashing

Do you have anything special in your configuration, like a custom firewall setting, or using some custom DNS settings? I have never been able to reproduce that problem here.

 

[loveleeyoungae]

No, just a bugfix where a buffer could potentially be read past the.

Sorry, I was going to edit my post. I think I got it: with every new miniupnpd version, you will always revert their "double-NAT" patch before making the build for your firmware.

 

[cmkelley]

Strange... I got this:



...anyone else with this problem?

Is it a converted TM-AC1900? If so, that's exactly what you're going to see - ASUS has put fixes in place to prevent flashing unauthorized firmware.

 

[saibot]

Strange... I got this:



...anyone else with this problem?

yup, try different browser, chrome didn't work for me, but Firefox was fine

 

[FauDrei]

yup, try different browser, chrome didn't work for me, but Firefox was fine

Thanks for the tip...

Tried iExplorer and FireFox (portable) beside Chrome - still the same "Invalid Firmware Upload" message.

 

[Protik]

384.8 was up for a week. today i cant get to login page just hangs. i will reboot here and update to the latest now. just wanted to report that.

Same here. Router was routing alright. But couldn't go to login page. Could ssh there but couldn't execute any command. The command just stuck after pressing Enter button. Updated to 348.8_2. Will keep an eye.

Sent from my Moto G (5) Plus using Tapatalk

 

[FauDrei]

A brief update (and reminder for me what to try next time):

I have disabled HW acceleration (had CTF+FA enabled) and either this or accompanying reboot solved my problem - after that upgrade to 384.8_2 finished successfully (RT-AC68U).

 

[DroidST]

EDIT: The 68U Repeater could not reconnect to the 86U on 2.4GHz either after reboot. It appears once this 2.4GHz issue starts, a client that remains connected will stay but cannot re-connect if disconnected.