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

Tue Aug 4 19:00:06 EDT 2015

On 4 August 2015 at 23:24, Joshua Judson Rosen <jrosen at harvestai.com> wrote:
> 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).

OK, yes technically it's not bridging :)

>> 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?
>

I was using trunk around March-April this year and didn't have any
problems. So I would suggest just trying newer version.

Regards,
Roman
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel