Hello, I am working on setting up a wifi repeater that extends my current ubiquiti infrastructure. Because unifi meshing has caused network loops in my environment before, I am unable to use that to accomplish this task. As a test I configured the AP to broadcast my LAN, and that worked successfully.
When I created a relay interface between wwan and LAN (with disabled DHCP on the LAN) the client was unable to obtain an IP. The cleint does connnect online if I set a static IP though. Using tcpdump on the openwrt AP’s interface Phy1-sta0 I saw the DHCP request leave the network. From the upstream AP I was able to see the DHCP offer, but that packet never went through my openwrt repeater AP. Is there an openwrt module that can help me diagnose or fix this problem?
I’ll take a stab at it, since probably no one replied because this is covered in the Openwrt wiki: Whenever I set up an AP to extend my wifi, I flash openwrt defaults, then set the LAN bridge IP to something in the router’s DHCP lan range, and update /etc/config/dhcp on the router, to keep track of that AP’s mac and IP assignment (also so it does not try to assign that IP elsewhere).
That’s the basics, probably covered in the wiki somewhere. Run an ethernet cable from the LAN port on the router to the wireless extension AP, or use 802.11s mesh on the router and wireless extension AP, or setup a client wifi in your Luci Wireless configuration, and use RelayD:
Key points are your ordinary LAN IP on the wireless extension AP device cannot be in the same subnet as your LAN, because you will be using RelayD and assigning an in-LAN IP for the device to the wwan portion instead.
Thanks for the advice and giving me a shot. I have been doing more digging and the cause of the issue is DHCP snooping (another setting I can not change). Ubiquiti switches drop DHCP offers because the ethernent.src in the frame is not the same as the client MAC address. It seems I may have to use a bridge lan configuration as it supposedly won’t modify my dhcp request frames.
Thank you for the response, and you are correct about complexity for sure. Unfortunately meshing has created network loops on my campus multiple times in the past. It would be better if I would leave areas with lower quality wifi signal than to disrupt all internet services across the campus. Does the idea of bridging the wwan interface to the lan interface, while an allowing dhcp though, sound like a feasible solution, or is that just an AI hallucination?
The problem with WDS is that it typically only works within the same firmware ecosystem. It rarely works across different vendor implementations. The op said they have unifi upstream which means wds is not going to work.
I have read this several times. My first experience with WDS was with ipq4019 vs mt7621 (MT7612EN). My second was with two mediateks, that fits your argument. Was I lucky on first try?
My bad I didn't understand correctly. I assumed cross-chipset. I have never tried cross-firmware. It seems obvious that I install OpenWrt on every devices
Your making this way more complex than it needs to be.
All you need to do to create a "campuswide mesh" is flash all your APs with stock OpenWRT, login to them and change 192.168.1.1 & subnet on the lan bridge interface to whatever preferred management IP you want to use, tell the lan interface to ignore the dhcp server, (optionally turn off ipv6 routing) then plug the LAN interface into your master switching fabric. You can disable the wan interface if you like, I generally don't bother (since it's not plugged into anything) No need to muck around with the bridge configuration in the AP.
I have a huge campuswide wifi network with 80 AP's, around 1,000 clients at any given time, 12 sites, multiple WAN links and switches tied together all carrying a single /16 on wifi with a single master DHCP server with a single SSID. I also don't have IEEE roaming enabled and it works well. Yes, without roaming, the clients are more "sticky" and will do stupid things like stay associated to an AP for a while that's down the hall from them while the person carrying the phone or whatever is standing practically under another AP, (eventually the clients do figure it out and drop association from the remote radio and reassociate to the nearby radio) but our people don't move around THAT much and it all works out.
Since no radios are connected to each other except through the hardwired ethernet switch, I don't have to muck around with any of that in the OpenWRT system I can handle that in the enterprise switches on the WAN (where it's supposed to be)
Obviously you can't daisy chain radios off each other this way but it's far cheaper to pull ONE ethernet drop to a dead area you want to light up and plug an AP into it, then deploy a full wiring plant.
