No DHCP or DNS for tagged VLANs on TP-Link EAP615 ver.1.0

I am unable to get guest and IoT VLANs to work on a EAP615 ver.1.0 access point. When connecting to these VLANs, I get a prompt for the password on the clients, but it disconnects after that. It looks like the client is not getting an address. Note that I already have multiple TP-Link AX23 access points on the network with a similar setup in terms of interfaces, VLANs, tagging, and firewall, and they all work fine.

The tagging on the EAP615 looks like this:

ubus output:


# ubus call system board
{
	"kernel": "5.15.167",
	"hostname": "OpenWrt",
	"system": "MediaTek MT7621 ver:1 eco:3",
	"model": "TP-Link EAP615-Wall v1",
	"board_name": "tplink,eap615-wall-v1",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.5",
		"revision": "r24106-10cc5fcd00",
		"target": "ramips/mt7621",
		"description": "OpenWrt 23.05.5 r24106-10cc5fcd00"
	}
}

Network configuration:

# cat /etc/config/network 

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd7e:91b7:9f55::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan0'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'

config interface 'lan'
	option device 'br-lan.99'
	option proto 'static'
	option ipaddr '10.0.0.115'
	option netmask '255.255.255.0'
	option ip6assign '60'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan0:t'
	list ports 'lan1:t'
	list ports 'lan2:t'
	list ports 'lan3:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '20'
	list ports 'lan0:t'
	list ports 'lan1:t'
	list ports 'lan2:t'
	list ports 'lan3:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '99'
	list ports 'lan0:u*'
	list ports 'lan1:u*'
	list ports 'lan2:u*'
	list ports 'lan3:u*'

config interface 'iot'
	option proto 'dhcp'
	option device 'br-lan.10'

config interface 'guest'
	option proto 'dhcp'
	option device 'br-lan.20'

DHCP-configuration:

# cat /etc/config/dhcp 

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'
	option filter_aaaa '0'
	option filter_a '0'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option ignore '1'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'guest'
	option interface 'guest'
	option ignore '1'

config dhcp 'iot'
	option interface 'iot'
	option ignore '1'

Firewall configuration:

# cat /etc/config/firewall 

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'guest'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'guest'

config zone
	option name 'iot'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'iot'

config forwarding
	option src 'guest'
	option dest 'lan'

config forwarding
	option src 'iot'
	option dest 'lan'

config rule
	option name 'DHCP DNS'
	option src '*'
	option target 'ACCEPT'
	list proto 'tcp'
	list proto 'udp'
	list proto 'icmp'
	option dest_port '53 67 68'

Wireless configuration:

# cat /etc/config/wireless 

config wifi-device 'radio0'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
	option channel '1'
	option band '2g'
	option htmode 'HE20'
	option disabled '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
	option channel '36'
	option band '5g'
	option htmode 'HE80'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'HomeWIFI'
	option encryption 'psk2'
	option key '********************'

config wifi-iface 'wifinet1'
	option device 'radio1'
	option mode 'ap'
	option ssid 'IoT'
	option encryption 'psk2'
	option key '*****************'
	option network 'iot'

config wifi-iface 'wifinet2'
	option device 'radio1'
	option mode 'ap'
	option ssid 'Guest'
	option encryption 'psk2'
	option key '*****************'
	option network 'guest'

Thanks.

Generally, things look okay. I would recommend chaining these two networks to unmanaged (option proto 'none'). Then reboot and test again.

If it still doesn't work, check the upstream connection to make sure that it has VLANs 10 and 20 tagged and VLAN 99 untagged + PVID on the respective port.

1 Like

Thank you very much for the input, @psherman. I reset the router, and set interfaces iot and guest to unmanaged, and lan to static (as before). Upon logging into the cli, I tried to ping 8.8.8.8, to no avail. Had to set DNS explicitly for the lan interface with uci to make it work (uci set network.lan.dns="8.8.8.8 8.8.4.4"). I then installed tcpdump. DHCP-packages look like this on the different interfaces:

For the lan interface:

# tcpdump -i br-lan -e -n vlan 99 | grep DHCP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:01:31.550210 f0:09:0d:9f:5b:e1 > 9e:9c:e4:00:f1:a4, ethertype 802.1Q (0x8100), length 346: vlan 99, p 0, ethertype IPv4 (0x0800), 10.0.0.1.67 > 10.0.0.211.68: BOOTP/DHCP, Reply, length 300
18:01:31.551586 f0:09:0d:9f:5b:e1 > 9e:9c:e4:00:f1:a4, ethertype 802.1Q (0x8100), length 346: vlan 99, p 0, ethertype IPv4 (0x0800), 10.0.0.1.67 > 10.0.0.211.68: BOOTP/DHCP, Reply, length 300
...

For the iot interface:

# tcpdump -i br-lan -e -n vlan 10 | grep DHCP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:03:44.246085 26:dd:e5:26:e4:a8 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 352: vlan 10, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 26:dd:e5:26:e4:a8, length 306
18:03:45.287572 26:dd:e5:26:e4:a8 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 352: vlan 10, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 26:dd:e5:26:e4:a8, length 306
18:03:47.158911 26:dd:e5:26:e4:a8 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 352: vlan 10, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 26:dd:e5:26:e4:a8, length 306
...

For the guest interface:

# tcpdump -i br-lan -e -n vlan 20 | grep DHCP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:05:02.752538 9e:9c:e4:00:f1:a4 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 352: vlan 20, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 9e:9c:e4:00:f1:a4, length 306
18:05:03.842793 9e:9c:e4:00:f1:a4 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 352: vlan 20, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 9e:9c:e4:00:f1:a4, length 306
18:05:05.988718 9e:9c:e4:00:f1:a4 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 352: vlan 20, p 0, ethertype IPv4 (0x0800), 0.0.0.0.68 > 255.
255.255.255.67: BOOTP/DHCP, Request from 9e:9c:e4:00:f1:a4, length 306
...

Looks like VLAN10 and VLAN20 are trying to get HCP from 0.0.0.0:67 or 68 unsuccessfully. Each dump contains an endless stream of these... VLAN99 gets what it needs without a hitch.

This is all very odd, as I have installed a bunch of APs without any problems, APs with an almost identical configuration. Now, those were AX23 routers, while this is an EAP65 access point. Maybe there is something about the hardware in this access point that I am missing? Any help much appreciated.

Although it is not a large contingent of devices, but there are some that do not like mixed untagged + tagged networks on the same port. I don't think this is the case here, though.

Let's review the config of this device again (/etc/config/network and /etc/config/wireless)

1 Like

Here's the network config:

# cat /etc/config/network 

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd25:3b33:8d31::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan0'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'

config interface 'lan'
	option device 'br-lan.99'
	option proto 'static'
	option ipaddr '10.0.0.115'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option gateway '10.0.0.1'
	list dns '8.8.8.8'
	list dns '8.8.4.4'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan0:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '20'
	list ports 'lan0:t'

config bridge-vlan
	option device 'br-lan'
	option vlan '99'
	list ports 'lan0:u*'

config interface 'iot'
	option proto 'none'
	option device 'br-lan.10'

config interface 'guest'
	option proto 'none'
	option device 'br-lan.20'

I think the only changes are the "option gateway" and the "list dns".

The wireless config:

# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
	option channel '1'
	option band '2g'
	option htmode 'HE20'
	option disabled '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
	option channel '36'
	option band '5g'
	option htmode 'HE80'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'HomeWIFI'
	option encryption 'psk2'
	option key '++++++++++++'

config wifi-iface 'wifinet1'
	option device 'radio1'
	option mode 'ap'
	option ssid 'IoT'
	option encryption 'psk2'
	option key '++++++++++++'
	option network 'iot'

config wifi-iface 'wifinet2'
	option device 'radio1'
	option mode 'ap'
	option ssid 'Guest'
	option encryption 'psk2'
	option key '++++++++++++'
	option network 'guest'

Thanks

These config files look fine... but let's try a change to the ethernet port configs...

let's make port lan3 the trunk, and then we'll assign the others as access ports, one per network. So make the changes like this:

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan3:t'
	list ports 'lan1:u*'

config bridge-vlan
	option device 'br-lan'
	option vlan '20'
	list ports 'lan3:t'
	list ports 'lan2:u*'

config bridge-vlan
	option device 'br-lan'
	option vlan '99'
	list ports 'lan3:u*'
	list ports 'lan0:u*'

Reboot the router. Move your uplink to port lan3. Then connect a computer to ports lan0 - lan2, one at a time, and check to see if they join the correct network.

1 Like

This access point is PoE, and it connects to lan0, so I configured the network like this:

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan0:t'
	list ports 'lan1:u*'

config bridge-vlan
	option device 'br-lan'
	option vlan '20'
	list ports 'lan0:t'
	list ports 'lan2:u*'

config bridge-vlan
	option device 'br-lan'
	option vlan '99'
	list ports 'lan0:u*'
	list ports 'lan3:u*'

Next, I tested ports 1 to 3 with a computer, and no address was obtained on lan1 and lan2. lan3 worked.

Thanks

Ok... that config is fine. But this indicates that the upstream may not be working as expected.

What is immediately upstream of this AP?

1 Like

First, an unmanaged switch, and then another unmanaged switch, followed by some 50 meters of ethernet cable to a third unmanaged switch, and after that, there is a router at 10.0.0.1.

I guess I should mention that all the other APs are much closer to the router, and connected via the switch just before the router.

Unmanaged switches should not be used with VLANs. Their behavior is undefined, and some may not work properly when tagged frames are present. In some cases, this can even result in serious network issues.

You said that you have other APs that are working... Try moving the AP in question to the first switch and see if it works.

Ultimately, you should be using managed switches anywhere there are are tagged networks -- this is not only important from a functional/reliability standpoint, but also helps with network administration and troubleshooting.

1 Like

Ok, will move the AP, and also change to managed switches. Thank you for the help. Much appreciated.

Please report on the results of the test when you move it to the most upstream switch.

1 Like

It works! Found a cable that went all the way back to the first switch after the router, and after some fiddling with the PoE (cable length leading to voltage drop, me thinks), it started working with proper tagging.

The next step — to ensure tagging everywhere on the LAN — is to get an OpenWRT-compatible smart switch.

Again, many thanks!

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