HOWTO: Create WiFi access point using wpa_supplicant

[SiliconFiend]

This is sort of a follow-up to the system build I did with a small cheap ECS Liva frontend documented here: https://forums.gentoo.org/viewtopic-t-1006786.html I am using this system as a MythTV frontend in a back bedroom. Since I have run CAT6 to that location, that frees up the wireless card to be used as a remote access point to boost my WiFi signal in that area. I was able to get this working with the net.* scripts, brctl and wpa_supplicant. This method forms an 802.1d Ethernet bridge between the wired and wireless interfaces, which will pass packets to-and-from the interfaces seamlessly.

Assumptions:

• The computer has both wired and WiFi adapters
  
• The wired connection is the uplink to the switch/router
  
• There is an existing DHCP server somewhere on the wired network
  
• The wireless interface will be set up as an access point, not a client. You need other packages and configuration to make that work (hint: ebtables)
  
• The wired interface is enp3s0, the wireless interface is wlan0 and the bridge is named br0. Substitute as necessary.
  

Prerequisites:

• Enable CONFIG_BRIDGE in your kernel config (module is okay)
  

Procedure:

[WD-40]

Looks interesting!

Do you happen to know off-hand how the traffic is routed for packets going between the bridge computer (the ECS LIVA in your case) and a wireless device which has connected to it?

For example, say you have an iPad connected wirelessly to the network via the bridge PC (the LIVA), and want to establish an AirPlay connection between the iPad and the MythTV Frontend running on that LIVA. Will that traffic make an extra round-trip loop through the wired router, or is the bridging smart enough to trap that locally on the LIVA? (Does using a DHCP server on the wired network, or running another one locally on the LIVA make any difference in that case?)

Thanks for the writeup!

[SiliconFiend]

[szatox]

Nice trick, I didn't know wpa_supplciant can work in AP mode at all. I used to configure it with iwconfig long time ago and then went for hostapd.

WD-40,
switches attempt to remember what MAC is attached to which interface. Also, enabling STP allows the virtual bridge discover and break loops, so there will not be a round-trip to a router with STP enabled and you can expect there won't be such a trip without STP either.
Routing would be like ipod -> wlan0 -> br0. While you technicaly CAN retrieve data packet as soon as it reaches wlan0, doing it on br0 is preferable as a much cleaner solution.

[charles17]

[szatox]

It uses netifrc speccific stuff. AFAIR dhcpcd can either work on listed interfaces or on not listed interfaces though, so you can limit it's activity a bit and configure some particular interface in a more custom way.
Depending on your setup, it's gonna get tricky, probably ugly, and might even eat your breakfest or kick your balls when you don't expect it, and will be way more complicated than necessary. So yes, it is possible. Don't do that

[khayyam]

[szatox]

khay, it seems to me that charles17 wanted to have AP active and use dhcpcd as network manager at the same time. This sounds like a bad idea.
Since you mentioned separate runlevels for AP mode and more dynamic, dhcpcd based one, yes, it is a good solution if it can be used.
It would require disabling strict dependencies though, as both, netifrc and dhcpcd provide net and we don't want both of them to be started at the same time.
Also, a service providing net must be explicitly added to the runlevel that requires it or one of many possible things will happen.

[khayyam]

[charles17]

[Jaglover]

Thanks for great tutorial!

There has been a slight syntax change, nowadays 'bridge_' prefix should be used for br0 options, like below.

[Hulda10]

Great update.