[Release] Asuswrt-Merlin 384.11 is available

[eclp]

Recently I get the following message more often. Can't find any further information in the forum. Can anyone say anything about it?

RT-AX88U (384.11) with Diversion & Skynet

May 14 20:38:31 kernel: FPM Pool 1: invalid token 0x219b0000 freed
May 14 20:41:48 kernel: FPM Pool 1: invalid token 0x21490000 freed
May 14 20:43:53 kernel: FPM Pool 1: invalid token 0x215b0000 freed
May 14 20:44:37 kernel: FPM Pool 1: invalid token 0x206b8000 freed

 

[RMerlin]

Can anyone say anything about it?

Nope. That message comes from a Broadcom blackbox, only them have any clue what this message means.

 

[RMerlin]

BTW, Asus's 45717 contains a "security" enhancement that means bad news for me if they did it the way I heard they did. I need to wait for access to GPL code to determine how bad it is. I knew ahead of time of the change, and I could confirm that the change made it into that release when I tested it on an RT-AC88U, however the big question is to see how it was implemented, so I can devise a workaround. For this I will need to wait until I get GPL drops for that release.

For now, be advised that if you install 45717 and then decide to switch back to my firmware, any script you had installed in /jffs/ will no longer work, and will require "fixing". I can't go into any further detail for now, sorry.

 

[MDM]

BTW, Asus's 45717 contains a "security" enhancement that means bad news for me if they did it the way I heard they did. I need to wait for access to GPL code to determine how bad it is. I knew ahead of time of the change, and I could confirm that the change made it into that release when I tested it on an RT-AC88U, however the big question is to see how it was implemented, so I can devise a workaround. For this I will need to wait until I get GPL drops for that release.

For now, be advised that if you install 45717 and then decide to switch back to my firmware, any script you had installed in /jffs/ will no longer work, and will require "fixing". I can't go into any further detail for now, sorry.

Uh Oh...

 

[jsbeddow]

BTW, Asus's 45717 contains a "security" enhancement that means bad news for me if they did it the way I heard they did. I need to wait for access to GPL code to determine how bad it is. I knew ahead of time of the change, and I could confirm that the change made it into that release when I tested it on an RT-AC88U, however the big question is to see how it was implemented, so I can devise a workaround. For this I will need to wait until I get GPL drops for that release.

For now, be advised that if you install 45717 and then decide to switch back to my firmware, any script you had installed in /jffs/ will no longer work, and will require "fixing". I can't go into any further detail for now, sorry.

Yikes....fingers crossed that this is not as ugly as it sounds. ASUS would be shooting themselves in the foot if it means the end of custom scripts, or worse, then end of RMerlin's ability to release his vastly improved versions of their firmware.

 

[scjr]

Yikes....fingers crossed that this is not as ugly as it sounds. ASUS would be shooting themselves in the foot if it means the end of custom scripts, or worse, then end of RMerlin's ability to release his vastly improved versions of their firmware.

I strongly agree. I chose my router over another brand, because of Merlin. I would be sorely disappointed if ASUS did anything to hinder development of Merlin and if so, that would play a big factor in which brand I choose in the future.

 

[Kingp1n]

I strongly agree. I chose my router over another brand, because of Merlin. I would be sorely disappointed if ASUS did anything to hinder development of Merlin and if so, that would play a big factor in which brand I choose in the future.

Don't like the sound of this... hopefully it's not bad...but it might be time to switch to Google mesh system for me. I've just need it an excuse haha I will hold off until RMerlin has looked into it further....without RMerlin I don't use Asus stock FW.

 

[akb]

BTW, Asus's 45717 contains a "security" enhancement that means bad news for me if they did it the way I heard they did. I need to wait for access to GPL code to determine how bad it is. I knew ahead of time of the change, and I could confirm that the change made it into that release when I tested it on an RT-AC88U, however the big question is to see how it was implemented, so I can devise a workaround. For this I will need to wait until I get GPL drops for that release.

For now, be advised that if you install 45717 and then decide to switch back to my firmware, any script you had installed in /jffs/ will no longer work, and will require "fixing". I can't go into any further detail for now, sorry.

Sounds like no good, I too only purchase ASUS products which are supported by Merlin. The second its not supported, I am going with a new vendor.

 

[skeal]

I'm guessing this means WAN Aggregation is not working? Anyone know?

 

[Gar]

Uh Oh...

No 384.12...

Edit: I shouldn't have said that.

 

[Swistheater]

BTW, Asus's 45717 contains a "security" enhancement that means bad news for me if they did it the way I heard they did. I need to wait for access to GPL code to determine how bad it is. I knew ahead of time of the change, and I could confirm that the change made it into that release when I tested it on an RT-AC88U, however the big question is to see how it was implemented, so I can devise a workaround. For this I will need to wait until I get GPL drops for that release.

For now, be advised that if you install 45717 and then decide to switch back to my firmware, any script you had installed in /jffs/ will no longer work, and will require "fixing". I can't go into any further detail for now, sorry.

Not trying to Pry into your code, but which one of the new fixes would "potentially" cause an issue with your code?

 

[Swistheater]

I'm guessing this means WAN Aggregation is not working? Anyone know?

that looks to be the case with me.. it appears that it is not supporting your setup.

 

[Swistheater]

that looks to be the case with me.. it appears that it is not supporting your setup.

do you see any logs about it?

 

[Paliv]

Has anybody else tried Quad9 with DoT and DNSSEC? It randomly won’t resolve pages on occasion requiring several refreshes. I saw people in the stubby thread mention this months ago, guess it’s still a problem.

 

[dave14305]

Has anybody else tried Quad9 with DoT and DNSSEC? It randomly won’t resolve pages on occasion requiring several refreshes. I saw people in the stubby thread mention this months ago, guess it’s still a problem.

I was using it rather successfully for a while after adjusting the idle timeout as recommended by @EmeraldDeer in this post from the beta thread:
[Beta] Asuswrt-Merlin 384.11 Beta is now available

 

[RMerlin]

Not trying to Pry into your code, but which one of the new fixes would "potentially" cause an issue with your code?

It's not in the changelog.

 

[Paliv]

I was using it rather successfully for a while after adjusting the idle timeout as recommended by @EmeraldDeer in this post from the beta thread:
[Beta] Asuswrt-Merlin 384.11 Beta is now available

Thanks, might look into that.

 

[Swistheater]

It's not in the changelog.

oh okay I can see how that is discerning.

 

[Gar]

Has anybody else tried Quad9 with DoT and DNSSEC? It randomly won’t resolve pages on occasion requiring several refreshes. I saw people in the stubby thread mention this months ago, guess it’s still a problem.

It usually works for me, not 100%

 

[Treadler]

Has anybody else tried Quad9 with DoT and DNSSEC? It randomly won’t resolve pages on occasion requiring several refreshes. I saw people in the stubby thread mention this months ago, guess it’s still a problem.

I have. Some pages very slow to load, if they load at all.

Quad1 & Quad8 no problem.

I just use Quad1 & job’s done....

[Edit] Just for fun I reverted to Quad9, but only selected the primary server, not the secondary.
Working great now!