On Arch Linux, I would like to have eth0 (connected to bridged router) share the connection received from wlan0, I've read tutorials but I'm not command savvy as other users are and don't completely understand.

please do not put '[solved]' in the question or title, accepting an answer is the correct way to show that a problem was solved. It changes the way the question is displayed on the main listing as well as putting the green check mark on the answer you have marked as correct.
– ZypherSep 25 '10 at 0:14

1

I'd appreciate it if nobody messed with this page. If you have any problems, contact me. Thank you.
– dbdii407Sep 25 '10 at 0:26

What is this setting for and why do you specifically suggest to use it in this scenario?
– hakreJun 19 '16 at 17:07

This is a solution for "Operation not permited" error when trying to add wlan0 interface to the bridge interface. After that you have to specify the bridge interface in /etc/network/interfaces in order to be bringed up after startup.
– Str82DHeaDOct 19 '16 at 12:45

1

@hakre The 4addr mode make WiFi behave enough like wired Ethernet that bridging will work. Without it, bridging will not work without NAT.
– David SchwartzApr 21 '17 at 8:42

1

4addr does require that both sides of a wireless link support it (presuming you are trying to implement a wifi extender)
– nhedApr 17 '18 at 16:15

1) It might only want to see packets coming from you, with your known link layer address (and hence not of bridged packets)
2) It might actually be even smarter, and know which IP address should belong to which link layer address (cause it knows DHCP and inspects it)

If 1+2 are both true, you need indeed something like IP NAT, DHCP, ..

But if only 1) is the case, you can fake the link-layer address, and reverse map it onto the right one in the other direction as described here:

While this does allow you to a wifi interface to a bridge it will also break the connectivity to that wifi interface. I think this could be resolved with iptables or route, but I'm not savvy enough with those tools to know how to fix the issue.
– RoraΖJun 22 '17 at 12:52

4addr as described in other answers is certainly the best way when supported by the adapter/driver, but not all of them does. NAT might work for some things, but getting proper communication both ways on the lan will become problematic (ex. connecting a printer or accessing other IoT devices on the other side of the NAT). Anything relying on broadcast/multicast (ex. auto-discovery, bonjour) will fail through the NAT.

The alternative is using an ARP Proxy (parprouted) as described in https://wiki.debian.org/BridgeNetworkConnectionsProxyArp. I've set this up on a Raspberry Pi for a printer and it works like a charm (I have added a 10 second sleep in the post-up commands to let it get an IP address first, it might have to do with the slowness of my old RPi...)