Transparent Bridge from Existing WiFi to Ethernet?

Question

I've seen lots of examples that turn the bridging machine into another router with its own DHCP server, etc. But I want to use a wired device as if it were connected directly to the original router. The bridging machine has no trouble connecting to the WiFi on its own.

This answer seems to be close to what I want, but it also says, The wlan0 interface also has to be condigured to connect to your remote AP so this configuration is not be used verbatim.

True to the warning, it doesn't work on its own - can't find the WiFi adapter, so it can't connect - but it doesn't say how to reestablish the original, working connection. How do I do that?

---

/etc/wpa_supplicant/wpa_supplicant.conf is:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US

network={
    ssid="MyNetwork"
    psk="MyPassword"
    key_mgmt=WPA-PSK
}

---

When the WiFi works, /etc/network/interfaces is the default:

# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

And the result of ifconfig:

pi@FCC-FOH:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:4c:6c:a7  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.43.35  netmask 255.255.255.0  broadcast 192.168.43.255
        inet6 fe80::c39b:c8ac:86c9:1f0e  prefixlen 64  scopeid 0x20<link>
        inet6 2600:100a:b02f:8196:b8ae:3d20:c4d0:817c  prefixlen 64  scopeid 0x0<global>
        ether 00:f0:00:36:1f:1a  txqueuelen 1000  (Ethernet)
        RX packets 17  bytes 1955 (1.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 52  bytes 7956 (7.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@FCC-FOH:~ $ 

---

When I try to enable the bridge, /etc/network/interfaces is:

# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto eth0
allow-hotplug eth0
iface eth0 inet manual

auto wlan0
allow-hotplug wlan0
iface wlan0 inet manual

auto br0
iface br0 inet dhcp
bridge_ports eth0 wlan0

And the result of ifconfig:

pi@FCC-FOH:~ $ ifconfig
br0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:4c:6c:a7  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:4c:6c:a7  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:f0:00:36:1f:1a  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@FCC-FOH:~ $ 

Solution 1

I got it! Just needed some slight tweaking from this starting point, which appears to translate one direction, but not the other. Filling in the other direction made it "click".

Apparently, you can't use DHCP through this kind of bridge for reasons I still don't fully understand (wired device onto a WiFi network), but if you're okay with static addresses for the bridge and for the device, it works. Here's how I did it:

---

Add this in /etc/network/interfaces:

auto eth0
auto lo wlan0
iface lo inet loopback

# We're going to play router on this interface, so set that address
iface eth0 inet static
    address 192.168.3.1
    netmask 255.255.255.0

# Setup WiFi and take a static address, so we know the context
allow-hotplug wlan0
iface wlan0 inet static
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
    address 192.168.2.5
    netmask 255.255.255.0
    gateway 192.168.2.1

# Take a second address, so we can bridge it to the single device at 192.168.3.x
iface wlan0 inet static
    address 192.168.2.6

---

Add this in /etc/rc.local:

# Match settings in /etc/network/interfaces
IP_THIS="192.168.2.6"
IP_OTHR="192.168.3.6"

# Actual work
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING  -d $IP_OTHR -i  eth0 -j DNAT --to-destination $IP_THIS
iptables -t nat -A PREROUTING  -d $IP_THIS -i wlan0 -j DNAT --to-destination $IP_OTHR
iptables -t nat -A POSTROUTING -s $IP_THIS          -j SNAT --to-source      $IP_OTHR
iptables -t nat -A POSTROUTING -s $IP_OTHR          -j SNAT --to-source      $IP_THIS

---

Make sure that /etc/wpa_supplicant/wpa_supplicant.conf includes this:

network={
    ssid="MyNetwork"
    psk="MyPassword"
    key_mgmt=WPA-PSK
}

It could be there already, if you're already connected through a graphical utility, but make sure anyway. Modify as needed for your network.

---

Set the bridged device to be static:

address: 192.168.3.6
netmask: 255.255.255.0
gateway: 192.168.3.1

and its targets, if any, on the 192.168.2.x network as if it were directly on that network.

It seems odd to communicate with something outside of its own subnet, but when the bridge does its translation (iptables), it comes out right.

Likewise, configure anything on the main network to use the bridge's second address, not the actual address, to talk to the bridged device.

---

Use a crossover cable to connect the device to the bridge, and after rebooting the bridge, it should "just work". (or at least it did for me)

The resulting structure is:

Router:
addr: 192.168.2.1
ssid: MyNetwork
pass: MyPassword
auth: WPA2
dhcp: 100+

Target for Bridged Device
addr: 192.168.2.2

Bridge
addr: 192.168.2.5 (WiFi primary - used for the Bridge Machine itself)
addr: 192.168.2.6 (WiFi secondary - forwards to Bridged Device)
addr: 192.168.3.1 (Wired - "plays router" for Bridged Device)

Bridged Device
addr: 192.168.3.6

Of course, you can change these addresses as needed, but be sure to keep them all straight.

Solution 2

Ok, I think the main problem here was a communication problem: You were using terms that have a very specific meaning in networking (bridge WLAN to LAN) instead of describing the desired outcome (I have a device A without WLAN, and I want to connect it to my WLAN router via a second device, so that is reachable from every other device on the WLAN, and vice versa). And then of course you get an answer fitting the terms with specific meaning (your Y in the XY-Problem)), which is not what you wanted (your X).

Which is what the XY-Problem is all about: If you ask about X instead of Y, you get proper answers. If you ask about Y, people can't answer properly.

So, let's do some networking basics. The OSI model describes several layers of networking. Layer 2 is the Ethernet/Wifi layer: Devices are identified by a MAC address, there is a segment (also called broadcast domain) where all devices see each other and can send messages to all other devices on this segment. Layer 3 on the other hand uses Internet (IP) addresses.

Bridging means to connect two layer 2 segments so that they appear as a single layer 2 segment (so layer 2 broadcasts will be seen in both former segments). Routing means to connect two layer 2 segments by finding the next destination for a packet on layer 3, and then forwarding this packet towards this destination on layer 2.

Now WLAN was designed to allow several access points on a layer two segment (called distribution system (DS)):

<--- SEGMENT (DS) --->  <- SEGMENT ->

    LAN         WLAN        LAN 
     |      
     |           .....C1------------D
     |---- B1 ....
A----|           .....C2
     |
     |---- B2 ..
     |

A is the gateway of the DS, B1 and B2 are access points (APs), C1 and C2 are stations (STA), D is a computer connected to C1 via LAN.

Simplifying a bit, packets sent over WLAN contain the MAC addresses for A, B and C (3-address mode). Because of that, the AP can bridge the WLAN and LAN adapters, forming a single segment: If C wants to send a layer 2 packet directly to A, it knows it's associated to B, so it can put addresses (A,B,C) into the packet. When B receives the packet, it sees the final destination is A, so it can just send it out again on the bridged LAN interface. And similarly in the other direction.

Now what happens if the STA C tries to do the same, and bridge LAN and WLAN? So when D sends a layer 2 packet to A, what addresses should C put in the WLAN packet? It can put in (A,B,D). If communication is not encrypted, then the AP B says "hey, that packet is coming from D, but I'm not associated to D. So that packet must have gone wrong, let's drop it". Even worse, if the communication is encryped (which should be the standard today), the key is negotiated between the AP and the STA. But C only has the <B,C> key, not the <B,D> key. So this packet can't be properly encrypted.

What if C just puts in its own MAC address? Then for packets going to D, they'll also end up being addressed to C instead. So C has to decide how it should distinguish between forwarding packets to D, and accepting those packets itself. This is difficult to do, because on layer 2 it doesn't have a lot of information to base this decision on. Which is why in that case, you end up with C "disappearing" while D appears to be directly connected to B. This is the solution WLAN_KABEL implements. Variations of this do base this decision on the (layer 3) ports used, etc.

Another option is to just put in all involved addresses (A,B,C,D) instead of only (A,B,C). This is called 4-address-mode, or sometimes a wireless distribution system (WDS; careful, WDS is also used for other, proprietary ways of doing something similar).

So now you know why you can bridge LAN and WLAN on a STA.

If you don't want to bridge, and just keep the segments as in the picture, then everything becomes simple: You route, and just add proper (static) routing tables for D on A and all Bs, and just like this, it becomes reachable. As layer 3 IP addresses are assigned based on segments, it just will have an address in a different range. E.g., the WLAN segment is 192.168.23.0/24, let's say A is 192.168.23.1, B1 is 192.168.23.2, B2 is 192.168.23.3, C1 is 192.168.23.100, and C2 is 192.168.23.101; and the LAN segement between C1 and D has C1 as 10.0.0.1 and D as 10.0.0.2. Then C2 can just say "send a layer 3 packet to 10.0.0.2" and it will arrive fine. No NAT needed.

Note that on most home networks, there's just a single AP (and few people know how to setup multiple APs properly, and do horrible things like double NAT instead if they want several APs), and your home router combines A and B into a single device. But the protocol is still as described above.

You'll find multiple APs set up like described in hotels etc., where professionals did the installation.

Comments

[dirkt]

That's a FAQ, search for similar questions. Basically you can't bridge WLAN STA to LAN, though you can bridge WLAN AP to LAN. You need (1) 4-address mode, or (2) a bridging host with multiple STAs, or (3) give up WLAN access to bridging host.

[elademir]

@dirkt I've never had much success with the search tool on any SE site, or Google. They all return way too much clutter. SE's related suggestions are marginally better, and I do check them as I write a new question, but only marginally. Sometimes I get my answer from there, upvote it, and abandon my new question, but I usually end up finishing and posting because none of the suggestions seem to be relevant either.

[elademir]

A lot of them are similar, but the details are always different from what I'm trying to do, and there's only a specific solution for that set of details. No attempt at a general solution or explanation that is adapted to the OP's situation as an example, so that I might adapt it to mine following that example. The closest I've seen so far for this problem is your comment of you can't bridge WLAN STA to LAN, which begs the questions, Why not? and What's STA?

[elademir]

Sorry for the rant - might be better for meta - but thanks for understanding at least.

[dirkt]

I hear you, and I agree the search is bad, and if I could find the question quickly, I'd have given the link. OTOH, I've seen similar questions now half a dozen times, and it gets tiring to always answer the same questions. STA = station (or client, if you want), AP = access point, you can't bridge a STA because the default 3-address mode provides one MAC address behind the AP (which the bridging needs), but no MAC address behind the STA.

[dirkt]

See e.g. here or here or here for some variants of the question.

[elademir]

@dirkt I think I can drop the requirement for DHCP through the "bridge". Everything I'm doing now can be static, though the router will still have it on for random new devices. And as I said at the top of this question, it's only for one device that doesn't have its own WiFi hardware but does have wired. I can't seem to find a working configuration for that either. The closest is this in terms of ping success, but still no traffic through the "bridge". Would that be a separate question? Or should I edit this one?

[dirkt]

If you don't need DHCP or anything else that only works in a single LAN segment, you can also just route instead of bridging. That's vastly easier to set up (add a static route to the "bridging device" and enable forwarding, add a static route to your main router), and all your devices will be able to reach all your devices "just as they were connected directly to the router", except for broadcasts. If this is what you want, this was an XY-Problem.

[elademir]

@dirkt From a technical perspective using formal definitions, it may have been an XY-Problem. But to a layman, all of those terms are functionally equal and so the XY disappears. We may ask for something specific because we happened to run across that term somewhere, but we're really interested in "whatever works". It's like calling all audio equipment "EQ", which is something that bugs me as a decently-skilled audio engineer.

[dirkt]

This does NAT, which isn't really necessary, and it won't forward broadcasts as a bridge does. If this does what you want, just use plain routing without NAT, unless the requirement is "IP address of the NATed device must be in the range of the main LAN segment".