Hi Jiapeng,
I think your problem is different. As I understand it, what you say is just
how the Luci web interface works. It doesn't let you scan with a single
wifi virtual interface in AP mode while it is enabled. It has nothing to do
with the driver.
Your patch doesn't change anything because the bit flag your are forcing to
be set was already being set a few lines below your modification, inside
the "if" construct.
What I say is also unrelated to the driver, it's just how services
wpa_supplicant (STA manager) and hostapd (AP manager) interact with each
other. Maybe, I should start a different email conversation...
Regards,
Diego
On Thu, Sep 19, 2013 at 5:26 AM, Jiapeng Li <gaplee...@gmail.com> wrote:
> Hi Diego,
> I am not familiar with the command you mentioned, i test this patch use
> the LuCI.
> Just as what you said in the mail, now the AP and STA mode can work
> together.
>
> But i found that when i open AP mode first, then the scan function is
> invalid.
> I must disable the WIFI first, then click the scan button, after do this,
> openwrt router can find the SSID of my Wireless router.
> And i can join it. Then i create a new AP device successfully. Now AP+STA
> works together,
> and i can access the internet through the openwrt routter.
>
> When i open AP mode first, then the STA function is disabled, i can't scan
> any more,
> i think we both come across the same problem.
>
> I try the patche below, add another BIT(NL80211_IFTYPE_AP) to the
> interface_modes,
> but this doesn't work.
> I modify another place in the rt2x00dev.c. May be it is stupid. But
> indeed change in this way does not work.
> *rt2x00dev->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_AP) |
> BIT(NL80211_IFTYPE_STATION);*
>
> --- a/drivers/net/wireless/rt2x00/rt2x00dev.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
> @@ -1263,7 +1263,7 @@ static inline void rt2x00lib_set_if_comb
> */
> if_limit = &rt2x00dev->if_limits_ap;
> if_limit->max = rt2x00dev->ops->max_ap_intf;
> - if_limit->types = BIT(NL80211_IFTYPE_AP);
> + if_limit->types = BIT(NL80211_IFTYPE_AP) | BIT(NL80211_IFTYPE_STATION);
> #ifdef CPTCFG_MAC80211_MESH
> if_limit->types |= BIT(NL80211_IFTYPE_MESH_POINT);
> #endif
> @@ -1381,7 +1381,7 @@ int rt2x00lib_probe_dev(struct rt2x00_de
> * which require beaconing, depend on the availability of
> * beacon entries.
> */
> - rt2x00dev->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
> + rt2x00dev->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_AP) |
> BIT(NL80211_IFTYPE_STATION);
> if (rt2x00dev->bcn->limit > 0)
> rt2x00dev->hw->wiphy->interface_modes |=
> BIT(NL80211_IFTYPE_ADHOC) |
>
> Thank you, jonsmirl. Your patch makes the AP+STA mode works, not perfect,
> but works.
>
>
> 2013/9/19 Diego Lopez Recas <suelt...@gmail.com>
>
>> Hi,
>>
>> I am also interested in this feature and I've tried your patch, jonsmirl.
>> It seems to work fine, thanks! I haven't tested it that much, but no
>> functional problems so far.
>>
>> I have another question. I've noticed that, in AP+STA mode, the AP is
>> switched off when the STA is not connected. I would like to prevent this
>> from happening and make it possible for the AP to stay up even if the STA
>> is not connected.
>>
>> I understand that the main limitation is that the PHY can only operate in
>> one channel at a time and the AP being up means you are stuck to the
>> current channel and cannot initiate a STA association in a different
>> channel. I guess the current implementation is based in the assumption that
>> this mode is most commonly used in a repeater configuration, where the STA
>> is the only link facing the Internet and it's ok to turn off the AP if it
>> is not providing Internet access. However, I think that keeping the AP up
>> makes sense in environments where lan local services exist (printers,
>> samba, DLNA services...).
>>
>> I have no in-depth knowledge of the code, only what I've been able to
>> deduce with some "greps", but I think that the AP could be switched off
>> only when the STA wants to associate, and switched back on in case the
>> association was unsuccessful. As I understand, the AP is turned off when
>> wpa_supplicant goes to states DISCONNECTED, ASSOCIATING or ASSOCIATING and
>> is only turned on again when wpa_supplicant reaches COMPLETED. As a first
>> approach, my idea is to also turn the AP on when wpa_supplicant goes to
>> state INACTIVE, so that some shell scripting can be coded to stop
>> wpa_supplicant from trying to associate after a given timeout and let it
>> try again after a while (if scan results show suitable candidates).
>>
>> This is what I have tried:
>>
>> --- a/wpa_supplicant/wpa_supplicant.c
>> +++ b/wpa_supplicant/wpa_supplicant.c
>> @@ -123,6 +123,19 @@
>> return 0;
>> }
>>
>> +static int hostapd_start(struct wpa_supplicant *wpa_s)
>> +{
>> + const char *cmd = "UPDATE ";
>> + char buf[256];
>> + int len = sizeof(buf);
>> +
>> + if (wpa_ctrl_request(wpa_s->hostapd, cmd, os_strlen(cmd), buf, &len,
>> NULL) < 0) {
>> + wpa_printf(MSG_ERROR, "\nFailed to start hostapd AP interfaces\n");
>> + return -1;
>> + }
>> + return 0;
>> +}
>> +
>> static int hostapd_reload(struct wpa_supplicant *wpa_s, struct wpa_bss
>> *bss)
>> {
>> char *cmd = NULL;
>> @@ -734,6 +747,13 @@
>> wpa_drv_set_supp_port(wpa_s, 0);
>> #endif /* IEEE8021X_EAPOL */
>> sme_sched_obss_scan(wpa_s, 0);
>> +#ifdef MULTICALL
>> + } else if (state == WPA_INACTIVE && wpa_s->hostapd) {
>> + if (wpa_s->current_bss)
>> + hostapd_reload(wpa_s, wpa_s->current_bss);
>> + else
>> + hostapd_start(wpa_s);
>> +#endif
>> }
>> wpa_s->wpa_state = state;
>>
>>
>>
>> Unfortunately, it does not work. I have one AP Router, the OpenWrt AP+STA
>> and one PC. OpenWrt STA connects to the AP Router and my PC's wifi connects
>> to OpenWrt AP. In the initial configuration, everything goes fine, wireless
>> connections work as I just said, but if I issue the following command in a
>> console in my OpenWrt:
>>
>> # wpa_cli -p /var/run/wpa_supplicant-wlan0-1 -i wlan0-1 disable_net 0
>>
>> OK
>>
>>
>> The OpenWrt AP is turned off, my PC's wifi is disconnected from OpenWrt
>> and cannot connect back anymore even though wpa_supplicant has gone to
>> INACTIVE:
>>
>> # wpa_cli -p /var/run/wpa_supplicant-wlan0-1 -i wlan0-1 status
>> wpa_state=INACTIVE
>> ip_address=X.X.X.X
>> address=xx:xx:xx:xx:xx:xx
>>
>> What am I missing? Can the behavior I propose be implemented?
>>
>> Regards,
>> Diego
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 9, 2013 at 2:18 AM, jonsm...@gmail.com <jonsm...@gmail.com>wrote:
>>
>>> On Sun, Sep 8, 2013 at 8:08 PM, Jiapeng Li <gaplee...@gmail.com> wrote:
>>> > Thanks jonsmirl,
>>> > I'll test it to see what happens, and give you a feed back.
>>>
>>> I believe you need to apply that patch in the 80211mac project because
>>> of the way git openwrt builds.
>>>
>>>
>>> >
>>> >
>>> > 2013/9/8 jonsm...@gmail.com <jonsm...@gmail.com>
>>> >
>>> >> You can try this and see what breaks.... but a lot of testing and
>>> >> verification will be needed to ensure that this is working correctly.
>>> >>
>>> >> --- a/drivers/net/wireless/rt2x00/rt2x00dev.c
>>> >> +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
>>> >> @@ -1264,7 +1264,7 @@ static inline void rt2x00lib_set_if_comb
>>> >> */
>>> >> if_limit = &rt2x00dev->if_limits_ap;
>>> >> if_limit->max = rt2x00dev->ops->max_ap_intf;
>>> >> - if_limit->types = BIT(NL80211_IFTYPE_AP);
>>> >> + if_limit->types = BIT(NL80211_IFTYPE_STATION) |
>>> >> BIT(NL80211_IFTYPE_AP);
>>> >> #ifdef CONFIG_MAC80211_MESH
>>> >> if_limit->types |= BIT(NL80211_IFTYPE_MESH_POINT);
>>> >> #endif
>>> >>
>>> >>
>>> >>
>>> >> On Sun, Sep 8, 2013 at 9:07 AM, Jiapeng Li <gaplee...@gmail.com>
>>> wrote:
>>> >> > Hi jonsmirl,
>>> >> >
>>> >> > Thank you, i am new to Openwrt, and not sure about this feature.
>>> >> >
>>> >> > What i know now is that RT5350 chip truly supports AP+STA mode, i
>>> test
>>> >> > the
>>> >> > MPR-A2, it can support this feature and works fine.
>>> >> >
>>> >> > If it is because of the WIFI driver, i think we can take an effort
>>> to
>>> >> > make
>>> >> > OpenWrt support this feature.
>>> >> > AP+STA mode is a very useful function.
>>> >> >
>>> >> > Can you give me some idea about how to enhance the WIFI driver to
>>> >> > support
>>> >> > this feature?
>>> >> >
>>> >> >
>>> >> > Regards.
>>> >> >
>>> >> > JiapengLi
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > 2013/9/7 jonsm...@gmail.com <jonsm...@gmail.com>
>>> >> >
>>> >> >> This is what an AtherOS chip says...
>>> >> >>
>>> >> >> > valid interface combinations:
>>> >> >> > * #{ managed, WDS, P2P-client } <= 2048, #{
>>> IBSS,
>>> >> >> > AP,
>>> >> >> > mesh point, P2P-GO } <= 8,
>>> >> >> > total <= 2048, #channels <= 1
>>> >> >> >
>>> >> >>
>>> >> >> On Sat, Sep 7, 2013 at 10:36 AM, jonsm...@gmail.com
>>> >> >> <jonsm...@gmail.com>
>>> >> >> wrote:
>>> >> >> > Use the iw command.. iw phy for rt5350..
>>> >> >> >
>>> >> >> > valid interface combinations:
>>> >> >> > * #{ AP, mesh point } <= 8,
>>> >> >> > total <= 8, #channels <= 1
>>> >> >> >
>>> >> >> > I suspect this is a software limitation that could be expanded
>>> with
>>> >> >> > some driver work.
>>> >> >> >
>>> >> >> > The AtherOS chips will do what you want.
>>> >> >> >
>>> >> >> >
>>> >> >> > On Sat, Sep 7, 2013 at 6:29 AM, Jiapeng Li <gaplee...@gmail.com>
>>> >> >> > wrote:
>>> >> >> >> hi bastian,
>>> >> >> >> Yes, each of AP and STA mode can work alone, but can't work
>>> >> >> >> together.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> 2013/9/7 Bastian Bittorf <bitt...@bluebottle.com>
>>> >> >> >>>
>>> >> >> >>> * Jiapeng Li <gaplee...@gmail.com> [07.09.2013 09:34]:
>>> >> >> >>> > and found that OpenWrt can't open wifi client and master mode
>>> >> >> >>> > simultaneously.
>>> >> >> >>>
>>> >> >> >>> have you tried to establish only one mode of each?
>>> >> >> >>> does AP work?
>>> >> >> >>> does STA work?
>>> >> >> >>>
>>> >> >> >>> IMHO for client (aka 'station'-mode) you need
>>> >> >> >>> to include wpa-supplicant...
>>> >> >> >>>
>>> >> >> >>> bye, bastian
>>> >> >> >>> _______________________________________________
>>> >> >> >>> openwrt-devel mailing list
>>> >> >> >>> openwrt-devel@lists.openwrt.org
>>> >> >> >>>
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> _______________________________________________
>>> >> >> >> openwrt-devel mailing list
>>> >> >> >> openwrt-devel@lists.openwrt.org
>>> >> >> >>
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> > Jon Smirl
>>> >> >> > jonsm...@gmail.com
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Jon Smirl
>>> >> >> jonsm...@gmail.com
>>> >> >> _______________________________________________
>>> >> >> openwrt-devel mailing list
>>> >> >> openwrt-devel@lists.openwrt.org
>>> >> >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > openwrt-devel mailing list
>>> >> > openwrt-devel@lists.openwrt.org
>>> >> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Jon Smirl
>>> >> jonsm...@gmail.com
>>> >> _______________________________________________
>>> >> openwrt-devel mailing list
>>> >> openwrt-devel@lists.openwrt.org
>>> >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > openwrt-devel mailing list
>>> > openwrt-devel@lists.openwrt.org
>>> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>> >
>>>
>>>
>>>
>>> --
>>> Jon Smirl
>>> jonsm...@gmail.com
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
>>
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
