[Release] FreshJR Adaptive QOS (Improvements / Custom Rules / and Inner workings)

[FreshJR]

I also had a problem after installing beta8. When I install and reboot, the drive I have never seems to mount by itself again. Thus entware doesn't start and skynet fails, ab-solution doesn't start. The drive finally in the end mounts but far to late for entware and skynet and ab-solution. If I stay to the earlier version 1.92 everything works fine. My system reboots ok again.

You wouldn't happen to have a copy of those logs would you?

Feb 13 18:00:33 custom_script: Running /jffs/scripts/firewall-start (args: eth0)    (14:33:18 corrected timestamp)
Feb 13 18:00:35 usb: USB vfat fs at /dev/sda1 mounted on /tmp/mnt/USB.              (14:33:20 corrected timestamp)
Mar  7 14:33:21 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/USB)
Mar  7 14:33:24 Skynet: [INFO] Startup Initiated... ( banmalware autoupdate )
Mar  7 14:33:53 adaptive QOS: Warming Up

On my system, QOS started 25-35 seconds after the disk mount.

As for potential issues with ABsolution/Skynet, when you see the "Parsing QOS rates" logger entry from adaptiveQOS, then at iptables is getting cleared at that moment.
This disables both scripts functionality.
Immediately after getting cleared, firewall-start is once again called to repopulate everything back to normal.

Mar  7 14:34:04 Skynet: [Complete]
Mar  7 14:34:16 adaptive QOS: Applying Custom Upload Rules
Mar  7 14:34:18 adaptive QOS: Applying Custom Download Rules
Mar  7 14:35:15 adaptive QOS: Parsing User QOS Rates -> (No Changes)  **  IPTABLES CLEARED HERE **
Mar  7 14:35:16 rc_service: udhcpc 438:notify_rc start_firewall
Mar  7 14:35:18 custom_script: Running /jffs/scripts/firewall-start (args: eth0) ** IPTABLES REPOPULATED HERE **
Mar  7 14:35:20 Skynet: [INFO] Startup Initiated... ( banmalware autoupdate )
Mar  7 14:35:42 adaptive QOS: Applying Iptables Rules
Mar  7 14:35:42 adaptive QOS: Changing 1:10 class rate
Mar  7 14:35:46 adaptive QOS: Changing 1:11 class rate
Mar  7 14:35:46 adaptive QOS: Changing 1:12 class rate
Mar  7 14:35:47 adaptive QOS: Changing 1:13 class rate
Mar  7 14:35:51 adaptive QOS: Changing 1:14 class rate
Mar  7 14:35:51 Skynet: [Complete]
Mar  7 14:35:53 adaptive QOS: Changing 1:15 class rate
Mar  7 14:35:56 adaptive QOS: Changing 1:16 class rate
Mar  7 14:35:58 adaptive QOS: Changing 1:17 class rate

So on my setup, disk-mount is working, and firewall-start is being called at the correct time.

 

[skeal]

You wouldn't happen to have a copy of those logs would you?

Feb 13 18:00:33 custom_script: Running /jffs/scripts/firewall-start (args: eth0)    (14:33:18 corrected timestamp)
Feb 13 18:00:35 usb: USB vfat fs at /dev/sda1 mounted on /tmp/mnt/USB.              (14:33:20 corrected timestamp)
Mar  7 14:33:21 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/USB)
Mar  7 14:33:53 adaptive QOS: Warming Up

On my system, QOS started 25 seconds after the disk mount.

When you see "Parsing QOS rates" logger entry from adaptiveQOS then at that moment iptables gets cleared. But immedietly after that entry, firewall-start is called to repopulate everything to normal.

Mar  7 14:34:04 Skynet: [Complete]
Mar  7 14:34:16 adaptive QOS: Applying Custom Upload Rules
Mar  7 14:34:18 adaptive QOS: Applying Custom Download Rules
Mar  7 14:35:15 adaptive QOS: Parsing User QOS Rates -> (No Changes)  **  IPTABLES CLEARED HERE **
Mar  7 14:35:16 rc_service: udhcpc 438:notify_rc start_firewall
Mar  7 14:35:18 custom_script: Running /jffs/scripts/firewall-start (args: eth0) ** IPTABLES REPOPULATED HERE **
Mar  7 14:35:20 Skynet: [INFO] Startup Initiated... ( banmalware autoupdate )
Mar  7 14:35:42 adaptive QOS: Applying Iptables Rules
Mar  7 14:35:42 adaptive QOS: Changing 1:10 class rate
Mar  7 14:35:46 adaptive QOS: Changing 1:11 class rate
Mar  7 14:35:46 adaptive QOS: Changing 1:12 class rate
Mar  7 14:35:47 adaptive QOS: Changing 1:13 class rate
Mar  7 14:35:51 adaptive QOS: Changing 1:14 class rate
Mar  7 14:35:51 Skynet: [Complete]
Mar  7 14:35:53 adaptive QOS: Changing 1:15 class rate
Mar  7 14:35:56 adaptive QOS: Changing 1:16 class rate
Mar  7 14:35:58 adaptive QOS: Changing 1:17 class rate

So on my setup, disk-mount is working, and firewall-start is being called at the correct time.

On my system all that happens as well but only after Entware fails. A few seconds later the drive mounts and QOS log entries show up as expected (without ab-solution and skynet able to start). If I go back to 1.92 Entware does not fail to start and everything returns to normal.
EDIT: In my logs it looks as if services-start only gets called once and its early in the boot process. Really early!

 

[FreshJR]

On my system all that happens as well but only after Entware fails. A few seconds later the drive mounts and QOS log entries show up as expected (without ab-solution and skynet able to start). If I go back to 1.92 Entware does not fail to start and everything returns to normal.

Did you try any of the other beta's by chance?
Did this start happening recently?

If the issue is occurring in the log before the first "adaptive QOS: Warming Up" entry, I am kind of at a loss, as the the only thing I run before that is init-start script to mount fakeTC.

(And here I was tightening the timings on my personal version to avoid the long 100s waittime)

 

[skeal]

Did you try any of the other beta's by chance?
Did this start happening recently?

If the issue is occurring in the log before the first "adaptive QOS: Warming Up" entry, I am kind of at a loss, as the the only thing I run before that is init-start script to mount fakeTC.

I looked at your script for the first time yesterday. I installed the older version because it was on first page. All went well it worked as expected. I later found your beta 7 and 8. I went to 8 right away. Ran all the commands with QOS off everything ok. Restart QOS it all works version 8 works; however as soon as you reboot it causes the issues I described above. To remove I edited the entries in jffs and then deleted the 2 separate script files. Restart router and all is good. Install older version 1.92 and all is good even after a reboot.

 

[FreshJR]

Install older version 1.92 and all is good even after a reboot.

You have look for v382 instead of v1.92.

It's the same execution, but v382 contains changes required for fw v382+

 

[skeal]

You have look for v382 instead of v1.92.

It's the same execution, but v382 contains changes required for fw v382+

Not sure what you mean can you link a post or something please and I will try?

 

[FreshJR]

Not sure what you mean can you link a post or something please and I will try?

v1.92 is depreciated.
It has been replaced with a v382 version.

That or wait for beta9. I will try to come up with a version without the hacky sleep approach that might be causing your restart issues.

The reason I drifted away from RMerlins version and implemented the hacky sleep is because I was still occasionally getting errors in the QOS log. This was vanilla fakeTC that comes with the firmware, with no modifications.

Maybe I need to retest again on v384.4 beta2 without the sleep since I was testing it on beta1.

 

[skeal]

v1.92 is depreciated.
It has been replaced with a v382 version.

That or wait for beta9. I will try to come up with a version without the hacky sleep approach that might be causing your restart issues.

The reason I drifted away from RMerlins version and implemented the hacky sleep is because I was still occasionally getting errors in the QOS log without it.

Can you show me where I can get the v382 version? I cannot find it.

 

[FreshJR]

Can you show me where I can get the v382 version? I cannot find it.

Somewhere between pages 30-40 most likely.

 

[skeal]

Somewhere between pages 30-40 most likely.

Should I see anything else in my logs besides this?

Adaptive QOS: Modification Script Started

I copied the new version into /jffs/ and restarted QOS.

 

[FreshJR]

That one had a long hard coded sleep due to recent firmware changes

 

[skeal]

That one had a long hard coded sleep due to recent firmware changes

Yes sir it works now!!

 

[skeal]

Everything works with that v382. Like you said it has a long sleep before starting. It starts though and runs well.

 

[skeal]

Everything works with that v382. Like you said it has a long sleep before starting. It starts though and runs well.

Beta8 probably has a starting issue on my router causing the mount to screw up.

 

[FreshJR]

After some more investigation there is no way around removing the hacky sleep approach if you want to guarantee no error messages.
I can still trigger the error messages on RMerlins more streamlined version of the script, without FreshJR_QOS installed.

So we are left with having two versions offered to users.

1) script triggered on firewall-start with a long wait
2) fakeTC interceptor with hacky sleep approach

#1 is great since the changes of bugs is almost ZERO
#2 is great since you have instant results to see if your rules are working instead of waiting 3 minutes

#1 has drawbacks since sometimes QOS will turn off if fiddling with router settings, and it will stay off until a scheduled persistence check occurs at midnight
#2 has drawbacks since apparently there can be compatability issue between other scripts on router bootup

QOS performance is the same with both methods.

Ideally, I would just want to fix the compatibility issue that skeal is experiencing, but I will not have time to experiment more for another few weeks. (I basically burnt all my free time the past few days)

I also have successfully tightened the timings on my own setup to apply the 1:10-1:17 rates a LOT sooner.

--

So future plans
1) offer both #1 and #2 versions of the script in the first post.
This way users have an option to use the more compatible #1 version with its slight drawback.
2) Fix comparability issue with other scripts on router bootup present in script version #2
3) Make the "unidentified" QOS container adjustable in the webUI so it doesn't have to be useless and gather dust (This will only work with the fakeTC version of the script)

 

[skeal]

After some more investigation there is no way around removing the hacky sleep approach if you want to guarantee no error messages.
I can still trigger the error messages on RMerlins more streamlined version of the script, without FreshJR_QOS installed.

So we are left with having two versions offered to users.

1) script triggered on firewall-start with a long wait
2) fakeTC interceptor with hacky sleep approach

#1 is great since the changes of bugs is almost ZERO
#2 is great since you have instant results to see if your rules are working instead of waiting 3 minutes

#1 has drawbacks since sometimes QOS will turn off if fiddling with router settings, and it will stay off until a scheduled persistence check occurs at midnight
#2 has drawbacks since apparently there can be compatability issue between other scripts on router bootup

QOS performance is the same with both methods.

Ideally, I would just want to fix the compatibility issue that skeal is experiencing, but I will not have time to experiment more for another few weeks. (I basically burnt all my free time the past few days)

I also have successfully tightened the timings on my own setup to apply the 1:10-1:17 rates a LOT sooner.

--

So future plans
1) offer both #1 and #2 versions of the script in the first post.
This way users have an option to use the more compatible #1 version with its slight drawback.
2) Fix comparability issue with other scripts on router bootup present in script version #2
3) Make the "unidentified" QOS container adjustable in the webUI so it doesn't have to be useless and gather dust (This will only work with the fakeTC version of the script)

I like door number 1 Monty!

 

[Sinner]

I think option 1 is fine as long as there are clear msgs someplace stating it will take 3min or whatever to take effect mostly for those not following this thread as closely. I kinda miss the old single file setup you had.

 

[FreshJR]

I think option 1 is fine as long as there are clear msgs someplace stating it will take 3min or whatever to take effect mostly for those not following this thread as closely. I kinda miss the old single file setup you had.

The old single file is option1.

 

[Sinner]

The old single file is option1.

Oh like v1.92? I didnt realize it still worked

 

[FreshJR]

Oh like v1.92? I didnt realize it still worked

It has been replaced by v382