I have a Netgear Orbi RBK50 and RBS50 on the latest firmware 23.05.3.
This is my first time setting OpenWRT and have been able to get most the settings up and running as needed, the one hurdle I'm facing is what Netgear calls the backhaul connection for the mesh wifi. Specifically, I can't seem to get the Qualcomm Atheros QCA9984 to work.
What's happening:
In Network > Wireless, I see Radio0 which is the problematic one (on both devices)
I can scan for networks and devices show up.
I created a 802.11s (as well as other network types) network with various settings, channels, and power. When logging into my RBS50, using the it's own QCA9984, I cannot see that network, but I see others.
I set the Country Code as recommended on another thread and rebooted.
I'm a bit lost as to what to check. The signal is and bitrates are always 0 or ? or unknown depending where I am viewing it. Encryption always shows none, whether or not I'm using encryption or not.
iwinfo
phy0-mesh0 ESSID: "backhaul"
Access Point: (REMOVED BY ME)
Mode: Mesh Point Channel: 157 (5.785 GHz) HT Mode: VHT80
Center Channel 1: 155 2: unknown
Tx-Power: 20 dBm Link Quality: unknown/70
Signal: unknown Noise: -105 dBm
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11ac/n
Hardware: 168C:0046 168C:CAFE [Qualcomm Atheros QCA9984]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
I tried removing the built in ath10k-firmware-qca9984-ct software package and replacing it with the newer ath10k-firmware-qca9984 to no avail
I'm a bit at a loss of what to do. At this point I'm just trying to get it discoverable, but it looks like I'm running into a bug or a driver issue, but no real clue what to troubleshoot here.
This is a closed source mesh-like protocol with core functions built into the QCA chipset. As it is closed source it is not supported by OpenWrt, but in fact you do not need it as 802.11s mesh networking will do the job - in fact it will work between just about any OpenWrt supported routers apart from those with Broadcom wireless chips.
To get 802.11s mesh working, it is best to remove all the mesh configs you have done and start again. In fact doing a "factory reset" back to basic untouched 23.05.3 would be the quickest.
Then change the ath10k-ct drivers over to the non-ct versions and you will be readty to start.
Mesh11sd is a package that dynamically configures and manages the mesh network, making it all a very simple process.
Usually this is all that is needed apart from a few minor customisation tweaks, but if you want do go full power user you can switch into "manual mode", but don't do this until you really know what you are doing
Read the documentation first, then come back here to ask questions. It should be a really simple process for you to get going, with no configuration to do. You can do customisation once you get up to speed with a working mesh!
Hmm, so I ran through it on my RBS satellite to test
Removed any ct related packages and installed the non-ct versions of both my IPQ and QCA radios ( I also tried with a custom build without the ct ones)
Ran through the installs for kmod-nft-bridge, wpad-mesh-mbedtls, removed wpad-basic-mbedtls, restarted wpad and installed mesh11sd 2.0
The behavior seems to be the same. I dont see anything, from a GUI perspective, configured, though the wording on the articles sounds like I shouldn't (I'm unclear if mesh11sd is supposed to configure and I see it in the gui, or its totally unavailable in the gui), but the radio seems to be the same
Unfortunately each time I tried to use the mesh11sd 3.1 package, my router straight up died, I tried static IPs on my connected device, rebooting, etc, only re-flashing could get it up. Same thing happened on the RBR the initial time I tested.
I might try again later when the next package is released unless you think I'm doing something obviously wrong.
Yes I do think that. The documentation might not be as clear as it should be, so I will go through the setup.
Ah, I did state in my first reply that you need the 3.1.0 version.
Since you tried, the build system has now made 3.1.0 available.
Do you have the 2 pack Orbi RBK50?
As far as I can tell, once you have OpenWrt installed, these are identical, but the labelling on the ethernet ports is different in that one has the leftmost port marked as "wan".
By default, mesh11sd 3.1.0 is fully autonomous and auto-configures everything.
My guess is that it was working.
Points to consider for a default install:
The wireless AP would be enabled with a new SSID set to OpenWrt-xxxx where xxxx is the last for digits of the mac address.
The Orbi wan port (leftmost port on either of the units) will be used to detect the presence of an upstream network (an Internet feed). If a live connection is detected, mesh11sd will configure the unit as a router with dhcp and dns services provided on the br-lan bridge, with ipv4 address of the value in /etc/config/network (default 192.168.1.1). This configuration is known as a "Mesh Portal"
If there is no upstream connection (no Internet feed), mesh11sd will configure as a "Mesh Peer" with dhcp disabled.
If there is no "Mesh Portal", there will be no ipv4 so this is probably why you thought "my router straight up died"
You should aim to have the exact same setup on both units.
Only if there is an Internet feed to the wan port of one of them, will it spring into life
This is all the default for mesh11sd of course and is the quickest way to get working.
"Advanced" customisation can follow once the basic mesh is running.
Luci will not know anything about the mesh11sd configuration as, by default, it is a dynamic configuration. So no, Luci will not show anything configured, at least initially.
I wonder if it was thinking my laptop was the upstream port, I forget which side it was on (whatever port was required to flash)
I'll try wiping both of them and starting from scratch tonight/tomorrow and go one step at a time depending on if I can get a maintenance window ( its a home network but I run a business from it too )
I should just be able to build them all with the correct packages (including mesh11sd) from the custom build option correct? Or do they need to be installed in a correct order post?
If not, finagling internet at the RBS might be a bit tricky, I'd been joining it as a client to my main RBK's wifi as a workaround (or downloading the packages and shifting my laptop back and fourth), but maybe that is contributing to the problem.
If you want to pre-build a ready-to-go image then you can use either imagebuilder, or more convenient, the OpenWrt Firmware Selector: https://firmware-selector.openwrt.org/
What is the ipv4 address of your ISP router? If it is 192.168.1.1, you should set the lan address in the image to a different subnet eg 192.168.2.1 (same image so same on every Orbi).
It will be the identical image to use on every Orbi
Start with any Orbi, connect the upstream link ie an ethernet cable from the leftmost port to a LAN port on your ISP router.
The ssid will be OpenWrt-2g-xxxx where xxxx is the last 4 digits of the mac address.
Flash a second Orbi. Power it up with no ethernet connection. Its ssid will have the last 4 digits of its mac.
Give it a few minute to join the mesh and then try connecting.
Okay, great I think I understand how this all works now. I had to revert back due to time constraints and some minor issues I don't think were related to the image.
The only thing I wasn't immediately expecting was it to take over all the radios (I should have assumed since it was autoconfig).
So right now I just need to set it to manual and target just the QCA9984 radio. I see those instructions underneath the Manual section of your previously linked article so hopefully I will be all set tomorrow
I assume the mesh was up and running and you could connect to the remote node's access point wifi?
A quick trick, that I should add to the documentation:
When the mesh is up and running, run uci commit wireless, on both.
Use mesh11sd connect to get to the remote node.
This will write the wireless config.
Then you can turn off auto_config leaving a ready configured wireless that you can customise as needed - enable/disable interfaces, set channels, set ssids etc etc.
Unfortunately the issues persist. I spent a couple hours trying to get things to work. The mesh definitely connects, but when I go through the process of running uci commit wireless on both nodes, setting the auto_config to 0 on /etc/config/mesh11sd (by uncommenting) then rebooting, things immediately go back to the issue I was having persistently though this process:
I connect to either of the wifi's, after a few seconds, it disconnects. For a brief moment I was able to login and get to the kernel logs before being totally locked out (as in, unable to get a connection stable for more than a few seconds, no dhcp, etc). Trying to set a static IP, from my Mac, literally does not work. It is as if it is crashing or trying to connect and does not physically let me click the dropdown to change DHCP to manual, then shortly thereafter, disconnects. Any other wifi networks behave fine.
At some point I did see ip conflicts in logs somewhere but didn't grab them in time
This particular failure's logs had a kernel built with the following, though I did try other variations which I cannot recall at this time. There were no other scenarios where I was able to make it to the logs before things started crashing and burning:
@nchorekchyan
Woah! You are getting a bit ahead of yourself here
Before you make ANY changes, we need to confirm the mesh comes up and is working.
You have 2 units, both with exactly the same flash, created with the firmware selector or imagebuilder, with no uci-defaults settings.
Connect one of them by ethernet from its wan port to the isp router lan port.
Power it up
Put the second unit over the other side of the room, or the next room and power it up.
Look for the ssid of the first, isp connected unit (this is the mesh portal). The ssid will be OpenWrt-2g-xxxx where xxxx is the last 4 digits of the mac address of the unit.
Connect via wifi to this portal unit and ssh to 192.168.1.1
Are you connected with a terminal session? The prompt will be something like root@meshnode-xxxx:~#, where, like above xxxx is the last 4 digits of the mac address
Run the commands mesh11sd status and mesh11sd stations and show the results.
Once we verify we get to that point we can do some more testing so you get the feel of it, then think about customising.
If you don't get to this point, we will look for what is wrong!
To be clear, in my previous testing, prior to the commit attempts, starting from scratch:
Same flash configs listed in my earlier post using image builder. Obviously one was RBK vs RBS but otherwise the same
This was done
Done (its possible the secondary router was up first since its easier to access but I believe I specifically made sure to have the primary up first in a few tests)
Done
I saw a 2G and 5G versions of both routers, so 4 SSIDs in total
I connected to both to make sure connectivity was working to the internet
I SSHed to root@192.168.1.1. I saw the main node's mac (one connected to the modem/WAN port).
I did not run mesh11sd status, but. I did run mesh11sd connect, which showed the peer and was able to connect to it, and proceeded to commit / edit auto_config to 0 on both.
Rebooted. At this point it stopped working
I will retry it once more today and double check I didn't do anything else..
Don't do ANY changes yet. We need to do other tests to make sure everything is ok as well as check the autoconfiguration.
The order the meshnodes are powered up does not matter.
Both 2g and 5g wifi will be enabled automatically, so yes you will see 4 ssids.
Can you list what you want to achieve when you are customising?
There may well be multiple ways of doing things.
Note: Mesh11sd uses the uci utility to manage dynamic configuration changes, both autoconfig and run time.
The autoconfiguration is done on every startup and is not a one off process. In normal operation, config changes are not written to the config files in /etc/config but are kept in volatile storage by way of the uci utility.
Directly editing a config file might possibly break something, all changes should be done with the uci utility.
)