This topic contains guidelines for using the target platform as a network bridge between two networks.
Requirements
To make a target platform act as a network bridge between two networks:
-
The target platform must have at least two network interfaces (either wired or wireless).
-
The Linux kernel image of the target platform must support network bridging. By default, the Linux kernel compiled with Digi Embedded Yocto already supports bridging.
Methods
There are two methods for connecting a pair of networks:
-
Bridging: The platform device acts like a tunnel that connects the two networks (or two network segments), forming one big subnet that allows devices to connect to each other without the need for routers.
-
IP forwarding: The platform device translates the address of a packet to a new destination according to a routing table.
The following instructions explain the bridging method.
Access point bridging
This chapter illustrates how to configure a target platform to act as a network bridge. Consider the following scenario:
-
A target platform embedded device acts as the bridge.
-
The target is connected through one wired Ethernet interface to a wired LAN that has access to the Internet.
-
There are three wireless devices to connect by bridge.
-
There is no wireless AP, so the wireless devices cannot access the LAN.
By configuring the platform as a bridge, you can connect the three wireless devices to the LAN and gain access to the Internet.
A network bridge can be established between two network interfaces of any kind: two wired Ethernets, a wired Ethernet and a USB-Ethernet gadget, a USB-Ethernet gadget and a wireless interface, and so on. |
This topic demonstrates how to establish a network bridge between a wired Ethernet (eth0) and a wireless interface in AP mode (wlan0), including how to configure the wireless interface. You can follow similar steps to create the bridge between arbitrary network interfaces as long as you configure each interface properly.
Network bridging support on the kernel
Network bridging support on the kernel requires the following options:
Networking support --> Networking options --> [*] 802.1d Ethernet Bridging (CONFIG_BRIDGE) [*] IGMP MLD snooping (CONFIG_BRIDGE_IGMP_SNOOPING)
These options are enabled by default on Digi Embedded Yocto kernel configuration. |
Configure NetworkManager
For the bridge to work, you must prevent the Network Manager daemon from managing the network interfaces involved in the bridge.
Add the relevant network interfaces (in the example eth0 and wlan0) to the list of unmanaged-devices in /etc/NetworkManager/NetworkManager.conf.
[main]
plugins=ifupdown,keyfile
no-auto-default=type:ethernet
rc-manager=file
[ifupdown]
managed=false
[keyfile]
unmanaged-devices=interface-name:p2p*;interface-name:wlan1;interface-name:eth0;interface-name:wlan0
[device]
wifi.scan-rand-mac-address=no
Restart the Network Manager daemon to use the new configuration:
~# /etc/init.d/networkmanager restart Stopping NetworkManager: done Starting NetworkManager: done
Wired network interface
Make sure the wired network interface is connected to the network and bring it up:
~# ifconfig eth0 up
Wireless network interface
Bring the wireless interface down to reconfigure it:
~# ifconfig wlan0 down
Kill all running instances of wpa_supplicant daemon:
~# killall wpa_supplicant
Configuration as SoftAP
Configure the connection settings of your wireless interface in /etc/wpa_supplicant.conf on your target’s root file system.
Make sure the parameter mode is set to 2, to work as SoftAP. The following example shows a configuration that uses WPA-PSK/AES authentication with SSID my-bridge-ap:
# SoftAP mode (WPA-PSK/AES)
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
fast_reauth=1
update_config=1
ap_scan=2
network={
ssid="my-bridge-ap"
mode=2
frequency=2412
key_mgmt=WPA-PSK
proto=RSN
pairwise=CCMP
psk="12345678"
}
Start the wireless interface as SoftAP
Bring the interface up:
~# ifconfig wlan0 up
Before running the wpa-supplicant daemon, we need to create the bridge.
Bridge interface
Create the bridge interface br0:
~# brctl addbr br0
Run the wpa_supplicant daemon and force it to use the bridge br0:
~# wpa_supplicant -B -i wlan0 -D nl80211 -c /etc/wpa_supplicant.conf -b br0
Remove the IP addresses of the two network interfaces that the bridge will join (in the example, eth0 and wlan0).
~# ifconfig eth0 0.0.0.0 ~# ifconfig wlan0 0.0.0.0
Add each network interface to the br0 bridge:
~# brctl addif br0 eth0 ~# brctl addif br0 wlan0
Verify the bridge lists the two interfaces:
~# brctl show bridge name bridge id STP enabled interfaces br0 8000.0004f3280000 no eth0 wlan0
If the interfaces are not correctly listed as associated to the bridge, delete the bridge and recreate it. To remove the bridge and restart the procedure, do the following: |
~# ifconfig br0 down
~# brctl delbr br0
~# killall wpa_supplicant
Assign a static or dynamic IP address to the bridge.
This step is optional but recommended if you want to reach the bridge (the target platform) in the network.
~# ifconfig br0 192.168.1.5 netmask 255.255.0.0
Bring the bridge up:
~# ifconfig br0 up
Configuration is complete. Your wireless devices should now be able to connect to the target platform (acting as SoftAP), and reach any device in the LAN network, or the Internet (if the LAN has access to it).
Create the bridge interface automatically at boot time
To automatically create the bridge interface at startup, edit /etc/network/interface and add the following lines at the end of the file:
auto br0
iface br0 inet static
bridge_ports eth0 wlan0
address 192.168.1.5
netmask 255.255.0.0
bridge_wpa_driver nl80211
bridge_wpa_conf /etc/wpa_supplicant.conf
The bridge must appear as the last item in the file to make sure the involved interfaces exist when the bridge is created. |
Client side bridging (Wi-Fi extender)
For a Wi-Fi extender configuration both the AP and the client sides needs to be bridged. This configuration allows to extend a wireless LAN across a Wi-Fi direct bridge, effectively extending the LAN.
802.11 4 address mode
The 802.11 standard uses three fields on the MAC frame to carry layer 2 MAC address information. This 3 address model does not support client side bridging as the source MAC address is dropped on the frames transmitted between AP and station. To overcome this limitation, 802.11 defines an optional 4 address mode. The 802.11 standard only provisions the extra field without providing implementation details.
Several OEMs use this 4 address mode to implement Wi-Fi extender features, for example for Wireless Distribution Service (WDS). These implementations are non-standard and require matching hardware and software on all devices, and usually require softMAC chipsets, that is, chipsets that use the mac80211 layer on the Linux kernel. This softMAC devices usually suffer from a performance penalty compared to devices that implement their own MAC layer in hardware (hard MAC).
The AR6233 chipset is a hard MAC device and 4 address mode is not currently supported.
Wi-Fi extender with BATMAN layer 2 protocol
However, Wi-Fi extender can be implemented by using a layer 2 routing protocol to provide the source address resolution missing from the 3 address 802.11 mode.
The setup below uses the BATMAN (Better Approach to Mobile Adhoc Networking) layer 2 protocol implemented as a driver in the Linux kernel:
-
Configure the Linux kernel with support for BATMAN advanced.
Networking support --> Networking options --> [*] B.A.T.M.A.N Advanced Meshing Protocol (CONFIG_BATMAN_ADV)
These options are enabled by default on Digi Embedded Yocto kernel configuration. |
-
Set up a Wi-Fi direct link, for example using the Negotiated GO method described at Wi-Fi Direct.
-
Add the P2P interface to the BATMAN interface at both ends:
~# batctl if add p2p-p2p0-0
~# ip link set up dev bat0
-
Bridge the wired Ethernet and BATMAN interface at both ends:
~# ifconfig eth0 0.0.0.0
~# ifconfig bat0 0.0.0.0
~# brctl addbr br0
~# brctl addif br0 eth0
~# brctl addif br0 bat0
~# ifconfig br0 up
The network will take up to 30 seconds to be established as the nodes need to discover each other. Devices at both sides of the bridge should now be configured on the same subnet and will be able to ping each other.