Ad hoc networking problem under Vista
We have a real-time application that uses an ad hoc connection to stream data. It works fine under XP. Using Vista we find that every 60 seconds we get a brief, up to 2.3 second, interruption in the TCP data stream. This has been shown on more than one system and with more than one wireless adapter from different companies.
We used a network analyzer to ascertain what was happening. It turns out that the problem is caused by an 802.11 probe request. Immediately after the probe(s) we get a block of TCP retransmissions until the connection recovers.
We feel that the problem is with the default Vista interface configuration since the problem is vendor independent and does not happen on XP.
We want to determine if using Native WiFI can correct this problem. For example, does the wlan_intf_opcode_background_scan_enabled flag have any relation to this problem? Is there better documentation available for these parameters? The MSDN library does not have adequate information. Any help would be appreciated.
Tom
[1049 byte] By [
tskinner] at [2008-2-22]
It is likely that the background scan caused the interruption in the TCP data stream.
By default, the wireless service performs a background scan every minute to get the updated wireless network information. You can disable background scan by calling WlanSetInterface and setting wlan_intf_opcode_background_scan_enabled to FALSE.
You need to open a handle by calling WlanOpenHandle() and keep the handle open until you want to re-enable the scan.
You cannot disable background scan if the wireless adapter is not connected and the scan is automatically enabled once the network is disconnected.
Regards,
Yi
Thanks for this information. I did try disabling the background scan by modifying the sample program to add the call. However, I may have made the call before the call to establish the connection, I ran this from the command line and therefore the handle was closed, but the connection remained. This was a modified "conn" command in the sample.
I will run further tests to make sure the connection is established first and that I keep the handle open.
I should also note that this problem does not occur for an infrastructure network and we can't demonstrate it with a connection sending data continuously. We send data in small packets every 10 milliseconds,
Thanks,
Tom
I modified the sample code's conn command as follows:
//In "conn" command
dwError = WlanConnect(
hClient,
&guidIntf,
&wlanConnPara,
NULL // reserved
);
//Added
BOOL flag = FALSE;
dwError = WlanSetInterface(hClient, &guidIntf, wlan_intf_opcode_background_scan_enabled, sizeof(BOOL), &flag, NULL);
int xxx;
cin >> xxx; //to freeze after connection to hold handle open
//End adds
After successfully connecting from the command line I ran the application and I still saw interruptions in data flow every 60 seconds. The code above does not appear to work or there is some other problem that repeats every 60 seconds like clockwork.
I wrote a simple test application (.NET) to eliminate anything in our application and this test shows the same behaviour. We only see this anomaly when sending data with some delay betrween packets, e.g., 10 ms. Sending data continuously does not seem to stall at all.
Tom
Do you have Vista on both stations (the sender and receiver)?
If so, you need to disable background scan on both stations.
As far as I know, some drivers have certain logic to ignore background scan if there is data traffic. This may explain why you don't see the issue with continuous data.
Yi
We originally found the issue with a device that uses Windows CE. We then demonstrated the problem with a simulation running on Windows XP. Our final testing was with a program written for this test running on a WIndows XP syatem and on a Vista system. The Vista system receives data sent from the XP system so there should be no issue of disabling background scan on both..
Is the background scan feature used with infrastructure networks? If so then this isn't the problem as we do not experience the problem on such networks. Is there a way to verify that backgrouind scans are really disabled? For example, the absence of any 802.11 probe requests from the adapter on the Vista mnachine?
I would be glad to provide our test program so you can try to duplicate the issue.We have demonstrated the issue with three different adapters, one of which is running with an XP driver.
Tom
You can use WlanQueryInterface to check whether background scan is disabled in OS. There is no way to verify whether the driver is conducting passive scan itself, because it will not send out probe requests as it does for active scan.
Could you try your test on two Vista machines? Please disable background scan on both machines and see whether the problem goes away.
Background scan is applicable to both infrastructure and ad hoc networks. I think the reason that you didn't experience this problem on infrastructure networks is that infrastructure networks support power save. Before the driver leaves the current channel to scan for networks, it tells the AP that it will go into low power mode so that the AP will cache packets for this station. You can verify this by looking for null data packets with power save bit set sent out by the station.
Thanks,
Yi
Sorry for not replying sooner. I have discovered that the call to disable background scan is not working. I was not checking the error return previously. I now find that the error is a code 5023 which does NOT match any of the error codes in the documentation for this call. I checked for all of them. Clearly there is something wrong here and we need help very badly on this.
The call is:
BOOL flag = FALSE;
dwError = WlanSetInterface(hClient, &guidIntf, wlan_intf_opcode_background_scan_enabled, sizeof(BOOL), &flag, NULL);
If I do a query interface right after this I get TRUE returnred for background scan and no error on that call. That would verify that hClient and guidIntf paramteres to the previous call are valid. I can't see anything else in the set interface call that look incorrect. Can you verify that this call actually works?
Any help would be greatly appreciated as we would like to be able to ship our product to run on Vista, otherwise we will have to stipulate XP only until we get a fix.
Tom
Please ignore my last post. The problem was that the connection was not established and that is why the call was failing. It is now working and the query shows FALSE for the background scan. However, the problem we are having has not gone away.
We have purchased a couple of newer USB wireless adapters with Vista drivers. When they arrive we will test them. We have tested with a D-Link adapter with very recent Vista driver, an Intel adapter and an older Linksys adaper.
If I understand correctly it is possible that the driver may be ignoring the request to disable the background scan. Is there any other Vista related behaviour that can be causing this? Could this be something in the ACM?
Is their someone at MSFT willing to run our test program that demonstrates this issue? It would be greatly appreciated.
Tom
