Slashdot Mirror
Microsoft Virtually Duplicates Your Wireless Card
akhomerun writes "Microsoft has released version 1.0 of its experimental new VirtualWiFi Software. The free software enables Windows users to use a single wireless card to connect to multiple wireless networks simultaneously. The current build is a very primitive release, with no support for WEP or WPA encryption."
This just doesn't look like typical Microsoft, and IMO that's a good thing...
Source code, a simple web site, and command line operation.....what more could I ask for?
Thanks, Microsoft (geez I still feel wierd saying that....)
I used to get high on life, but I developed a tolerance. Now I need something stronger.
They're probably too busy finishing their software to finish their website. Shame the same can't be said for a lot of open source projects.
They likely created the page in about two minutes. It looks like a page which was originally created for internal employee access, functional only with no intent towards glamour.
Except that the above creates an alias, using the same connection.
The above allows you to associate to more than one wireless network using just one wireless card. Try plugging your regular nic into two switches at once and see how it goes...
Plopping two WiFi devices (or more) between some type of routing app and I have _much_ faster bittorrent/LinuxISO/whatever downloads. This way I am working over two (or more) networks so not only do I have speed I have redundancy.
...or am I missing a spork in my lunchbox?
The fact that you can acquire it MUCH cheaper while connected to say 4 diffrent WLANs, with only one PCMCIA card, then you can say with 3 diffrent physical PCMCIA, makes it I would say pretty popluar. (I'm not sure about you but my laptop only came with two slots.)
i hate to double post but look here:
Multiple cards: The kernel implementation of VirtualWiFi supports multiple cards. However, we have not incorporated this support in the user level code of this release.
Meaning its going to be, if not already implemented in the Longhorn kernel. They're definatly aiming this at something, and since there's a user level implementation being created it means that whatever it is will probably be out before Vista has fully taken hold.
You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
At the moment, wireless AP's don't have to worry about frequent switching.
But if everyone and their brother started using these things, suddenly a given AP is going to have to deal with a huge amount of hookup requests.
Now admittedly I don't know much about the guts of an AP, and how limited their processing ability is (apart from bandwidth)... but this certainly isn't what they were designed for. I would be surprised if they could handle this kind of abuse from multiple users.
Or am I completely off base?
come on, this software isn't even anywhere near actual release. Give the guy a break. It doesn't come with a gui and the ability to check mail yet either.
Check out my sysadmin blog!
Great idea! That would allow you to switch access points while you're on the move; similar to ordinary cellular networks. The buffering would indeed create some latency, but if both connections are already established it should hardly be noticeble.
Yes, but if I remember correctly it is pretty complicated to actually handle parallel radio signals using 802.11b. More likely, it would come down to a form of time sharing with consequently higher latency. Guess they just choose the way of least resistance given that Wifi cards are a relatively cheap component in perspective of longhorn/vista's hardware requirements.
Anyway, being able to switch AP with low latency would considerably close the gap between wireless voip and gsm phones.
Considering that it's a first release of an experimental package that performs a function that few if any have ever done before, no, it's not the best idea to use it. Even the most basic encryption is not yet there.
Still, this shows that even Microsoft can pull some really neat things out of its R&D division. I shall look forward to a similar feature going into the MadWiFi driver set in the coming months, and thence into the Auditor Security Toolkit.
You can never go home again... but I guess you can shop there.
In cell networks, each handset retains a low-level session to at a minimum two cell towers. When the signal from one tower gets too low, it pops over to the other.
Good things about this technology:
- I see this technology being used to reduce handoff delays between networks, or even between access points. The neat thing is that it does it on the client side, not the infrastructure side.
- The thing that this is going to be best at is mitigating the problems streaming video or audio across a network, where delays of 50ms can kill your stream.
- Solutions like MobileIP where each AP becomes aware of a care-of address that the client was previously associated with help handoff, but require new firmware on the access point or router. This puts that intelligence on the client side. Increasing the queue depths on both sides couldn't hurt, however.
- Because 90-95% of the handoff time between access points is a rescan for new channels, keeping a session going between two different networks and being aware of the channels around you will actually reduce congestion and handoff time because there is no rescan and its consequent flood of PROBE frames which clog the channel with BROADCAST responses!
- Because the clients will retain knowledge of who's around them, the access point's BROADCAST frames can come less often than the present ~100ms, increasing the available bandwidth.
Not-so-good things about this tech:
- Not a lot.
- Subnet resolution might be a problem, no, wait, it wouldn't because they maintain a separate IP address for each virtual adapter. However, if those IP addresses are on the same subnet and someone pings the broadcast address of the subnet, the clients on the other network might respond as well... but I guess that would only happen if the virtual adapters were bridged.
That's usually the problem with things like MobileIP - some routers don't get the message and update their routing tables so packets get duplicated all over the place.
- Available IP address space problems. If everyone is opening two sessions...
- Doesn't support WEP, but who cares. Everything important should be encrypted at the application level anyway. Thing that concerns me is the lack of 802.1x support.
All in all, not a bad idea. I hope to see more out of these guys. I'm taking this down to the lab to run tcpdump and airopeek on it.
'Be always mindful, even when ditch-digging.' --D. T. Suzuki
I do. You're welcome to associate to it, hell, you can even sniff my traffic if you want. Anything of any real value is already going over SSH or SSL.
WEP/WPA is for tinfoil-hat wearers. If you wanted security, you would not be using wireless.