[OpenWrt-Devel] "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)

Tue Aug 4 16:24:23 EDT 2015

On 2015-08-04 14:14, Roman Yeryomin wrote:
> On 4 August 2015 at 17:58, Joshua Judson Rosen <jrosen at harvestai.com> wrote:
>> On 2015-08-04 02:26, David Lang wrote:
>>> A given radio can be either an AP or a client, but not both at once.
>>>
>>> so if you use a radio to connect to another AP, you are making it a client, and
>>> in client mode all it can do is connect to that other AP as shows up as the SSID
>>> of that other AP.
>>>
>>> you can do this with one radio, while using the other radio (assuming you have
>>> two) to act as an AP for local clients.
>>
>>
>> This is not necessarily true: with at least some hardware/drivers, it's
>> possible to create multiple virtual interfaces on top of a single radio--
>> and separate virtual interfaces can in fact operate in different modes
>> (e.g.: one in STA mode, two in AP mode, one in mesh mode...).
>>
>> Assuming that your hardware/driver is capable of supporting multiple
>> virtual interfaces on top of the single physical radio,
>> you can create these interfaces by adding "wifi-iface" stanzas
>> in /etc/config/wireless, e.g:
>>
>>         config wifi-device 'radio0'
>>                 option type 'mac80211'
>>                 option channel '11'
>>                 option hwmode '11g'
>>                 option path 'platform/ar933x_wmac'
>>                 option htmode 'HT20'
>>                 option country 'US'
>>                 option txpower '20'
>>
>>         config wifi-iface 'ap1'
>>                 option device 'radio0'
>>                 option mode 'ap'
>>                 option wds '1'
>>                 option ssid 'my AP'
>>                 option network 'lan'
>>
>>         config wifi-iface 'mesh1'
>>                 option device 'radio0'
>>                 option mode 'mesh'
>>                 option mesh_id 'my mesh'
>>                 option network 'lan'
>>
>>
>> That creates two virtual interfaces using the same physical radio,
>> and bridges them together onto the OpenWrt "lan network"
>> (which is itself defined in /etc/config/network).
>>
>>
>> I believe you could also have an interface with "mode 'sta'", but note
>> that it would also need to use the same channel as the other interfaces--
>> which means that the external AP to which you connect it would also
>> need to use that same channel (11, in the example above).
>> That's where having multiple *radios* helps: you can run them on
>> different frequencies (either completely different bands [2.4 GHz vs. 5 GHz],
>> or on different channels within the same band [e.g. 2.427 GHz = channel 4
>> vs. 2.472 GHz = channel 13]) to increase efficiency by multiplexing
>> less data over a single radio, or to increase compatibility with other
>> APs outside of your control that you might want to connect to.
>>
>> Also note that, if you want to bridge a STA interface onto anything else,
>> it'll need to be in "WDS" mode _and_ the the AP to which it's connecting
>> will also need to be in "WDS" mode (note the "option wds '1'",
>> in my example above), because the standard "3-address mode" of Wi-Fi
>> isn't bridgeable (and note that WDS "4-address mode" is bridgeable,
>> but not standardised across different platforms--so you're probably
>> OK so long as all of your equipment is running Linux and using
>> the same Wi-Fi driver, but don't expect to bridge a STA interface
>> that's connected non-Linux Wi-Fi router).
>>
>> At least, I've seen this work with Atheros chips. There are some
>> notes in the wiki about how Broadcom chips have their own, different
>> solution implemented in hardware; and about how some drivers
>> don't support this stuff at all....
> 
> Actually 3-address mode bridging is possible with the help of relayd

That's not actually "3-address mode bridging", though--
it's relaying (done entirely through a userspace daemon,
which AFAICT actually relays only IPv4, ARP, and DHCP packets).

> and it even works quite good.
> But there is an issue (also mentioned in a parallel thread): when
> client interface cannot connect then AP interface doesn't come up
> also. Which may not be a problem unless you want to bridge ethernet
> there also.
> On the other hand you may not be able to switch the main AP into
> 4-address mode so relayd is a way out.

It may be a solution.

When I tried it a few months back (in Barrier Breaker),
relayd wasn't really working for me....

I know that's a terrible (non-)description; I don't specifically
remember what seemed to be going wrong, except that there was
a lot of traffic not reliably getting through to where it was supposed to,
and that it was confusing, and that I was able to slightly improve
the situation by fiddling with some of the options that the init-script
passed to relayd (IIRC, I had some success using "-I" on only one interface
and "-i" on the other), but I didn't have time to dig in and actually
understand what wasn't working--just switching to 4-address mode and having
OpenWrt set up a kernel-level bridge w/ brctl was a more expedient
path for me to get something working reliably at the time.

Actually, if anyone can offer guesses as to what my issues
with relayd might have actually been, I'd be glad to hear them :)

I'm not specifically aware of a reason why IPv4+ARP+DHCP relaying
should have been insufficient for what I was doing (I wasn't
running any weird non-IP protocols...).

Maybe someone can point me to a basic explanation of what
sort of "ARP cache and host route management" the "-I" option
is actually doing--and why I might need to disable it on one
of my interfaces?

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel