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 <kerry9...@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.li...@gmail.com> > wrote: > >> On 4 August 2015 at 23:24, Joshua Judson Rosen <jro...@harvestai.com> >> wrote: >> > On 2015-08-04 14:14, Roman Yeryomin wrote: >> >> On 4 August 2015 at 17:58, Joshua Judson Rosen <jro...@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@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel