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

So, I went on a quick research and I've found this: https://openwrt.org/docs/techref/filesystems
It turns out that squashfs has its own problems on NAND Flash too. JFFS2 looks better in terms of wear leveling and so on. I have to admit that by no means I'm a specialist on this matter. But I think the discussion is valid as this equipment uses mainly SD Card storage.

You can easily resize your root partition, use resize2fs and tune2fs on OpenWrt itself.

  1. Install the required tools
opkg update
opkg install parted tune2fs resize2fs
  1. Start the parted utility
# parted
(parted) print                        //note the root parition number
(parted) resizepart 2 11000           //this will set the 2nd partition(root) end to 11GB
(parted) print                        //verify new partition end and size
(parted) q                            //exit parted
  1. remount root as RO (if fails, reboot and remount as ro)
mount -o remount,ro /
  1. Remove reserved GDT blocks (workaround as online resizing of root partition fails)
tune2fs -O^resize_inode /dev/mmcblk0p2        #verify your root parition
fsck.ext4 /dev/mmcblk0p2                      #answer y to all
  1. Reboot and
resize2fs /dev/mmcblk0p2
  1. Check new root partition size with:
df -h
7 Likes

There's no parted in RC4. Is there an alternative utility?

You can always install the ipk from snapshot.

https://downloads.openwrt.org/snapshots/packages/aarch64_generic/packages/parted_3.4-1_aarch64_generic.ipk

1 Like

Using Armbian as the host OS will be fine in your case.

One thing to be aware of running an OpenWRT router as a container -- I did it for several years -- is that the host OS is responsible for the most of the tuning that can affect NIC performance and network throughput. In other words, OpenWRT's kernel and driver default settings have been continually optimized over the years to work well out of the box as a network appliance. As a container, OpenWRT has no control over these things. So expect to have to tune sysctl settings and other details in the host OS to get the same results out of it.

I am planning to buy the R4S. Can you please confirm that WAN is RTL8211E and LAN is PCIE RTL8211H (or is it RTL8111H?) as shown in this image https://www.friendlyarm.com/image/catalog/description/R4S_en_07.jpg and https://www.friendlyarm.com/image/catalog/description/R4S_en_05.jpg ?

So based on your post, RTL8211H is working fine with VLANs but RTL8211E has problems. Is that right?

Hi I can confirm the wan NIC doesn't see the VLAN tagged packets, unless you enable the promiscuous mode.

A possible workaround (I use at home) is to execute a script with a single command at boot time to enable promiscuous mode. But unsure if it has any impact on performance. A quick (unoptimized) benchmark reached >650Mb/s TCP with LAN to WAN routing + VLAN on WAN side + IPv4 encapsulated in IPv6).

Also, setting a custom MTU doesn't work too on WAN NIC.

1 Like

RTL8211E is a PHY transceiver chip connect to wan through usb bus. Lan is ethernet controller RTL8111H chip.
Yep, RTL8111H vlans work without issues, 8211E need enable promis mode.

1 Like

So as a last resort I tried writing the snapshot image to a different SD card. And boom, it worked perfectly. So annoying to discover it was a bad card that was keeping it from booting!

I'm sharing my build that I compiled today, after a lot of trial and error this has been stable for me and able to run ntopng in containerd. EXT4 with docker too.

To run ntopng as a virtualized container on my image follow the README.md in https://github.com/TheLinuxGuy/openwrt-ntopng

I haven't fix the github actions to auto-compile yet. I don't know when I will get to it.

Compiling raw openwrt using my .config was crashing when rebooting R4S; so ended up mixing some of anerlosky tweaks and patched immortalwrt code. This has made it stable and usable. It has NAT6 support built-in.

https://drive.google.com/file/d/18BM8WukT3MLf58VyxIPm1JhDKwp0IDs-/view?usp=sharing

I’m really split between this device or the raspberry pi 4b.

Has anyone confirmed if this can sqm with a 1 gig line?

Also can I build a solid master snapshot for this device yet?

I’d be using this for a pppoe connection 910 down and 110 up and shaping it through sqm before handing off to a switch.

Thanks all

1 Like

It's too near the theoretical limit of the interfaces but this little buddy is very powerful. There's some tests already done and posted here and they go a little bit further then 910Mbps without pppoe, I think. My guess is if both devices (R4S and RPi4b) have PCI-E backed interfaces (as R4S has), they may have similar performance.
If you need to get the maximum speed, maybe you'll have to look for a 2.5Gbps device...
Just trying to help thinking, maybe someone here has better insights.

2 Likes

The RPI4b has a maximum MTU of 1500.

You won't be able to PPPoE with 1508, you wont be able to use any encapsulation method without inducing fragementation, or being forced to lower your LAN from the standard 1500. No Jumbo-frames.

Oh, and the Wifi can't do 802.11s (Meshing), and is also locked at MTU 1500. Networking-wise, i consider the RPI4 underwhelming.

So a hard NO for me.

2 Likes

Are most devices not restricted to 1500 MTU though and operate at 1492 without issue using pppoe in openwrt?

Just wondering what the NanoPi R4S would operate like as a hand off to a managed switch.

I'm thinking that EXT4 based image targets should include this resizing script (most likely fine-tuned for each device's specifics). It's already a pain in the ass to do updates on EXT4, and squashfs based builds for indeterminate flash size targets (i.e. SD cards, x86 builds) cannot be expanded...

Sure, you can run your PPPoE at MTU at (1500-8=1492), but then any full-size MTU 1500 package from your LAN will need to be be split because of those extra 8. That will cost performance. So, if your ISP allows an MTU of 1508 on the WAN-ETH link, you can have MTU 1500 on your PPP-Device.

ath9k support 2304. ath10k 1662, MT76xx and many others can go higher than 1500. Of the top of my head I only know of Realtek, Broadcom, than wont support neither MTU>1500 nor 80211.s mesh. (In the devices I've looked at more closely)

1 Like

Looks like despite the patches being in from june, the R4S is NOT in the recent 21.02 release still.

Index of /releases/21.02.0/targets/rockchip/armv8/ (openwrt.org)

I purchased a 128gb SD card for NanoPi R4S 4GB. I am trying to do a dual firmware setup like Linksys devices. I found this OpenWrt A/B Upgrades [https://github.com/pyther/openwrt-sysupgrade-ab] . However it is for x86 not ARM. I am not knowledgeable to make it for Nanopi R4S.

Are there any detailed guidance I can follow to multiboot Nanopi R4S? I appreciate your help.

Dual firmware setup like Linksys is as follows :

  • Setup SD card "A" using usual documented procedures.
  • Setup SD card "B" using same usual documented procedures
  • Boot SD "A" and use it as you should
  • When you put yourself in trouble with SD "A", shutdown
  • Remove SD "A" and replace with SD "B"
  • Boot with SD "B"
  • OpenWrt running from SD "B" is now active

The fact SD is removable IS dual/triple/quadruple firmware setup, just because SD is removable.

Linksys routers don't have removable boot storage, that's why they need dual firmware recovery scheme...

3 Likes