This site uses cookies for analytics, personalized content and ads. By continuing to browse this site, you agree to this use. Learn more
(VirtualWiFi is an old project, and we started working on it in 2002. We are not actively working on this project since 2006, and will not be supporting this software at Microsoft Research. Thanks for your interest. However, the software and code will still be available for you to play around with. Also, check out the supported VirtualWiFi OIDs in Windows 7.)
VirtualWiFi (previously known as MultiNet) is a virtualization architecture for wireless LAN (WLAN) cards. It abstracts a single WLAN card to appear as multiple virtual WLAN cards to the user. The user can then configure each virtual card to connect to a different wireless network. Therefore, VirtualWiFi allows a user to simultaneously connect his machine to multiple wireless networks using just one WLAN card. This new functionality introduced by VirtualWiFi enables many new applications, which were not possible earlier using a single WLAN card. For example,
We have explored several other applications of VirtualWiFi. The first application is called Client Conduit, which is a very useful tool for fault diagnosis and recovery in Wireless LANs. Client Conduit is a tool that provides a thin pipe of communication for disconnected clients to exchange diagnosis information with the back end servers. The thin pipe is achieved by running VirtualWiFi on the connected clients. These clients dynamically connect to disconnected clients over an ad hoc network, and send messages from them to the back end servers. VirtualWiFi enables this thin pipe without requiring the connected client to explicitly disconnect from the infrastructure network. A more detailed description of Client Conduit can be found in the paper titled: “Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks“.
The second application of VirtualWiFi that increases the capacity of wireless ad hoc networks using orthogonal channels is called Slotted Seeded Channel Hopping (SSCH). SSCH uses VirtualWiFi to virtualize a wireless card with as many instances as the number of orthogonal channels. It then connects each virtual wireless card on a different orthogonal channel. Furthermore, SSCH proposes a novel scheme of partial synchronization that can be used with VirtualWiFi. The details of the SSCH protocol are described in another paper, titled: “SSCH: Slotted Seeded Channel Hopping for Capacity Improvement in IEEE 802.11 Ad-Hoc Wireless Networks“.
The third application of VirtualWiFi is called WiFiProfiler, which enables clients to cooperatively diagnose the root cause of various wireless problems. Clients, including the ones that are disconnected from the WLAN, use VirtualWiFi to form an information plane, which is different from the data plane (the WLAN). All clients then exchange configuration information over this information plane and use this information to diagnose the root cause of various wireless failures. The details of this idea are described in a technical paper, titled: “WiFiProfiler: Cooperative Diagnosis in Wireless LANs“.
We have implemented VirtualWiFi on Windows XP. The current version is a prototype implementation of VirtualWiFi, and we are in the process of making our software more robust to include more features. Your comments are very welcome.
(VirtualWiFi is an old project, and we started working on it in 2002. We are not actively working on this project since 2006, and will not be supporting this software at Microsoft Research. Thanks for your interest. However, the software and code will still be available for you to play around with. Also, check out the supported VirtualWiFi OIDs in Windows 7.)
Download VirtualWiFi. This bundle contains:
VirtualWiFi software is also available as part of the Academic Resource Toolkit. In addition to VirtualWiFi, this toolkit has the Mesh Connectivity Layer (MCL) software. MCL was developed as part of the Mesh Networking Project in the Networking Group at Microsoft Research.
The current version of VirtualWiFi does not implement some features. Please keep checking this page for updates. The features not implemented in this release of VirtualWiFi are:
Following are the prerequisites for using VirtualWiFi:
To install VirtualWiFi, open the command prompt, go to the directory where you unzipped the VirtualWiFi binaries, and type:
Remember to press “Continue” if prompted for driver signing. If you face problems, refer to the VirtualWiFi installation FAQ.
To uninstall VirtualWiFi, open the command prompt, go to the directory where you unzipped the VirtualWiFi binaries, and type: “VirtualWiFi uninstall”Note that the wireless card over which you installed VirtualWiFi should be plugged in and enabled for uninstall to be successful. If you face problems, refer to the VirtualWiFi uninstallation FAQ.
A correct installation of VirtualWiFi should do the following:
A screen snapshot after installing VirtualWiFi shows the checked VirtualWiFi attribute for the Orinoco wireless card. It also shows the VirtualWiFi Virtual Miniport named “VirtualWiFi_IS_rover”, since the card was in IS mode, and the ssid was “rover”. (Note that for better viewing of this figure, you might want to watch it in its original size.)
The instructions on this page assume that you have correctly installed VirtualWiFi using the steps described in the VirtualWiFi install section.
If we were connected to an infrastructure network called rover, and wanted simultaneous connectivity to an ad hoc network with ssid VirtualWiFi, with non-adaptive switching, and a switch time of 500 ms for the infrastructure network, then our sequence of commands would be as follows:
In the screen snapshot after running the above commands, we see two new virtual adapters, with the following names: VirtualWiFi IS rover and VirtualWiFi AH MultiNet corresponding to the two networks. The task manager also shows the service, and the corresponding executable VirtualWiFiSvc.exe, which is created and started by the installer. The name of the service is VirtualWiFiService.
The following tests could be used to verify the correct operation of VirtualWiFi:
VirtualWiFi works over the latest drivers of these wireless cards:
VirtualWiFi worked over all the cards we tried. Let us know if VirtualWiFi does not work over any IEEE 802.11 card. To find out if your card supports VirtualWiFi, install VirtualWiFi and try the verification steps described in the VirtualWiFi Install section.
The following are required on the machine used for building VirtualWiFi:
At this point, copy the VirtualWiFi sources. Unzip the contents to a directory, and go to that directory in the Windows XP Checked or Free build environment in DDK.Run build -ceZ, and this should compile the entire VirtualWiFi tree. Copy the following files required for installing VirtualWiFi to one directory:
We have provided a file called “copyobjchkfiles.bat” that will copy all the sys, dll and exe files into a directory called “installfiles”.
The VirtualWiFi source tree comprises the following directories:
Q: Why do we need VirtualWiFi? Why not use one wireless card for each network?
A: Using multiple cards will cost you more money and what is worse is that your machine will consume more energy (battery power). Also, in most legacy laptops, it is cumbersome to fit multiple cards.
Q: Could you briefly describe the working of VirtualWiFi?
A: The VirtualWiFi virtualization architecture exposes multiple virtual adapters, one for each wireless network to which connectivity is desired. It then uses a network hopping scheme that switches the wireless card across the desired wireless networks. The goal is to make the switching transparent to the user, such that he feels connected on all the wireless networks.
Q: Briefly, how is VirtualWiFi implemented?
A: VirtualWiFi is implemented as an NDIS intermediate driver, and a user-level service in Windows XP. VirtualWiFi interacts with the card device driver at the lower end, and network protocols at the upper end. The buffering protocol is implemented in the kernel, while the switching logic is implemented as a user-level service.
Q: Why not use a different design of VirtualWiFi, where we queue packets, and switch to the network over which the packet in the head of the queue is to be sent?
A: Switching the wireless card to another network incurs a significant overhead. Incurring this overhead for every packet will significantly degrade the performance of VirtualWiFi.
Q: Why does VirtualWiFi have to switch across different networks? Can’t nodes receive packets from other networks, if it is promiscuous mode?
A: Different networks could be on physically different channels. In such a case, nodes might not receive packets from other networks, even in promiscuous mode. Furthermore, if a node is not associated on a network, it is in media disconnected state, and will be unable to send any packets on the network. Therefore, VirtualWiFi has to switch and associate to a network in order to send and receive packets on it.
Q: What all is implemented in the current version of VirtualWiFi software?
A: The current version of the VirtualWiFi software allows a user to connect a WLAN card to multiple wireless networks. It dynamically adapts to the switching delay incurred by a wireless card, independent of the manufacturer. It also does not require manual intervention for assigning IP addresses on individual networks. Furthermore, this version of VirtualWiFi also provides users with a command-line interface to dynamically add and remove connectivity to a network. The adaptive scheduling technique described in the paper is also implemented.
Q: What all is NOT implemented in the current version of VirtualWiFi software?
A: However, some features of VirtualWiFi have only been prototyped, and not included in this release. In particular, the idea of using PSM and remote node buffering is not implemented. Users will notice hooks in the driver code to provide remote node buffering, but our user-level service currently does not support it. Similarly, although the VirtualWiFi kernel module has support for multiple WLAN cards, the VirtualWiFi service does not support it yet. Finally, we have not yet included support for WEP and 802.1X in the current VirtualWiFi software release.
Q: Is VirtualWiFi specific to IEEE 802.11, or can it be used with other schemes such as HomeRF, Bluetooth, etc.?
A: We believe that the VirtualWiFi idea can be applied to any standard. However, we have only tested our system with IEEE 802.11 cards.
Q: Can VirtualWiFi connect to two networks, such that one is IEEE 802.11a and the other is 802.11b?
A: Yes, if the underlying wireless card supports it. However, switching an A,B wireless card across the modes incurs a higher switch time, and will adversely affect the performance of VirtualWiFi.
Q: What is the time taken by a card to switch to another wireless network?
A: This number varies across cards. It also varies across networks, and across ad hoc and infrastructure networks. In our experience, switching delays vary from 100 ms to 600 ms across commercial cards. Over special Native WiFi cards, this delay was a few tens of ms. Ideally, as has been pointed out by recent research in solid state circuits, and the values that have been used in our SSCH paper, this switching delay should be of the order of 100 micro seconds.
Q: I am having problems installing VirtualWiFi. An error report comes up when I run “VirtualWiFi install”. No virtual miniport as shown in the screen snapshot comes up in the Network Connections window. However, there is an unchecked VirtualWiFi attribute in the properties of my wireless card. How should I fix this problem?
OR
Q: The device name of my wireless card does not have any keywords mentioned in the prerequisites. How do I use VirtualWiFi?
A: Copy the VirtualWiFi source code to a local directory. Open notifyob\notify.cpp, and in the lines 758-771, add for any word in your Wireless adapter, and include it in the condition. Note that this word should not be in any other network adapter. Recompile, and install VirtualWiFi. Read the documentation for building the binaries from the VirtualWiFi sources, and compile the software. You are all set!
Q: I see an extra virtual adapter for my Ethernet adapter?
A: Verify that none of the adapters in the “Network Connections” window of XP have a keyword mentioned for wireless adapters. If so, remove it as described in the previous answer.
Q: The installation just exits without any messages, but VirtualWiFi is not installed. Why does this happen?
A: This could happen due to three reasons. Firstly, check to see that you have administrative privileges on your machine. Secondly, VirtualWiFi will not be installed if your card is currently not connected to any network. Connect your card to any desired network before installing VirtualWiFi. The third reason is as follows. We have noticed this sympton on some machines, which occurs when VirtualWiFi is being installed for the first time on the machine. In such a case, you should do the following to overcome the problem. Go to Start->Control Panel->Network Connections->Wireless Connection, then right click to go to Properties->Install->Protocol->Have Disk and go to the directory where you have unzipped the binaries. Press “Continue” when asked about driver signing. Once installed, uninstall VirtualWiFi by going to Properties of the Wireless Adapter, or using “VirtualWiFi uninstall”. After uninstalling VirtualWiFi, subsequent installations can be done automatically using the “VirtualWiFi.exe install” command described in the install section.
Q: During installation I get an error message saying “couldn’t create service. The service has been marked for deletion”. How do I get over it?
A: Do a “VirtualWiFi uninstall”. Then go the Task Manager, and kill VirtualWiFiSvc.exe. The install after this should work.
Q: Why does VirtualWiFi not work with my card?
A: VirtualWiFi will not work over cards whose drivers don’t forward packets that have a source address. This functionality is required since VirtualWiFi virtual miniports already have a MAC address. Another reason VirtualWiFi could fail is when the wireless card does not support packet filters NDIS_PACKET_TYPE_DIRECTED and NDIS_PACKET_TYPE_BROADCAST.
Q: The “VirtualWiFi install” command never completes. It gets to a point, and continues to wait.
A: This happens on non-English versions of XP. You will have to manually install VirtualWiFi as described in the answer to the next question.
Q: Is there a manual way of installing VirtualWiFi, not through VirtualWiFi.exe?
A: Yes. Stop Wireless Zero Config, and then go to Start->Control Panel->Network Connections->Wireless Connection, then right click to go to Properties->Install->Protocol->Have Disk and then point to the directory where you unzipped the VirtualWiFi Binaries. Click on “Continue” when warned about driver signing. This will install VirtualWiFi. Rename the added virtual miniport to “VirtualWiFi MM SSID” where MM is the mode, and SSID is the current network SSID. Then install the VirtualWiFi service using: “VirtualWiFiSvc.exe -install”. Finally, for VirtualWiFi to work correctly across reboots, add an entry for network name, i.e. “VirtualWiFi MM SSID” in C:\Windows\VirtualWiFiData.txt.
Q: Why am I unable to uninstall VirtualWiFi? The uninstall command seems to hang.
A: This will happen if the VirtualWiFi service is not running. To start the service, either run “net start VirtualWiFiService”, OR “VirtualWiFiSvc.exe -start”. If VirtualWiFi Service is not installed, you could install it using “VirtualWiFiSvc.exe -install”.
Q: Is there a manual way to uninstall VirtualWiFi?
A: Yes. Go to Start->Control Panel->Network Connections->Wireless Connection, right click and and go to Properties. Click on VirtualWiFi Miniport Driver, and click Uninstall. Note that the VirtualWiFi Service should be running at this time. Once the driver is uninstalled, you should remove the service, by executing “net stop VirtualWiFiService””, followed by “VirtualWiFiSvc.exe -remove”.
Q: I am unable to uninstall VirtualWiFi. Nothing seems to work. Is there a brute force method?
A: Yes. Go to the Windows registry using Start->Run->”regedit”. Note that you will be modifying the registry at your own risk. It is always better to save a copy of the registry before modifying it. From the registry, look for all entries having VirtualWiFi, and delete them. This is better done in safe mode. Also run “VirtualWiFiSvc.exe -remove” to remove the service. We have provided an easier way to delete these registry entries. Follow these steps: (i) Run “VirtualWiFi uninstall” (ii) Reboot your machine (iii) Run “RegDelete”. Note you will have to delete one entry manually, which is prompted by RegDelete. (iv) Reboot, and you are all set! However, please use RegDelete carefully. Check carefully the entries that RegDelete prompts! It should not belong to another program, and correspond to README.txt in the RegEdit directory under Sources.
Q: If VirtualWiFi automatically determines the switch time of a card, why is the switch time used in VirtualWiFi.exe changeparams important?
A: Think of this value as a timeout value for switching a card to another network. Even if VirtualWiFi is unable to associate to another network, it still buffers packets sent on that network. These packets will be freed, only when the switch timeout is exceeded. In most cases, the timeout value used by default works well, and need not be changed.
Q: What is a good number for the switch time to use in VirtualWiFi.exe changeparams?
A: This number varies across different cards, and across different implementations. For a Lucent card, you could use numbers around 400 ms to switch to an ad hoc network, and 500 ms to switch to an IS network. For Compaq WLAN cards, this number was worse, around 650 ms to switch to an IS network. Overall, our suggestion is to try a safe number.
Q: How do I find out the time my card takes to switch to a network?
A: We found this value using Airopeek, which is a wireless sniffer. However, you do not have to use this expensive tool. An easier way to measure this number is using the utility we provide with our distribution of VirtualWiFi, called VirtualWiFihelper.exe. The command VirtualWiFihelper.exe -op getCardSwitchTime gives the time taken by the card to switch to a network.
Q: Why does the card seem not to connect/stay on a network?
A: You should try increasing the switch time using “VirtualWiFi changeparams -switch “. Also make sure the wireless zero config is turned off, and you are able to connect to the network. A way to check for connectivity is by following these steps. Firstly, turn off the VirtualWiFi service, using “net stop VirtualWiFiService”. Then, turn on Wireless Zero Configuration, and try connecting to your network. Once you are done testing, turn off Zero Configuration, and turn on the VirtualWiFi service.
Q: Why do you ask me to stop wireless zero configuration service, and other wireless adapter utilities?
A: These utilities interact with the wireless card, and try to force connectivity to their preferred networks. This might interfere with the correct operation of VirtualWiFi.
Q: Why did my ad hoc network get a DHCP address, and not an autoconfig address?
A: In our current implementation of VirtualWiFi, all packets arriving at a wireless card are forwarded to the currently active virtual adapter. As soon as you start VirtualWiFi over an ad hoc network, the virtual adapter starts a DHCP request. In the non-VirtualWiFi scenario the card will get an autoconfig address after the DHCP request fails. If you started another network before the DHCP request timed out, it is possible for the card to receive a DHCP reply from another network and forward it to the incorrect virtual adapter. We suggest that the user wait for an ad hoc network to get a valid autoconfig address before it adds another network.
Q: Will VirtualWiFi work when I reboot, or unplug and replug my card?
A: Yes. It will automatically work after reboot. However, after an unplug and replug, you will have to manually restart the service using: “net stop VirtualWiFiService”, followed by “net start VirtualWiFiservice”.
Q: How does removing a network work across machine reboots?
A: On rebooting the machine, VirtualWiFi starts connecting to all networks, including the ones that were removed. You should explicitly add the networks you had removed, and remove them again to get back to a consistent state.
Q: My VirtualWiFi adapter always shows connectivity in the Network Connections window. Does it mean that my underlying card is able to successfully switch to that network?
A: No. VirtualWiFi stops MEDIA_DISCONNECT messages from going up (read paper for details). So, you will be unable to monitor the state of the network by looking at the Network Connections window. We recommend using “VirtualWiFihelper.exe -op getSSID” to check if VirtualWiFi is able to connect to a network.
Q: Is there a manual way, other than using VirtualWiFi.exe, to add a network?
A: Yes. First stop the VirtualWiFi Service by using “net stop VirtualWiFiService. Then connect your wireless card to the network you want to add, and do the following: Go to Start->Control Panel->Network Connections->Wireless Adapter, right click to go to Properties. Then high “VirtualWiFi Miniport Driver”, and go to its properties. Click on “Add a Miniport”, and press Continue if prompted for Driver Signing. Change the name of the newly added virtual miniport in the Network Connections window and make an entry in C:\Windows\VirtualWiFiData.txt. Then start the VirtualWiFi Service using “net start VirtualWiFiService”, and your network has been added.
Q: Is there a manual way, other than using VirtualWiFi.exe, to remove a network?
A: Yes. Stop the VirtualWiFi Service. Go to Start->Control Panel->Network Connections->VirtualWiFi adapter you want to remove. Right click, and press Disable. Then, start the VirtualWiFi Service. This will remove the miniport.
Q: Why does DDK complain about undeclared SDK_INCLUDE_PATH when building the VirtualWiFi sources?
A: You need to define it to the path of SDK include files. Remember to handle blank spaces correctly. So, if on my machine SDK was installed in C:\Program Files\Win-SDK, then SDK_INCLUDE_PATH would be defined as C:\Progra~1\Win-SDK\include.
Q: How do I debug VirtualWiFi? Have you provided any hooks in the software?
A: The best way to debug VirtualWiFi is to use a Windows kernel debugger, such as Windbg. The code has DBGPRINT statements, with different verbosity level of debug messages to be printed. To debug the install/uninstall/addnetwork/removenetwork commands, you could use “VirtualWiFi.exe -v” instead of VirtualWiFi, for more debug output.
Q: Why is copyobjchkfiles.bat unable to copy files to the installfiles directory?
A: Depending on your settings, your obj directories in DDK might have a different name, for example objchk_wxp_x86, or something similar. Change objchk in copyobjchkfiles.bat to the directory in your setting. Copying will also not work if there is no directory called “installfiles”. You should create this directory first. Finally, files with similar names in “installfiles” should not have read-only permissions. This will also cause the copy to fail.
Q: Why am I unable to replace vwifi.dll after recompiling it?
A: Uninstall VirtualWiFi, if installed. You might have to wait for a few minutes. Close the Network connections Window and retry. You should be successful.
Ranveer ChandraPhD Thesis, Cornell University, September 2005.
Ranveer Chandra, Paramvir Bahl and Pradeep BahlProceedings of IEEE Infocom 2004, Hong Kong, March 7-11, 2004.Infocom Presentation
Ranveer Chandra, Paramvir Bahl and Pradeep BahlDemo and Poster in ACM/USENIX MobiSys, San Francisco, May 5-8, 2003Poster in Mesh Networking Summit, Snoqualmie, WA, June 23-24, 2004
Paramvir Bahl, Pradeep Bahl and Ranveer ChandraMicrosoft Tech Report, MSR-TR-2003-46, June 2003
Atul Adya, Paramvir Bahl, Ranveer Chandra and Lili QiuProceedings of ACM Mobicom, Philadelphia, September 26-30, 2004.
Paramvir Bahl, Ranveer Chandra and John DunaganPoster in Mesh Networking Summit, Snoqualmie, WA, June 23-24, 2004
Paramvir Bahl, Ranveer Chandra and John DunaganProceedings of ACM Mobicom, Philadelphia, September 26-30, 2004.Mobicom Presentation
Ranveer Chandra, Venkata N. Padmanabhan and Ming ZhangProceedings of ACM/USENIX MobiSys, Uppsala, Sweden, June 19-22, 2006.MobiSys Presentation
Paramvir Bahl, Ranveer Chandra, Patrick P. C. Lee, Vishal Misra, Jitendra Padhye, Dan Rubenstein and Yan YuProceedings of ACM CoNEXT, Madrid, Spain, December 9-12, 2008.
This work has been done in collaboration with:
We have also worked with researchers at Microsoft Research on different applications of VirtualWiFi. In particular, we have worked with Atul Adya on Client Conduit, John Dunagan on SSCH, and Venkat Padmanabhan and Ming Zhang on WiFiProfiler.
VirtualWiFi received some press coverage in late October, 2005. Some of the articles are linked below:
Principal Researcher
Distinguished Scientist Director, Mobile & Networking Research
