Setting Up Wired 802.1X

I have a device running LEDE set up as an access point. As I have 4 additional ethernet ports available, I would like to use them to connect devices, extending the ports available in my router, and using 802.1X for client authentication and VLAN assignment.

My understanding is that hostapd can be used for this purpose using the 'wired' driver. I have set up the switch in my router so that the 'LAN' ports are tagged and can carry the VIDs used for my network. However, I haven't been able to find much information about getting this setup to work, let alone using LEDE or OpenWRT.

I have tried using hostapd this way, but when I connect a device(*) to one of the LAN ethernet ports and try to use 802.1X, nothing really happens. I see nothing in the hostapd output, and my RADIUS server does not report any authentication attempts.

So, I have a few questions:

  1. Am I doing something wrong in the configuration of my AP's switch or of hostapd that is causing this not to work?
  2. While creating a custom init script to run hostapd on the wired port is not really an issue, it would be so much cleaner to let LEDE handle generating the configuration file and running hostapd. Is there any way this can currently be done? I was thinking along the lines of (ab)using the /etc/config/wireless file for this, although then LEDE would try to do wireless-related things to the interface, like assigning it a channel.

(*) The device I tried was a MacBook running macOS, and the procedure was connecting it to the port and pressing the 'Connect' button next to 802.1X under the ethernet settings. Maybe trying a Linux device with WPA Supplicant would yield different results, but I haven't tested this yet.


Sample of my network configuration file. In this case, VLAN 2 is used only internally by the device (connected to the WAN), while VLAN 1 can be shared through the LAN ports. This configuration works when devices are connected directly to the AP and they are set to use the correct VLAN.

config switch
    	option name 'switch0'
    	option reset '1'
    	option enable_vlan '1'
    	option mirror_source_port '0'
    	option mirror_monitor_port '0'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option vid '1'
	option ports '0t 1t 2t 3t 4t 5t 6t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option vid '2'
	option ports '1t 6t'


eth1 corresponds to the LAN port, where client devices are to be connected.
eth0 corresponds to the WAN port, which is connected to the router actually handling the network. This file is based on the hostapd.conf file generated for my wireless network, with irrelevant fields removed and some minor changes (like interface names and the driver used.)


Haven't played with wired dot1x mysefl yet, but the first thing I'd try is untagging the access ports. Supplicants might be hardcoded to send EAPOL untagged... I have seen commercial gear allow trunk VLANs to be added to dot1x ports through AAA attributes, and in "voice vlan" setups I imagine EAPOL on the tagged VLAN must work, but that's a specialized situation... most EAPOL is usually done over the PVID.

SO you'd want 0t 1t 2 3 4 5 6t

Keep in mind that with (wired) 802.1x the traffic for all LAN ports needs to pass through the CPU, barely any plastic router can cope with that (managed switches can do lots of that with hardware assistance).

Hrm... I wonder if hostapd could be taught to only keep the bridge in br-netfilter mode during auth and then just monitor link state until it flaps to pop it back in. That would be compatible with the multi-host model.

Though if you care enough to do wired 802.1x you'll probably be doing dhcpsnooping/sourceguard/mac-protect and multi-auth or multi-domain as well, so maybe there's little use case for that.

@skids I haven't got to experimenting with this a bit more yet, but I imagined hostapd would simply capture the untagged supplicant traffic on eth1, as the tagged VLANs have their own device (i.e., eth1.X). That is, I thought the port could be used in an either-or setup (manual VLAN tagging or untagged 802.1X), which is very convenient for testing. I'll try what you propose.

I want to set up 802.1X mostly because it allows me to easily and securely manage VLANs across the network. For the moment, I'm not running much besides EAP, as the devices within VLANs are relatively trusted (I'm considering DHCP snooping for the guest VLAN.)

@slh: Sure, it needs to pass through the CPU, but I believe running LEDE on a router pretty much disables hardware acceleration, so packages pass through the CPU no matter what. Or do you mean that there is some additional CPU overhead? When and if I get this working, I'll run a benchmark, but I don't expect to see a huge difference either way.

By default, without IEEE 802.1X, LAN traffic never hits the CPU, the configurable switch just provides the interconnect between the LAN ports directly (at line speed). With IEEE 802.1X, "something" needs to decrypt the traffic - which would be the CPU (with all traffic having to go through the CPU port as well); at least I don't know of any common plastic router supported by LEDE which would be able to get anywhere close to line speed doing this. On highend managed switches this decryption is done within the switch fabric using dedicated parallel hardware.

When you get to dhcpsnooping, see here:

But what slh is referring to is that often what you do with an AP is allow the switch to pass vlan traffic from access ports directly to the trunk without going through the CPU at all.. it stays inside the switch silicon. This won't matter if the device is already being used as a router instead of an AP... there's no encryption in wired 802.1x unless you are using MACSec.

Hi there,

Did someone ever managed to get a fully working wired 802.1x + vlan bridge with hostapd?

I got this setup to work without any troubles using wireless interface (configured through /etc/config/wireless thanks to this great article:

But surprisingly, getting it to work using an ethernet interface is a complete mess...

Authentication against radius server is working.
When listening to an ethernet interface, using wired driver, hostapd (full hostapd package, not mini) is unable to create dynamic vlan interface:

IEEE 802.11: could not add dynamic VLAN interface for vlan=x

where x stands for the vlan id provided by the radius server

The same config (generated by openwrt via luci) for wlan is working fine, wlan0.x is being created by hostapd and added to the bridge interface dynamically.

Using wired driver, the only way to solve this "error" is to manually create an ethernet vlan subinterface, adding it to the vlan_bridge, and binding it in vlan_file through hostapd beforehand.

Although it does seem to solve the issue according to hostapd logs (no errors, debug mode enabled): once authenticated, the ethernet traffic isn't offloaded to the provided subinterface (eg: eth1.x), but keeps flowing through primary interface (eth1 in my case), so nothing gets to reach the bridge interface as only eth1.x lies in it.

Although there's plenty write ups about wireless hostapd, and wired 802.1x for cisco switches, I wasn't able to find any relevant information about wired 802.1x (with vlans) using hostapd.

I guess I'm missing something, but I'm out of ideas, at least for now.
I'm considering switching to a more versatile alternative that is IPSEC (heavier tho) if I remain stuck on this.

Thanks for reading this till' the end.


Did you get it work for wired clients using hostapd? I am able to do the same with WLAN but not with wired. Can anyone please help if they got it working?


Nah sorry. I eventually gave up on this due to a lack of time.
I hope this gets figured out one day... In hostile environments, MAC filtering (alone) is definitely weak (easily spoofed) compared to 802.1 X auth / IPSEC alternatives.

Till then, my advice would be using IPSEC instead (CPU intensive due to involved encryption mechanisms though), or switching to more capable hardware.

Nah sorry. I eventually gave up on this due to a lack of time.
I hope this gets figured out one day... In hostile environments, MAC filtering (alone) is definitely weak (easily spoofed) compared to 802.1 X auth / IPSEC alternatives.

Till then, my advice would be using IPSEC instead (CPU intensive due to involved encryption mechanisms though), or switching to more capable hardware.

Thanks. But how do we configure wired interface using UCI to hostapd.conf. For wireless, we do configurations under radio0 in /etc/config/wireless as device but what should we do for wired. :thinking:

I've been trying to set up 802.1x wired with hostapd.
Here is my network topology.

Supplicant: ubuntu

AP: work as bridge mode;
br0(eth0 for uplink, ath00 as "wlan" and eth1 as "lan")

Radius server



At first, hostapd does not receive any eapol frame. So, i hacked a little bit of the source code,
and remove the "bind" releatd code in fucnion "wired_init_sockets" and modify "send" to "sendto"
and filled the addr with "eth1", and then it worked.

When i plugs the wire into the ap, the ubuntu network manger would prompt a diaglob box, let me
put in the identity and password. The hostapd log shows that ubuntu is authenticated.

is it possible for you to share the patch? I got wifi-8021x working and now want to do wired-8021x in parallel.

I got wired 802.1x working (under Armbian, but I don't think that makes a significant difference, other than having to recompile to enable wired mode), using the following steps. I wasn't trying to assign VLAN's, though.





"bob" MD5 "hello"
"bob" MD5 "hello" [2]

This is using the built-in radius server, you can obviously configure it to connect to an external one if you prefer.

I am curious to know whether anyone has had success implementing 802.1x-2010 with MACSec?

I have got manually configured MACSec interfaces configured between a workstation and an OpenWrt router, and verified that the traffic was encrypted at a network level. Now I'd like to be able to automate the key exchange process using 802.1x.