This arrogance is really interesting reading back. Extender's issue is that it EXTENDS the wifi SSID and rebroadcasts it and does allow you to connect to the ports on it directly for a bridge; however, issues come up with the broadcasting of the SSID. Cannot find any way to tell this router to not broadcast the repeated base router's SSID, which is actually causing issues with machines and where some devices see each other on the network and others don't until you go back to near the base router and away from this bridge. I 100 percent saw from the first question what they were saying because it is an issue and the GL.iNet staff is not taking time to understand how normal people try to use this as the advertised wireless bridge. The definition that you all have for wireless bridge is not accurate for what people are looking up and is misleading becuase there isn't a true bridge mode. The modes are a WIFI REPEATER mode, which causes issues.
I don't really get what the issue is, tbh.
Extender will extend - so the SSID will be the same.
Repeater can repeat, but you can choose which SSID you like since it works in WISP mode.
So what exactly is the issue?
A router is a router, not some repeater as people might know from tp.link and Co.
I read the post again and I think I answered the exact questions and posted the exact solutions.
Then cgl has a more complicated setup and didn't resolve.
I replied to CyborgSocket's question about PoE and I am not sure what is the problem is there.
Extending wifi is a difficult process. There is no IEEE standard for this function. Regular wifi transmits with 3 MAC addresses, (sender-transmitter-receiver-), the 4th needed MAC address is missing: the (-destination). For regular wifi the receiver is also the destination.
Each vendor solves it it's own way. 4-address mode , AKA wifi-bridge mode, is a vendor dependent implementation.
The only common standard is WDS mode, but this WDS can give security-encryption-different settings between different vendors.
Extending wifi then uses quite some tricks to make it work. The receiver is a "pseudo bridge" (AKA 2.5 level bridge) with one MAC to multiple IP addresses. The pseudo bridge will redirect based on the IP address, to the correct local MAC, if and only if that device communicated first to populate that IP-to-MAC table.
DHCP , with it's 2 MAC addresses (receiver MAC in the header, destination MAC in the DHCP payload) creates confusions. It is the first protocol to suffer in a 3-MAC communication.
Workaround are 1: Use WDS, 2: Use a DHCP relay, 3 Use local DHCP with a shared subnet, 4: Create a layer 2 tunnel over that wifi link (L2TP, EoIP, MPLS/VPLS, PPTP, Zerotier, ...) 5: Use router mode with the needed NAT and forwarding.
Same problem here,
Router as AP with only one cable in LAN.
Vlan 30 configured in switch with cpu tagged and lan ports tagged
Wifi bridged with vlan on eth0.30
The device does not communicate with the uplink over cable to get the ip address.
Also double checked with another openwrt router with the same configuration, works perfectly.
I know this is months later, but I figured this issue out. I first plugged my laptop into the LAN port, then used the default "router mode" to acquire my main network wifi signal. The I went to the "wireless tab" and turned off the SSID broadcast networks. Then I switched modes to "Extender". I went to the web interface after the switch and verified that the broadcast SSID's remained off. They were. Did some testing.... I am now on the main network via LAN with an IP issued from my main router, and no conflicting SSID's broadcasting from the iNet router. This SHOULD be spelled out more clearly in the manual. I've been at it for HOURS. Hope this helps someone.