Sounds like it might be the configuration for the R5C to me. The last few builds mj82 have put out have been syncing the config to 5.15 so there might be something there.
I haven't updated mine to the latest build so I'm not too sure and I installed it a while ago and have been keeping setting the whole time so I might not ever see the issue.
Iām not sure how much this helps but I flashed the latest kernel 6.1 OpenWRT build from the above GitHub with ākeep settingsā and the ports are still working.
Thank you for letting me know, I do think this info will be useful to others who end up here after google'ing for the same problem. It does seem that my device works for kernel 5.10, but not 6.x, whereas others report 6.x kernels work for them (cf this Github issue).
have no idea what's wrong with your device tbh.
the only cause i could think is the ethernet driver, can you post kernel log here?
btw, you may also try our firmware which is based on openwrt snapshot + kernel 5.15:
https://firmware-selector.immortalwrt.org/?version=SNAPSHOT&target=rockchip%2Farmv8&id=friendlyarm_nanopi-r5c
Does your firmware have a lot of packages installed or is it pretty lightweight?
Just like the official openwrt firmware, only necessary packages are included by default.
I started running the ImmortalWRT snapshot yesterday and can report no issues with it so far.
Of course you have to install luck after the fact or customize the image on their firmware selector page.
So... is there any card that would potentially work and provide 2.4/5Ghz in AP mode. I was aiming for 802.11ac and up to 1300 Mbps over wifi. Thanks.
Finally ported it to openwrt mainline, see
any review/test would be appreciated
So I muddled my way through a compile/build of OpenWRT for nanopi r5c after a few attempts. Currently it works (though I have not put it in productions); However I have no video coming from HDMI. What do I need to compile HDMI Support.
This is the video support section for the Kernel section:
#
# Video Support
#
# CONFIG_PACKAGE_kmod-backlight-pwm is not set
# CONFIG_PACKAGE_kmod-drm-kms-helper is not set
# CONFIG_PACKAGE_kmod-drm-ttm is not set
CONFIG_PACKAGE_kmod-fb=y
CONFIG_PACKAGE_kmod-fb-cfb-copyarea=y
# CONFIG_PACKAGE_kmod-fb-cfb-fillrect is not set
# CONFIG_PACKAGE_kmod-fb-cfb-imgblt is not set
# CONFIG_PACKAGE_kmod-fb-sys-fops is not set
# CONFIG_PACKAGE_kmod-fb-sys-ram is not set
# CONFIG_PACKAGE_kmod-fb-tft is not set
# CONFIG_PACKAGE_kmod-fb-tft-ili9486 is not set
# CONFIG_PACKAGE_kmod-v4l2loopback is not set
CONFIG_PACKAGE_kmod-video-core=y
# CONFIG_PACKAGE_kmod-video-cpia2 is not set
# CONFIG_PACKAGE_kmod-video-gspca-core is not set
# CONFIG_PACKAGE_kmod-video-pwc is not set
# CONFIG_PACKAGE_kmod-video-uvc is not set
# CONFIG_PACKAGE_kmod-video-videobuf2 is not set
# end of Video Support
Am I missing something perhaps?
WiFi and ethernet are working though I can only test 1Gbps right now
Here is a pastebin link to my .config
Thank you u/1715173329! Appreciated your work and effort!
I have been testing different openwrt builds on the R5C and there seems to be a loss in downstream performance on devices connected to an omada access point compared to the original friendlywrt builds. On the original friendlywrt builds, I get symmetric download and upload speeds around ~500 Mb/s, while on the community openwrt builds, the download speed is significantly limited to ~100/200 Mb/s. I have confirmed that it is the router that is indeed the issue, as the WAP runs at the required speed with a different router.
I have tried different builds from @mj82 (rockchip v6.1, v6.4 and the openwrt v23.05 releases on github ) and also the immportalwrt builds from @1715173329 (snapshot (6.1 kernel) and 23.05 snapshot (5.15 kernel)). Does anyone have any idea as to what might be causing this issue?
Edit: I'm referring to speedtests to the internet over NAT. Local speedtests (openspeedtest, iperf) not traversing the NAT are fine. iperf tests to a public server also seemed to be limited in download speed
OpenWrt 22.03.5 r20134-5f15225c1e / LuCI ce20b4a6e0c86313c0c6e9c89eedf8f033f5e637 branch git-23.159.16195-b232534 FriendlyElec NanoPi R5S
R5S no sqm https://www.speedtest.net/result/14865614307 851.33/49.74Mbps, Ping ms 24/48/27
R5S sqm 0/40000 eth0, pocake, ppo22, mpu64 https://www.speedtest.net/result/14865641443 885.36/37.46Mbps Ping ms 22/52/16
Are you running speedtests on the nanopi or on a device on the LAN? When I run it on the nanopi device, the speeds are fine. When I run it on a device connected via ethernet, the speeds are fine. When I run tests on WiFi with a different router (ISP provided), the test are fine. The low perf is only with a wifi device with the nanopi as the router.
pc to nanopi R5S to TC4400 cable modem to 1024/50 ISP service.
My specific issues are limited to wifi. the same wifi access point connected to the nanopi running friendlywrt gets ~600Mb/s up and down, but when connected to the nanopi, it gets only ~300 Mb/s down and 600Mb/s up with the community built openwrt.
I was thinking that there may be some settings differences between te 2 builds, but comparing that seems tricky. if anyone has any ideas, please let me know.
Edit: Also wanted to add that I did a waveform bufferbloat test and the latency increased siginificantly on downloads. Hardly any change on uploads. Got a grade C. I haven't run the test with friendlywrt, but I presume that given the speeds were high, the test results won't be so bad.
Youāre running these builds off of SD cards and not installing them over each other with ākeep settings?ā
Also since you specifically say itās limited to Wi-Fi do wired clients have the same slow down?
I know immortal has some different default NAT settings but Iām not sure how they affect speeds (full cone NAT and a few others.) Iāve tried to keep the settings on immortal closer to default OpenWRT but annoying they get reset on sysupgrade even with keep settings checked.
For reference though with both mj82ās builds and immortal I get my 800/20 line speeds.
I'm running the builds off EMMC. Downloading the tar.gz to /tmp/ and using dd to write it to /dev/mmcblk1 and reboot. Is this the correct way to install it? This should wipe all settings and I set things up from scratch each time. The friendlywrt downloads seem to be much larger than in size than the community builds. Does that matter?
I ended up breaking the MASK button off my board while trying to press and hold it at some point, so booting of SD card is going to be difficult.
With wired connections, they ramp up to the full 900Mb/s link speed quickly. I have tested it on mutiple ports, even on the port that the access point is connected to and there isn't any issue.
I believe you are right that using dd to write the image should wipe all settings.
FriendlyWRT includes a lot of packages that increases the build size if I remember correctly but shouldnāt matter for your issue.
To me it sounds like there is something with the WAP that may be causing this slow down rather than the router install that may just have been coincidental to your reimage. Is the WAP in auto mode for channel selection? Are you in a crowded Wi-Fi environment?
I can see drops like that in my home network depending on what channel my access point is on.
My first conclusion was to assume that it's the WAP causing the issue, but I tested it out with friendlywrt on the nanopi handling NAT first, then completely removing it and using the ISP router and this drop in download speeds isn't there. I remember the download speeds being high before I upgraded to mj's version of openwrt, so I went back and tested these other routers.
Channel selection and channel width is in auto, I believe it's using band 36. I tried manually setting few other bands and performance only seems to drop. There are many other wifi networks broadcasting here, but all that shouldn't matter if other routers handling NAT don't cause issues for the WAP.
The issue seems weird, because upload speeds are still high and it's only downloads that are affected. The drop in download speeds is linked with an increase in the latency in the download part of the waveform bufferblot test. All this was leading me to think that this might be something to do with how NAT is handled on the router. Maybe in the wired setting, the packets appear fast enough to the router so there isn't an issue, but the shared medium nature of wifi causes some slowdowns. I am no expert on this, so any suggestions from the community is welcome.
Certainly is an interesting issue. It just doesnāt make sense to me that the issue is only through the access point and not wired as well if it was a NAT problem. I canāt imagine what the differences between friendly and the other builds are that would cause this.
Have you tried with and without packet steering? Or software off loading on and off? Might be a bit of a stretch with those since Iād think youād see the problems with both wired and wireless if it was related to those.
Also in a similar vein maybe try testing with and without ipv6 enabled.