[OpenWrt-Devel] Fwd: "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
John kerry
kerry9842 at gmail.com
Thu Aug 6 09:24:18 EDT 2015
Hi,
I have configured wireless as below:
*config wifi-device 'wifi0' option type 'qcawifi' option
channel 'auto' option macaddr '00:03:7f:42:06:61' option
hwmode '11ng' option txpower '19' option htmode 'HT20'config
wifi-iface option device 'wifi0' option network 'lan'
option mode 'ap' option encryption 'psk2' option ssid
'Test_ap_1' option key **'Test_ap_1'*
*It works fine with WPA2 key but when i try to connect another router this
will become as client and SSID will change to that router SSID as i
mentioned before also.*
*As i understand we can create one more to avoid this problem as explained
in previous mail.*
*Basically i need that when i connect to wireless WAN, the LAN SSID should
not change. I am using AR9344. Can i use below script for my requirement.*
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'
Thanks & Regards,
On Wed, Aug 5, 2015 at 7:00 AM, Roman Yeryomin <leroi.lists at gmail.com>
wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150806/f055f7e2/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list