What's new

My experience with the RT-AC86U

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

maybe the CPU timing is wrong.. Something is seriously wrong if it cannot get past that.

try this?

Code:
#!/bin/sh
trap '' HUP INT QUIT ABRT TERM
(i="0"
while true; do
  i="$(( i + 1 ))";
  for nv in 1 2 3 4 5; do
    unset "state${nv}";
    [ "$(ps -T | grep "nvram get" | wc -l )" -le "2" ] && eval "state${nv}"="$(/bin/nvram get vpn_client${nv}_state)";
  done
  clear
  echo "$state1" "$state2" "$state3" "$state4" "$state5"
  echo "$i"
done) > /tmp/mynvramerror.log 2>&1 &
exit 0

or

Code:
#!/bin/sh
trap '' HUP INT QUIT ABRT TERM
(i="0"
until [ "$(ps -T | grep "nvram get" | wc -l )" -gt "2" ]; do
  i="$(( i + 1 ))";
  for nv in 1 2 3 4 5; do
    unset "state${nv}";
    [ "$(ps -T | grep "nvram get" | wc -l )" -le "2" ] && eval "state${nv}"="$(/bin/nvram get vpn_client${nv}_state)";
  done
  clear
  echo "$state1" "$state2" "$state3" "$state4" "$state5"
  echo "$i"
done) > /tmp/mynvramerror.log 2>&1 &
exit 0
Thanks for another go at this, @SomeWhereOverTheRainBow... ;) Your first bit of code yielded similar results. Everything is mostly blank, with a few exceptions where it was able to squeeze an nvram call in there:
1655295396181.png


The second bit of code seemed to quit right after it ran, and the log file was blank.
 
Thanks for another go at this, @SomeWhereOverTheRainBow... ;) Your first bit of code yielded similar results. Everything is mostly blank, with a few exceptions where it was able to squeeze an nvram call in there:
View attachment 41890

The second bit of code seemed to quit right after it ran, and the log file was blank.
Yea the process really needs serialization have you tried with @eibgrad nvram wrapper?
 
False start.
admin@RT-AC86U:/jffs/scripts# ./nvram.sh
cp: can't stat '/usr/sbin/nvram': No such file or directory
mount: mounting /tmp/nvram on /usr/sbin/nvram failed: No such file or directory
admin@RT-AC86U:/jffs/scripts# find / -name nvram
/bin/nvram
/tmp/nvram
/jffs/nvram
/proc/nvram
I guess I need the one from /bin.
 
Thanks for another go at this, @SomeWhereOverTheRainBow... ;) Your first bit of code yielded similar results. Everything is mostly blank, with a few exceptions where it was able to squeeze an nvram call in there:
View attachment 41890

The second bit of code seemed to quit right after it ran, and the log file was blank.
Code:
#!/bin/sh
trap '' HUP INT QUIT ABRT TERM
(i="0"
while true; do
  i="$(( i + 1 ))";
  for nv in 1 2 3 4 5; do
    unset "state${nv}";
    [ "$(ps -T | grep "nvram get" | wc -l )" -gt "1" ] && sleep 1
    eval "state${nv}"="$(/bin/nvram get vpn_client${nv}_state)";
  done
  clear
  echo "$state1" "$state2" "$state3" "$state4" "$state5"
  echo "$i"
done) > /tmp/mynvramerror.log 2>&1 &
exit 0

Would probably be better.
 
Tried the eibgrad hack.
Stuck predictably.
Code:
0 0 0 0 0
2699
I can see the override is used but doesn't change the outcome.
The nvram function must be blocking itself if the serialization is working. I.e., it fails on its own.
 
Since serialization attempt didn't work, can we do something else - wrap the nvram command in a timeout call, so it doesn't block entire processes when it fails? Or even better, try nvram get, if it doesn't respond in a second or two, kill it, try again and if it doesn't respond again, exit and move on?
I've just done step 1 which is installing the timeout utility: opkg install coreutils-timeout
Next I'd like to try something like timeout 2 nvram get whatever, then check if whatever has a value, if not, run a second timeout 2 nvram get whatever and continue...

@Tech9 Remember when I complained after all criticism that I was under the impression my router would fail any moment? :)
Turns out it was already failing, I just wasn't aware. It takes time for stuck processes to accumulate and I didn't have htop to see it.

Update
I can answer my own question. I used the eibgrad hack as a template, commented out the locking part and added timeout: timeout 1 /tmp/_nvram $@
The result: got to 20,000 iterations with no hang ups.
Now, I don't dare let the system run like this because I don't know if timeout is accessible to root like it is to me in the console. For example, I noticed that in the PuTTY console I get to use one find function while the router internally uses another more basic version. I checked and the $PATH variable for me is different to the one the router uses when executing the post-mount script, for example.
 
Last edited:
Code:
bind(3, {sa_family=AF_NETLINK, nl_pid=1098, nl_groups=00000000}, 12) = -1 EADDRINUSE (Address already in use)
The difference.
@dave14305 Can you try strace'ing a variable that's been moved jffs? Notice how it doesn't use netlink but normal file IO, with locking. Just curious at what point it fails, or maybe it doesn't.
Code:
strace -r nvram get dhcp_staticlist
 
@Tech9 Remember when I complained after all criticism that I was under the impression my router would fail any moment?

This router, if you have IPv6 enabled plus NAT acceleration, the syslog turns into Niagara Falls from kernel errors.
 
I'm sharing my version but the [ -z "$rc" ] condition is not good, neither is [ ! -n "$rc" ]. At least according to the system log this is never true. Nothing was reported even after I reached 50,001.
Bash:
#!/bin/sh

# copy original nvram executable to /tmp
cp /bin/nvram /tmp/_nvram

# create nvram wrapper that calls original nvram executable in /tmp
cat << 'EOF' > /tmp/nvram
#!/bin/sh
#set -x # comment/uncomment to disable/enable debug mode

timeout 1 /tmp/_nvram $@
rc=$?

# this retry part doesn't work, do something else; what if the the command is nvram set?
#if [ -z "$rc" ]; then
#   usleep 1000
#   logger -t "nvram override" "Couldn't execute nvram $@"
#   timeout 1 /tmp/_nvram $@
#   rc=$?
#   logger -t "nvram override" "Retried executing nvram $@: $rc"
#fi

exit $rc
EOF
chmod +x /tmp/nvram

# replace nvram in /usr/sbin w/ nvram wrapper in /tmp
mount -o bind /tmp/nvram /bin/nvram
 
Last edited:
I'm sharing my version but the [ -z "$rc" ] condition is not good, neither is [ ! -n "$rc" ]. At least according to the system log this is never true. Nothing was reported even after I reached 50,001.
The timeout command will always fail (rc=127) because it's an Entware command and you haven't setup the Entware paths in the nvram script.
 
The timeout command will always fail (rc=127) because it's an Entware command and you haven't setup the Entware paths in the nvram script.
So there has to be a check first if Entware is there, then if the timeout command is there (it's an extra) and finally set the path.
By setting the path you mean export $PATH:entware places, right?
 
So there has to be a check first if Entware is there, then if the timeout command is there (it's an extra) and finally set the path.
By setting the path you mean export $PATH:entware places, right?
Yes. I think all you'd need is export PATH=/opt/bin:/opt/sbin:$PATH
 
Ok. I'll add that. /opt/bin and /opt/sbin have to go in front?
I'm sure my implementation is lousy. There is also a performance hit because every call to nvram now invokes additional call to timeout. I could see it executing a bit slowlier than before.
Probably the gurus here would know a better way to do this.

Added the paths. No luck with the logger. I'm missing something more.
 
Last edited:
Ok. I'll add that. /opt/bin and /opt/sbin have to go in front?
Actually, checking this it looks like I was wrong. At least on my RT-AX86U /opt/sbin:/opt/bin is already in the path. Maybe your firmware is different. Try running the script in debug mode.
 
Ok. I'll add that. /opt/bin and /opt/sbin have to go in front?
I'm sure my implementation is lousy. There is also a performance hit because every call to nvram now invokes additional call to timeout. I could see it executing a bit slowlier than before.
Probably the gurus here would know a better way to do this.

Last I recall, @Viktor Jaep had already tried using timeout (at my suggestion). At least while experimenting. But as a long term solution, while it will allow the script to continue, the call to nvram still fails. Or do we know the call only hangs *after* the is value is successfully gotten or set?
 
I've never experienced this with nvram set.
As for nvram get - it doesn't return a value. If you see behind, the actual error is already known, thanks to dave14305: EADDRINUSE (Address already in use).

That's why I wanted to have the stuck operation killed and issue the same a second time, so it can fetch the requested value.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top