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 <[email protected]> wrote: > 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
