Locally I have an internal Ethernet NIC set back to DHCP as per the guide. It is also being assigned an IPV6 address automatically, but I do have custom DNS server settings configured on the adapter (both IPv4 and IPv6 [Cloudflare if it matters]) Bing bang boom, everything is working, although my AT&T Fiber Gateway is not showing the static IP on the WAN side (..1.10) and of course doesn't show the LAN side by design (..2.10).
Thing is, I can leave my NIC in DHCP mode and leave the Subnet Mask and IP Address fields blank, yet I can still open SSH and LuCI via browser at either IP: 192.168.1.10 and 192.168.2.10. Since I'm being assigned a an address from the gateway at 192.168.1.254 I must be on that default subnet, and ipconfig confirms. But how the hell can I still access 192.168.2.10 (repeater with my ethernet cable plugged in)?
Sorry if this has lots of useless info. I can give any info required. here is my UCI config (sensitive fields removed):
You did also create the relayd bridge, as mentioned here: https://openwrt.org/docs/guide-user/network/wifi/relay_configuration#installing_relayd_package
The repeater itself (under the hood) works with .2.10 to pass all data to .1.10
Therefore it should not be possible to access .2.10 (repeater) if you got a .1.10 dhcp ip. That can only with PC static connected to repeater in the right subnet.
So it's also written on the mentioned page:
The LAN interface subnet will be used only as a “management” interface, as devices connecting to the Wi-Fi repeater will be on the main network's subnet instead. If the relayd device becomes unreachable, you will have to configure a PC with a static address in the same subnet as the LAN interface (eg. 192.168.2.10 for our example) to connect and be able to use LuCI GUI or SSH.
Check if all settings mentioned in the LAN Interface section (and others) are correct and if relayd is working (Status / Processes and or System / Startup / Initscripts)
Thanks for the welcome and suggestions. I am very new to OpenWRT, but fortunately in a situation with this that allows for, essentially, a sandboxed network and all the trial and error and experimenting I can handle. I did indeed configure the relayd bridge as per the guide and I am currently using 22.0.3 on a Wavlink WL-WN530HG4 however, when this cropped up I was on 22.02.2. I went ahead and reset then flashed the latest and despite the very limited space, relayd and luci-proto-relay seem to fit and install and initialize without getting wonky, so going forward it'll be 22.0.3. I am doing the setup line by line again, but I have a couple other stupid questions:
The guide explicitly states that relayd only handles IPv4, so when I enable IPv6 as per the guide, none of the IPv6 traffic should cross that Relay Bridge I configured and it is being handled by SLAAC and some other upstream sorcery I don't understand? Also, the Relay Bridge should be in an undefined firewall zone? The guide doesn't make it clear outside of which interfaces it should attach to.
One more question... I should have no trouble setting up a Master AP on the same radio as the client/main internet access to RG after relayd is configured, right? In order to make this an actual repeater that can extend and allow wireless devices in addition to ethernet?
The documentation writes indeed only IPv4, so your traffic could run over IPv6 if you enabled it.
Try with IPv6 off?
'Stupid questions don't exist, only stupid answers.' <- my dad
About your last question, as far as I can see: yes, radio mostly auto? and wifi same as main router.
Repeater passes all requests to main router (dhcp & traffic, IPv6?).
It works as expansion of main router, all devices in one LAN.
Oh the firmware customization, I have gone through that a few times trying to replace wpad-basic-wolfssl with wpad-mesh-wolfssl for a different router. It's a great system, but:
On a ramips/mt76** build like this with very little wiggle room for extras, is the builder "smart" in terms of not building an image that will be too big? If it does end up pulling in a bunch of dependencies because a user does something silly like add "nano" or something with 20 dependencies or whatever, does it go ahead and do it up and bring in everything nano needs and spit out a 10mb image and assume the user sees the problem? And in reverse, if I wanna trim fat and decide to cut out ppp and the luci-ppp package, is the build system capable of not also culling every dependency up or down on each package and just remove those if nothing depends on them? I ask because I had a hell of a time trying to get an error with failed output and some 0 error "green" complete builds I got back out broke luci for me (my fault certainly, but hard to spot first when a build gives no errors).
I have flashed 21.02.1 per your suggestion and setup everything as per the relay guide EXCEPT IPv6. I followed until the UCI shell configuration instruction begins. Everything seems like it's working fine, BUT I've got the same issue. Also, the guide notes that my Overview should not know the IP of the Host on my Client AP and instead show a ? in place. I am not showing the ? and am showing the host. If I enable IPv6 I think it even resolves the host down to device.attlocal.* (AT&T Fiber, no choice). Here is a picture:
I doubt it, but you can also remove packages you don't need (but make sure you don't remove 'needed' packages).
And there is not much error checking, therefore you should make your own build environment which gives all info back.
Your setup gets more clear to me, it has only Wifi on your repeater, your router has only wired connections.
But it's weird that you see that ip address (192.168.1.254), although it's the 'real' host.
Are you sure that after removing the WAN interface also the corresponding firewall zone is gone?
(Warning: These actions will also automatically remove any redundant firewall traffic and port forwarding rules.)
Something looks to be wrong, but I don't see what.
Could you check your settings with the items within CLI setup?
In your list I see twice the local IP, but it is not shown in the CLI setup overview:
"Relay bridge" is not compatible with IPv6. It's based on intercepting ARP and mapping all IPs of clients being repeated to the incoming MAC of the repeater. This is implemented only for IPv4.
If it is possible to install static routes in your main router, you could use symmetric routing instead.
Here's a funny thing.. When I use the 5Ghz radio to bridge AP to AP rather than the 2.4Ghz, everything works as it should. I now have to set my IP and subnet to ..2.* in order to connect to the now-working bridge. This also changed the Host to a proper ? as it now really doesn't see it. I have absolutely no idea why this made any difference unless Windows 11 was doing some "realtime invisible WLAN correction" in the background and not only adjusting my routing to work across subnets but then being evil and not even telling me. At this point I am not surprised at the virtualization of everything Windows 11 Pro does, so maybe it is also Skynet.
One more thing I did find to have overlooked because it isn't actually stated implicitly in the guide is which firewall zone the repeater_bridge belongs on. What I ended up doing was creating a new zone (bridgezone) and adding LAN, WWAN, and WWAN6 to it as per this alternate config guide:
As of right now, the machine is running and I'm afraid to touch anything. The only thing left is to enable the Master AP in order to allow WiFi, but I'm gonna run 100 ft of cat5 so I can move this bridge router into the planned garage spot.
Right, I did know that but I was under the impression that I was circumventing the bridge with IPv6 by using the setup guide. Should I remove the WWAN6 interface from the repeater zone though? Should the WWAN6 interface be "touching" anything besides the LAN and getting the upstream IP6 details?
If you don't need any IPv6 from the repeater-side then yes, all other answers: no.
So it looks like its working, although as wifi-repeater.
This should also work by cable, I persume.
There is also a message in the beginning of repeater-setup that says: Using relayd as instructed in this article isn't guaranteed to work with all Openwrt compatible devices or wifi networks.
Maybe you should consider to setup a mesh network:
