DHCP Lease not forwarded from Wifi on Linksys E5400

Installing and Using OpenWrt
1

Hi all strange behavior here:

==== Configuration =====
I have a linksys EA7500 v1 (running OpenWRT 23.05.0) connected to my main router (Tomato, running the DHCP server for two network segments) which in turn is connected to my ISP router on a bridged port.
The EA7500 is a WIFI access point (WDS) for 2.4 and 5.1 GHz.
I have 4 other routers (all running OpenWRT 23.05.0) which are connected as client (WDS) router to the EA7500, two to the 5.1 and two to the 2.4 GHz Wifis.
All 4 clients routers get a proper IP according to the configuration of the Tomato router.
The client routers are configured to have a lan bridge. The wifi as well as all NICs are in the lan bridge and the lan bridge is in the LAN firewall zone (there is no other firewall zone). I am aware that the wifi devices cannot be added to the lan bridge in the device section of the interface, but in the wifi section in luci.
DHCP server is switched off on all clients and the EA7500 as well. Firewall-SW and DHCP-server are still on the clients and not blocked, just switched off resp. not used.

==== Expected behavior ====
If I connect any network station (Laptop. PC, .....) to any of the sockets at any client router, It is expected to enter the lan zone, a DHCP request will be forwarded to the DHCP Server, and an answer with a DHCP Configuration will be received as reply. The network station configures its NIC according to the reply and is then connected to the Network. Traffic goes to other stations in the network segment or the gateway and into the internet.
In total I have 5 network stations connected to the four client routers (ok 4 wifi client routers and 5 network stations is a bit strange, but they are not all connected. 2 client routers are just spare for tests and if problems occur on the ones where network stations are connected to the sockets. The client routers have detachable antennas and I can sent/receive on longer distance/thicker walls than using just the build-in wifi device of the connected network stations)

==== Observed behaiour ======
Strange enough, it is working as expected only on three of the four client routers. On just one of the client routers, connected network stations do not receive the DHCP configuration from the DHCP server.
I installed tcpdump on the malfunctioning client router and see:

root@Linksys-E5400-CaiSec:/var# tcpdump | grep -v STP | grep -v ARP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:16:34.453420 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 54:ee:75:d2:f6:37 (oui Unknown), length 291
13:16:34.453537 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 54:ee:75:d2:f6:37 (oui Unknown), length 291
13:16:34.453561 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 54:ee:75:d2:f6:37 (oui Unknown), length 291
13:16:34.476398 IP 172.16.6.1.67 > 172.16.6.11.68: BOOTP/DHCP, Reply, length 324
13:16:36.453026 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 54:ee:75:d2:f6:37 (oui Unknown), length 291
13:16:36.453141 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 54:ee:75:d2:f6:37 (oui Unknown), length 291
13:16:36.453167 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 54:ee:75:d2:f6:37 (oui Unknown), length 291
13:16:36.457274 IP 172.16.6.1.67 > 172.16.6.11.68: BOOTP/DHCP, Reply, length 315
13:16:39.186370 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 54:ee:75:d2:f6:37 (oui Unknown), length 291
13:16:39.186492 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 54:ee:75:d2:f6:37 (oui Unknown), length 291
13:16:39.186518 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 54:ee:75:d2:f6:37 (oui Unknown), length 291
13:16:39.189113 IP 172.16.6.1.67 > 172.16.6.11.68: BOOTP/DHCP, Reply, length 315

Note:

  1. I skipped ARP and STP lines of the dump using grep.
  2. The malfunctioning client router is a Linksys-E5400.
  3. The device of the network station which is requesting the DHCP config has the MAC 54:ee:75:d2:f6:37
  4. The DHCP Server has the fixed IP 172.16.6.11 linked to the MAC 54:ee:75:d2:f6:37
  5. As from the protocol above, the reply with the correct IP is sent from the DHCP Server into the lan bridge on the malfunctioning client router, but not forwarded to the network station.

Question: Why does the reply from the DHCP Server not reach the network station that requested it????

What I tried:
a) other device/MAC requesting DHCP config - same result
b) other cable - same result
c) switched off 2 of the client routers - same result

I got the expected result with other client routers - tested: Linksys EA7500 as client router also (I have two of these), Linksys EA6500, TP-Link WR1043ND.
I checked the configs of the working client routers config in luci against the malfunctioning for diffs - none found (one of the working client routers has no switch - but the other have and everything is working perfect)

Has anyone come over such problems earlier or is it an issue of the client (E5400)?

I also tried a bit of switching the Wifi between 2.4 and 5.1 and found, that I should take care to avoid loops/backpaths, because if I have those, i.e. two connections between stations in the network, the STP goes indefinitely deep and everything else is blocked. So second question, less important: Where to switch off the STP?

Looking for some advice.....

2

Found a solution, it is on the switch config!

Remember: This concerns only situations in which
a) the main DHCP Server is connected by cable to an AP and
b) the local router is a client in that AP's WIFI
c) DHCP requests go from computer connected via network cable to the local router
d) leases are expected to travel cable, wifi and cable again to the requester.

Solution by switch config;

  1. must have VLAN functions activated
  2. at least two VLANs
  3. at least one CPU for each VLAN set to "tagged" (If only one CPU, then "taqged" on both VLANs)
  4. no CPU set to "untagged" anywhere.
  5. the link where you want the lease to be forwarded to the client must be set to "untagged" on at least one VLAN (other don't care, but not untagged as well)

(Standard implausible configs do not work, off cause, e.g. no CPU assigned to the VLAN where the link is untagged, etc.)

If that is the config, then it works, just one condition not met - no lease reply from the main DHCP server in the network.

--- Strange enough ----

Further:
Do not set all (CPU + Links)
a) for one VLAN to "untagged" and "off" for the other - huge net traffic - device cannot be reached any more - hard reset needed.
b) alternatively one to "off", next to "tagged" - saving is not possible, nevertheless the device cannot be reached and hard reset needed.

I just checked this out, but have no explanation for the whole behavior, if anyone can explain, it were highly appreciated.

(I updated all to OpernWRT: 23.05.05)

3

This seems reasonable based on the way the internal switches work.

I don't think this is necessary.

The CPU port should typically be tagged, yes. but...

This is also usually correct. However, this isn't necessarily a hard requirement in most cases provided that the bridge is configured properly.

In the case of a single/flat network topology, yes, you'll typically be working with untagged networks on the switch ports. But if the network uses VLANs, this may be different.

Not having seen the config, I would guess that you changed some of the defaults and thus caused an invalid/inconsistent configuration.

Well, most misconfigurations will indeed break the network, but we'd have to see the broken configs.

Turning off or deleting the second VLAN should be fine. The problem here may have been if you untagged/disabled the CPU port (and didn't account for it on the downstream config items) and/or disabled the VLAN that is used for the lan.

Not sure what you mean here.

Ultimately, I think this was related to user confusion about how to configure the VLANs on the switch and CPU and the other parts of the configuration (namely the bridge in this particular case).

4

My concern is that this should work without VLANS, (VLAN functions disabled, all VLANS deleted) as I do not have/need VLANS.
I did not find any detailed explanation how to configure the LAN bridge, in particular the "Advanced device options" (I know what "Enable IGMP snooping" means but not "Force IGMP version" - things like that...)
And: I just cross checked: if I delete all but one VLAN and save, it is working as well....until the next reboot, then no DHCP lease, not even if I create another VLAN - reboot is needed, then working again - just observations.....

5

It should work in theory, but you have to understand the implications of making the changes and the other related config changes that are required.

However, with that in mind, it is important to distinguish the idea of VLANs at an external/user level vs that which is operating within the device. It is common for many consumer "plastic box" routers to have a 5 port switch, where 1 port is used for the wan and the other 4 are used for the lan. Since all 5 ports are on the same switch, the router will (internally) use VLANs to keep the wan and lan separated. In the case of OpenWrt, this will be visible when you're working with the configuration, but the default state of OpenWrt has no user VLANs (I.e. on the lan side), unless the user decides to add VLANs to their configurations.

To make a silly analogy... take the game of monopoly and think about the 'banker' -- this person has to keep the bank's money separate from their own since both are within easy reach -- maybe they have a pile to their right that is their own "personal" money and on the left is the bank's money -- the positions here would be kind of analogous to the VLANs inside the switch in the default config for the wan/lan.

6

Dear Psherman, thanks for your explanation, so it seems that without VLANs it is not working.

7

I wouldn't come to that conclusion, personally. Since I have not seen the configuration and haven't had the chance to advise on the necessary changes, I can only guess that there were inconsistencies and/or invalid elements in the configurations you attempted. I still think it would be theoretically possible, but...

From the default configuration, there is nothing that needs to change with respect to the VLAN/switch configuration except if you want to also include the wan port as 'just another port' on the switch.

The only things that need to be changed on a simple bridged-AP configuration are:

  • IP address (either DHCP protocol or if static must be non-conflicting and outside the DHCP pool)
  • disable dhcp server
  • configure and enable WiFi
  • connect via lan port.
8

Minimal changes are a good choice to get things running....
But sometimes I want to understand the details. So far my philosophy....

No stick to the subject:
In this particular case I want a wifi client to forward traffic to the ĹAN Ports (described in the first post in this thread but probably a bit long....)
The AP is working fine on another device.
Yes, your hints on the config are clear and that is what I did. For the wifi client the wifi config is set as client (WDS).

The standard is working fine, I just wanted to check whether I can omit the VLANS.

Config:

  1. All LAN ports, all WIFI in one single bridge. Interfaces -> devices: Only the bridge "configured" (Must be, else the device does not connect to the AP and is also not reachable as DHCP client itself with "shared" connection).
  2. One WIFI client (WDS) connection.
  3. Switch: All default -> "Enable VLAN functionality" ticked, 2 VLANs, one for LAN ports, one for WAN port. one tagged CPU for each VLAN)

All working as expected (DHCP request forwarded by wifi and granted as well, trafic routed correct.) :star_struck:

Then I cross checked some changes to the config:

  1. Deleted VLAN2, i.e. left: One VLAN with CPU tagged, LAN and WAN ports all untagged, WAN also off
    (More tests with CPU untagged as well, WAN port off, also "Enable VLAN functionality" unticked - all same result)
    Device connects to network but does not route DHCP requests and/or answers
    (leases) from/to the LAN ports. Situation as described in the first post: The lease is granted by the DHCP Server, but not forwarded to the client, that connected to the device via LAN.

Conclusion: Standard config is working fine (Actually that is all I want) but removing one VLAN or untick "Enable VLAN functionality" breaks the (=this) config....

I am sure Peter is right, should work without VLAN (that is also what logic tells us), but that would probably mean more distortions in the other components of the config.

That's all, folks!

9

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.