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: http://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:

Code: Select all

emerge bridge-utils wpa_supplicant

Optionally if you want to use DHCP for the bridge address:

Code: Select all

emerge dhcpcd

Set up your /etc/conf.d/net

Code: Select all

# The bridge will take the ip address, so the individual interfaces don't need any
config_enp3s0="null"
config_wlan0="null"

modules_wlan0="wpa_supplicant"
wpa_supplicant_wlan0="-b br0"

# Set up an Ethernet bridge--only add the wired interface initially
bridge_br0="enp3s0"
# Use DHCP to get the IP address for the bridge. Could be static or APIPA also.
config_br0="dhcp"
# Ensure the wired interface is up/started before creating the bridge
rc_net_br0_need="net.enp3s0"
# In case DHCP fails
fallback_br0="192.168.X.Y/24"
fallback_routes_br0="default via 192.168.X.Z"

# Assign mac to bridge if necessary
#mac_br0="aa:bb:cc:dd:ee:ff"

# You may want to add this otherwise other services which depend on net may not start because they're waiting for wlan0
rc_net_wlan0_provide="!net"

# Use the new method to configure bridge parameters
stp_state_br0="1"

# Want this to be 0 but it seems to want a minimum of 200
#forward_delay_br0="0"

# Want this to be 2 but minimum seems to be 100
hello_time_br0="100"

# This doesn't work because it tries to add wlan0 to the bridge before wpa_supplicant runs and you get Operation not supported
#bridge_add_wlan0="br0"
# So instead we use the postup script to add wlan0 to the bridge after it is up
postup() {
  if  [[ ${IFACE} = "wlan0" ]]; then
    ebegin "Adding ${IFACE} to bridge";
    /sbin/brctl addif br0 wlan0
    eend $?
  fi
  return 0;
}

The parameter -b br0 for wpa_supplicant is key. Without it, you will get "Operation not supported" trying to add the interface wlan0 to the bridge br0.

Now create and add the network services to the appropriate runlevels.

Code: Select all

ln -s /etc/init.d/net.lo /etc/init.d/net.enp3s0
ln -s /etc/init.d/net.lo /etc/init.d/net.wlan0
ln -s /etc/init.d/net.lo /etc/init.d/net.br0
rc-update add net.br0 default
rc-update add net.wlan0 default

Note that you specifically do not want net.enp3s0, dhcpcd or wpa_supplicant in any runlevel (they will be brought in automatically by the net configuration).

Next, set up the access point. Here is the essential configuration to create an access point using wpa_supplicant (network security is WPA2 pre-shared key with AES) :

Code: Select all

ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=1
fast_reauth=1
network={
        ssid="Bridge Test"
        psk="Shared Key"
        key_mgmt=WPA-PSK
        proto=WPA2
        group=CCMP
        priority=10
# These next two lines put the interface in access point mode on channel 11
        mode=2
        frequency=2462
}

I recommend using a distinct SSID for testing (such as "Bridge Test" as above) first. Once you confirm you can connect and get an IP address, then you can change the SSID and security settings to be equal to your primary wireless access point SSID to support automatic roaming.

Usage:
Simply reboot, or just stop all the net.* services (except net.lo) and then start net.br0 and net.wlan0. /etc/init.d/net.br0 will bring up net.enp30, inherit its MAC address and request an address from the DHCP server. Then /etc/init.d/wlan0 will start and create the access point, and will then be added to the bridge. If the MAC address of the wireless interface is numerically lower than that of the wired interface (as it is in my case), the bridge will assume that MAC address. I don't believe this is a problem, however, because dhcpcd caches the MAC address it used to request the lease and (I believe) it will re-use that when renewing the lease. If it is a problem, you can always manually assign a MAC address to the bridge using the mac_br0="..." directive as commented out in the /etc/conf.d/net example above.

For testing different wireless access point settings, it is sufficient to just restart /etc/init.d/wlan0

This Ubuntu forum post was helpful in getting me pointed in the right direction: http://ubuntuforums.org/showthread.php?t=1692292

Edit: Added proto=WPA2 (alias for RSN) to /etc/wpa_supplicant/wpa_supplicant.conf to force WPA2 operation

[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]

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?)

This method shouldn't affect routing at all (it's done on the Ethernet level, below the IP level), so I'd expect it would land directly on the device. I haven't tested it, though...

[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]

Set up your /etc/conf.d/net

Code: Select all

Does it work only with Gentoo net.* scripts or is it possible also with dhcpcd as network manager?

[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]

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 :D

szatox, charles17 ... the simple solution is to create runlevels with the specific network configuration required for each. So, dhcpcd for one 'configuration' and config/net for another (AP) ... you can then switch between these with 'rc <runlevel>'.

Note, not many people use runlevels (at least in my experience, and to their full advantage), in such a case you can have conf.d/dhcpcd.<runlevel> and conf.d/net.<runlevel> or even conf.d/net.<interface>.<runlevel> ... and so fine tune whatever setup you want for the specific setup (a search for my name as author and stacked (or runlevels) as the search term should return some examples).

best ... khay

[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]

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.

szatox ... yes, but he could create a runlevel in which dhcpcd is configured to only manage a specific interface. Anyhow, he doesn't really need to change what he does for 'normal' networking, just shift this specific setup to its own runlevel and replicate the above "AP" via another (which was really all I wanted to point out).

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.

yes, exactly, but it needn't stop there, runlevels can be created for all manner of things, 'ad-hoc' networks, or for a specific set of services for a specific network connection/location, etc ... you can create as many of these as you might need.

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.

No, because each has its own config, so 'rc_*_need, 'rc_*_provides', etc, can be used.

Also, a service providing net must be explicitly added to the runlevel that requires it or one of many possible things will happen.

Actually, thats not the case, if something 'needs' net, then something that 'provides' it is started (though not necessarily the provider you intended). Anyhow, its not a problem because they are seperate runlevels (its just like having multiple versions of 'default' only differently configured).

best ... khay

[charles17]

khay, it seems to me that charles17 wanted to have AP active and use dhcpcd as network manager at the same time.

No, sorry. Not that complicated. You've already answered my question

It uses netifrc speccific stuff.

[Jaglover]

Thanks for great tutorial!

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

Code: Select all

bridge_stp_state_br0="1" 

bridge_forward_delay_br0="0" 

bridge_hello_time_br0="100" 

[Hulda10]

Great update.