NanoPi R4S rk3399 R6S RK3588S 4G is a great new OpenWrt device

What's the reason for the (potential) switch from R4S to RPi4?

What's wrong with your R4S experience?

I'am using pppoe on eth0. But I dont have any issues with cake on interface pppoe-wan.
My connection is 100/37

Do you use stable/rc release or snapshot/own build ?

Like I mentioned, I encountered the reboot issue and don't like how they handled it. Prior to that, I was very happy with the devices. I'm confident that, once I figure out this SquashFS issue, the RPi4 will be a more mature and well supported option.

1 Like

I’m using 4 RaspberryPI in my LAN but no one is a router, and I would never use it to routing my WAN connection for different reasons: now WAN port, no good OpenWrt support, too much ports/things to be a router (hdmi, audio, etc..), the GPU, and a bit less powerful than the R4S. It’s also more expensive now. So I don’t understand why your choice.

At the moment I haven’t any trouble with the R4S, despite is a quite new device. When it will become more supported by OpenWrt, I’ll switch to the R5S, not to a RaspberryPI, because I think it’s not the right device to act as a router. :slight_smile: but this is only my personal preference/idea.

I don’t have encountered the issues you reporter. My only issue is the microSD cars, I would have preferred a built-in storage.

rc5 and rc6.

no worries :slight_smile:

I tried enabling trace debug; there's nothing printed during the test, but the enabling of SQM showed this:

Fri Aug  5 16:03:26 2022 user.notice SQM:
Fri Aug  5 16:03:26 2022 user.notice SQM: Fri Aug  5 16:03:26 IDT 2022: Starting.
Fri Aug  5 16:03:26 2022 user.notice SQM: Starting SQM script: piece_of_cake.qos on pppoe-wan, in: 550000 Kbps, out: 58000 Kbps
Fri Aug  5 16:03:26 2022 user.notice SQM: fn_exists: function candidate name: sqm_start
Fri Aug  5 16:03:26 2022 user.notice SQM: fn_exists: TYPE_OUTPUT: sqm_start: not found
Fri Aug  5 16:03:26 2022 user.notice SQM: fn_exists: return value: 1
Fri Aug  5 16:03:26 2022 user.notice SQM: Using generic sqm_start_default function.
Fri Aug  5 16:03:26 2022 user.notice SQM: fn_exists: function candidate name: sqm_prepare_script
Fri Aug  5 16:03:26 2022 user.notice SQM: fn_exists: TYPE_OUTPUT: sqm_prepare_script is a function
Fri Aug  5 16:03:26 2022 user.notice SQM: fn_exists: return value: 0
Fri Aug  5 16:03:26 2022 user.notice SQM: sqm_start_default: starting sqm_prepare_script
Fri Aug  5 16:03:26 2022 daemon.err modprobe: failed to find a module named act_ipt
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link add name SQM_IFB_c5f07 type ifb
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_c5f07 type ifb
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc replace dev SQM_IFB_c5f07 root cake
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_c5f07 root cake
Fri Aug  5 16:03:26 2022 user.notice SQM: QDISC cake is useable.
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev SQM_IFB_c5f07 down
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_c5f07 down
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link delete SQM_IFB_c5f07 type ifb
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_c5f07 type ifb
Fri Aug  5 16:03:26 2022 daemon.err modprobe: failed to find a module named act_ipt
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link add name SQM_IFB_0effa type ifb
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_0effa type ifb
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc replace dev SQM_IFB_0effa root cake
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_0effa root cake
Fri Aug  5 16:03:26 2022 user.notice SQM: QDISC cake is useable.
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev SQM_IFB_0effa down
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_0effa down
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link delete SQM_IFB_0effa type ifb
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_0effa type ifb
Fri Aug  5 16:03:26 2022 user.notice SQM: sqm_start_default: Starting piece_of_cake.qos
Fri Aug  5 16:03:26 2022 user.notice SQM: ifb associated with interface pppoe-wan:
Fri Aug  5 16:03:26 2022 user.notice SQM: Currently no ifb is associated with pppoe-wan, this is normal during starting of the sqm system.
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link add name ifb4pppoe-wan type ifb
Fri Aug  5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name ifb4pppoe-wan type ifb
Fri Aug  5 16:03:27 2022 user.notice SQM: fn_exists: function candidate name: egress
Fri Aug  5 16:03:27 2022 user.notice SQM: fn_exists: TYPE_OUTPUT: egress is a function
Fri Aug  5 16:03:27 2022 user.notice SQM: fn_exists: return value: 0
Fri Aug  5 16:03:27 2022 user.notice SQM: egress
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: invocation silenced by request, FAILURE either expected or acceptable.
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc del dev pppoe-wan root
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev pppoe-wan root
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: LAST ERROR: Error: Cannot delete qdisc with handle of zero.
Fri Aug  5 16:03:27 2022 user.notice SQM: LLA: default link layer adjustment method for cake is cake
Fri Aug  5 16:03:27 2022 user.notice SQM: cake link layer adjustments:  overhead 44 mpu 0
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc add dev pppoe-wan root cake bandwidth 58000kbit overhead 44 mpu 0 besteffort
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev pppoe-wan root cake bandwidth 58000kbit overhead 44 mpu 0 besteffort
Fri Aug  5 16:03:27 2022 user.notice SQM: sqm_start_default: egress shaping activated
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link add name SQM_IFB_f6872 type ifb
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_f6872 type ifb
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc replace dev SQM_IFB_f6872 ingress
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_f6872 ingress
Fri Aug  5 16:03:27 2022 user.notice SQM: QDISC ingress is useable.
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev SQM_IFB_f6872 down
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_f6872 down
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link delete SQM_IFB_f6872 type ifb
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_f6872 type ifb
Fri Aug  5 16:03:27 2022 user.notice SQM: fn_exists: function candidate name: ingress
Fri Aug  5 16:03:27 2022 user.notice SQM: fn_exists: TYPE_OUTPUT: ingress is a function
Fri Aug  5 16:03:27 2022 user.notice SQM: fn_exists: return value: 0
Fri Aug  5 16:03:27 2022 user.notice SQM: ingress
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: invocation silenced by request, FAILURE either expected or acceptable.
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc del dev pppoe-wan handle ffff: ingress
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev pppoe-wan handle ffff: ingress
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: LAST ERROR: Error: Invalid handle.
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc add dev pppoe-wan handle ffff: ingress
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev pppoe-wan handle ffff: ingress
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: invocation silenced by request, FAILURE either expected or acceptable.
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc del dev ifb4pppoe-wan root
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev ifb4pppoe-wan root
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: LAST ERROR: Error: Cannot delete qdisc with handle of zero.
Fri Aug  5 16:03:27 2022 user.notice SQM: LLA: default link layer adjustment method for cake is cake
Fri Aug  5 16:03:27 2022 user.notice SQM: cake link layer adjustments:  overhead 44 mpu 0
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc add dev ifb4pppoe-wan root cake bandwidth 550000kbit overhead 44 mpu 0 besteffort wash
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev ifb4pppoe-wan root cake bandwidth 550000kbit overhead 44 mpu 0 besteffort wash
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev ifb4pppoe-wan up
Fri Aug  5 16:03:27 2022 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::2a6f:7fff:fe2a:ee00%pppoe-wan: Address not available
Fri Aug  5 16:03:27 2022 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::2a6f:7fff:fe2a:ee00%pppoe-wan: Address not available
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev ifb4pppoe-wan up
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc filter add dev pppoe-wan parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb4pppoe-wan
Fri Aug  5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc filter add dev pppoe-wan parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb4pppoe-wan
Fri Aug  5 16:03:27 2022 user.notice SQM: sqm_start_default: ingress shaping activated
Fri Aug  5 16:03:27 2022 user.notice SQM: piece_of_cake.qos was started on pppoe-wan successfully

There are a lot more problematic-looking prints than I'd like to see, but it doesn't seem like there's anything actually wrong, just a bunch of deletes that don't check first if the thing to be deleted exists (plus the ip tables modprobe)

I... I just realized I'm an idiot.

Because all of my devices are on Wi-Fi (or wired to an access point acting like a client), I've always run the speedtests on my router itself. This lets me max out both my download and my upload (my wifi speeds are normally limited to about 200Mbps). However, the speedtest CLI on the arm chip is apparently what's lying to me about the upload. It was telling me 560 (no SQM) and 510 (SQM) for download, and 50 (no SQM) and 10 (SQM) for upload. However, if I run from my laptop, I get a consistent 200 down (limited by Wi-Fi) and 55 or 50 up, which is what I was expecting.

I don't see it being CPU limited on any of the cores via htop, but maybe there's something else in the client that's being limited. In any case, it's clearly the executable that's lying, and not the line itself (I am using the native version from ookla, not the python version).

Thanks for all your help. Sorry for wasting your time on this!

(I'm using SQM even though I have the wifi limits because (a) I can saturate the upload and (b) the 200Mbps is per client, but I can do several at 200 at the same time)

2 Likes

So the trouble was Speedtest (ookla), I had a similar trouble, I’ve also opened a new post some months ago, IIRC from the app (running on the iPad) I was also having low speed. From the website instead, all was fine.

I don’t use anymore Ookla app, and I run the Speedtest on different services, dslreport, waveform, etc.. Speedtest is okay just for a quick test but I wouldn’t trust it alone.

Anyway you solved this weird issue :+1:

1 Like

if you really want to use a pi as gateway?

at least use this to make it dual ports.

2 Likes

Of course friendlyelec will have their own thing, i mean its the only way to have new devices supported really fast right before\after oficial release of the hardware itself, in other words, imagine trying to add new devices to oficial openwrt right before they launch? It would be a nightmare! Even more if things needs to get changed right before or after launch...
Using official openwrt only, it would also leak new devices a long time before they are actually released which would be bad for such company, and the last reason is that with them having their own thing, means full control to change stuff, fix, improve, remove, add and etc, whenever they need\want.

Openwrt takes too long to do anything on the official repo, its volunteer work and the system itself supports so many devices which makes everything slower and more complicated.

Example of how long stuff takes below

A really small change:

It took almost 1 year for this simple change to get merged, it just went into limbo.

The reboot issue:

Only got merged cause me + a lot of other people from this topic went to the PR and started making noise! Otherwise it would go into limbo as well. It was suppose to solve the issue, but it does not seem to fix it, not for everybody at least since you are here complaining.

Initial support for the r4s?

Took 6 months before it was supported.

This pr for proper kernel 5.15 support?

It has been tested, but it doesn't move forward! Its almost 2 months old already.

So yeah it makes all the sense in the world for friendlyelec to have their own openwrt repo that focus on their hardware.

PS: I am not hating on oficial openwrt repo, i am just pointing to a fact that a lot of stuff and a lot of the time takes too long to be done, at least things related to the rockchip architecture it seems?

To me you should cooperate a little bit, in other words, you can use the following logic to have the following conclusion:

1 - Try friendlywrt, to see if the problem happens there...
2 - It does? Then you report to friendlyelec with logs if possible and tell then that this is a major issue!
3 - Wait until they fix it, because its their obligation to do so.
4 - Port the code that fixes the issue using a pr into official openwrt repo.
5 - Congratulations, now you can use oficial openwrt with the problem solved!

If i had this issue, i would had done this already tbh! But with my custom snapshot build using kernel 5.15 + uboot patches from friendlywrt repo + driver r8168 i have no such problem, meaning that i can reboot my r4s using shell or the web interface as many times as i want and it will boot properly every time.

Of course i also think that friendlyelec should upstream stuff into official openwrt, but they dont... So there isn't much that we can do besides asking them to do it, but i don't think they will!

I 100% disagree and i am not happy at all with their decision to not upstream important fixes and improvements.

One of the reasons they dont(i guess), is that not everything will be accepted the way they want to do it!

Like these uboot patches:

301 to 308 which are also suppose to fix the reboot issue + other problems... They are doing it as uboot patches but it seems that official openwrt would not accept this and they would need to upstream it to the uboot repo just like the oficial openwrt repo did not accept the uboot patch that adds support for the 1gb version of the r4s and thats why oficial openwrt does have support for the 1gb version.

In other words, friendlyelec needs their own thing cause they need full control... But having their own thing and also trying to upstream stuff to the oficial repo it would be too much work since things will need to be done differently or a lot differently which requires double work to fix the same issue, so they don't do it.

5 Likes

If i am not mistaken, this one is better:

I think this video shows several tests showing that the one above works better /\

Not sure if this is still the case or not :smiley:

1 Like

either is better than base pi. the pi itself is powerful its just lacking the dual ports for wan/lan and its pitiful wifi makes for a poor router. Its why i got an R4S. its the pi with steroids and i just use ubiquiti wifi with docker on the r4s. simples :slight_smile:

:edit: also the pi has no hardware encryption cos they didnt pay the licence which is VERY important for VPNs
see here for more

2 Likes

Hey guys, have the latest snapshots incorporated the updated kernel yet? I want to install docker but the kernel is out of date.

I fully understand the reasons behind all this. However, that doesn't change the reality; for a lot of users, who just want a device to work, the R4S currently has some problems.

That said, RPi4 is not without issues. I have given up on getting SquashFS working and my Z-Wave dongle mysteriously doesn't work, over a USB extension cable. These are dealbreakers. The PSU has more than enough power, so I'm not wasting time on it. The R4S has neither of those issues, so I am back on the R4S now and just have to live with the problems.

On that note, how does one use the FriendlyElec U-Boot?

Give his releases a go. plus he has docker built in.

4 Likes

Before trying to do a custom openwrt build to include the uboot patches from friendlywrt, you should try actually running friendlywrt 22.03:

https://drive.google.com/drive/folders/1_uJIkMynmSp9oKTFmOYWNx5ZhQba0zzv

To see if you are going to have any reboot issues, cause if they dont happen with friendlywrt 22.03 then the uboot patches are working properly and if you do a build of openwrt with them included it is suppose to work as well.

1 Like

@jaredoconnor you can try this build as well, just like @mercygroundabyss suggests above...

Its basically official openwrt but its using driver r8168 instead of driver r8169 + 8169 firmware and it also includes a patch to fix the reboot issue, this patch is the first one that actually fixed the issue and it comes from immortalwrt.

But it seems that friendlywrt approach to fix the issue seems to be the best one between all of the solutions which are differently in openwrt, immortalwrt and friendlywrt.

2 Likes

@mercygroundabyss , thanks a ton mate.
Quick question and a n00b one at that, I'm already using the snapshoot release from Openwrt. Which release should I use that will allow me to use Openwrt's built in upgrade (i'll do a full factory reset as well)?

I'd like to avoid having to use Belena Etcher and gParted again.

i just have a pair of 32gb sdcards and i drop the new image on a 2nd one and copy over the 3rd partition (which holds my /opt folder with my docker stuff) to it.

Plus a clean install now and then is always good. I have a checklist too to make sure config is good. (i ssh over some things and reboot for most tweaks)

Thanks, I did the upgrade and ended up having to whip out gParted anyway xD.
Now onto figuring out how to mount my network NAS through OpenWRT and into Docker.

1 Like