Wireless Bridge On OpenWrt 23.05 Xiaomi 4A Gigabit Edition

Installing and Using OpenWrt Network and Wireless Configuration
1

Wireless Bridge On OpenWrt 23.05 Xiaomi 4A Gigabit Edition

I am trying to create a wireless bridge between an experimental OpenWrt Router on a Xiaomi Router. I am doing this to extend a network wirelessly.

I watched two videos in a row, but was not able to make it work. I am stuck on the part where a client device connects to the Xiaomi router wirelessly, and should get an IP dynamically via the primary router.

The videos I watched:

My Network:

  • Primary Router on 10.0.0.0 network
  • Xiaomi Router on 192.168.10.1
  • I was able to connect the Xiaomi Router to the Primary Router via Wi-Fi, and a wwan interface was automatically created
  • installed the luci-proto-relay package, and created the relay-bridge interface. I have tied this to wwan and lan together
  • wwan is set to dynamic IP for the time being, it is getting IP from the primary router, so this works so far
  • the lan interface is using a static 192.168.10.1 so I can locally managed it when directly attached to a pc.
  • A Wi-Fi AP is configured, and attached to lan, and it is broadcasting fine, but this is where the problem goes in. When I use my mobile phone to connect to the ssid broadcast, it is not getting an IP.

Reference Image:

image
image1166×672 67.4 KB

UPDATE:
I followed the text guide, which seem to match the webui of my router. Followed through but still the same issue on my end.

I did another attempt, started over again, used another router as main router. It worked. So now I need to troubleshoot on the first main/root router, as to why it is not giving out IP address. I supposed the first root router is not allowing more than 1-hop for the given IP address. I need assistance on this one, please? What can be done if this is so, and if I have no control nor admin priv on the target root router?

2

There's a guide you can follow:
https://openwrt.org/docs/guide-user/network/wifi/relay_configuration

Packet capture can show if the DHCP traffic goes to the main router, and if a reply comes back, when you connect the mobile phone to the extender SSID.

root@OpenWrt:~# opkg install tcpdump
root@OpenWrt:~# tcpdump -nni any udp port 67 or udp port 68
3

Thank you for responding.

I did a reset and started over and followed the text guide, but still stuck on the dhcp, mobile phone did not get an IP.

Xiaomi Router is on 192.168.1.1 / Main Router is on 10.0.0.1
TCP Dump Result (i need help interpreting):

cpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
12:50:00.796525 phy0-ap0 B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:00.796550 lan1  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:00.796565 eth0  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:00.796579 br-lan B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:00.796833 phy1-sta0 Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:01.871125 phy0-ap0 B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:01.871155 lan1  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:01.871173 eth0  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:01.871209 br-lan B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:01.871423 phy1-sta0 Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:03.762396 phy0-ap0 B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:03.762434 lan1  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:03.762457 eth0  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:03.762479 br-lan B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:03.762734 phy1-sta0 Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 306
12:50:05.801621 phy0-ap0 B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:05.801662 lan1  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:05.801684 eth0  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:05.801705 br-lan B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:05.801974 phy1-sta0 Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:06.864196 phy0-ap0 B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:06.864238 lan1  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:06.864262 eth0  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:06.864285 br-lan B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:06.864540 phy1-sta0 Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:09.003654 phy0-ap0 B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:09.003696 lan1  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:09.003719 eth0  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:09.003743 br-lan B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:09.004011 phy1-sta0 Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 302
12:50:13.318959 phy0-ap0 B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 300
12:50:13.318990 lan1  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 300
12:50:13.319006 eth0  Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 300
12:50:13.319021 br-lan B   IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 300
12:50:13.319270 phy1-sta0 Out IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from <redacted>, length 300

Also, if I may ask if the relay bridge should also be under lan firewall, or unspecified?

5

Hi, I followed through the text guide, I did several attempts. But the last one worked, but using a second root router.

I am suspecting the first root router does not allow more than 1-hop for the given IP address. FYI, the first root/primary router is out of my control.

Question, can I speculate that the culprit on my issue is the main/root router? If so, is there a thing I can do to workaround it? I don't have access to the root router's admin. However, i think I can ask for support and do something on their end.

6

Coming up!

The lines above belong together, you can see that because the timestamp is the same (12:50:00).

What you are seeing is the "DHCP Request" for an IP address.

And you are seeing the same request multiple times, because we captured with -i any, meaning any interface. As the request traverses the various interfaces on the OpenWrt box, you will therefore see multiple lines logged.

After the Timestamp | Interface | Direction fields, the rest of the line contains a dump of the actual contents of the DHCP request; you can just ignore the rest of the line.

Same as above, these belong together too.

First, the DHCP request arrives on phy0-ap0 which is one of your wifi networks, likely the one your client device is on.

Next, it ends up on the lan1 interface which corresponds to a port in the back of the router.

Third line is eth0 which represents the switch hardware that operates all the lanX ports.

Not sure what is going on in line 4 and 5... Looks like the DHCP request is also flooded out via bridging to another wifi network (phy1-sta0).

In any case, we expected to see a DHCP Response too, coming in the other direction (either In via eth0/lan1, or In via phy1-sta0). But we are not seeing that.

Could mean either that there is no DHCP server on either of those two networks.

Or that the DHCP server does not like the request that your client sent and relayd forwarded.

1 Like
7

Awesome

Ooh, that sounds like a reasonable suspicion.

In that case, maybe it would be possible to change the TTL value of the DHCP request with ebtables or nftables or some such.

Bit of a special scenario, not sure if there are any guides out there for doing that kind of thing...

With some more tcpdump magic (-s0 -w my.pcap) you can write the capture to a file, open it up in Wireshark, and compare the TTL difference etc. between the arriving and the forwarded request. But that's pretty advanced and will likely take a good deal of time and research into fx. how Wireshark works first.

Either that, or relayd mangled the DHCP request, or it is being forwarded out of the wrong interface.. Probably...

I'm fresh out of ideas, sorry

1 Like
8

@appelsin thanks a mil! comprehensive response, but will take me quite a while to digest and execute. it's my bad not yours :slight_smile: , and thank you!

a bit of learning curve.

1 Like
9

No problem, glad you found it useful :slight_smile: