[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[kolodzij]

Any thought of the effort required to add adaptive QOS to the fork for ARM routers ? The wireless performance of the fork is why I use it but being able to have adaptive QOS and NAT acceleration would be much better in my opinion.

 

[john9527]

Any thought of the effort required to add adaptive QOS to the fork for ARM routers ? The wireless performance of the fork is why I use it but being able to have adaptive QOS and NAT acceleration would be much better in my opinion.

Sorry, but Adaptive QOS means having to bring in the TrendMicro DPI engine, and that's just way beyond the scope of this fork.

 

[kolodzij]

Sorry, but Adaptive QOS means having to bring in the TrendMicro DPI engine, and that's just way beyond the scope of this fork.

Its really too bad because all the ISP's are boosting their speeds and traditional QOS cuts the speed these routers can support in half. Will native IPv6 allow these routers faster maximum speeds vs IPv4?

 

[Nullity]

Its really too bad because all the ISP's are boosting their speeds and traditional QOS cuts the speed these routers can support in half. Will native IPv6 allow these routers faster maximum speeds vs IPv4?

That is not correct. Edit: Yes, it is. Traditional QoS requires the disabling of NAT/HW Acceleration, while Adaptive QoS can function with NAT/HW Acceleration enabled. My mistake.
The only useful improvement that Adaptive QoS offers is Deep Packet Inspection. DPI is becoming increasingly useless because it can only inspect unencrypted traffic.

Beyond that, traditional QoS is just as powerful as Adaptive QoS.

Actually, DPI can be a source of slow-downs itself since it is so processor intensive.

 

[RMerlin]

That is not correct.
The only useful improvement that Adaptive QoS offers is Deep Packet Inspection. DPI is becoming increasingly useless because it can only inspect unencrypted traffic.

Beyond that, traditional QoS is just as powerful as Adaptive QoS.

Actually, DPI can be a source of slow-downs itself since it is so processor intensive.

The Trend Micro engine doesn't just rely on DPI, it also relies on other criteria such as the destination address/port. For instance, the Apps Analysis page can report a separate entry for "Google User Content (SSL)".

 

[john9527]

Beyond that, traditional QoS is just as powerful as Adaptive QoS.

Actually, DPI can be a source of slow-downs itself since it is so processor intensive.

I think what @kolodzij is referring to is that traditional QoS disables NAT acceleration, so you're limited if for example you have a Gbps connection. Adaptive QoS works with NAT acceleration.

 

[charlie2alpha]

I think what @kolodzij is referring to is that traditional QoS disables NAT acceleration, so you're limited if for example you have a Gbps connection. Adaptive QoS works with NAT acceleration.

That's exactly what he meant of course. But it's not just a matter of the abilities of each QoS type but also an ease of use one. The Adaptive QoS is the best solution for the average buyer who doesn't know squat about linux, ports, subnets etc etc all the technical stuff, since it does what it does automatically

On the other hand, Traditional QoS can be more powerfull if you know what you're doing and combine it with your own scripts. If used only through the Web UI, it's weaker in what it can do compared to the Adaptive one.

In any case, I agree with John that this is irrelevant to this fork project, and even more so probably not possible anyway since it requires bringing in newer closed source components that most likely wouldn't work with this fork.

 

[Nullity]

The Trend Micro engine doesn't just rely on DPI, it also relies on other criteria such as the destination address/port. For instance, the Apps Analysis page can report a separate entry for "Google User Content (SSL)".

That can be done with traditional QoS too though, right?

Destination port 5228 or something.

 

[RMerlin]

That can be done with traditional QoS too though, right?

Destination port 5228 or something.

If you are willing to manually enter a large bunch of IPs, sure. The idea behind Adaptive QoS is that it requires zero technical knowledge to setup.

 

[TFNG2015]

Been gone a long time. Coming from 374.43_2-10j9527. Been clicking through these pages reading amap. Straight to v14? No reset needed as I understand. Unless I have missed something somewhere. I'll have to say, this is the best danged firmware since the wheel. Never had anything be as stable. No reboots, waiting, nothing. Just works. Thanks. Wish a manufacturer could figure it out.

 

[john9527]

Been gone a long time. Coming from 374.43_2-10j9527. Been clicking through these pages reading amap. Straight to v14? No reset needed as I understand. Unless I have missed something somewhere. I'll have to say, this is the best danged firmware since the wheel. Never had anything be as stable. No reboots, waiting, nothing. Just works. Thanks. Wish a manufacturer could figure it out.

Thanks for the kind words....

You should be able to go directly from V10 to V14E1 without a reset (I actually add code to avoid having to do the reset to correctly initialize any new functions).

 

[TFNG2015]

Here it goes. Thanks again. Just being honest.

 

[TFNG2015]

Up and running flawlessly as we speak. Running cooler as well. CPU was 83. Down to 79 celsius. Painless. Most appreciative.

 

[TFNG2015]

Stronger signal to all devices as well? Different parameters for data? Curious. Strong and Stable at the moment. Flawless update.

 

[john9527]

Running cooler as well.

Stronger signal to all devices as well? Different parameters for data?

Wish there was something I could point to that I did....but no. Didn't change any processes that would affect CPU utilization or make any changes to the wireless subsystem.

For the wireless part, did you touch the router (maybe to power cycle) and move it at all? It's surprising how even a small change in position can affect the wireless signal as it tries to penetrate all the obstructions in a typical home.

 

[followmsi]

I have 2 RT-AC68 boxes running on John´s fork version 14E1.
One is running as the main router and one is running in media bridge mode.

Everything works perfekt except Apple Air printing.

The Air Print printer (hp jaser jet) is connected to the media bridge - wired.
First the media bridge was running on John´s version 13E1 and Air printing was not working too.
Then I moved to Merlin 378.55 and Air printing was starting to work immediately.

My intention is clearly to run both boxes on the same firmware release - on John´s fork.

As I saw the release notes for 14E1 ..
Enable avahi-reflector as default for improved Apple connectivity
.. I was hoping

But it still does not work on 14E1.

What is the difference to 378.55 in terms of air print printer discovery ?

Could an "avahi post.conf" on jffs2 fix this problem on 14E1 ?

 

[TFNG2015]

In response. Did touch the router. No power cycle. Disconnected a Sprint Airave and hooked up macbook to upload firmware. Disconnected mac .and reconnected Airave. Maybe 1/2 inch movement. Changed no settings. Still running cooler. All devices are showing a lower db other than the Mac, and seem to be faster.

 

[TFNG2015]

Let me correct. Did power cycle, no reset. Brain dead at the moment. Halloween and 4 kids.

 

[john9527]

I have 2 RT-AC68 boxes running on John´s fork version 14E1.
One is running as the main router and one is running in media bridge mode.

Everything works perfekt except Apple Air printing.

The Air Print printer (hp jaser jet) is connected to the media bridge - wired.
First the media bridge was running on John´s version 13E1 and Air printing was not working too.
Then I moved to Merlin 378.55 and Air printing was starting to work immediately.

My intention is clearly to run both boxes on the same firmware release - on John´s fork.

As I saw the release notes for 14E1 ..
Enable avahi-reflector as default for improved Apple connectivity
.. I was hoping

But it still does not work on 14E1.

What is the difference to 378.55 in terms of air print printer discovery ?

Could an "avahi post.conf" on jffs2 fix this problem on 14E1 ?

The Apple support has always been a bit hit or miss. But I remember seeing a post similar to this in another thread (it might have actually been from you) with the exact same experience. For V15, I backported some more avahi changes from 378.55 with the hopes that it might help. Unfortunately, I'm not an Apple user so can't test/debug anything there.

V15 will be coming shortly....we can keep our fingers crossed

 

[john9527]

Let me correct. Did power cycle, no reset. Brain dead at the moment. Halloween and 4 kids.

The 'good' ghosts must have been at work at your house....only explanation