you invent a Tivo clone that automatically mutes acceptance speeches. That is all.
Which one is right for you?
There’s now an addition to the HAL specification identifying mobile broadband cards, and a hot new hal-info package (20080215) that contains the necessary .fdi file for most of the cards directly supported in Linux. This specification helps NetworkManager and other tools identify that (a) the card is really a modem instead an unconnected serial port, and (b) whether it’s a GSM or a CDMA modem. I also updated NetworkManager SVN to work with the new spec. Plug it in, watch it work, be happy.
VMware workstation 6.0.2 build-59824 is apparently the latest available for download. VMware has a ‘vmxnet’ driver that is installed when you install the VMware Tools inside your VM.
It does not:
- support HAL
- support carrier detection
To get HAL to recognize the network device, you need to have the ‘device’ link in sysfs point to the hardware device of your card, ie /sys/class/net/eth0/device -> /sys/devices/pci0000:00/0000:00:11.0/0000:02:00.0. This is accomplished simply by adding SET_NETDEV_DEV(<struct net_device *>, <struct device *>) to your driver. Almost all of the worthwhile in-kernel drivers do this already. vmxnet does not.
qemu’s ne2000 driver doesn’t support carrier detection either; but you can use a different qemu driver that emulates an rtl8139 card which does support carrier detection, and hence works nicely with NetworkManager. Both call SET_NETDEV_DEV().
I’ve submitted a VMware Support Request (#1104170215) for this issue, including a patch. We’ll see what happens.
[UPDATE]: I’ve been helpfully pointed to open-vm-tools by Philip. It has SET_NETDEV_DEV and carrier detection, but it doesn’t look like it easily supports mii-tool or ethtool with recent kernels (which use ethtool_ops). Carrier detection is pretty much useless if you can’t actually find out whether or not the driver supports it. So NetworkManager pokes the card with SIOCGMIIPHY + MII_BMSR or ETHTOOL_GLINK and if there aren’t any errors, assumes the card supports carrier detection.
I’ve got a patch for minimal ethtool support (at least for drvinfo and link reporting), but I have to (a) make a half-assed effort to make the patch compatible with kernels that don’t have ethtool_ops, and (b) sign and fax a copyright assignment to VMware before they’ll think about taking the patch.
Yeah, I’m talking to you happy, carefree, wireless-using, Nordic-looking prettygirl, with your Sprint Novatel S720 all up in our face.
I spent an hour or so hacking in CDMA card support on top of Tambet Ingo’s awesome 3G mobile broadband and PPP bits. And it just works. And like the GSM cards that Tambet’s got working, your VPN works over it too. Like magic. Tambet is the man.
What we do need to do, though, is standardize a method in HAL for tagging CDMA and GSM cards as “modems” (along with other things that are modems and accept AT commands). We also need to tag cards as CDMA or GSM. David Zeuthen had a few ideas on this, but I think in the end it’s going to have to be with .fdi files, because vendors just don’t follow the spec. There are separate USB protocol numbers allocated for CDMA and GSM devices, but no card I’ve been able to find uses them. And that won’t work for PCMCIA-based devices like the Sierra Wireless AirCard 860. When will hardware manufacturers learn? (hint: likely never).
The CDMA support won’t go into trunk until Tambet’s added yet more hotness, like signal strength detection and pulling out the currently connected network and showing that to the user. I’ve proved, though, that it’s trivial to add the CDMA bits when the GSM support is further along.
Rejoice, and be merry, for the wireless future is almost here.
No, this isn’t about porn, but when it’s done it’ll be even more awesome.
Tambet Ingo has been kicking mobile broadband ass recently, using it to club the NetworkManager PPP integration into shape. And that rocks. He’s been a driving force of NetworkManager for the last year, spearheading the D-Bus interface rewrite and the major refactoring for the upcoming 0.7 release. Buy him a whole keg next time you sit down at a bar and find out he’s just two seats down from you, looking all badass.
Now with 100% more NetworkManager
Interaction with 3G cards is going to work a lot like VPN connections currently do. The 3G card will show up in the applet’s menu. It will have a sub-menu of connections that you’ve created for the card. If you use more than one provider, you can create a connection for each provider and switch between the two. Eventually, you’ll be able to share that 3G connection over wifi or ethernet too. Obligatory mockup follows:
Deliciously easy 3G…
Right now the preliminary support is for GSM-based cards, most things that have the words GPRS, EDGE, UMTS, HSDPA, HSUPA, or HSPA on them. We’ll soon add support for CDMA-based 1xRTT, EVDO rev 0, and EVDO rev A cards too. It’s pretty rough at the moment, and he just committed it this morning, so don’t expect the thing to work just because you plugged it in (yet). After the PPP bits have been worked over Jack Bristo-style and are begging for mercy, we’ll start adding support for serial modem, ISDN, and Bluetooth DUN.
You ask, we provide.
Jon, T-Mo USA isn’t going to deploy HSPA in their 1900 MHz PCS spectrum because they are the most spectrum starved of all the national US carriers. They need their 1900 MHz blocks for regular voice calls. That’s why the spent $4 billion in the AWS auction last summer to buy up as much 1700MHz spectrum as they could. They are going to deploy HSPA in their 1700MHz spectrum. But first the government needs to move government agencies out of the 1700MHz spectrum, which is going slowly. So T-Mobile is between a rock (growing their subscriber base) and a hard place (government agencies that are slow to move out of the 1700MHz AWS band so that cellular companies can use the spectrum they bought).
Sprint has _GOBS_ of spectrum. They have 30MHz or more over the entire US in the 1900 MHz band, plus 10 or 20 MHz in the Nextel SMR bands around 800MHz. Sprint has so much spectrum, they rent it out to MVNOs like Helio and Virgin Mobile, then they fill their swimming pool with more, do laps in it, and use still more to light their cubans and have tankfarms left over. They have farkloads of 2.5 GHz spectrum in which they are already starting to deploy WiMAX. They were part of a consortium (SpectrumCo) that bought yet more spectrum in the 1700MHz AWS auction.
AT&T and Verizon have lots of spectrum because they either used to be or bought up companies that had licenses at 850MHz from the original cellular auction in the early 80s, plus they have spectrum in the PCS bands at 1900MHz. AT&T still operates the largest AMPS (ie, analog) cellular network in the country, but in 3 months they get to turn the lights out on that and move it over to GSM 850. Verizon and Cingular both bid on chunks of spectrum in the AWS auction at 1700MHz, but they don’t need it yet because they have so much Cellular and PCS spectrum available. That’s why AT&T can deploy HSPA in the 1900MHz and 850MHz bands, and why Verizon can deploy EVDO at 1900MHz.
T-Mobile has none of that. You won’t see HSPA on T-Mobile until 2008 at the earliest, and then only in large, important markets. They do apparently have UMTS running in Bellevue around their testing labs in the 1900MHz band though.
The US has 6 bands that are or will be used for cellular communications:
- 700MHz – the new band, to be auctioned in February next year. There “open access” rules tied to about 1/3rd of the spectrum to stop carrier locks on devices.
- 800MHz SMR – where Nextel operates; Nextel bought up taxi dispatch operators nationwide and converted them over to iDEN back when only 2 cellular licenses were available in each market.
- 850MHz – the original cellular band, initially AMPS but now being converted over to GSM and CDMA
- 1900MHz – the PCS band, digital from the start and where Sprint and Voicestream (now T-Mobile) entered the cellular industry. All the major players have spectrum here.
- 1700MHz – the AWS bands auctioned last year for broadband data like HSPA and EVDO
- 2500MHz – the “educational” band in which both Sprint and Clearwire have vast holdings and will deploy nationwide WiMAX networks over the next two years
This post brought to you by the letter G, the number 4, and a large furry dog that hides behind trees and doesn’t come out.
It will cure cancer. It can divide by zero. It can touch M.C. Hammer. And it’ll make your life better too. Why?
Drivers Suck Less
Drivers were (and still are) the largest reason for NM flakiness. But today, they are more consistent in their support of Linux Wireless Extensions, the standard ioctl-based method of talking to wireless drivers. NetworkManager directly caused the addition of WEXT-based WPA support to Madwifi, ndiswrapper, and linux-wlan-ng. And mac80211, the new kernel 802.11 wireless stack, will provide a consistency of driver operation unseen yet in Linux. That rocks, since we’ll have one place to fix the behavior instead of 6 or 7. It just keeps getting better, even though it’s taken a while to get here. I put together a list of driver problems waaay back in 2005. People cared. Drivers got fixed.
More Bars in More Places
The biggest reason why NM 0.6.x couldn’t support some device types or WPA authentication methods was that the configuration D-Bus API wasn’t flexible enough. The config framework has been completely rewritten. It’s more flexible, better engineered, and quite a bit easier to understand. We’ll support GSM/GPRS/EDGE/UMTS/HDSPA/HSUPA and 1xRTT/EVDO-r0/EVDO-rA broadband cards via better PPP integration, which also means dialup and possibly ISDN/PPPoE/PPPoATM support too. Bluetooth DUN and PAN will be possible now too.
You’re not in Soviet Russia
The network doesn’t control you. It’s the other way ’round. A major goal of 0.7 is widening the usefulness of NetworkManager. Through static IP support (including multiple IP addresses), you could use NM on your server or stationary desktop machine if you wish. You don’t need to use DHCP. You can override specific pieces of DHCP-provided configuration (like search domains). You can set up multiple connections for a device, with static IPs when you’re at work and DHCP when you’re at home. You’ll be able to have more than one device active at one time, and share an internet connection between them. For once you’ll be able to easily share that $9.99/hr hotel WiFi connection with your friends over ethernet, or an ethernet connection with your friends over WiFi.
Your Mom is NetworkManager’s Other Ride
With NetworkManager, she won’t have to care about how she connects to the Internet to check her email or sell her stuff on Ebay when she uses Linux. Wherever she happens to be tonight. Even though 0.7 will have awesome new capabilities that you and your mom will love longtime, it will still have the same easy simplicity of use you’ve come to expect from stuff that Just Works. We’re going to keep the GNOME applet simple up-front, and punt the really nasty configuration complexity to an out-of-band connection properties tool. So you won’t have to see configuration options that 95% of people don’t have to touch anyway.
On the Technical Side
There’s been a lot of code churn. Driving wpa_supplicant via D-Bus makes everything incredibly robust and allowed us to drop threads completely. Dropping the dep on dhcdbd makes DHCP work so much better (thanks to Robert Frank for the initial patch). Tambet Ingo showed the internal structure who was boss (hint: he was), and reworked the D-Bus API adding much-needed sanity and introspection support. The configuration D-Bus interface is based on dicts, allowing a lot of future flexibility.
Christmas in October?
Probably not; Fedora 8 has been the driving force for 0.7 so far, and we’ll get something quite usable in F8 even if it’s not feature-complete enough to call 0.7.0. The first focus is feature parity with 0.6.5, then multiple active device support, and then we’ll unleash 0.7.0 upon the world.
NetworkManager 0.7 uses wpa_supplicant (over D-Bus) for everything. Why you ask? Because it saves code. We’ve been ripping code out of 0.7 faster than hugsie & co. can add code to PackageKit. Somebody must preserve the galactic balance of code. When wpa_supplicant gets notified of new scan results by the wireless driver, it echoes that notification back out over D-Bus.
Drivers Behaving Badly (duh…)
Turns out that ipw2200 and ipw2100 make extensive use of background scanning. They send out scan result notifications many times per second. Which causes wpa_supplicant to wake up, process the scan results, and emit its own scan results available signal over D-Bus. Causing NetworkManager to wake up and ask wpa_supplicant for the parsed scan results. Causing nm-applet to wake up and process updates as they come in from NetworkManager. See a pattern?
48 Hours Later…
Three patches to wireless drivers to fix asstastic scanning behavior and make your life better, your battery not hate you, and NetworkManager rock harder:
- http://marc.info/?l=linux-wireless&m=119194675024816&w=2 (orinoco)
- http://marc.info/?l=linux-wireless&m=119195246702824&w=2 (ipw2200)
- http://marc.info/?l=linux-wireless&m=119203367309826&w=2 (ipw2100)
Not huge, but little fixes keep piling up until stuff Just Works.