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

[octopus]

Ok sorry, to fast.

octopus@OCTOPUS:/tmp/home/root# /jffs/scripts/openvpn-event
+ /jffs/scripts/openvpn-event
+ basename /jffs/scripts/openvpn-event
+ logger -st (openvpn-event) 1037 Openvpn event '' () via args = []
(openvpn-event): 1037 Openvpn event '' () via args = []
+ basename /jffs/scripts/openvpn-event
+ scr_name=openvpn-event[1037]
+ vpn_name=
+ vpn_script_name=vpn-
+ nvram get vpn_script_state
+ vpn_script_state=vpn-
+ nvram set vpn_script_state=vpn-
+ [ vpn- = vpn- ]
+ echo VPN script vpn- already run
+ logger -t openvpn-event[1037]
+ exit 0

 

[john9527]

@octopus - Sorry about the $P1 error (@Martineau correctly provided the fix of changing it to $1) I pulled out some old code before posting that was there to handle the blank args before the vpnrouting.sh PARAM change).

I've now changed to the exact code with the $1 change and it works fine here....

Dec 19 08:45:15 custom script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1558 10.69.10.6 10.69.10.5)
Dec 19 08:45:15 vpnclient1-route-up: VPN BYPASS: created ipsets

Text isn't important, but the vpnclient1-route-up script name is gen'd correctly and being called (VPN BYPASS is another function I'm working on that I'm debugging with scripts called this way )

You won't be able to use @Martineau 's method to test, because the $dev, etc parms are only present in the shell that is executed by the openvpn code.

You also didn't say how you created/edited your scripts. But first thing I'd try on the router is

dos2unix /jffs/scripts/openvpn-event

when strange things like this happen in script execution.

 

[Martineau]

Ok sorry, to fast.

octopus@OCTOPUS:/tmp/home/root# /jffs/scripts/openvpn-event
+ /jffs/scripts/openvpn-event
+ basename /jffs/scripts/openvpn-event
+ logger -st (openvpn-event) 1037 Openvpn event '' () via args = []
(openvpn-event): 1037 Openvpn event '' () via args = []
+ basename /jffs/scripts/openvpn-event
+ scr_name=openvpn-event[1037]
+ vpn_name=
+ vpn_script_name=vpn-
+ nvram get vpn_script_state
+ vpn_script_state=vpn-
+ nvram set vpn_script_state=vpn-
+ [ vpn- = vpn- ]
+ echo VPN script vpn- already run
+ logger -t openvpn-event[1037]
+ exit 0

So without any args, variable 'vpn_name' is not set to a value, but if you issue

/jffs/scripts/openvpn-event   tun11

then the variable should be set to 'Client1' unless you are still using "$P1" or "$dev" as recommended.

 

[octopus]

Okay thanks to you both.
I'm trying to catch up with you I'm not a programmer.
No problem with some typo, that happening sometimes.
I want to use this to run script outside openvpn-event client/server. It's easier to test things then.
Create manually vpnclient1-rout-up in /scripts folder and use dos2unix on all script when strange things happening.
I'm unsure to get this working as you have @john9527 How do you test it's working?

 

[octopus]

Okey after some MORE testing i get this, when change to $dev

Dec 19 19:10:38 custom script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1561 10.129.xxx.xx )
Dec 19 19:10:38 (openvpn-event): 2730 Openvpn event 'route-up' (tun11) via 10.129.xxx.xx args = [tun11 1500 1561 10.129.xxx.xx ]
Dec 19 19:10:38 (vpnclient1-route-up): 2738 vpnclient1-rote-up is [[ executed ]]

 

[octopus]

Thank you @john9527 and @Martineau for all help.

 

[Martineau]

Okey after some MORE testing i get this, when change to $dev

Dec 19 19:10:38 custom script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1561 10.129.xxx.xx )
Dec 19 19:10:38 (openvpn-event): 2730 Openvpn event 'route-up' (tun11) via 10.129.xxx.xx args = [tun11 1500 1561 10.129.xxx.xx ]
Dec 19 19:10:38 (vpnclient1-route-up): 2738 vpnclient1-rote-up is [[ executed ]]

Glad you (as a self-confessed non-programmer ) persevered to get it working!

It does appear that for the openvpn-event script the bug still exists where you cannot always rely on the variables $1,$2,$3 etc. to be resolved individually, instead you have to use the OpenVPN environment variables such as $dev etc.

 

[john9527]

It does appear that for the openvpn-event script the bug still exists where you cannot always rely on the variables $1,$2,$3 etc. to be resolved individually, instead you have to use the OpenVPN environment variables such as $dev etc.

I've never had a problem.....where do you see it?

 

[Martineau]

I've never had a problem.....where do you see it?

Various firmwares on all three of the router models I have used RT-N66U/AC-56U/AC-68U....can't recall if it was as a result of your mod to vpnrouting.sh whilst RMerlin was AWOL?

NOTE: I have only ever experienced this spurious issue for openvpn-event......I didn't investigate in detail as clearly the reliable solution is to always reference the OpenVPN environment variables - after all, that's why they are there right?

P.S. @octopus stated that he initially changed "$P1" to "$1" and your script still didn't work until he followed my suggestion to use "$dev".

 

[webs0r]

Hi, with the beta I only get stats on downloads not uploads - see below:

 

[john9527]

Hi, with the beta I only get stats on downloads not uploads - see below:

Need to see your settings/rules....please post a screen shot of your main QoS page.

 

[webs0r]

Sure - thanks John.

 

[john9527]

Sure - thanks John.

View attachment 8031

Do you really want your upload bandwidth capped at 800 Kb/s? With the rounding problem in the current beta it may take a little while for some data to show up with that setting.

EDIT: BTW...nice set of rules. Only suggestion I might have is to put the DNS rule at the top of the list (I know it's a pain to have to delete and re-add everything, it's on my to-do list ). If you are comfortable with the command line, you could edit nvram qos_rulelist to move it.

 

[webs0r]

Ah OK. That's cool - if its because of a known issue, great, no rush. The upload bandwidth is right - we don't get much down under

Thanks. I'll try moving that line up.

 

[punchsuckr]

Something weird happened... I upgraded my speeds to 20mbit up/down and now getting A ratings for bufferbloat instead of the usual F and continuous +8000ms-with Qos set to bandwidth limiter i.e. off.

The actual upload speed, though, is approx half on dslreports tests (speedtest shows full as per the norm).

 

[punchsuckr]

Don't know whether it's a new bug on B4 though never noticed before, media server crashes when, after the library db is created, I switch to no on scan media on every boot option.

 

[john9527]

Don't know whether it's a new bug on B4 though never noticed before, media server crashes when, after the library db is created, I switch to no on scan media on every boot option.

Haven't touched anything there in ages. Thanks for the report, I'll take a look.

EDIT: @punchsuckr - Can't recreate any problem here. Is there anything in the .minidlna/minidlna.log file in your shared media directory?

 

[punchsuckr]

Haven't touched anything there in ages. Thanks for the report, I'll take a look.

EDIT: @punchsuckr - Can't recreate any problem here. Is there anything in the .minidlna/minidlna.log file in your shared media directory?

It's a mess in there and I don't know the time it crashed; I'll recreate the db again, first clearing away the file, then post back.

 

[punchsuckr]

Seems to have been a fluke or maybe the rebuild or cleaning the log file helped it some. It did happen twice though.

 

[n00b]

Is there anyway to check cpu usage for this? I tried 'top' command via putty but it is showing
CPU: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

Also, what is the normal temperature for 2.4 GHz - 5 GHz - CPU? I am getting 49C 54C 76C respectively. Is that safe in a long run?
Sorry if this has been asked before, I am new here.