How do I configure a network interface bridge from WiFi to Ethernet with Debian?
I am using Raspberry Pi using Raspbian which is just Debian. I would like to bridge from the primary WiFi network router that connects to Cox Cable to my cabled router here for my subnet to have reliable internet access. It needs to be a WiFi-to-Ethernet bridge. I have set /etc/networks for a static address for the USB wlan1 with the external adapter and hi-gain antenna. wpa_supplicant is configured to log in to the master router properly. So right now it is set up so I can login to the proper network with the password, on external wlan1. Static address is set in /etc/networks. Gateway and nameserver are OK. I can browse web pages, etc. The missing link is to bridge this to the eth0 port so my router can connect also, to provide service to my subnet. No need for any extra network services like routing or nat or dhcp, etc. Just a simple bridge. Can anyone please point me in the right direction to make this happen?
Did you try a very basic bridge by setting no IP on your Ethernet device, creating a bridge with brctl addbr br0 , adding both devices to the bridge with brctl addif br0 device , and then setting your original Ethernet address and route on br0 ?
Good point. I added some edits to clarify. I like your answer below. It is precisely the opposite of what I am trying to do, but that’s OK because I think it is enough information to get me moving. Thank you for posting it.
Found this one and the first answer is funny. ‘too broadly correct’ — so this bridging stuff apparently requires magic, also. unix.stackexchange.com/questions/272146/…
Update from the future (late 2018): Since 2.6.33, you can’t bridge wlan to eth. You can bridge wlan to eth only if you switched then wlan0 into 4addr mode. Not all drivers support that. You can read more about it here.
3 Answers 3
For configuring a bridge from ethernet to wifi, it is as simple as doing in your /etc/network/interfaces :
auto eth0 allow-hotplug eth0 iface eth0 inet manual auto wlan0 allow-hotplug wlan0 iface wlan0 inet manual auto br0 iface br0 inet static bridge_ports eth0 wlan0 address 192.168.1.100 netmask 255.255.255.0 Replace the IP address with something more appropriate to your network.
If you prefer the IP attribution done via DHCP, change it to:
auto br0 iface br0 inet dhcp bridge_ports eth0 wlan0 After changing /etc/network/interfaces , either restarting Debian or doing
service networking restart Will activate this configuration.
You will have to make sure for this configuration to have bridge-utils installed. You can install it with:
sudo apt install bridge-utils The wlan0 interface also has to be condigured to connect to your remote AP so this configuration is not be used verbatim.
Additional note: bridging eth0 and wlan0 together means in poor layman´s terms that br0 will present itself as a single logical interface englobing the interfaces that make part of the bridge. Usually such configuration is made when both extend or belong to the same network.
It is not actually the opposite; if you want wifi clients to connect to the raspberry you need hostapd on top of this configuration; I actually have an openwrt that has been configured here to do what you are asking
I’m a little bit confused. If I try your setup and do sudo ifup -a I get the error message can’t add wlan0 to bridge br0: Operation not supported . This was widely discussed with Bridging wlan0 to eth0. What I’m missing with your setup?
No problem to open a new question but I’m unsure if it make sense. I think your answer is outdated and should be corrected. Since kernel >=2.6.33 you cannot add wifi to a bridge (except when WDS is used). This is what is discussed in Bridging wlan0 to eth0.
Side notice: I learned in the past few days is, that bridging wifi to eth interfaces with running dhcp requires 4addr mode sudo iw dev wlp2s0 set 4addr on for both, AP and clients. To do this, all of the involved wifi interfaces must support interface mode AP, see iw list | less and connections need to take down for 4addr on first, and then take up again, to prevent the Operation not supported error message, as mentioned by @Ingo
Bridging with a wireless NIC Just like you can bridge two wired ethernet interfaces, you can bridge between an ethernet interface and a wireless interface. However, most Access Points (APs) will reject frames that have a source address that didn’t authenticate with the AP. Since Linux does ethernet bridging transparently (doesn’t modify outgoing or incoming frames), we have to set up some rules to do this with a program called ebtables.
For an alternative Layer 3 approach using proxy ARP and routing, see BridgeNetworkConnectionsProxyArp.
ebtables Overview ebtables is essentially like iptables, except it operates on the MAC sublayer of the data-link layer of the OSI model, instead of the network layer. In our case, this allows to change the source MAC address of all of our frames. This is handy because we fool our AP into thinking that all of our forwarded frames come from the machine which authenticated to the AP.
. The instructions there go on to manage a list of addresses on one side, I couldn’t follow.
Comment Reply: I don’t see where you get 3. For 4 it depends on how you divide things between L1 and L2, if you draw a box around the radio signals that indicate «This WiFi radio is going to transmit» and include the first 2 addresses. And view those as part of the L1 session meaning they form a physical connection between 2 radios. Then there is no problem with too many L2 addresses, we are safely back at 2.
I’d be interested in documentation that describes how ebtables manages all these addresses.
It’s not (just?) about authentication: bridging with 3 MAC addresses instead of 4 (yes 3 and 4, while Ethernet has only 2) won’t allow systems behind the bridge to work. See networkengineering.stackexchange.com/questions/25100/…
I am told that, for those of us who have advanced hardware and firmware, the accepted bridge solution works. But for me, using open source linux firmware for ath9k, combined with an open source atheros qualcom chip set, the above answer does not work. So, if you try the bridge and you get the ‘Operation Not Permitted’ error.
WiFi and Ethernet cannot be directly bridged via the Debian bridge-utils package containing brctl because the level 3 package protocols are different. WiFi assumes that every packet comes from another source and includes that information, while Ethernet does not. Spoofing/cheating methods exist, but they are recognized as a threat by the outside world and blocked.
You must rebuild the level 3 package to convert Ethernet headers to WiFi headers via a Linux service called dnsmasq.service which masquerades packages, rebuilding the level 3 headers. The declaration of what is to happen may be created via Linux iptables wnich may employ a process called Network Address Translation.
#!/bin/bash # # wifi2eth # # Tested on Debian GNU/Linux bullseye/sid system. # Used to connect a Magic Jack Ethernet device so that I may use a corded telephone through the computer which connects to a cellular to WiFi hot-spot device (the MiFi-8000). # There are certain numbers which, when dialed out, where I can hear the person I called, but they cannot hear me. The problem was resolved by adding UNTRACKED to the list of packets which should be forwarded from WiFi to Ethernet (the telephone). # When an incoming packet is marked as UNTRACKED, then the state mechanism is broken. I have no problem yet, but if UNTRACKED is used by a sender which is not part of VOIP, then that will create a browsing problem. I would prefer my computer disrespect UNTRACKED requests. # # This program creates a functioning WiFi to Ethernet 'bridge' # # Step 0: Reset < # the redirect of this block also hides bash -x sudo ifdown --all for zUp in $(ip addr show | sed -nEe 's/2+: ([^:]+).* UP .*/\1/p' | tr '\n' ' '); do sudo ip link set "$zUp" down # force interface down which ifdown was unable to bring down done sudo iptables -F sudo iptables -t nat -F sudo systemctl stop dnsmasq.service sudo systemctl disable dnsmasq.service >&> /dev/null sudo ifup --all sudo ifup wlNet 2>&1 | grep -Ee "^Listening on" -e "^DHCPDISCOVER" -e "^bound to" if [[ $(ip link show wlNet) = *' state DOWN '* ]]; then echo "$(tput setaf 1). $(basename "$0"): Could not ifup wlNet . $(tput sgr0)" exit fi # Step 1: Create the iptables aEthernet="enTele" # the Ethernet output I want for magicJack aWireless="wlNet" # the functioning wireless input aNext=192.168.2 # the next subnet after 192.168.1 aIp_address="$aNext.1" # use the next subnet to create internal network aNetmask="255.255.255.0" # the network mask # aNetwork="$aNext.0" # the external inet representing the internal block # aBroadcast="$aNext.255" # the broadcast IP aDhcp_range_start="$aNext.50" # inet addresses to be available in subnet aDhcp_range_end="$aNext.100" # inet addresses to be available in subnet aDhcp_time="12h" # address lease duration sudo iptables --flush sudo iptables -F sudo iptables -A FORWARD -i $aWireless -o $aEthernet -m state --state RELATED,ESTABLISHED,UNTRACKED -j ACCEPT sudo iptables -A FORWARD -i $aEthernet -o $aWireless -j ACCEPT sudo iptables -t nat -F sudo iptables -t nat -A POSTROUTING -o $aWireless -j MASQUERADE # Step 2: Turn on IP forwarding. sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" sudo ifconfig $aEthernet $aIp_address netmask $aNetmask # May also have to uncomment net.ipv4.ip_forward=1 in /etc/sysctl.conf # Remove possible default route created by dhcpcd. # Hide error if route does not exist. sudo ip route del 0/0 dev $aEthernet &> /dev/null # Step 3: Reconfigure and restart domain name masquerade. sudo systemctl stop dnsmasq cat - > /tmp/custom-dnsmasq.conf iptables.rules # write current rules to configuration file # $ sudo iptables-restore < iptables.rules # restore rules from configuration file # $ sudo apt-get install iptables-persistent # package for automated iptables-save/restore Above is a program needing chmod +x which creates the NAT forwarding 'bridge' when executed. It will not automatically create the 'bridge' when you reboot.
Note: Packages like network-manager, wicd, connman, etc. all do their own thing. Such packages add configuration, GUI, and control layers which, in my opinion, serve only to convolute everything. Uninstall all of them. This method uses only packages which actually perform a required task: dnsmasq, iptables, and wpasupplicant. The simpler you system, the more comprehendible and reliable your solution.
$ ip addr show # list every network interface and its current situation $ sudo ifup INTERFACE # raise interface declared in /etc/network/interfaces $ sudo ifdown INTERFACE # lower interface declared in /etc/network/interfaces Best wishes in your pursuit to remain totally open source.
netplan добавить в bridge интерфейс wifi с получением dhcp по wifi
Вообще, где-то на debian 6 я добавлял wifi в бридж, но в том случае это делалось утилитой hostapd. Оно было точкой доступа. Сейчас задача обратная.
Wireless interface on a bridge To add a wireless interface to a bridge, you first have to assign the wireless interface to an access point or start an access point with hostapd. Otherwise the wireless interface will not be added to the bridge.
насколько это актуально сейчас?
Посмотрите, что в логах и dmesg не забудьте.
ЗЫ Нарыл свой древний(ещё из первого десятилетия) скрипт, может что-то подскажет. Это на поддиванном роутере работало, в бридж собирал сетевку локалки и wifi карточку
BR=`which brctl` IC=`which ifconfig` IFE='eth0' IFW='wlan0' IFBR='br0' IPBR='172.17.0.1' MASKBR='255.255.255.128' if $IC $IFBR 1>/dev/null 2>&1; then $IC $IFBR down $BR delbr $IFBR fi $IC $IFE 0.0.0.0 $IC $IFW 0.0.0.0 $BR addbr $IFBR $BR addif $IFBR $IFE $BR addif $IFBR $IFW $BR stp $IFBR off $IC $IFBR $IPBR netmask $MASKBR can't add wlp70s0 to bridge br_lan: Operation not supported
targitaj ★★★★★ ( 06.02.23 22:34:38 MSK )
Последнее исправление: targitaj 06.02.23 22:34:44 MSK (всего исправлений: 1)
Вот здесь https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi говорят, что у неё «limited feature support» И судя по тому, что ей трэба фирмварь, она не совсем хардверная 🙂 Я тоже как-то случайно купил софтверную, полностью хардверная была model_name, а софтверная model_name+ (с плюсом на конце) ну я не придал этому значения, оказалось зря 🙂
anc ★★★★★ ( 06.02.23 23:18:43 MSK )
Последнее исправление: anc 06.02.23 23:33:18 MSK (всего исправлений: 2)
Хм. Вот как. Я решу другим способом.