Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#698 - Nexx WT3020F wifi packet loss problem #7998

Closed
openwrt-bot opened this issue Apr 10, 2017 · 9 comments
Closed

FS#698 - Nexx WT3020F wifi packet loss problem #7998

openwrt-bot opened this issue Apr 10, 2017 · 9 comments
Labels

Comments

@openwrt-bot
Copy link

ViBE:

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.

{{https://i.imgur.com/QPycaPQ.jpg}}

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?

@openwrt-bot
Copy link
Author

nbd:

Please try a current LEDE snapshot

@openwrt-bot
Copy link
Author

ViBE:

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.

@openwrt-bot
Copy link
Author

ViBE:

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

@openwrt-bot
Copy link
Author

ViBE:

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.

@openwrt-bot
Copy link
Author

por:

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.

@openwrt-bot
Copy link
Author

bjonglez:

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

@openwrt-bot
Copy link
Author

ViBE:

@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 [[https://bugs.lede-project.org/index.php?do=details&task_id=896|FS#896]] sounds familiar. I reported a very similar issue on [[https://www.gargoyle-router.com/phpbb/viewtopic.php?f=11&t=11123|Gargoyle forum]] a few days ago.

@openwrt-bot
Copy link
Author

ViBE:

Whats now...?

@openwrt-bot
Copy link
Author

por:

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant