On 2019-03-21 3:57 a.m., Stefan Sperling wrote: > Thanks! Have you confirmed that you can still trigger it in -current > without my diff?
I have now tried -current without your diff and I can confirm that it *does not in fact trigger*. All commentary from here on will be in relation to unpatched -current > Does the speed settle eventually? Note that our 11n and 11g modes > use different Tx scaling algorithms. 11g in particular scales up > slowly and is sensitive to unrelated traffic on the same channel. > In 11n mode Tx speed jumps around a lot but should be equal or > higher than 11g on average. The speed does not settle, it remains erratic even with quite lengthy tcpbench testing. I run this exact same hardware as an AP under linux and have no issues, and I can confirm there is no rouge interference either from other APs, or anything else around me with almost total certainty. > Can you show me frames the AP is receiving when the problem occurs? > This will give you an AP-side packet capture which you could mail to > me (please compress it with gzip): > > tcpdump -n -i athn0 -y IEEE802_11_RADIO -s 4096 -w /tmp/athn.pcap > File attached in a separate email to you personally as athn_n.pcap.gz and athn_g.pcap.gz. Both experience ping and speed issues, but only 802.11n mode seems to have random problems with auth. > That might tell us why your client can't associate 50% of the time. > > Do you happen to have an iwn(4) device? If so I'd like to see a packet > capture in monitor mode. Ditto with iwn_g.gz and iwn_n.gz from a third, unassociated system in monitor mode. Sorry for the large file sizes, I wanted to capture a decent chunk of the behavior, especially the failures to associate. (the athn captures suffered some dropped packets due to not being able to write fast enough due to a shitty usb device, can redo tests with an alternate setup if necessary stuff wasn't captured) Thanks again for the effort, I know hardware problems are involve a lot of hair pulling.
