Good joob project
Can you please post a link to the specific OpenWrt image you used and let us know what processâ specifically, your OS and the tool (e.g. dd, Etcher, etc.)âyou used to transfer the image to the xD card?
anyone here knows what this patch means for the R2S?
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=8b4233188dae1415a019b4d5323ebba2075ebcfb
I'm asking because right now I'm running on snapshot and front leds (wan and lan) don't work for me, so I wonder it this is supposed to fix it (and what else 
)
The patch looks to have changes to the LED configuration, you can try it out and it might fix your problem.
Also this patch addresses some of the slow SD cards that failed to boot on.
@donaldsycamore.
I suggest looking at uart log.
1 Like
need some help here, trying to upgrade to latest snapshot by following:
cd /tmp
wget https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-friendlyarm_nanopi-r2s-squashfs-sysupgrade.img.gz
sysupgrade -v /tmp/openwrt-rockchip-armv8-friendlyarm_nanopi-r2s-squashfs-sysupgrade.img.gz
sysupgrade log
root@OpenWrt_R2S:/tmp# sysupgrade -v /tmp/openwrt-rockchip-armv8-friendlyarm_nanopi-r2s-squashfs-sysupgrade.img.gz
Reading partition table from bootdisk...
Reading partition table from image...
Saving config files...
etc/collectd.conf
etc/config/adblock
etc/config/collectd
etc/config/dawn
etc/config/dhcp
etc/config/dropbear
etc/config/firewall
etc/config/luci
etc/config/luci-opkg
etc/config/luci_statistics
etc/config/luci_statistics-opkg
etc/config/network
etc/config/rpcd
etc/config/sqm
etc/config/system
etc/config/ucitrack
etc/config/ucitrack-opkg
etc/config/uhttpd
etc/config/umdns
etc/dropbear/authorized_keys
etc/dropbear/dropbear_ed25519_host_key
etc/dropbear/dropbear_rsa_host_key
etc/group
etc/hosts
etc/inittab
etc/luci-uploads/.placeholder
etc/opkg/keys/0b26f36ae0f4106d
etc/opkg/keys/1035ac73cc4e59e3
etc/opkg/keys/2a1fad379442d9e6
etc/opkg/keys/5151f69420c3f508
etc/opkg/keys/72a57f2191b211e0
etc/opkg/keys/792d9d9b39f180dc
etc/opkg/keys/9ef4694208102c43
etc/opkg/keys/b2d571e0880ff617
etc/opkg/keys/b5043e70f9a75cde
etc/opkg/keys/c10b9afab19ee428
etc/opkg/keys/dace9d4df16896bf
etc/opkg/keys/dd6de0d06bbd3d85
etc/opkg/keys/f94b9dd6febac963
etc/passwd
etc/profile
etc/rc.local
etc/shadow
etc/shells
etc/shinit
etc/sysctl.conf
Commencing upgrade. Closing all shell sessions.
Connection to 192.168.2.1 closed by remote host.
Connection to 192.168.2.1 closed.
But it seems like there is only partial upgrade happening, when I login I'm greeted with the correct revision:
-----------------------------------------------------
OpenWrt SNAPSHOT, r14612-18acf62be1
-----------------------------------------------------
but all the packages were not removed/updated, for example luci is still there while I expected it to be removed and all the kmod are built for old kernel:
opkg list-upgradable | sort
root@OpenWrt_R2S:~# opkg list-upgradable | sort
base-files - 228-r14427-668c988fc5 - 230-r14612-18acf62be1
dnsmasq - 2.82-4 - 2.82-6
kmod-gpio-button-hotplug - 5.4.63-3 - 5.4.68-3
kmod-ip6tables - 5.4.63-1 - 5.4.68-1
kmod-ipt-conntrack - 5.4.63-1 - 5.4.68-1
kmod-ipt-core - 5.4.63-1 - 5.4.68-1
kmod-ipt-nat - 5.4.63-1 - 5.4.68-1
kmod-ipt-offload - 5.4.63-1 - 5.4.68-1
kmod-ledtrig-default-on - 5.4.63-1 - 5.4.68-1
kmod-ledtrig-heartbeat - 5.4.63-1 - 5.4.68-1
kmod-ledtrig-netdev - 5.4.63-1 - 5.4.68-1
kmod-ledtrig-timer - 5.4.63-1 - 5.4.68-1
kmod-lib-crc-ccitt - 5.4.63-1 - 5.4.68-1
kmod-mii - 5.4.63-1 - 5.4.68-1
kmod-nf-conntrack - 5.4.63-1 - 5.4.68-1
kmod-nf-conntrack6 - 5.4.63-1 - 5.4.68-1
kmod-nf-flow - 5.4.63-1 - 5.4.68-1
kmod-nf-ipt - 5.4.63-1 - 5.4.68-1
kmod-nf-ipt6 - 5.4.63-1 - 5.4.68-1
kmod-nf-nat - 5.4.63-1 - 5.4.68-1
kmod-nf-reject - 5.4.63-1 - 5.4.68-1
kmod-nf-reject6 - 5.4.63-1 - 5.4.68-1
kmod-nls-base - 5.4.63-1 - 5.4.68-1
kmod-ppp - 5.4.63-1 - 5.4.68-1
kmod-pppoe - 5.4.63-1 - 5.4.68-1
kmod-pppox - 5.4.63-1 - 5.4.68-1
kmod-slhc - 5.4.63-1 - 5.4.68-1
kmod-usb-core - 5.4.63-1 - 5.4.68-1
kmod-usb-net - 5.4.63-1 - 5.4.68-1
kmod-usb-net-rtl8152 - 5.4.63-1 - 5.4.68-1
libjson-c5 - 0.14-2 - 0.15-1
luci - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-app-dawn - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-app-firewall - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-app-opkg - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-app-statistics - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-base - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-compat - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-lib-base - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-lib-ip - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-lib-json - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-lib-jsonc - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-lib-nixio - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-mod-admin-full - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-mod-network - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-mod-status - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-mod-system - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-proto-ipv6 - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-proto-ppp - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-theme-bootstrap - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
luci-theme-material - git-20.272.49386-f2e45c9 - git-20.273.53306-6207c0d
netifd - 2020-09-08-d7b614a8-1 - 2020-09-12-55a7b6b7-1
rpcd - 2020-05-26-078bb57e-1 - 2020-09-18-3fea6559-1
rpcd-mod-file - 2020-05-26-078bb57e-1 - 2020-09-18-3fea6559-1
rpcd-mod-iwinfo - 2020-05-26-078bb57e-1 - 2020-09-18-3fea6559-1
uboot-envtools - 2020.04-2 - 2020.04-4
uhttpd - 2020-08-05-212f8364-1 - 2020-09-18-47c34bd6-1
uhttpd-mod-ubus - 2020-08-05-212f8364-1 - 2020-09-18-47c34bd6-1
usbutils - 007-10 - 007-11
attempting to manually upgrade the packages works for luci but fails to all the rest.
any idea how to proceed? do I need to unlock filesystem before the upgrade?
You have to reset system to default settings after updating.
What you seem to need is to restore the default settings.
If you do not restore the default configuration, the installed packages will be retained.
jffs2reset -y && reboot now
executing jffs2reset -y && reboot now will reset network config as well?
why is it different than my Redmi AC2100 which I simply flash with the latest snapshot, it keeps network config and then I need to re-install luci and additional pacakges?
This seems to be because R2S boots from an SD card, no NVRAM type stuff.
The file system is split into 2 layers of system and configuration, to delete the configuration file layer then the network configuration is lost, otherwise everything is kept.
will moving to EX4 makes things better? or there is no difference in this regard?
The version of EXT4 does not have the function to restore factory settings.
But I'm not sure that upgrading the EXT4 firmware will preserve the current configuration, it has to do with how the system upgrade is implemented, I haven't used it so I don't have an answer.
so maybe this is a more generic question and not specific to the R2S, I think I'll ask in the configuration forum.
thanks anyway
I'd have to upload my build somewhere. As for the OS/Tool, I used etcher on openSUSE. Would be fine on Windows I'm sure.
++ @wevsty
If you went with the ext4 route, you can simply upgrade through the web UI or sysupgrade. In either of those methods, your /etc/config/* is retained, as well as any other files/paths defined in /etc/sysupgrade.conf.
I explain more about the sysupgrade.conf and rc.local files here: How to upgrade x86 OpenWrt? I have some examples there from my config, though in that thread I am referring to my setup on an x86_64 VM. Regardless, itâs also ext4 and the same principles apply with ext4 on the NanoPi R2S.
1 Like
Hi Guys!
Recently bought an R2S to serve as a home router for a 1000/50 FTTP connection which requires SQM/upload shaping. I tried OpenWRT and FriendlyWRT and seem to get better speeds with the latter, but cannot manage ~ >800mbps down with SQM enabled (using either fq_codel or cake) on either platform. Any general pointers or configuration tips would be excellent, and I can provide further info when I'm back home on my PC.
That would roughly match (respectively even surpass) the performance figures stated in the very first post of this thread:
SQM is (single-threaded and) rather CPU intensive, at 1 GBit/s WAN speed you're punching above your weight limit.
3 Likes
++ @Ziggy
I have tried to tell others the same through the various SQM tests (starting here) I posted earlier in this thread. Perhaps the thread is just getting too long now?
Either way, for everyone looking at this device for gigabit shaping, I just donât see it ever being the right fit. There is only so much that software tuning can do before you ultimately just bottleneck at the CPU with SQM.
For gigabit shaping, you really need to be looking at x86_64 or possibly mevebu-based hardware. Havenât used mvebu myself, but I can vouch for x86, as I use that now.
Bottom-line, there is more to shaping gigabit than just looking at interface port speed, saying âoooh, gigabit!â and hitting the purchase button. There are many devices that can route+NAT at gigabit speed because of efficient offloading. That means the CPU handles initial flow evaluation against firewall and route rules, but once evaluated subsequent traffic matching the same pattern can bypass the CPU (thus the offloading) and is why that is so fast.
SQM, as it stands today, requires what would otherwise be offloaded to instead be constantly evaluated by the CPUâitâs why SQM can do the magic it does. But this requires that your CPU be constantly ready to ramp up and handle those flows, especially when bursting up into the gigabit territory. To @slhâs point, this is CPU intensive and in my experience, ARM procs tend to struggle in that territory.
1 Like
After reading my prior post, if youâre still set on using the R2S, one option you have is to disable SQM on the ingress side since it really canât handle your gigabit. But, you could enable it on the egress side to easily shape your 50mbps up.
Figured as much, thanks for the clarification!
Thanks for taking the time to reply. @_FailSafe I understand what you're saying. My Netgear R7000 was definitely not going to cut it, so I ended up buying the R2S prior to actually knowing I would need to shape my upload to avoid being throttled by the infrastructure's policer (which doesn't seem to happen on any other plans, just this new gigabit plan). Without shaping, I easily hit 950mbps+ with the R2S, on both OpenWRT/FriendlyWRT. I just wanted to double check that there were no 'tweaks' or something that I didn't know about, so I would know for sure that I wasn't leaving any performance on the table prior to moving to an x86/x64 system. I did try shaping egress only but it still seemed to cause an overall performance drop versus having SQM disabled.
EDIT: I really appreciate all the hard work @jayanta525 and everyone else on this forum is doing for this device!
1 Like