<div dir="ltr"><div>Hi,<br><br><br></div><div>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.<br><br><br></div><div>Thanks,<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 9:24 PM, John kerry <span dir="ltr"><<a href="mailto:kerry9842@gmail.com" target="_blank">kerry9842@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div><span class=""><div><div>Hi,<br><br></div>I have configured wireless as below:<br><br><b><span>config wifi-device 'wifi0'<br>        option type 'qcawifi'<br>        option channel 'auto'<br>        option macaddr '00:03:7f:42:06:61'<br></span>        option hwmode '11ng'<br>        option txpower '19'<br>        option htmode 'HT20'<span><br><br>config wifi-iface<br>        option device 'wifi0'<br>        option network 'lan'<br>        option mode 'ap'<br></span>        option encryption 'psk2'<br>        option ssid 'Test_ap_1'<br>        option key </b><b>'Test_ap_1'</b><b><br><br></b></div></span><b>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.<br><br></b></div><div><div class="h5"><b>As i understand we can create one more to avoid this problem as explained in previous mail.<br><br></b></div></div></div><div><div class="h5"><b>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.<br></b><div><div><span><br>config wifi-device 'radio0'<br>
>>                 option type 'mac80211'<br>
>>                 option channel '11'<br>
>>                 option hwmode '11g'<br>
>>                 option path 'platform/ar933x_wmac'<br>
>>                 option htmode 'HT20'<br>
>>                 option country 'US'<br>
>>                 option txpower '20'<br>
>><br>
>>         config wifi-iface 'ap1'<br>
>>                 option device 'radio0'<br>
>>                 option mode 'ap'<br>
>>                 option wds '1'<br>
>>                 option ssid 'my AP'<br>
>>                 option network 'lan'<br>
>><br>
>>         config wifi-iface 'mesh1'<br>
>>                 option device 'radio0'<br>
>>                 option mode 'mesh'<br>
>>                 option mesh_id 'my mesh'<br>
>>                 option network 'lan'</span><div><div><div><br><br></div><div>Thanks & Regards,<br></div></div></div></div></div></div></div></div><div><div class="h5"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 5, 2015 at 7:00 AM, Roman Yeryomin <span dir="ltr"><<a href="mailto:leroi.lists@gmail.com" target="_blank">leroi.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 4 August 2015 at 23:24, Joshua Judson Rosen <<a href="mailto:jrosen@harvestai.com" target="_blank">jrosen@harvestai.com</a>> wrote:<br>
> On 2015-08-04 14:14, Roman Yeryomin wrote:<br>
>> On 4 August 2015 at 17:58, Joshua Judson Rosen <<a href="mailto:jrosen@harvestai.com" target="_blank">jrosen@harvestai.com</a>> wrote:<br>
>>> On 2015-08-04 02:26, David Lang wrote:<br>
>>>> A given radio can be either an AP or a client, but not both at once.<br>
>>>><br>
>>>> so if you use a radio to connect to another AP, you are making it a client, and<br>
>>>> in client mode all it can do is connect to that other AP as shows up as the SSID<br>
>>>> of that other AP.<br>
>>>><br>
>>>> you can do this with one radio, while using the other radio (assuming you have<br>
>>>> two) to act as an AP for local clients.<br>
>>><br>
>>><br>
>>> This is not necessarily true: with at least some hardware/drivers, it's<br>
>>> possible to create multiple virtual interfaces on top of a single radio--<br>
>>> and separate virtual interfaces can in fact operate in different modes<br>
>>> (e.g.: one in STA mode, two in AP mode, one in mesh mode...).<br>
>>><br>
>>> Assuming that your hardware/driver is capable of supporting multiple<br>
>>> virtual interfaces on top of the single physical radio,<br>
>>> you can create these interfaces by adding "wifi-iface" stanzas<br>
>>> in /etc/config/wireless, e.g:<br>
>>><br>
>>>         config wifi-device 'radio0'<br>
>>>                 option type 'mac80211'<br>
>>>                 option channel '11'<br>
>>>                 option hwmode '11g'<br>
>>>                 option path 'platform/ar933x_wmac'<br>
>>>                 option htmode 'HT20'<br>
>>>                 option country 'US'<br>
>>>                 option txpower '20'<br>
>>><br>
>>>         config wifi-iface 'ap1'<br>
>>>                 option device 'radio0'<br>
>>>                 option mode 'ap'<br>
>>>                 option wds '1'<br>
>>>                 option ssid 'my AP'<br>
>>>                 option network 'lan'<br>
>>><br>
>>>         config wifi-iface 'mesh1'<br>
>>>                 option device 'radio0'<br>
>>>                 option mode 'mesh'<br>
>>>                 option mesh_id 'my mesh'<br>
>>>                 option network 'lan'<br>
>>><br>
>>><br>
>>> That creates two virtual interfaces using the same physical radio,<br>
>>> and bridges them together onto the OpenWrt "lan network"<br>
>>> (which is itself defined in /etc/config/network).<br>
>>><br>
>>><br>
>>> I believe you could also have an interface with "mode 'sta'", but note<br>
>>> that it would also need to use the same channel as the other interfaces--<br>
>>> which means that the external AP to which you connect it would also<br>
>>> need to use that same channel (11, in the example above).<br>
>>> That's where having multiple *radios* helps: you can run them on<br>
>>> different frequencies (either completely different bands [2.4 GHz vs. 5 GHz],<br>
>>> or on different channels within the same band [e.g. 2.427 GHz = channel 4<br>
>>> vs. 2.472 GHz = channel 13]) to increase efficiency by multiplexing<br>
>>> less data over a single radio, or to increase compatibility with other<br>
>>> APs outside of your control that you might want to connect to.<br>
>>><br>
>>> Also note that, if you want to bridge a STA interface onto anything else,<br>
>>> it'll need to be in "WDS" mode _and_ the the AP to which it's connecting<br>
>>> will also need to be in "WDS" mode (note the "option wds '1'",<br>
>>> in my example above), because the standard "3-address mode" of Wi-Fi<br>
>>> isn't bridgeable (and note that WDS "4-address mode" is bridgeable,<br>
>>> but not standardised across different platforms--so you're probably<br>
>>> OK so long as all of your equipment is running Linux and using<br>
>>> the same Wi-Fi driver, but don't expect to bridge a STA interface<br>
>>> that's connected non-Linux Wi-Fi router).<br>
>>><br>
>>> At least, I've seen this work with Atheros chips. There are some<br>
>>> notes in the wiki about how Broadcom chips have their own, different<br>
>>> solution implemented in hardware; and about how some drivers<br>
>>> don't support this stuff at all....<br>
>><br>
>> Actually 3-address mode bridging is possible with the help of relayd<br>
><br>
> That's not actually "3-address mode bridging", though--<br>
> it's relaying (done entirely through a userspace daemon,<br>
> which AFAICT actually relays only IPv4, ARP, and DHCP packets).<br>
<br>
</div></div>OK, yes technically it's not bridging :)<br>
<div><div><br>
>> and it even works quite good.<br>
>> But there is an issue (also mentioned in a parallel thread): when<br>
>> client interface cannot connect then AP interface doesn't come up<br>
>> also. Which may not be a problem unless you want to bridge ethernet<br>
>> there also.<br>
>> On the other hand you may not be able to switch the main AP into<br>
>> 4-address mode so relayd is a way out.<br>
><br>
> It may be a solution.<br>
><br>
> When I tried it a few months back (in Barrier Breaker),<br>
> relayd wasn't really working for me....<br>
><br>
> I know that's a terrible (non-)description; I don't specifically<br>
> remember what seemed to be going wrong, except that there was<br>
> a lot of traffic not reliably getting through to where it was supposed to,<br>
> and that it was confusing, and that I was able to slightly improve<br>
> the situation by fiddling with some of the options that the init-script<br>
> passed to relayd (IIRC, I had some success using "-I" on only one interface<br>
> and "-i" on the other), but I didn't have time to dig in and actually<br>
> understand what wasn't working--just switching to 4-address mode and having<br>
> OpenWrt set up a kernel-level bridge w/ brctl was a more expedient<br>
> path for me to get something working reliably at the time.<br>
><br>
> Actually, if anyone can offer guesses as to what my issues<br>
> with relayd might have actually been, I'd be glad to hear them :)<br>
><br>
> I'm not specifically aware of a reason why IPv4+ARP+DHCP relaying<br>
> should have been insufficient for what I was doing (I wasn't<br>
> running any weird non-IP protocols...).<br>
><br>
> Maybe someone can point me to a basic explanation of what<br>
> sort of "ARP cache and host route management" the "-I" option<br>
> is actually doing--and why I might need to disable it on one<br>
> of my interfaces?<br>
><br>
<br>
</div></div>I was using trunk around March-April this year and didn't have any<br>
problems. So I would suggest just trying newer version.<br>
<br>
<br>
Regards,<br>
Roman<br>
</blockquote></div><br></div>
</div></div></div></div></div><br></div>
</blockquote></div><br></div>