[OpenWrt-Devel] "3-address Wi-Fi bridging" (was: Multiple Wi-Fi client/AP interfaces on one radio)
John kerry
kerry9842 at gmail.com
Thu Aug 6 23:15:54 EDT 2015
Hi,
Could anyone please help me on this to configure the wireless in such a way
that when we connect to wireless WAN the LAN SSID should not change.
Thanks,
On Thu, Aug 6, 2015 at 9:24 PM, John kerry <kerry9842 at gmail.com> wrote:
> 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/20150807/5d8d5b84/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