On Wed, 2020-01-29 at 12:01 -0800, Ben Greear wrote: > On 1/29/20 11:48 AM, Marlon Smith wrote: > > > > On Wed, 2020-01-29 at 11:27 -0800, Ben Greear wrote: > > > > > > On 1/29/20 11:22 AM, Marlon Smith wrote: > > > > > > > > > > > > On Wed, 2020-01-29 at 10:42 -0800, Ben Greear wrote: > > > > > > > > > > > > > > > On 1/29/20 10:39 AM, Marlon Smith wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > I have two RT5370 devices connected to the same access > > > > > > point. > > > > > > Both > > > > > > devices are very slow, but the instant I disconnect one > > > > > > device, > > > > > > the > > > > > > other speeds up by a factor of 10. > > > > > Out of curiosity, are both of the RT5370 used on the same > > > > > client > > > > > device? > > > > > > > > > > > > > > > > > > Did you check that they have unique MAC addresses? > > > > > > Thanks, > > > > > Ben > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The really strange part is that one device will perform > > > > > > slowly > > > > > > even > > > > > > if > > > > > > the other device is basically idle! I've confirmed this > > > > > > with a > > > > > > packet > > > > > > sniffer. > > > > > > > > > > > > I've been trying to do some debugging, and I've found that > > > > > > when > > > > > > both > > > > > > devices are connected to the access point, they report a > > > > > > large > > > > > > number > > > > > > of duplicate frames. I added some debug output > > > > > > in ieee80211_rx_h_check_dup() to confirm that this only > > > > > > happens > > > > > > while > > > > > > both devices are connected. The packet sniffer also shows a > > > > > > large > > > > > > number of retries while this is occurring. > > > > > > > > > > > > Using backports 5.3-rc4 for this, but also tested on 4.14- > > > > > > rc2. > > > > > > > > > > > > I did post about this previously on this mailing list > > > > > > (RT5370 > > > > > > performance issues), but I thought I'd post again with this > > > > > > new > > > > > > information and more descriptive title. I'm a little bit > > > > > > stuck > > > > > > on > > > > > > this > > > > > > for a while now, so any ideas are much appreciated. > > > > > > > > > > > > Thanks! > > > > > > > > > > > > Marlon > > > > > > > > > > They are on separate devices, although the mac addresses are > > > > close. > > > > 70:F1:1C:2E:AF:B4 and > > > > 70:F1:1C:2E:AF:B6. > > > > > > > > However, I have a third device 70:F1:1C:2E:AF:BB which performs > > > > well > > > > and does not affect the performance of the other two. > > > > > > > Have you tried a different AP? > > > > > > And also tried using the exact same MAC addresses configured on a > > > different > > > radio (like ath9k)? > > > > > > Thanks, > > > Ben > > > > > > > > I have tried a different access point in a different environment > > but no > > luck. I'll see if I can configure my laptop to use one of the > > problematic devices' mac address. > It might be tricky to determine, but if you can notice whether one of > your station devices > is (block-)acking the other's frames, that would be a good clue that > it is a station > side bug. A carefully inspected sniff, especially if you can put > sniffer near one station > and far from the other and so use RSSI as a sorting factor, should > allow you to determine > this. > > Thanks, > Ben > > I'll double check this, but I believe there is very little traffic from the second station while the first station is (slowly) transferring data. I think that means it's not likely that one device is acking the other's frames? I will test this though, and the mac address spoofing, and get back to you tomorrow. Really appreciate the help so far, thank you!
