I have the source to the binary blob for mtk7620n/a I dont know if it
supports the previous chips and it has an alpha label.
On Thu, Sep 19, 2013 at 8:11 PM, jonsm...@gmail.com <jonsm...@gmail.com>wrote:
> Changing those bits just lets the kernel wifi code get into the driver
> in simultaneous AP/STA mode. Whether the driver actually works in that
> mode has never been tested. Who knows if that binary Ralink blob will
> work in this mode. We don't have the source so there is no way to fix
> it.
>
> On Thu, Sep 19, 2013 at 7:15 AM, Diego Lopez Recas <suelt...@gmail.com>
> wrote:
> > 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
> >
>
>
>
> --
> 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
