Global Moderators

@shoresup Glad you got that sorted, sometimes it just needs a second pair of eyes. We've all been there.

Iperf is testing the max performance through the device, but file transfer utilities have several overheads, so for example if I use sftp, we have several steps:

1. read data chunk
2. encrypt data
3. transmit data
4. wait for ack
   repeat

sftp (for example) packet size can impact on performance, depending on your network driver (either wifi/ethernet et al), you may get better performance by tweaking -B parameter on sftp.

A simple test I use if ftp, because it removes the overhead of encryption/encoding of sftp. Actually I often use zmodem or modem for my test, maybe because I'm old

@DocHardinger I think I have a clue. I managed to reliably reproduce the issue on a Lenovo P15s notebook running windoze 10. It will reliably disconnect if I run iw ra0 scan in a loop on OpenWrt 23. So I ran Wireshark to check for lost packets, acks etc, nothing notable to report. However I did notice the Wifi signal strength kept dropping and then the SSID disappears. If I set the saved network to autoconnect, it reconnects fine. But as the loop runs it disconnects again and then reconnects etc. I put my iPhone and Android 11 devices next to the P15s at the same so they are the same distance from the Omage2p and neither of them disconnect when the windoze device disconnects.

This Lenovo P15s can dual boot either windoze 10 or Ubuntu 24.10, so this time I booted into Ubuntu and ran the same test, it doesn't disconnect. So the problem is isolated to windoze.

I ran LinSSID on Ubuntu and it does not detect any notable drop in signal strength, so I rebooted in windoze and ran Acrylic WiFi Analyser, it shows a short-lived drop in signal strength when I'm running iw ra0 scan in a loop.

My working hypothesis is that windoze is aggressively monitoring connectivity and the faster the machine the more likely it is to disconnect, but slower devices like iphones, android phones and old Surface devices are simply not noticing the short lived signal drop.

OpenWrt 22 uses iw v5.16 OpenWrt 23 uses iw v5.19, so I wondered if the newer iw is doing something different. Looking at the code the changes are minimal, so I installed iw v5.16 on OpenWrt 23 but the issue persists.

Both 22 and 23 use the same mt76 firmware release, so I'm looking at the driver code for some hints.

@eng_Ahmed I think everyone needs to use the approach that best aligns with their current experience and expertise. My approach would be to build the package from source and then install it on the devices. I think it's a slower start than simply installing the packages but by building from source to start with, you already have a leg up on task 3, you also can evaluate what each configuration change you make in stage 2 actually does at source code level. So by the time you are ready for stage 3 you already have an understanding of the code.

@ElGoose39 Take a look at the 23.05 documentation that has a detailed explanation on how to create your own repository. You could then remove the old version of python and install your own version. This documentation is relevant to the earlier Onion firmware 18.06 as well.

@eng_Ahmed ipip (ip tunnelling) needs the kmod which needs to be build for the kernel you are using. But since you are using oonf-olsrd2 package it doesn't have that dependency.

@shoresup you can isolate the file system as a performance bottleneck by running a test using dd. I create one file name myread containing:

#!/bin/sh

dd if=/dev/zero of=myfile bs=8k count=10000
sync

and another named mywrite containing:

#!/bin/sh

dd of=/dev/zero if=myfile bs=8k count=10000
sync

Now run these commands to see their timings:

time -v sh myread
time -v sh mywrite

This will give you the file system timings for reading and writing 10000 blocks to and fro the file system

There are other tools but I like dd because it's a really basic test

@DocHardinger Can you set option disassoc_low_ack '0' on your AP and see if it makes any difference. I need it on my sta when connecting to one of Unifi APs.

@DocHardinger said in 23.05.3 iwinfo scan disconnects AP:

with old mt76 driver and it disconnects it cant be the driver, right?

Well. The Mediatek driver is broken up so that the various Mediatek hardware drivers use various shared code, and leverage the kernel and other kmods so that can also be a factor, but I built on the 6.6 kernel whereas the Onion build uses 5.15.

I have more things to test, this will also impact my own devices so I am keen to get to the bottom of the issue before it bites me in the ass.

Tonight I'll add some logging to the kmod and see if it gives some hints as to where to look next. My main issue is being able to reliably cause the dropout. My guess is it is lost packets perhaps due to power issues and or the windows driver's tolerance of these. The hardware and/or drivers on my Windows notebook may be more tolerant than yours, so I tried it on an old Mickey$oft Surface device, it never dropped out and that's a pretty crappy piece of hardware.

@DocHardinger That was OpenWrt 23.05 with the OpenWrt 22 MT76 driver code merged in. I tested on my Windows 11 machine, ran 6 or 7 scans and it never disconnected. May I suggest, if you have not already, power your Omega2 using a USB power adapter. Wifi scanning typically shows a spike in current, so I wonder if that's the issue.

@shoresup Have you used iperf to measure your actual performance? What rate are achieving?

If you are not in the US change your country option to match your actual country. I'm in Oz and if I leave my Omega2+ set to US, performance seems to fluctuate. The cause is the difference in wifi frequencies between the AP and the Omega2+, since hardware available here in Oz adheres to the Aussie regulations which are different to the US regulations.

If you run iperf and record the results then update your device to openwrt 23 Beta release available here you can easily do a performance comparison.