[OpenWrt-Devel] [LEDE-DEV] MT7620A WiFi issue - with a twist!
daniel at makrotopia.org
Sat Feb 4 13:11:53 EST 2017
On Fri, Feb 03, 2017 at 07:49:22PM -0500, Weedy wrote:
> On 1 February 2017 at 15:29, Jamie Stuart <jamie at onebillion.org> wrote:
> > Hello LEDE / OpenWRT devs,
> > I am requesting your help. First a little background…
> > This a known issue with the chipset and seems to have been round for years.
> > We are currently building on LEDE trunk and still the issue persists.
> > We are not driver developers, so my question is whether anyone with
> > knowledge can help and provide a proper fix for this issue?
> You will probably have the most luck posting a bounty on the linux
> wifi mailing list.
As a response to the many issues and obvious code quality problems in
the patch adding support for MT7620 to rt2x00 I started a kickstarter
project to fund an afternoon or two (depending on the amount people
throw into my hat) of focussing on rt2x00 running on MT7620:
> Your root problem is picking a platform that basically uses a client
> mode tested driver in AP mode and then hanging a million clients off
> of it. I'm honestly surprised it didn't fall over sooner.
Well, rt2x00 is used for both AP and Client mode, and afaik there
wasn't a lot of testing for either mode of operation. And AP mode has
recently seen quite a bunch of improvements.
Having seperate drivers for AP and STA is a common strategy of chip
makers to devide-and-conquer QA and also add product differentiation,
ie. sell the same hardware for more if it is used for specific tasks.
Thus Ralink used to give away the station-mode driver for free and used
to charge people for the AP-mode driver (they do share a common
codebase). The bigger issue here is that Ralink's WiFi chip design is
flawed when using the chips in multi-STA modes (AP, Adhoc, Mesh)
because instead of having a way to set parameters for each associated
station it only allows it to be set globally, see  for an example of
how rt2x00 thus needs to limit the hardware to use the parameters of
the weakest associated station (the vendor driver does the same).
> May I suggest when it comes time to refresh the hardware you guys pick
> something with NGFF or mini-pcie slots for ALL radios.
Though I personally don't believe it's ever going to get as chaotic
and complex as for the final generation of Ralink's WiFi chips (ie.
which later became MT76x0). Ralink/Mediatek's newer chips are much
cleaner and don't share the same issues.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel