I was just wondering if someone could point me in the right direction for checking the current CPU frequency on the R9000. hwinfo and lscpu show nothing. I tried using collectd-cpufreq and that just gives errors in syslog.
Sat Apr 9 18:39:55 2022 daemon.err collectd[17063]: plugin_load: plugin "cpufreq" successfully loaded.
Sat Apr 9 18:39:55 2022 daemon.err collectd[17063]: cpufreq plugin: Found 0 CPUs
cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq
That would be the problem, i take it. There is no /sys/devices/system/cpu/cpufreq/
I'm not saying that's necessarily a problem (is frequency scaling enabled in the first place?), my advice was generic - I don't own this particular device.
First successful test with kernel 5.15.
I will port my patches to 5.15 and deprecate 5.10 support, there will be no more updates for 5.10.
There will be a new branch netgear-r9000-linux-5.10.
The branch netgear-r9000 will become 5.15.
i donāt think we have cpufreq support.
For some reason having issues with NAND when updating via Web UI.
But sysupgrade via SSH works.
Consider yourself warned.
I'm investigating.
Flashed my R9000 and XR700 with 5.15 kernel, so far everything works fine.
Very good experience with Linux 5.15 so far. No issues with WLAN or Ethernet.
One thing i noticed is that "Channel Analysis" stops working as soon as i enable the corresponding WLAN interface.
And a manual scan also doesn't work in that case.
root@OpenWrt-dev:/# iw dev wlan1 scan
command failed: Resource busy (-16)
This worked with older WLAN drivers, i think.
Can't reproduce the mentioned NAND issue, don't know what happened but tread carefully.
WLAN scan with a 5GHz device doesn't work only with a DFS channel, probably not allowed to scan on a DFS channel.
Thanks @ [egorenar] for the effort!
Although not connected to 5.15 kernel upgrade, but have you succeeded in enabling VLAN on the slave switch yet?
iām not aware of any issues. what is wrong ?
When VLAN is enabled on the slave switch, clients connected to the slave switch ports do not get DHCP/IP assignment. Assigning static IP on valid subnet to the clients does not work as well.
Please find my etc/config/network on my earlier post:
if iām not mistaken, we already had a discussion about tagging and slave switch.
your configuration seems to be incorrect because you only configure switch0 (master).
if you want to use different vlans on slave switch (switch1) then all trunk ports should be tagged, not only ones on master but also on slave, the communication is bi-directional.
the default switch configuration doesnāt enable tagging on trunk ports of both switches because it assumes that on switch1 all ports belong to vlan1.
see https://github.com/egorenar/openwrt/commit/f2495d85082316f826372f87a01d371c8605a1fa for reference how switches are configured.
Yes, we had a discussion about this earlier and I spent a whole weekend on the issue, tagging the trunks between master and slave but still couldn't get it to work. I started to suspect my R9000 might have hw problems.
BTW: at your spare time, could you please provide an example config that enables vlan on both the master and slave switches.
Thanks!
iāll test it tomorrow.
one simple test is to take the default switch config and to only add tagging on trunk ports, leaving everything else unchanged. this shouldnāt break anything and is equivalent to the default config, if iām not mistaken.
I can confirm that enabling tagging on trunk ports (both switches) results in considerable packet drops.
Investigating.
The likelihood of finding out why VLAN tagging is not working on trunk ports is basically 0 because i have no switch documentation. The default setup is based on the information i extracted from the Netgear FW and DDWRT.
I think i have got a solution for you, my tests were successful, it would be nice if you could test the new patches to further confirm it.
I tried hard to get tagging working with trunk ports, but unfortunately i couldn't get it to work.
My next idea was to make do without trunking at all. I removed trunk ports from the switch configuration.
By the way trunking really means Link Aggregation. The name trunk is very confusing.
To undo trunking you need to change target/linux/alpine/files/arch/arm/boot/dts/alpine-netgear.dtsi:
@@ -1075,8 +1075,8 @@
0x00090 0x4e /* PORT5_STATUS */
0x00094 0x7e /* PORT6_STATUS */
/* Trunk 1: P4 + P6 */
- 0x00700 0xd000 /* GOL_TRUNK_CTRL0 */
- 0x00704 0xec0000 /* GOL_TRUNK_CTRL1 */
+ 0x00700 0x0000 /* GOL_TRUNK_CTRL0 */
+ 0x00704 0x000000 /* GOL_TRUNK_CTRL1 */
0x00808 0x7f004e /* QM_CTRL_REG */
>;
};
@@ -1098,8 +1098,8 @@
0x0007c 0x7e /* PORT0_STATUS */
0x00090 0x7e /* PORT5_STATUS */
/* Trunk 0: P0 + P5 */
- 0x00700 0xa1 /* GOL_TRUNK_CTRL0 */
- 0x00704 0xd8 /* GOL_TRUNK_CTRL1 */
+ 0x00700 0x00 /* GOL_TRUNK_CTRL0 */
+ 0x00704 0x00 /* GOL_TRUNK_CTRL1 */
0x00808 0x7f004e /* QM_CTRL_REG */
>;
};
Then rebuild your image and flash it. Make sure you actually use this change, just in case remove kernel build dir before re-compiling.
This is my new switch config:
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0t 1 2 4t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '3 5t'
config switch
option name 'switch1'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch1'
option vlan '1'
option ports '5t 1 2'
config switch_vlan
option device 'switch1'
option vlan '3'
option ports '5t 3 4'
As you can see above, i use tagged ports P4 of switch0 and P5 of switch1 to connect both switches.
It is important to make these two ports tagged, otherwise you cannot have multiple VLANs on the slave switch.
As example i have configured 2 VLANs on the slave switch:
Please test these and report back. Thanks!
By the way, for your information, P4 of master is connected to P5 of slave, and P6 of master is connected to P0 of slave.
In the above switch configuration i used the pair P4 <-> P5 to connect both switches. I also tested the pair P6 <-> P0, it works as well. But don't use both pairs at once, there is no link aggregation anymore.
By getting rid of link aggregation between the switches, i couldn't see any performance difference.
iperf3 shows the same stats. if your tests are successful then i will remove link aggregation from my branch.
Thanks @egorenar
When I make the suggested changes to: target/linux/alpine/files/arch/arm/boot/dts/alpine-netgear.dtsi, all LAN ports (on switch0 and switch1) stop getting DHCP/IP assignment.
I had to go via TFTP to flash a build that does not contain the change.
I repeated the test with a build containing the changes to target/linux/alpine/files/arch/arm/boot/dts/alpine-netgear.dtsi and the result was the same.
I am back to my initial build, currently configured 4 VLANS on switch0. switch0-port2 configured to trunk all 4 VLANs, switch0-port1 assigned to a separate VLAN. switch1 and it's associated ports on VLAN1, this configuration functions flawlessly.
this is to be expected, because sysupgrade restores your old switch config which becomes invalid with the new fw.
you can either use a serial console to fix it after an update.
or patch your target/linux/alpine/base-files/etc/board.d/02_network and then use factory fw flash.
i tested the new switch setup with both my r9000 and xr700 routers, and everything works.
i tested everything myself before i posted the instructions here.
Kudos to @egorenar for all the wonderful work developing this build. I may now be able to use my R9000 for something other than a paper weight.
Being a noob to this sort of thing and knowing enough to get me into trouble, I finally got the two builds flashed and working. Biggest issue was figuring out how to connect the R9000 to the internet behind my main router to update and upgrade all the packages.
So I am in a remote area and can only use a cellular modem to obtain internet service. I currently have a cellular modem with the latest Sierra Wireless EM9191 modem installed which will eventually get me 5G when available. It is tethered to a Linksys 1900acs router which runs ROOter/Goldenorb fw which is a fork of openwrt. Their interface allows modem control on the config menu. I am not sure how they do that or if it is a custom build using modemmanager and includes the mbim protocol.
Any plans on adding it to your current build for the R9000, for people like me in remote locations and RVārs stuck with cellular connectivity?
I always build my own firmware and all packages. Usually i just make most of the packages i need permanently built-in, this saves me the effort to reinstall everything after an upgrade.
This makes a sysupgrade image very big (currently about 180MB) but thanks to the big 512MB NAND
this is no issue with the router.
Less useful packages are kept external and i store them on a USB which is connected to the router. Then i just point opkg to the USB drive and i am able to install everything i need.
It is unlikely i will be able to help you here, did you check the OpenWRT packages, maybe there is one for your modem.
Thanks for the quick response egorenar!!! I also contacted the folks down-under at ROOter and told them about your build. One of the monitors of their forum responded:
"If they do contribute their changes back to master to get proper OpenWRT support going, that would make it much more viable to pull into ROOter. DM does occasionally keep snapshot build systems going to get ROOter support for really compelling new stuff that's almost there and has a lot of demand."
I am waiting to hear back from the developer of ROOter, (DM aka dairyman) to see if he is interested in taking it any further or if there is a big interest in developing anything for this router from other people.
Thanks again