On 4 August 2015 at 23:24, Joshua Judson Rosen <[email protected]> wrote: > On 2015-08-04 14:14, Roman Yeryomin wrote: >> On 4 August 2015 at 17:58, Joshua Judson Rosen <[email protected]> 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 [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
