OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Critical
  • Priority Very Low
  • Reported Version lede-17.01
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by ViBE - 10.04.2017

FS#698 - Nexx WT3020F wifi packet loss problem

I have two this devices. I try to figure out which is the ideal firmware for it so I tested it with a few. I tested it with OpenWRT 15.05.1, LEDE 17.01.0 and Gargoyle 1.9.1/1.9.2. But I found a common issue. The device lose packets via wifi. Tested with several clients/devices. No matter what configuration I use. No problem on LAN but on wifi it lose a bunch of packets. Maybe it’s a driver issue? Would be good to figure out.


I also noticed that the latency is unstable on wifi. I guess it’s also a related with this issue. Should I open another ticket for it?

Project Manager
Felix Fietkau commented on 18.04.2017 07:34

Please try a current LEDE snapshot

ViBE commented on 03.05.2017 09:50

I would like to. Please tell me how configure it via terminal to let it connect to the net because it has no direct net connection and I'm still not familiar with OpenWRT/LEDE commands. It's connecting to an HGW which doing the dial-up.

ViBE commented on 17.06.2017 12:35

Meanwhile I updated to 17.01.2 r3435-65eec8bd5f. I set up the PPPoE. The new version is still affected!

ViBE commented on 16.07.2017 14:39

This is not going anywhere and I reported this more than three months ago. What should I do to get more attention? Reporting feels pretty nonsense.

Paul Oranje commented on 16.07.2017 14:53

Packet loss can be due to many causes. To make sure the packet loss is not the result of some personal circumstance it would help if you run the test with a ping to a station nearby (a few meters) and in clear sight of the WiFi access point.

When no packets are lost in that test, then the packets loss you reported is probably caused by either local interference, thick walls or a bad transmitter/antenna (either the AP or the STA). Only when all such local circumstances have been falsified one could start to think that the problem is generic and its cause be some error in the software.

Project Manager
Baptiste Jonglez commented on 16.07.2017 15:46

Probably a similar issue as FS#557 and  FS#896 

ViBE commented on 16.07.2017 17:03

@Paul Oranje I already tested. There are only a few routers operating nearby and using different channels. Also far away from my flat. So my area is not crowded. Walls cannot be a problem cause the devices are in the same room. The maximum distance was when I tested was 2 metres. So overall the distance and the interference are not players. I'm pretty sure that something wrong but not the testing environment.

@Baptiste Jonglez I'm not sure are these related but FS#896 sounds familiar. I reported a very similar issue on Gargoyle forum a few days ago.

ViBE commented on 04.08.2017 18:26

Whats now...?

Paul Oranje commented on 04.08.2017 20:41

In  FS#896  @psyborg55 referred to a patch that seemed to fix this with larger buffers, but in the end (sept 2015) that patch did not make it after @nbd commented:

512 frames seems to be overly excessive. Ever heard of bufferbloat?
It seems to me that the driver should simply call ieee80211_stop_queue
earlier to ensure that mac80211 does not attempt to fill the queues as
much. The driver queue length should probably be around 64 or less.

Did such a fix with a call of ieee80211_stop_queue() ever get implemented ?


Available keyboard shortcuts


Task Details

Task Editing