NanoPI R2S is a great OpenWrt device

Does the USB NIC cause any lag or have any limitations? I was considering buying this device so I can take advantage of SQM, but I don't want to purchase if it could potentially increase my ping in games.

No. I've tested both NICs with iperf and fio to a usb memory stick at the same time and the iperf results returned about 940mbps. This is an awesome device - the only downside to the hardware is the usb2.0 port. If that was USB 3.0 this device would be perfect.
The bigger issue for the NanoPi R2S is the lack of a stable openwrt image. The FriendlyWRT image is not secure (it's a great demo but not suitable for use by beginners as needs a lot of work to make it secure on the WAN interface). The OpenWRT snapshots need intermediate+ openwrt experience to install and configure a useful feature set.
I've now bought 2 of these, highly recommended if you can spare the time.

1 Like

Hi, is available a firmware based on snapshot with a GUI and a set of basic plugins for security e privacy? I can try to do myself if there is a tutorial that list the basic plugin set to install.
I need only a basic set of plugins like clients OpenVPN / WireGuard / TOR, VPN policies, DNS over TLS and Dnscrypt-Proxy, Firewall....etc....for use in Europe.

Thanks, zWolf

PS english language firmware

Is something wrong with the daily built?
I had some sparetime and want to update the router. I get internetconnection but installing Luci fails:

root@OpenWrt:~# opkg install luci
Package luci (git-20.305.75999-ea61f5d) installed in root is up to date.
Collected errors:
 * opkg_conf_parse_file: Duplicate src declaration (openwrt_kmods Skipping.
root@OpenWrt:~# opkg install luci
Package luci (git-20.305.75999-ea61f5d) installed in root is up to date.
Collected errors:
 * opkg_conf_parse_file: Duplicate src declaration (openwrt_kmods Skipping.

I am using the 30-10 snapshot:

How to solve this?

Edit: tried on 2nd SD card but I get the same error. Can anybody provide me the link to the snapshot from yesterday?

Edit 2: just tried the samewith the todays snapshot...still getting the same error.
How to solve this?

Edit 3: there seems to be a problem:
There is a recent change to okpg dependency handling that may be related:

I setup IPV6 but i couldn't seem to get pass test... anyone can get it working? I'm using pppoe protocol on WAN anyway.



vi /etc/okpg/distfeeds.conf

Insert "#" at the begin of the 4th line.

I'm trying to add support for rockchip on kernel 5.9, for anyone willing to help testing here is the source tree:

although some packages don't build yet , I got the R2S booting fine:


Have been using with everything strip-down to just what i need..

Just clone
add at end of ./SEED/config_no_docker.seed

Everything working and without china-bloat

EDIT: forgot to mention, the OC dont work for me, i just set cpu max freq to 120000 and no reboots

Absolutely, avoid USB3 NICs. It may check out with no problems during the iPerf test, but its performance will degrade with time, and it will require a hot unplug/ plug to restore the speed or even a reboot of the device running OpenWRT.

I have a solution on how to avoid the USB3 NIC and run OpenWRT on a single NIC. Check out my post of November 5, 2020.

Most probably you have faulty hardware , I haven't seen any performance degradation on the USB3 NIC used on the R2S.

Are you really sure, that this is valid for every USB3 NIC?

I can imagine, that there are some better devices and some worse devices (perhaps depending on the chipset and the related driver).

Would like to hear from other forum members, who had bad or good experiences.

Personally, I tested three different chipsets (all by Realtek): 8152, 8153, and 8156. I’ve tested them with OpenWRT and with macOS. They all have the same problem. The problem is well documented and the Internet is replete with this information. But besides the fact that Realtek may have a bug in their chipsets, the very foundation of the USB3 based bus is the problem with consistent rx and tx rates. To have a reliable and consistent network connection, the network controller should utilize the PCI bus. This is what Thunderbolt based NIC dongles do. Thunderbolt provides direct PCI bus to an external device.

The problem with USB-based devices are not only NIC specific, but also storage specific, Wi-Fi adapter specific, etc. Anything connected to a USB3 bus suffers inconsistent speed. I don’t need to be dissuaded because I’ve tested this thoroughly with multiple adapters with OpenWRT, with VMWare ESXi. and with MacOS. In ESXi and macOS I had a benefit of being able to compare the consistency of USB3 based NIC dongles with Thunderbolt based NIC dongles. Even though USB3 NIC dongles can appear fine on iPerf tests, their performance degraded with time measured sometimes in days and sometimes in hours. It may not be critical with a dongle connected to a computer, but it’s critical with a dongle connected to a router or a server.

Now that the Raspberry Pi foundation has released Compute Module 4 and the matching official IO board where they removed USB3, thus freeing up the PCI bus and providing a PCIe 1x connector on the IO board, NICs directly connected to the PCI bus on an SBC like the Raspberry Pi CM4 has become a reality. That’s the way to build routers going forward, by utilizing one or more NICs with a direct connection to the PCI bus. Because of the lack of cases for CM4 with IO board v4 at the time of this writing, one can use the workaround that I discovered, tested, and am using now, which allows one to utilize a single onboard adapter for both LAN and WAN interfaces to eliminate the flakiness of the USB3 based Ethernet dongle.

I do wish the Raspberry Pi foundation would release another version is the Raspberry Pi 4B where they would remove the USB3 bus and replace it with a second PCIe-bus attached Ethernet Controller. Better yet, if they could put two multi-Gigabit controllers on the board for using it as a high-throughput router/firewall. I would pay $60 for a 2-port multi-gigabit (1/2.5/5 Gbps) board with 2 GB of RAM.

I think what you're talking about are USB bus resets. I have seen that before on USB NICs and it caused the NIC to reset, and the operating system would see that as a device down and then up. All of that leaves traces in the kernel logs (dmesg). I've been running my NanoPi R2S as my home router for over a month now and haven't seen any such messages in the kernel or system logs. Nor earlier when I was stress testing the USB3 NIC and USB 2.0 port at the same time. I'm just not seeing the USB3.0 bus cause any issue or performance impact for this device.
I have a spare R2S that I can use for testing. If you can specify a workload that will demonstrate an issue, I'll do it and post the results.

Inconsistent results with speed tests to reliable and consistent servers, packet loss, high jitter, etc. The problem came and went. I was blaming the problem with the internet connection, or the congestion in the ISP network, or the problem with the test server,, etc. This went on for several days until my son’s music teacher told me that the video conference was simply terrible and he could not hear my son most of the time. The speedtest would result in an extremely poor upload and download throughput when this was happening. It got to the point that I had to swap out the firewalls and replace the OpenWRT WITH my previous pfSense box. It was only after I eliminated the USB3 dongle that everything went back to normal: the speed tests became consistent again,

I had the same phenomenon in macOS when I was hard-wired via a USB3 Gigabit Ethernet adapter. I tried three different USB3 and Thunderbolt3 docks with built-in rtl8152 chip connecting to the Mac via a USB 3 controller. Unfortunately, even TB3 docks do not provide a PCI connection to the NIC, as I’m sure dock manufacturers try to reduce their costs. I’ve also tried two USB3 dongles (rtl8153 and rtl8156), and all of them had a similar effect. To restore full throughput I had to unplug the Thunderbolt 3 dock or the USB3 Ethernet adapter and then plug it back in.

So, this was nothing that I could catch when iI was running iPerf tests through the OpenWRT box with the LAN interface being on the USB3 Gigabit Ethernet dongle. This condition would occur several hours after the USB3 Ethernet dongle was connected to the Raspberry Pi. Since I eliminated the USB3 -based NIC, I didn’t have this issue even once in the last 2 weeks that I have been running OpenWRT on a single physical onboard Gigabit Ethernet adapter.

Those who are not vigilant about this may never notice it’s happening. But I also wonder why so many people schedule nightly reboots of their OpenWRT systems. I haven’t had to reboot my system in two weeks now that I’ve eliminated the USB3 dongle. On the R2S board, one of the two Gigabit. Ethernet adapters is connected via the USB3 bus, so even without a USB3 dongle, one of the two NICs is USB3 based.

I hear your pain as the household system administrator.
The main difference I see between the Raspberry Pi + dongle NIC and the NanoPi R2S is that the USB 3.0 NIC is integrated in hardware: it's the only device on the SoC USB 3 port. The Raspberry Pi's have shared usb ports between usb3, onboard nic, usb2. Power supply would also be a point to watch for the rpi and external NIC.

When the R2S was released at the price, with the hardware specs and performance numbers listed on the box, I couldn't help try one despite the USB 3.0 attached nic. Having stress tested it to my satisfaction, it's been working flawlessly for my house internet router (50/20mbps: 3 streaming vids, work from home, vid conf). I'm really impressed with these devices (not affiliated in any way).

On the other hand, there is no stable wrt available for the R2S. FriendlWRT is only for demonstration and OpenWRT is snapshot-only for this target but the snapshots are stable at the moment. Armbian is stable if you want a general OS.

I’m glad it’s working for you. but my internet is 350/25, and with SQM applied, I’m getting about 317/21 with the buffer bloat staying below 10 ms on multiple stress tests. I don’t doubt that a USB-bus attached NIC can do 50 Mbps. I don’t think your download speed is high enough to notice the problem with the USB-attached NICs. Like I mentioned in my previous posts, it’s hard to catch this problem on iPerf tests in the lab because the problem is so sporadic. It comes and goes. You would have to be testing without a stop for hours to be able to catch it on an iPerf test.

If you are interested in what I did with a single interface serving as both WAN and LAN, read the post I made on November 5, 2020

Hi, what firmware do you use on your R2S devices?

Cheers zWolf

i have 300/150 and with SQM no problems here.
but i cant use snapshot, have to compile as i said in last post..

Has anyone seen this error where the boot gets stuck at random number generation. It doesn't go any further even if left for a long time

[    1.444562] init: - preinit -
[    1.587460] random: jshn: uninitialized urandom read (4 bytes read)
[    1.610946] random: jshn: uninitialized urandom read (4 bytes read)
[    1.632334] random: hexdump: uninitialized urandom read (5 bytes read)
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[    5.782368] mount_root: mounting /dev/root
[    5.784636] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    5.820312] EXT4-fs (mmcblk0p1): mounted filesystem without journal. Opts: (null)
[    5.828420] urandom-seed: Seeding with /etc/urandom.seed
[    5.849641] procd: - early -
[    6.392588] procd: - ubus -
[  187.294153] random: crng init done
[  187.294492] random: 5 urandom warning(s) missed due to ratelimiting

If the debug mode is set to 4, then it constantly throws ubus error message.

[    4.825490] procd: - ubus -
[    4.827193] procd: Create service ubus
[    4.827599] procd: Start instance ubus::instance1
[    4.828409] procd: Started instance ubus::instance1[173]
[    4.829096] procd: running /etc/init.d/ubus running
[    4.830880] procd: glob failed on /etc/init.d/ubus
[    4.834117] procd: Instance ubus::instance1 exit with error code 65280 after 0 seconds
[    4.877626] procd: Connection to ubus failed
[    4.977534] procd: Connection to ubus failed
[    5.178468] procd: Connection to ubus failed
[    5.578596] procd: Connection to ubus failed
[    5.835175] procd: Started instance ubus::instance1[174]
[    5.838930] procd: Instance ubus::instance1 exit with error code 65280 after 0 seconds
[    6.380752] procd: Connection to ubus failed
[    6.840660] procd: Started instance ubus::instance1[175]
[    6.844292] procd: Instance ubus::instance1 exit with error code 65280 after 0 seconds
[    7.383198] procd: Connection to ubus failed
[    7.846074] procd: Started instance ubus::instance1[176]
[    7.849696] procd: Instance ubus::instance1 exit with error code 65280 after 0 seconds
[    8.385526] procd: Connection to ubus failed

I am using the ext4 image but resized it using gparted to take advantage of a 16GB SD Card. The data partition has about 14GB of storage. It booted fine but when I restored a backup from another working r2s. It now won't boot.

Device is running today's snapshot built on Sun Nov 8 03:10:14 2020

Pine64 are allegedly going to rely on a "next gen SoC", for their router board. This should be good.