Viktor Jaep
Part of the Furniture
Yeah, I'm really not quite sure what to make of it... <cough>TIMETOORDERTHATAX86U<cough>maybe the CPU timing is wrong.. Something is seriously wrong if it cannot get past that.
Yeah, I'm really not quite sure what to make of it... <cough>TIMETOORDERTHATAX86U<cough>maybe the CPU timing is wrong.. Something is seriously wrong if it cannot get past that.
I would order the RT-AX88U.Yeah, I'm really not quite sure what to make of it... <cough>TIMETOORDERTHATAX86U<cough>
I would order the RT-AX88U.
the RT-AX88U is undervalued by 14 percent. The RT-AX86U (although newer) is only under valued by 11 percent. For the BANG in your BUCK, the deal arguably resides with the RT-AX88U. In light of the firmware issues of the AX86U and the long term stability of the AX88U, my cards reside with the AX88U.What is your reasoning for this? Just curious…..
Hope it pans out in the long run. Remember the gold rush didn't hit all that were looking for it.Ha ha, how is the 'undervaluing' calculated?
When I sold my RT-AX88U for the RT-AX86U it was because the newer router was much better than the router I sold, the hit to that cost, and the hit to the newer routers (because by then, I wanted two of them).
Nothing is undervalued or overvalued. It is worth the price paid if it works for your needs.
Your gold rush???? Get it, you pan for gold (atleast with the california gold rush)? The analogy is panning for gold is similar to the risk.Hope what pans out???
At least by undervalue, you cut your loss when the gold doesn't pan out. Here is an interesting read for you:Sorry, this is over my head.
How is this related to how you calculate the undervaluing of the routers you mention?
Hey, Your niche is your niche. Not even an article can properly articulate your personal experience. Similar to mine.I know that definition of undervalued. I don't know how you're calculating yours though.
As I've stated, I put my money where my mouth was, and bought the superior RT-AX86U over the RT-AX88U. Even the price of a second RT-AX86U didn't put me off of the 'value' I was getting and still enjoying almost 18 months later.
And proven superior even to the much-vaunted GT-AX6000 too, in my network, with my network loads, and with the limited (2) units I tested with.
RT-AX86U vs. RT-AX88U
I would replace the sleep 2 with something a lot shorter, e.g. usleep 1000 (1 millisecond). Or 10 ms.Here's an example of an nvram wrapper. Realize I quite literally threw this together a few minutes ago. So it might need some refinement. But I just wanted to provide a quick-n-dirty example.
Bash:#!/bin/sh # copy original nvram executable to /tmp cp /usr/sbin/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 # required for serialization when reentry is possible LOCK="/tmp/$(basename $0).lock" acquire_lock() { until mkdir $LOCK &>/dev/null; do sleep 2; done; } release_lock() { rmdir $LOCK &>/dev/null; } # one instance at a time acquire_lock # catch premature exit and cleanup trap 'release_lock; exit 1' SIGHUP SIGINT SIGTERM /tmp/_nvram $@ rc=$? # any concurrent instance(s) may now run release_lock exit $rc EOF chmod +x /tmp/nvram # replace nvram in /usr/sbin w/ nvram wrapper in /tmp mount -o bind /tmp/nvram /usr/sbin/nvram
The idea is to FORCE every reference to the nvram executable threw the above script, which enforces one-at-a-time semantics.
I would replace the sleep 2 with something a lot shorter, e.g. usleep 1000 (1 millisecond). Or 10 ms.
Overall, I don't quite get it though. How would this solve the problem, rather than just moving it upstream?
Don't we need proper serialization instead? E.g. create a big enough buffer and enqueue any nvram command to the buffer, so that they execute neatly after one another, rather than concurrently.
I remember your lock implementation in openvpn sync route script. I am still using this script.Here's an example of an nvram wrapper. Realize I quite literally threw this together a few minutes ago. So it might need some refinement. But I just wanted to provide a quick-n-dirty example.
Bash:#!/bin/sh # copy original nvram executable to /tmp cp /usr/sbin/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 # required for serialization when reentry is possible LOCK="/tmp/$(basename $0).lock" acquire_lock() { until mkdir $LOCK &>/dev/null; do sleep 2; done; } release_lock() { rmdir $LOCK &>/dev/null; } # one instance at a time acquire_lock # catch premature exit and cleanup trap 'release_lock; exit 1' SIGHUP SIGINT SIGTERM /tmp/_nvram $@ rc=$? # any concurrent instance(s) may now run release_lock exit $rc EOF chmod +x /tmp/nvram # replace nvram in /usr/sbin w/ nvram wrapper in /tmp mount -o bind /tmp/nvram /usr/sbin/nvram
The idea is to FORCE every reference to the nvram executable threw the above script, which enforces one-at-a-time semantics.
Hung one.
Code:Every 0s: strace -r nvram get wan0_enable 2022-06-14 19:15:30 .... 0.000000 execve("/bin/nvram", ["nvram", "get", "wan0_enable"], 0x7fea378f88 /* 18 vars */ <unfinished ...> 0.000698 [ Process PID=1098 runs in 32 bit mode. ] strace: WARNING: Proper structure decoding for this personality is not supported, please consider building strace with mpers support enabled. 0.000061 rt_sigaction(SIGRTMIN, {sa_handler=0xf6e8e278, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0xf6fe4b10}, NULL, 8) = 0 0.000064 rt_sigaction(SIGRT_1, {sa_handler=0xf6e8e35c, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0xf6fe4b10}, NULL, 8) = 0 0.000063 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 0.000055 ugetrlimit(RLIMIT_STACK, {rlim_cur=2048*1024, rlim_max=RLIM_INFINITY}) = 0 0.000210 mmap2(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf6e69000 0.000084 stat64("/jffs", 0xffb8e7a0) = 0 0.000055 stat64("/jffs/nvram_war", 0xffb8e7a0) = 0 0.000117 socket(AF_NETLINK, SOCK_RAW, 0x1f /* NETLINK_??? */) = 3 0.000078 bind(3, {sa_family=AF_NETLINK, nl_pid=1098, nl_groups=00000000}, 12) = -1 EADDRINUSE (Address already in use) [/QUOTE] I tried digging into this a bit. It feels like it might be a similar problem to a [URL='https://bugs.chromium.org/p/chromium/issues/detail?id=1224428']Chromium bug[/URL] which was related to calling bind() with a pre-filled PID for the AF_NETLINK socket, rather than setting it to zero and letting the kernel fill in the parameter. I don't have my own asuswrt build to debug with at the moment, but it looks like there are some binary blobs in the tree which implement jffs_nvram_get() and friends. I can't tell if that is where this is coming from, but I suspect it might be. I did find some code in shared/rtstate.c which looks to be doing a similar socket/bind sequence and which is filling in the nl_pid field, but I couldn't track down any calls to that function. I haven't done any AF_NETLINK socket programming before, but the [URL='https://github.com/pilebones/go-udev/issues/3#issuecomment-478353905']docs I found[/URL] seem to indicate that the nl_pid should typically be set to zero to allow the kernel to fill it in rather than filling it with the result of getpid().
You can do@eibgrad Thanks!
I'll give it a try. Now, before I do, could you guide me how to switch this on and off for testing purposes?
This is the part that redirects the nvram commands to your script, right?
mount -o bind /tmp/nvram /usr/sbin/nvram
umount /usr/sbin/nvram
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!