RT-AC68U new firmware 3.0.0.4.384_20624-g14d2f02

[maxbraketorque]

please stop that discussion - I am OP !!!

ALL 68U-types are welcome here!
no 66U (except _V2) or 86U
but all RT-AC68U, TM-AC1900, RT-AC68P, RT-AC68W, RT-AC1900 and whatelse they are named!

Whenever you can load this firmware as update it is meant to be the right thread!
I cant write all versions in the header ...

Wanted only say - hey there's a new firm for that router, maybe some interesting things.

And yes that is interesting that some will loose AiMesh.
AND that cfe is changing by this firmware, thats new for me that they are changing bootloader at all !!!
Would be interesting whether only TM with 1.0.2.5 have problems or even such with 1.0.2.0 or 1.0.2.1.

A TM-AC1900 is not an official variant of the RT-AC68U. It really should have its own thread because it was never meant to accept the RT-AC68U firmware, and its going to have its own set of issues beyond what people find for the RT-AC68U and its official variants. However, if people are going to discuss the TM-AC1900 in this thread, they should at least say that they are using a TM-AC1900 so that people can more quickly understand the nature of a new issue and realize that it may be endemic to only the TM-AC1900. And its helpful to ASUS because the reality is that ASUS owes no support to TM-AC1900 users who have converted to RT-AC68Us.

 

[mastermind85]

I am having the same issue here on my AC1900 converted router. How annoying...

 

[metalbender]

If I buy a used RT-AC68U on amazon, Asus gets nothing still. No defrauding Asus at all here yet they get $0.00.

Sent from my SM-G930P using Tapatalk

Seems you missed the point since this was in reference to the TM only which you totally ignored so miraculously you are not defrauding because you are using a product that supports AIMESH - oh and ASUS already received their money whether on a new or used product, so claiming ASUS received $0 is incorrect. And very few are purchasing legitimate new or used ASUS routers that support AIMESH since the TM versions are half or a third of the price - and the legitimate resellers of ASUS products that sell used like amazon warehouse and newegg - ASUS still receives revenue. With thousands of the TMs being sold fraudulently as being equivalent to RT-AC68X with AIMESH support then ASUS and their resellers are losing revenue. And good luck with purchasing a used version on amazon as most of these are TM models being sold as RT-AC68U. Again buyer beware. Ultimately ASUS is closing the hole to prevent the fraudulent use of the TM model to prevent the use of a feature that was never intended for this model.

 

[wshuman3]

Version 3.0.0.4.384.20624 2018/03/2642.7 MBytes

Please unzip the firmware file first then check the MD5 code.
MD5:146ce34f70a34b26492ffdeb9c6dd3d2

On the website @ https://www.asus.com/us/Networking/RTAC68U/HelpDesk_BIOS/

They have a new date listed for yesterday 2018-03-27 and the file that downloads does not match the md5sum listed. This is also the case for the RT-AC1900P

~/Downloads $ unzip FW_RT_AC68U_300438420624.ZIP
Archive: FW_RT_AC68U_300438420624.ZIP
extracting: RT-AC68U_3.0.0.4_384_20624-g14d2f02.trx
~/Downloads $ md5sum RT-AC68U_3.0.0.4_384_20624-g14d2f02.trx
ad3d614cac926598015aef87eefae7b4 RT-AC68U_3.0.0.4_384_20624-g14d2f02.trx

This is more concerning to me then dropping support of the TM-AC1900.

 

[scjr]

On the website @ https://www.asus.com/us/Networking/RTAC68U/HelpDesk_BIOS/

They have a new date listed for yesterday 2018-03-27 and the file that downloads does not match the md5sum listed. This is also the case for the RT-AC1900P

~/Downloads $ unzip FW_RT_AC68U_300438420624.ZIP
Archive: FW_RT_AC68U_300438420624.ZIP
extracting: RT-AC68U_3.0.0.4_384_20624-g14d2f02.trx
~/Downloads $ md5sum RT-AC68U_3.0.0.4_384_20624-g14d2f02.trx
ad3d614cac926598015aef87eefae7b4 RT-AC68U_3.0.0.4_384_20624-g14d2f02.trx

This is more concerning to me then dropping support of the TM-AC1900.

Maybe @arthurlien can explain the difference in md5 checksum?

 

[Sammy2]

On the website @ https://www.asus.com/us/Networking/RTAC68U/HelpDesk_BIOS/

They have a new date listed for yesterday 2018-03-27 and the file that downloads does not match the md5sum listed. This is also the case for the RT-AC1900P

~/Downloads $ unzip FW_RT_AC68U_300438420624.ZIP
Archive: FW_RT_AC68U_300438420624.ZIP
extracting: RT-AC68U_3.0.0.4_384_20624-g14d2f02.trx
~/Downloads $ md5sum RT-AC68U_3.0.0.4_384_20624-g14d2f02.trx
ad3d614cac926598015aef87eefae7b4 RT-AC68U_3.0.0.4_384_20624-g14d2f02.trx

This is more concerning to me then dropping support of the TM-AC1900.

Why is this more concerning to you?

Sent from my SM-G930P using Tapatalk

 

[Sammy2]

Seems you missed the point since this was in reference to the TM only which you totally ignored so miraculously you are not defrauding because you are using a product that supports AIMESH - oh and ASUS already received their money whether on a new or used product, so claiming ASUS received $0 is incorrect. And very few are purchasing legitimate new or used ASUS routers that support AIMESH since the TM versions are half or a third of the price - and the legitimate resellers of ASUS products that sell used like amazon warehouse and newegg - ASUS still receives revenue. With thousands of the TMs being sold fraudulently as being equivalent to RT-AC68X with AIMESH support then ASUS and their resellers are losing revenue. And good luck with purchasing a used version on amazon as most of these are TM models being sold as RT-AC68U. Again buyer beware. Ultimately ASUS is closing the hole to prevent the fraudulent use of the TM model to prevent the use of a feature that was never intended for this model.

Getting first sold revenue in 2013 or so doesn't contribute to the bottom line in 2018. I'm not sure what you mean. If I buy used today Asus gets nothing today.

Stating thay buying used on Amazon or eBay will result in a TM-AC1900 being shipped assumes facts not in evidence and is conjecture at best.

Simply not wanting to support the few hundred or so repurposed TM-AC1900's out there just so as to not carry that cost seems, to me anyhow, much more plausible yet in itself is conjecture as well. For all we know it wasn't even intentional.

Sent from my SM-G930P using Tapatalk

 

[wshuman3]

Why is this more concerning to you?

Sent from my SM-G930P using Tapatalk

The version (3.0.0.4_384_20624-g14d2f02) is exactly the same but the contents are not.

I updated from the previous file that matched the checksum on the webpage (146ce34f70a34b26492ffdeb9c6dd3d2). There is now a new file posted with a different checksum. Was there an issue with the version I used? Is it safe to update to this version even though the checksums do not match? Was something compromised?

 

[a-wrt]

I upgraded my RT-AC68U to this firmware today. I am noticing CPU usage constantly hovers around 35% for both cores. If I SSH into the router and use top to examine the breakdown, I am seeing that this usage appears to be coming from sirq (software irq or % CPU time spent servicing/handling software interrupts). The culprits appear to be the ksoftirqd/0 and ksoftirqd/1 processes.

Is anyone else seeing this behaviour? Does anyone know what's going on here?

 

[indark]

I upgraded my RT-AC68U to this firmware today. I am noticing CPU usage constantly hovers around 35% for both cores. If I SSH into the router and use top to examine the breakdown, I am seeing that this usage appears to be coming from sirq (software irq or % CPU time spent servicing/handling software interrupts).

Is anyone else seeing this behaviour? Does anyone know what's going on here?

Dont have that issue with my ac68u
have you tried power cycle and nvram clear?
I had 100% CPU load on core 1 few firmware back and doesn't matter how many time I reset, it stuck @ high CPU usage.
it was only fixed after I powercycle and nvram clear.

 

[a-wrt]

Dont have that issue with my ac68u
have you tried power cycle and nvram clear?
I had 100% CPU load on core 1 few firmware back and doesn't matter how many time I reset, it stuck @ high CPU usage.
it was only fixed after I powercycle and nvram clear.

Thank you for your response.

Via ssh I used "nvram reset" followed by "reboot". I then manually re-entered all my settings. I now find that sirq hovers around 10%-20% for both cores, so this has improved things but not resolved the issue, in my case. With the previous version of the firmware, sirq seemed effectively idle.

EDIT - The improvement was temporary, and the usage is back at around 35% constantly.

 

[indark]

Thank you for your response.

Via ssh I used "nvram reset" followed by "reboot". I then manually re-entered all my settings. I now find that sirq hovers around 10%-20% for both cores, so this has improved things but not resolved the issue, in my case. With the previous version of the firmware, sirq seemed effectively idle.

oh by power cycle, I meant to unplug the power for at least 30 sec to 5 min, and try another nvram ram reset via holding the wps while power on the router. wait till the LED start blinking then release the wps button.
it's my solution to deal with weird issue when switching between merlin and official firmware or when there is major code base change, ie 380 to 382 or 382 to 384.
hopefully it works for you.
that's my 68u without much traffic.


oh and if you have usb drive, might want to consider remove it before you set it up as well. It sometimes causing issue when updating firmware.

 

[Grisu]

The version (3.0.0.4_384_20624-g14d2f02) is exactly the same but the contents are not.

I updated from the previous file that matched the checksum on the webpage (146ce34f70a34b26492ffdeb9c6dd3d2). There is now a new file posted with a different checksum. Was there an issue with the version I used? Is it safe to update to this version even though the checksums do not match? Was something compromised?

MD5 is changed now too correlating to the new file with exactly the same name as before.
But only if I choose Drivers -> Win10 I see the new MD5, using Firmware there is the old MD5 with new file, you will have to wait a day for updating their servers ...

For me they work both on real RT-AC68U, maybe different for TM-AC1900 and RT-AC68P devices (dont have them).

 

[wshuman3]

MD5 is changed now too correlating to the new file with exactly the same name as before.
But only if I choose Drivers -> Win10 I see the new MD5, using Firmware there is the old MD5 with new file, you will have to wait a day for updating their servers ...

For me they work both on real RT-AC68U, maybe different for TM-AC1900 and RT-AC68P devices (dont have them).

That is progress I guess. I would still like to know what changed before I load this new firmware.

 

[a-wrt]

oh by power cycle, I meant to unplug the power for at least 30 sec to 5 min, and try another nvram ram reset via holding the wps while power on the router. wait till the LED start blinking then release the wps button.
it's my solution to deal with weird issue when switching between merlin and official firmware or when there is major code base change, ie 380 to 382 or 382 to 384.
hopefully it works for you.
that's my 68u without much traffic.
View attachment 12503

oh and if you have usb drive, might want to consider remove it before you set it up as well. It sometimes causing issue when updating firmware.

Thank you again for your kind response.

I followed your instructions exactly, and I am pleased to report that this has fixed my CPU usage problems! I will keep this procedure in my toolbox in the future.

 

[monaro-ds]

Hm …
I was unpacking .trx file yesterday and got trojan virus warning on 2 files inside of trx …
Checked file online and new file was different size
Also noticed in the name of the file “-“ was replaced by “_”

 

[Grisu]

Hm …
I was unpacking .trx file yesterday and got trojan virus warning on 2 files inside of trx …
Checked file online and new file was different size
Also noticed in the name of the file “-“ was replaced by “_”View attachment 12526

I checked both files too, exactly same warnings like yours.
So thats no difference in previous and recent file.

 

[indark]

that's interesting find
I throw one of the file up on virustotal
https://www.virustotal.com/#/file/e...088c3920b23ebfb898c3266aa65def2fcbb/detection

a quick search indicate that's AI detection so still need actual person to review and verify the file.

 

[monaro-ds]

Symantec and Microsoft say its Trojan

 

[RMerlin]

It's not even an x86 binary, so how could they identify it as a trojan? Those virus scanners are only designed to analyze x86 binaries, not ARM.

They are false positive.