[OpenWrt-Devel] [LEDE-DEV] MT7620A WiFi issue - with a twist!

[Jamie Stuart]

Hello LEDE / OpenWRT devs,

I am requesting your help. First a little background…

I am co-founder of an education technology charity, onebillion ( https://onebillion.org/ <https://onebillion.org/> ). We build apps that enable children to learn to read and become basically numerate in their own language. We are working with partners in Malawi and other sub-saharan African countries to scale tablet-based learning initiatives to marginalised children through the Unlocking Talent Initiative ( https://unlockingtalent.org <https://unlockingtalent.org/> ). Working through government schools in Malawi, groups of 30 children at a time are learning through our apps using solar-powered tablets. There are 120 schools (and rising) across the country taking part in the initiative. As of today, 20,000 children are getting numeracy and reading lesson in their own language every week.


In each school, the children’s tablets are connected via wifi to a small server to store their progress. It has a 3G connection to allow remote monitoring and MDM commands to be sent to the children’s tablets. The server ( http://www.zbtlink.com/products/router/WE1026.html <http://www.zbtlink.com/products/router/WE1026.html> ) currently runs OpenWRT (DD, from source, with a number of packages including MySQL, nginx, php7, OpenVPN,).

However…

We have a persistent problem. The tablets frequently have trouble communicating with the server over WiFi. We have replicated this issue in our London office using 30 iPad Minis connected to a test server. After running for a while (and especially during periods of high network activity, which are sparse), these errors appear in the logs:

rt2800mmio_txstatus_is_spurious: Warning - 4 spurious TX_FIFO_STATUS interrupt(s)
rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2
rt2800mmio_txdone: Warning - Got TX status for an empty queue 2, dropping


After that, data transfer between client and server either slows to a crawl or stops entirely and the client decides to disassociate. This is not good for the children as we lose the ability to monitor their progress, and for them to log in.


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?

Jamie, onebillion







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170201/4f59eadb/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel