Forum

> I found Tom Carpenters (CWNP -TV) video on USB 3.0 interference here:
> https://www.youtube.com/watch?v=MA979zIpTWg

Wish I had that spectrum analyzer! So if bringing a USB3 hub close to an antenna is that bad, what happens when both are built into something as tiny as a Surface Book? I have no idea where the antennas are, but they can't be more than a foot away from the ports. Would be interesting to see if the external ports are shared with internal devices on the same chip, or if they can turn them off when nothing is plugged in. I rarely use mine.

> I imagine that one of the biggest problems is due to poorly shielded USB connectors inside of either end-port.

There is barely room for the magnesium shell of my 'Book above and below the USB ports. Is magnesium any kind of shielding?

But all that USB exploration got pushed aside by the video YouTube put up after your first link:
<https://www.youtube.com/watch?v=vYbtiY3bnTM>
-----
In this webinar, Tom Carpenter shows you how to use NETSH, diagnostics, Microsoft Message Analyzer and more for native wireless analysis and troubleshooting.

netsh ras set tracing * enabled
netsh trace show providers
netsh trace show scenarios
netsh trace start capture=yes scenario=wlan report=yes tracefile=c:\traces\wlantrace1.etl
netsh trace stop
netsh ras set tracing * disabled
-----

I had vaguely heard there was a trace facility in Windows, but never heard enough hints there was anything worth exploring.

==> It is amazing! Why is nobody talking about the Microsoft Message Analyzer?

Tom's video showed exactly what to do and even provided copy/paste commands to do it. And clues how to begin looking at your capture.

Here's what happens during one of my slowdowns. The WIZnet serial-ethernet device is sending packets of one content byte each to the Surface Book...

Many packets from WizNet show:
Validation Warning Wi-Fi: The Reserved1 field in type APToClientWithQoSControlWithQAPPSBufferStateMacHeader is reserved and should be set to Zero, not 1 (0x01)

--> That seems to mostly correlate with the TCP "Push Function" flag, which the WinMsgAnalyzer displays exactly where Wireshark shows the Power Management flag in each packet list item... But the Push flag is totally different; the Power flag is buried in the MSMA detail dropdowns. Still, makes me wonder if someone is confusing the two! Windows clearly shows the Power flag not set alongside the Push flag that varies. Of course MSMA didn't grab the null function packet which Wireshark shows with the Power flag set...

The first slowdown:
---
36.870 seconds in timestamp

packet 341 warning source (I added the [[]]'s):
APToClientWithQoSControlWithQAPPSBufferStateMacHeader{FrameControl=FrameControl{Order=False,ProtectedFrame=True,MoreData=False,PwrMgt=False,Retry=False,MoreFrag=False,FromDS=True,ToDS=False,SubType=8,Type=2,ProtocolVersion=0},Duration=44,DA=B4-AE-2B-D1-66-5E,BSSID=F8-1A-67-CA-85-83,SA=00-08-DC-16-E2-A1,SequenceControl=SequenceControl{SequenceNumber=1918,FragmentNumber=0},[[[[[Reserved1=1]]]]],AckPolicy=0,EOSP=False,TID=0,QAPBufferedLoad=0,HighestPriorityBufferedAC=0,BufferedStateIndicated=False,Reserved2=0,HTControl=nothing}

But then, after packet 341 and an NBTNS-ICMP pair, the Reserved1 field is zero and the warnings stop

WIZnet keeps sending real data, without the warnings...

At 445, the Surface Book starts saying DUP ACK on 343 and asking for 341 again
WIZnet keeps sending more new real data, without the warnings...
At 497 the warnings return
499-513 say they are "retransmitted by 524" ???
515-523 are back to DUP ACK on 343 and asking for 341 again

524 transmits 175 bytes of content in one packet!
541 says it retransmits 524, but shows 237 bytes instead of 175, with content both before and after what was in 524 ???
557, 571, 587, 606, 620, 633 say they retransmit 524, but show ~5 more chars of payload each time, added to the end
647 is same except grown to 275 bytes, and no warning - still shows Push flag

650-658 is a Windows network scan
659 the warnings restart
670 the repeating "retransmit of 524" returns, now 280 bytes
752 last retransmit, 304 bytes
755 shows length 1, normal transmissions again

37.539 sec timestamp
670 mS is lost to this mess, every ten seconds!
---

So that's interesting, but it didn't capture the landmarks Wireshark does, no "null function", no RTS, no beacons, just the repeated retransmits of the same data (this is a totally different test):
---
Problem always begin with null function from Microsoft (same function from TP-Link is no problem) at 1 Mb/S:
44279 20:43:26.270868 0.005789 Microsof_d1:66:5e Tp-LinkT_ca:85:83 802.11 44 QoS Null function (No data), SN=3026, FN=0, Flags=...P...T
44280 20:43:26.271123 0.000255 Microsof_d1:66:5e (b4:ae:2b:d1:66:5e) (RA) 802.11 28 Acknowledgement, Flags=........

And the RTS storm begins - ten bursts of 12 RTS packets each:
44283 20:43:26.280813 0.000358 Tp-LinkT_ca:85:83 (f8:1a:67:ca:85:83) (TA) Microsof_d1:66:5e (b4:ae:2b:d1:66:5e) (RA) 802.11 34 Request-to-send, Flags=........
(with a few beacons and things...)

--> Between each burst of RTS packets, the two DS packets repeat, with always the same sequence number and data, at 13, or 11, or mostly 1 Mb/S:

--> Between each burst of RTS packets, the two DS packets repeat, with always the same sequence number and data, at 13, or 11, or mostly 1 Mb/S, second with Retry flag:
44296 20:43:26.290949 0.000598 88:42:75:00:b4:ae Microsof_d1:66:5e 802.11 468 QoS Data, SN=1656, FN=0, Flags=.p....F.
44297 20:43:26.291534 0.000585 88:4a:75:00:b4:ae Microsof_d1:66:5e 802.11 468 QoS Data, SN=1656, FN=0, Flags=.p..R.F.

--> Beacons during storm say "no data buffered", even though AP is trying to resend those two packets:
44385 20:43:26.389632 0.002386 Tp-LinkT_ca:85:83 Broadcast 802.11 280 Beacon frame, SN=1413, FN=0, Flags=........, BI=100, SSID=TP-LINK_2.4GHz_CA8583

Then five beacons over 0.25 second, three from active AP, two from its Guest SSID, all with "no data buffered".

And then another null function from Microsoft (delay from previous wake seems random, 200 - 500 mS):
44448 20:43:26.722968 0.029227 Microsof_d1:66:5e Tp-LinkT_ca:85:83 802.11 44 QoS Null function (No data), SN=3027, FN=0, Flags=.......T
==> With "PWR MGT: STA will stay up"
---

So I guess the next task is to see if the Microsoft Message Analyzer can display WLAN management packets. I'd think "capture=yes scenario=wlan" would have done that, but I guess not. Maybe one of these:
NDIS : Troubleshoot network adapter related issues
NetConnection : Troubleshoot issues with network connections

And then run both together under the same NTP time...

> Personally, I have seen more problems with Bluetooth or other wireless mice, but USB 3.0 can definitely create bigger problems.

My Bluetooth mouse (Apple Magic Mouse) seems to have no effect on the Wi-Fi, but something kills its connection regularly - sometimes ~hourly, sometimes less than a minute of operation.No relationship to any external influence I can see. Windows Wireshark apparently can't capture Bluetooth. I wonder if the Microsoft tool can?

Loren,

We're getting to the point of too many ideas in one forum topic.  It's getting hard to follow it all.

Glad to see you've found Toms' presentations.   He has some very good ones.   I liked that presentation too.

As far as the shielding ability of Magnesium goes, it all depends on exact alloy composition, and manufacturing steps, but by looking at "skin depth" at 2.4 GHz, it looks like magnesium is slightly better at shielding  than aluminum, and slightly worse at low frequencies (i.e.magnetic shielding).   I doubt the difference is significant once Apples engineers get done designing it.

I'm sure Apple uses the best USB 3.0 shielded connectors they can get.   Other than connectors on the end device, I'm sure the quality of the USB 3.0 shielding is the most important thing.   It's not just the metal in the shield, but the seams and gaps in it that matter at the high frequencies.

Note that USB has always had a bad reputation when it comes to grounding.   I gave up using USB-to-GPIB adaptor(s) on WLAN test sets at one time, and switched to Ethernet cables as soon as they were supported because of that problems.

There are also USB isolators ($25-$50) and (RFI) connector gaskets available to help with grounding and RFI.

Recently I found a $41 USB 3.0 adapter that all it does is remove the power lines from the connection, for audio gear.  OMG $41. 

Apple spends Enormous amounts of money on antenna design, and I'm sure a huge amount on shielding, not even including what's required for FCC certifications.  The RF test facilities they have are fantastic, both in size, sophistication, and cost.  Pictures of some of their anechoic chambers are unbelievable.

I haven't taken anything of Apples apart in a long time, but I remember looking at I-pads long ago, and being impressed how well they decoupled their antennas from the internal electronics - controlled cable routing, grounding planes, etc.   They were well beyond most other handheld designs by quite a margin.  That isn't to say they don't occasionally rush some products to market (some iphone models).

I have found the MetaGeek SA's to be great, partly because they are designed for use on 2.4 (and 5) GHz bands.   General purpose SA's don't have the logic inside them to look for Wi-Fi signals or noise.   They aren't perfect at discerning BT signals, but compared to say the $45k Anritsu test set I used, it's much less expensive.

One of the problems with most Wireshark setups, and the like, is that you only get to see what's going on in your immediate network, and many Control and Management frames don't get displayed.   You really need to be able to see them all - which is one reason I liked OmniPeek.

PS:  One byte at a time is really inefficient, and short packets can cause their own troubles with both transmission and reception from a radio's perspective.   Both directions have a ramp-up, and a ramp-down period they have to contend with.  Which is one reason IEEE 802.11 test specifications require LONG packet lengths.   Personally I prefer to use lengths representative of the equipment I am testing, but that is what the standards specify.

thank you for share local address information https://www.driversin.com

> We're getting to the point of too many ideas in one forum topic. It's getting hard to follow it all.

Tell me! Somehow I tend to get caught up in months-long projects.

> I'm sure Apple uses the best USB 3.0 shielded connectors they can get.

But my problem machine is a Microsoft Surface Book. Cosmetically it is Apple quality design. Functionally...

> Recently I found a $41 USB 3.0 adapter that all it does is remove the power lines from the connection, for audio gear. OMG $41.

Interesting! I made one of those, to solve ground offset problems. Mine can disable the 5V and ground lines separately.

> One of the problems with most Wireshark setups, and the like, is that you only get to see what's going on in your immediate network, and many Control and Management frames don't get displayed. You really need to be able to see them all - which is one reason I liked OmniPeek.

When I get it to work with a properly capable adapter, Wireshark shows all the beacons and probes and block ACKs, and the 4-way handshake... Maybe there is even more I've never heard of?

> PS: One byte at a time is really inefficient, and short packets can cause their own troubles with both transmission and reception from a radio's perspective. Both directions have a ramp-up, and a ramp-down period they have to contend with. Which is one reason IEEE 802.11 test specifications require LONG packet lengths. Personally I prefer to use lengths representative of the equipment I am testing, but that is what the standards specify.

That's what happens when you connect the cheapest Ethernet-serial adapter to a thirty-year-old microcomputer serial port. To get it to properly transmit single-character commands and parameters, you also force it to return one byte at a time. The normal response is less than 40 chars, so it isn't a big deal.

But dumping its log proves very handy for the testing I'm doing... Packets with one char show the ten-second periodicity just like 1565-char packets, and leave you with tiny capture files instead of hundreds of MB. Plus the content is unencrypted and in a readable timestamped sequence.

After a couple of days "dealing with reality", doing surgery on an ancient PV Panel and fixing my shower, I dug really hard for a way to make the Microsoft Message Analyzer show me the Probe Response packets I think are the heart of my slowdowns. I dug through their list of hundreds of "ETW Providers" and selected everything I could imagine might be related to WLANs. Turned a 16MB trace into a 91MB trace, but still didn't show the actual management frames. It did show some error messages I'd never seen...

It is receiving a continuous sequence of data packets at full speed, and then it says:
158366 None 2019-04-18T21:24:15.2706480 Microsoft_Windows_TCPIP TCPIP: NBL 0xFFFFCA095A2D5420 fell off the receive fast path, Reason: Ethernet and IP header not contiguous. Protocol = Unknown, Family = IPV4, Number of NBLs = 11. SourceAddress = 0.0.0.0 nothing. DestAddress = 0.0.0.0 nothing.

It then goes back and examines each of those 11 packets in detail, and declares "accepted 0x0000000000000001 bytes, status = STATUS_SUCCESS (0x0)"

But it does that even in the comparatively fast periods. What it does in the slow periods is add:

Microsoft_Windows_TCPIP TCP: connection 0xFFFFCA0962367CC0: TCP send event, SeqNo = 2230856734, BytesSent = 0, CWnd = 14600, SndWnd = 2048, SRtt = 20572, RttVar = 6454, RTO = 300, RcvWnd = 17395. 
158401 None 2019-04-18T21:24:15.2707377 Microsoft_Windows_TCPIP TCPIP: SendDatagram 0xFFFFF80339A68510 fell off the send fast path, Reason: WFP filters present. Protocol = TCP, Family = IPV4, Number of NBLs = 1. SourceAddress = 10.1.1.10 nothing. DestAddress = 10.1.1.3 nothing. 
158402 None 2019-04-18T21:24:15.2707530 Microsoft_Windows_TCPIP TCPIP: SendDatagram 0xFFFFF80339A68510 fell off the send fast path, Reason: Interface is not Ethernet. Protocol = TCP, Family = IPV4, Number of NBLs = 1. SourceAddress = 10.1.1.10 nothing. DestAddress = 10.1.1.3 nothing. 
158404 None 2019-04-18T21:24:15.2785468 Microsoft_Windows_TCPIP TCP: connection 0xFFFFCA0962306010 send posted 113 bytes at 3736894473.

But that only causes a small slowdown. The massive drops are due to this:

--> Last good packet:
22271 Validation 2019-04-16T20:17:25.2259634 0.3877672 10.1.1.3 10.1.1.10 ReassembledTCP TCP Virtual Reassembled Segment, SrcPort: 12350, DstPort: 10796, Len: 1, Seq Range: 283363651 - 283363652

22274 None 2019-04-16T20:17:25.2290175 Microsoft_Windows_WLAN_AutoConfig RpcCall Scan from client 3780
22275 None 2019-04-16T20:17:25.2290500 Microsoft_Windows_WLAN_AutoConfig Scan for networks. Interface = Marvell AVASTAR Wireless-AC Network Controller, scan type = 0x80000003, flush BSS list = True
22276 None 2019-04-16T20:17:25.2291499 Microsoft_Windows_WLAN_AutoConfig Begin Scan
22277 None 2019-04-16T20:17:25.4352655 10.1.1.10 github.map.fastly.net TCP Keep-Alive, Flags: ...A...., SrcPort: 10795, DstPort: HTTPS(443), Length: 1, Seq Range: 21400624 - 21400625, Ack: 1787626049, Win: 17408(scale factor: 8)
22278 Application 2019-04-16T20:17:25.5654486 0.0000011 10.1.1.3 10.1.1.10 ReassembledTCP TCP Virtual Reassembled Segment, SrcPort: 12350, DstPort: 10796, Len: 1, Seq Range: 283363656 - 283363657
==> "Diagnosis Warning" says Lost 283363652 to 283363656

22373 Application 2019-04-16T20:17:25.6152144 10.1.1.10 10.1.1.3 TCP Flags: ...A...., SrcPort: 10796, DstPort: 12350, Length: 0, Seq Range: 2644640608 - 2644640608, Ack: 283363652, Win: 4479488(scale factor: 8)
==> DUP ACK, first request for retrans 283363652

Those four or five lost packets occur at ten-second intervals, precisely when it does the Scan for networks. And the scan takes five seconds to declare completion - this is the end of the scan begun above:

26245 None 2019-04-16T20:17:30.0942333 Number of Unique Wlan Networks 3
26246 None 2019-04-16T20:17:30.0943993 No auto switch for the current connection (TP-LINK_2.4GHz_CA8583).
26247 None 2019-04-16T20:17:30.0945666 Scan completion Status 0
26248 None 2019-04-16T20:17:30.0945725 Number of Unique Wlan Networks 3
26259 None 2019-04-16T20:17:30.1009674 Number of Unique Wlan Networks 3
26265 None 2019-04-16T20:17:30.1034665 Number of Unique Wlan Networks 3
26266 None 2019-04-16T20:17:30.1034931 Number of Unique Wlan Networks 3
26267 None 2019-04-16T20:17:30.1040412 Number of Unique Wlan Networks 3
26276 None 2019-04-16T20:17:30.1102738 Number of Unique Wlan Networks 3

Usually it finds four networks, but that seems not to matter:
658 None 2019-04-15T15:21:37.4523713 0.0002422 3456 12708 Microsoft_Windows_WLAN_AutoConfig Number of Unique Wlan Networks 4

This totally supports the problem I spotted in Wireshark long ago. Every ten seconds, in the middle of receiving data, it sets the power flag to sleep:

70411 12:24:28.160609 0.001033 Microsof_d1:66:5e Tp-LinkT_ca:85:83 802.11 44 QoS Null function (No data), SN=499, FN=0, Flags=...P...T
then ACK,
then 82 RTS over 90 mS
Then:
70496 12:24:28.250699 0.000316 Tp-LinkT_ca:85:83 (f8:1a:67:ca:85:83) (RA) 802.11 28 Clear-to-send, Flags=........
70497 12:24:28.254139 0.003440 Tp-LinkT_ca:85:83 Microsof_d1:66:5e 802.11 417 Probe Response, SN=3555, FN=0, Flags=........, BI=100, SSID=TP-LINK_2.4GHz_CA8583[Malformed Packet]

Then four more of those responses, but Microsoft responds to those RTS with a quick CTS instead of stalling for 90 mS. And then a wildcard probe request:
70516 12:24:28.329018 0.028175 Microsof_d1:66:5e Broadcast 802.11 91 Probe Request, SN=3946, FN=0, Flags=........, SSID=Wildcard (Broadcast)

Which gets seven replies from the main AP and two from the "Guest" side, and then finally after 333 mS, we're back to real data (this is an old iperf capture):
70550 12:24:28.493410 0.039859 Microsof_d1:66:5e TexasIns_4d:71:eb 802.11 1571 QoS Data, SN=3147, FN=0, Flags=.p..R..T

And that packet is a retransmission of the one following this last one that made it to air before this whole disaster:
70401 12:24:28.157345 0.000266 Microsof_d1:66:5e TexasIns_4d:71:eb 802.11 1571 QoS Data, SN=3146, FN=0, Flags=.p.....T

Quite obviously Microsoft jumps to its "Scan for networks" function every ten seconds. Somehow that results in the power flag being set to sleep mode, and four or five packets being lost. The AP sometimes keeps trying to retransmit the lost packets in-between the RTS, and sometimes just keeps sending RTS without retransmitting. Microsoft ignores it all until it somehow decides to respond with CTS and no sleep flag, and that brings in the probe responses.

The "Scan for networks" specifically for the current network causes most of the problems, but Windows also does ten-second scans for the other APs it knows about, and for "wildcard", in a rigid pattern:

138584 2019-04-18T21:24:10.4
142517 2019-04-18T21:24:11.4
143756 2019-04-18T21:24:11.9
146236 2019-04-18T21:24:12.4
147590 2019-04-18T21:24:13.0
150091 2019-04-18T21:24:13.6
151431 2019-04-18T21:24:14.2

181048 2019-04-18T21:24:20.0
182454 2019-04-18T21:24:20.4
186069 2019-04-18T21:24:21.4
187406 2019-04-18T21:24:21.9
188803 2019-04-18T21:24:22.5
191104 2019-04-18T21:24:23.1
192532 2019-04-18T21:24:23.7
195007 2019-04-18T21:24:24.3

223820 2019-04-18T21:24:30.0
226448 2019-04-18T21:24:30.5
229362 2019-04-18T21:24:31.4
*231803 2019-04-18T21:24:31.9
233214 2019-04-18T21:24:32.5
234576 2019-04-18T21:24:33.1
237071 2019-04-18T21:24:33.7
238333 2019-04-18T21:24:34.3

268186 2019-04-18T21:24:40.0
269503 2019-04-18T21:24:40.5
273347 2019-04-18T21:24:41.5
274730 2019-04-18T21:24:41.9
277132 2019-04-18T21:24:42.5
278466 2019-04-18T21:24:43.1
279864 2019-04-18T21:24:43.7
282368 2019-04-18T21:24:44.3

I'm a bit overwhelmed at the moment. But clearly I need to figure out which "ETW Providers" record those "Scan for networks" events, and get them into the same capture as the data packets, and hopefully those "null packets" with the Power flag. And get simultaneous Wireshark captures of each end of the link and the off-air traffic between them.

I suppose I'll discover many side trips and surprises trying to do that. And I have no faith whatsoever that Microsoft would fix anything I found even if I could explain it in detail. And any day now it will be time to deal with the trees and grasses outside before fire season. I think this wireless issue may get pushed aside.

But I'd love to hear any clues anyone has about it!

A power-save indicator doesn't just signify that a client is going into power save mode - it's also an indicator/control mechanism.   It is often set prior to a device performing an "active scan" before roaming.   It seems likely, now in retrospect, that this is what is happening on your network. 

So what we need to try next is the following, to speed-up or eliminate any unnecessary roaming.   

On a Win-7 system for example, and depending on the exact options available on the client's Wi-Fi radio:

1.  Open the "Network and Sharing Center"

2.   Click Manage Wireless Networks

       At this point, there should only be ONE network name (SSID) that is listed as "automatically connect".   This is the #1 reason  clients roam slowly !   You don't want it trying to look for another network that might only be back in the city.

3.   Under "Adapter Settings":

           Select Either IPV4 OR IPV6  (not both)  - I prefer IPV4 as it has less connection overhead.

4.    Click Configure, then the Advanced tab, then Power Management.

           Disable  "Allow computer to turn off....".   You probably already have this selected.   

5.    Return to the Advanced Tab on the Configure page.

            Disable "Associated Power Save" (in addition to the step above !).

            Set "Preamble mode" to "Short and Long"- you want the client to be flexible.

            Set "Roaming Sensitivity" to Low or Medium.   You never want this set to High on a stationary device.   I leave mine on      Medium, just in case.   Setting it to "OFF" could cause it's own problems.

            Set "TX Power" to High.   Only affects battery powered (mobile) devices.

6.   Save all your changes.  You may have to power cycle the client to have the changes take effect.   (or disable, then re-enable        the radio).

Hopefully this will work.   Let me know what effect this does or doesn't have on your system.

Notes: 

Way back in the day, MS actually sold their own AP's.   They were Horrible.   I think they confused proper Client and AP behaviors.  I had one and it was always disconnecting it's clients.

It may seem obvious that a device should signal "power save mode" before it actively scans, but not all early devices did this, they just actively scanned anyway (they didn't passively scan as newer devices do).  The opposite is also true, some devices never actively scanned once the original connection was made.

> A power-save indicator doesn't just signify that a client is going into power save mode - it's also an indicator/control mechanism. It is often set prior to a device performing an "active scan" before roaming. It seems likely, now in retrospect, that this is what is happening on your network.

Apparently it does the scan every ten seconds, regardless of what is already in the air on its way to the Surface Book. It sets the P flag and instantly ignores several packets the AP believes it has already sent, and ignores the AP's efforts to resend them when it doesn't get any ACKs. And once the scan is over it receives dozens of packets before figuring out those previous ones are missing.

> So what we need to try next is the following, to speed-up or eliminate any unnecessary roaming.
> On a Win-7 system for example, and depending on the exact options available on the client's Wi-Fi radio:

Windows 10 has gradually eliminated almost all of those settings. I can use the tray popup to set only my favorite AP to connect automatically.

> Select Either IPV4 OR IPV6 (not both) - I prefer IPV4 as it has less connection overhead.

That I can do in Control Panel\Network and Internet\Network Connections -> Properties -> Networking -> "uses the following items". Makes no difference.

> Disable "Allow computer to turn off....".

Not in any power setting anywhere, even via "God Mode". Used to be...

Nothing relevant to any of your setting names in the registry.

Searching my drive for bits of items from that huge Device Manager list of Properties -> Details, I find:

C:\Windows\INF\oem124.inf 34 KB Setup Information 10/10/2018 8:55:37 PM 10/10/2018 8:55:37 PM 10/10/2018 8:55:37 PM

C:\Windows\INF\netvwifibus.inf 7 KB Setup Information 4/11/2018 4:33:47 PM 4/11/2018 4:33:47 PM 4/11/2018 4:33:47 PM
C:\Windows\System32\DriverStore\FileRepository\netvwifibus.inf_amd64_ccaeaa6a1e360e08\netvwifibus.inf 7 KB Setup Information 4/11/2018 4:33:47 PM 4/11/2018 4:33:47 PM 4/11/2018 4:33:47 PM
C:\Windows\WinSxS\amd64_dual_netvwifibus.inf_31bf3856ad364e35_10.0.17134.1_none_38f5fc1b3f907808\netvwifibus.inf 7 KB Setup Information 4/11/2018 4:33:47 PM 4/11/2018 4:33:47 PM 4/11/2018 4:33:47 PM

C:\Windows\INF\mrvlpcie8897.inf 61 KB Setup Information 4/11/2018 4:33:48 PM 4/11/2018 4:33:48 PM 4/11/2018 4:33:48 PM
C:\Windows\INF\mrvlpcie8897.PNF 21 KB Precompiled Setup Information 8/10/2018 5:01:53 PM 12/9/2015 6:33:09 PM 12/9/2015 6:33:09 PM

(And 25 more variations on these...)

The INF I finally found for the Marvell adapter lists:
AddReg = mrvlpcie.reg, mrvlpcie.pci.reg, mrvlpcie.common_ndis.reg, mv15x.params.reg, wlansvc.reg
but none of those files exist here.
Nothing for *mv15x*.* either.

So comparing those Marvell files to the TRENDnet files that were supposedly uninstalled but obviously were not...

> Disable "Associated Power Save" (in addition to the step above !).

No user-level control. Looks like the TRENDnet adapters had that setting, but Marvell has:

; PS Control
; bit0 – 1/0: disable/enable IEEE PS in NO_POWER_SAVE case
; bit1 – 1/0: disable/enable auto Deep Sleep in NO_POWER_SAVE case
; bit2 – 1/0: enable/disable IEEE PS in AUTO_POWER_SAVE case
; bit3 – 1/0: enable/disable auto Deep Sleep in AUTO_POWER_SAVE case
; 0xF: FW default value
; i.e. enable IEEE PS & auto Deep Sleep in AUTO_POWER_SAVE case,
; disable IEEE PS & auto Deep Sleep in AUTO_POWER_SAVE case.
;----------------------------------------------------------------------------
HKR,,PSControl,0x00010001, 0xD

> Set "Preamble mode" to "Short and Long"- you want the client to be flexible.

Likewise, TRENDnet had that:

C:\Windows\INF\,oem154.inf,42 KB,Setup Information,4/11/2019 4:19:55 PM,4/11/2019 4:19:55 PM,4/11/2019 4:19:55 PM,
13,791,"HKR, Ndi\params\shortPreamble, ParamDesc, 0, %shortPreamble%"
13,792,"HKR, Ndi\params\shortPreamble, Base, 0, ""10"""
13,793,"HKR, Ndi\params\shortPreamble, default, 0, ""1"""
13,794,"HKR, Ndi\params\shortPreamble, type, 0, ""enum"""
13,795,"HKR, Ndi\params\shortPreamble\enum, ""1"", 0, %shortPreambleEnable%"
13,796,"HKR, Ndi\params\shortPreamble\enum, ""0"", 0, %shortPreambleDisable%"
13,985,"shortPreamble = ""802.11b Preamble"""
13,986,"shortPreambleEnable = ""Long and Short"""
13,987,"shortPreambleDisable = ""Long only"""

The only "short/long" thing in Marvell is:

;Default Guard Interval
; 0: Long GI
; 1: Short GI
; 0xFF: Fw default value (Short GI)
;---------------------------------------------------------------------------- HKR,,SGI,0x00010001, 0xFF

> Set "Roaming Sensitivity" to Low or Medium. You never want this set to High on a stationary device. I leave mine on Medium, just in case. Setting it to "OFF" could cause it's own problems.

Again, TRENDnet:

FastRoamingSensitivityà‰
NDI\params\FastRoamingSensitivityÿÿÿÿ%FAST_ROAMING_SENSITIVITY_STR%|ñTypeÿÿÿÿOptional<ù
NDI\params\FastRoamingSensitivity\enumÿÿÿÿ
%DISABLE_STR%ÿÿÿÿ
%LOWEST_STR%ÿÿÿÿ
%MEDIUM_LOW_STR%\Å 3ÿÿÿÿ
%MEDIUM_STR%ÿÿÿÿ
%MEDIUM_HIGH_STR%Ìñ 5ÿÿÿÿ
%HIGHEST_STR%ÿÿÿÿ*

But closest thing for Marvell:

; Turn On Full Passive Scan
;----------------------------------------------------------------------------
HKR,, Roam_FullPassiveScan, 0x00010001, 0x1
[mv15x.services.reg]
HKR,,Versions,0,""

So apparently some of your settings are possible, but Windows doesn't let GUI users change them. Maybe I could edit those files and re-install? Sounds scary!

AHA! Found the settings - ~50 keys with names from the INF file, none of your names:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\mrvlpcie8897
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mrvlpcie8897
Maybe 2/3 of those keys:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\Setup\Upgrade\Pnp\CurrentControlSet\Services\mrvlpcie8897

Also:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\vwifibus
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vwifibus
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_11AB&DEV_2B38&SUBSYS_045E0004&REV_00\4&1a5036a5&0&00EB
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\System\mrvlpcie8897

So maybe if I knew how to translate their proprietary terms to yours, I could change some of the settings. But I don't have much hope it would help. It isn't doing any actual roaming, or probing beyond the active channel during my slowdowns. I don't see any scan period setting for the adapters, seem like that comes from somewhere in Windows.

Here's my Preamble and GI in old captures:

Radiotap Header v0, Length 18
...
Flags: 0x00
.... ...0 = CFP: False
.... ..0. = Preamble: Long
...
0... .... = Short GI: False <--- ???

MCS information
Known MCS information: 0x37, Bandwidth, MCS index, Guard interval, FEC type, STBC streams
.... ..00 = Bandwidth: 20 MHz (0)
.... .1.. = Guard interval: short (1) <--- ???
...0 .... = FEC type: BCC (0)
.01. .... = STBC streams: 1
MCS index: 7

802.11 radio information
PHY type: 802.11n (7)
MCS index: 7
Bandwidth: 20 MHz (0)
Short GI: True <--- ???
...
[Duration: 213µs]
[Expert Info (Warning/Assumption): No plcp type information was available, assuming non greenfield.]
[Expert Info (Warning/Assumption): No extension stream information was available, assuming no extension streams.]
[Preamble: 40µs] <--- But it said "long" above ???

But in a different capture:

802.11 radio information
PHY type: 802.11b (4)
Short preamble: False
...
[Duration: 272�s]
[Preamble: 192�s] <--- this long preamble is almost 5X the other one ???

Looks like Wireshark believes they are either-or. Or maybe it can only show the one currently negotiated? And it disagrees with itself on different levels...

Windows Diagnostics shows roaming events:

Roaming history: 3 item(s)
Times: 2019-03-28 13:36:10-100
Roamed from BSSID: f8-1a-67-ca-85-83
Reason: 0x00000007
Times: 2019-03-28 13:12:48-884
Roamed from BSSID: f8-1a-67-ca-85-83
Reason: 0x00010006
Times: 2019-03-28 01:37:11-137
Roamed from BSSID: f8-1a-67-ca-85-83
Reason: 0x00000007

At least that day it was only "roaming" on wake events... To the same AP... Nothing else relevant in that file.

I'm back to worrying about wildfire prep more than slow network connections...

Loren,

Obviously, fire-proofing/mitigation is more important than a slow, but working, network.  Here in SoCal very close to me, we were surrounded by smoke and fire a mile away for more than a week.   Very unnerving, especially after Santa Rosa and Paradise.

It's hard, if not impossible, to change parameters a manufacturer doesn't want you too change.   I'll look through the Registry keys you posted and see if I can "un-mask" them any better.  Sometimes registry keys look like a chip manufacturers source code, and other times not.

From one thing you said:

 It sets the P flag and instantly ignores several packets the AP believes it has already sent, and ignores the AP's efforts to resend them when it doesn't get any ACKs. 

It appears that the AP is not even "hearing" the packets with the power-save bit set.   This is normally an indication of insufficient RF power on the Client side, or  poor antenna performance (including poor connectors).   However, in your case it could be due to the SGI settings.  We need to positively change/verify them to be non-SGI.   The network "should" strictly follow the AP's settings.

How flat is your property?  Can you change the AP's antenna (only)  to one with say +3 dB more gain?   That could help both sides of the link(s).   And because your are relatively remote, it shouldn't cause you many problems.

Regarding:

> Disable "Allow computer to turn off....".

Not in any power setting anywhere, even via "God Mode". Used to be...

Does the computer "think" it running on battery or wall power ?  Several years ago, my laptop "lost" the ability to tell the difference, even though it's always plugged-in   It always says it is running on battery power, even when it's not.   In my case (WIN-7) it's not creating any performance issues that are noticeable, but I know for a fact that some platforms/chip-sets can do drastic things, from a radio's perspective, when they think they are running off a battery-including reducing RF output power.

Can you change the power-saving mode set on your computer overall ?  What is it set to now ?

I doubt you are, but don't confuse "preambles" with "guard interval". 

Short preambles are made to "sweeten" the performance of a network, but often long preambles can improve performance, usually by reducing the number of re-tries (at least in my experience).

Regarding:

 I don't see any scan period setting for the adapters, seem like that comes from somewhere in Windows.

Or more likely the firmware for the chip-set.  There are several parameters in effect here, and I have seen them set to extreme values, usually in an attempt to maintain the connection.  Sometimes this is only based on the "philosophical" beliefs of the programmers involved - I'm sure you've seen this phenomena yourself.   It's usually not too bad if the programmer defines this, but I've seen ignorant managers override their more knowledgeable staff.

One last thing, if I haven't mentioned it already.  You need to make sure the DHCP lease time, in your router, is not too short.   Two hours should work fine.

Good luck on your fire-season prep.  We'll talk more later.

             Howard