Totally transparent bridge in layer 2?

For Developers
#1

Good morning,
I'am working with a Wi-Fi module with the SoC Atheros 9331. OpenWRT/LEDE gives us the option to make a physical bridge between LAN and WLAN, but in this chipset it doesnt work, so I must install relayd to build a pseusobridge. The problem is that relayd works in layer 3 (ARP NAT) instead of layer 2, so all the ARP packages throught the openWRTmodule has the ARP Sender address frame with the IP of the openWRT module instead of the real source (it is not a transparent bridge).

With Gargoyle the bridge is in layer 2 in versions below 1.8, with newer ones (1.9 and 1.10) the bridge is performed in layer 3 :confused:
I hear with the QSDK it is posible to build the bridge in layer 2 because it performs natively.

Can you help me to build a layer 2 bridge?

Thank you very much,
Regards

#2

It depends only on the WiFi driver
Recent ones 99% prevent to make a layer 2 bridge when in client mode

#3

Thank you, and how can I build the Wifi driver with layer 2 bridge?

#4

It is not a matter of build, you should develop it!
In short words: you cannot do it

#5

Ethernet and WiFi are different at Layer 2, so there is no such thing as a "native", Layer 2 bridge. You will need to tunnel Ethernet frames through a WiFi link. gretap is one method with low overhead and low computational cost. Depending on your objectives and hardware, WDS may also be an option.

#6

Thank you, WDS is not an option for me since the APs where I connect my modules has the WDS disabled and I have no access to enable.
Is there any package (regarding to "gretap") or compilatin setting to tunnel Ethernet frames through a WiFi to get layer 2 bridge?

#7

To have a GRE tunnel, you need to run the GRE driver on both ends of the link. So you need access to both routers, and they need to both have suitable software such as OpenWrt.

GREtap works by making a layer 3 connection between the two endpoints. It also ties into the kernel at layer 2. The layer 2 packets including MAC addresses are wrapped up into layer 3 packets, which will transport over a network that is not layer 2 bridged, such as an ordinary AP--STA WiFi link.

#8

Okay, unfortunately I cannot access to the AP.
So there is not any other way to bridge in layer 2 in openWRT?

#9

Not sure what this means -- any sort of bridging you are trying to do will require access to both ends of the tunnel to configure the protocol. You can't, for example, set up WDS on one end and expect the other end to "magically" connect.

#10

The bridge I want to build its between the LAN and WLAN interfaces of the same module. The AP must be independent from this process due to I only have the guest network credentials and I can't change his configuration.

#11

Umm, if I'm understanding you properly, you'd like to effectively straight-wire through someone else's router for which you don't have administrative privilege, ending up bypassing their routing, firewall, NAT, access control, ...

I'll assume the best in that you want a Layer 2 bridge from a host under your control that is using this AP for transport and some remote network that is also under your control. In that case, look at something like OpenVPN as being able to handle that kind of setup with authentication, encrypted transport, robustly, and with straightforward configuration.

1 Like
#12

Nope, I don't want to bypass any router or AP, I may explain bad.

I have a Wi-Fi module (lets call it MO1) configured as client. My MO1 module connects to an AP by Wi-FI.
Then I want to connect a PC to my MO1 module by ethernet, this way my MO1 module atcs as bridge between my PC (MO1's ethernet interface) and AP (MO1's wireless bridge). Thats the bridge which I'am talking about, the bridge between LAN and WLAN of the MO1 module itself.

#13

That bridge should just work. LEDE bridges Ethernet and wlan on all it's defaults. Are you saying that because it's in STA mode this kind of bridge doesn't work? I haven't tested that... But if it's true I don't think you can do much.

#14

I'm trying to understand the use case. Why is above a problem?

#15

Now that I think about it I bet wds is needed to make this work, otherwise how would the Mac addresses of Ethernet frames make it to the other end of link...

#16

The bridge with the atheros AR9331 doesn't work, you should install relayd to route the packages through interfaces.

1 Like
#17

The problem is that only I have the permission to assign one IP per PC, with the bidge in layer 3 I have to asign two IPs per PC (PC IP + Wi-Fi module IP) while with layer 2 bridge only have to asign one (PC IP) because the bridge is totally transparent.

#18

Just in case anyone is interested, I have arpnat working well on Kernel 5.4.43 on a WRT1900 ACS V2, since that device doesn't support WDS and relayd etc are painful in comparison. You can see my "fork" of current trunk at https://github.com/dmascord/openwrt

#19

I have been thinking about taking Gargoyle back to using arpnat.
I note that some of the patches from it are in your solution.


Good to see they still have a purpose.
#20

Just to be clear, it's not my solution at all :slight_smile: All that I've done is to keep it compatible with the latest kernels as they come out, integrated any fixes made by Ubiquity, and fixed a few bugs.

Ie, following the reference on https://projectgus.com/2010/03/wireless-client-bridging-with-openwrt/ as well as merging in fixes from https://github.com/unifi-hackers/unifi-gpl/blob/master/build_dir/toolchain-mips_gcc4.1.2/linux-2.6.15-5.2/net/bridge/netfilter/ebt_arpnat.c

Looking at your contributions, it looks like Gargoyle's patch has also moved on - https://github.com/q158073378252010/gargoyle_ericpaulbishop-GuiShiXiang/blob/master/patches-generic/011-arpnat.patch and now that 011-arpnat.patch is no longer in Gargoyle!

Do you find relayd to be performant enough for most cases? My WRT 1900 ACS v2 can easily push 300mbps over the wireless bridge with less than 10% CPU usage.