NetworkManager 0.6.6 for Fedora 7

I’ve build NM 0.6.6 for Fedora 7; I’d appreciate as much testing as possible! You’ll need both NetworkManager and libnl RPMs from Koji.

Or, if you wait until updates are pushed later tonight, you can:

yum update --enablerepo=updates-testing libnl NetworkManager

Let the bugs roll in.

Free, Fast and Hot

I’m not talking about anyone’s mom even though a few come to mind.  I’m talking about NetworkManager 0.6.6.  Almost a year after the previous release of 0.6.5, we bring you some awesome improvements:

  • A connection editor for Gnome
  • Support for WiFi killswitches
  • Better compatibility with various wireless and wired drivers
  • 802.1x wired authentication support
  • Better handling of VPN and WPA Enterprise security
  • Better handling of weird SSIDs
  • Populate the passphrase dialog with previous options
  • Translation updates and piles of bug fixes

Huge thanks again to Tambet Ingo who’s been the other invisible hand of NetworkManager World Domination over the past year. bugs fixed: 432401 354565 343679 354565 437396 420216 350061 499565 491047 334883 346833 466954 332953 464215 498887 511323 399292 435036 372154 449271 394264 449111 359541 332951

NetworkManager, your GSM mobile, and you…

Due to happy coincidence, the existing NetworkManager mobile broadband support isn’t just limited to mobile broadband cards.  You can most likely use your GSM mobile phone with NetworkManager (and the VPN too!) if you add the appropriate stuff to the HAL .fdi file.  Tag the serial port the phone exposes like so:

      <!-- Nokia N80 -->
      <match key="@info.parent:usb.vendor_id" int="0x0421">
        <match key="@info.parent:usb.product_id" int="0x0445">
          <match key="@info.parent:usb.interface.number" int="8">
            <append key="info.capabilities" type="strlist">modem</append>
            <append key="modem.command_sets" type="strlist">GSM-07.07</append>
            <append key="modem.command_sets" type="strlist">GSM-07.05</append>

and as long as you’ve got a data plan, it’ll probably Just Work.

NetworkManager 0.6.6 rc2

I’ve just rolled NetworkManager 0.6.6 rc2 (ie,  Grab hot, fresh, tasty tarballs tarballs tarballs.  Stuff you’ll like in 0.6.6:

  • A connection editor, available from the right-click menu of the GNOME applet
  • Handles weird SSIDs like “http://myhouse” nicely
  • Wired 802.1x support!
  • VPN connections terminate when you log out
  • Scanning is more responsive
  • Better handling of hidden SSIDs in conjunction with the ‘scan capability’ kernel patch
  • Many bug and leak fixes

Thanks go to many people, but more thanks go to Tambet Ingo than just about anybody else.  Barring major bugs, NetworkManager 0.6.6 will be released next week.

Now that 0.6.6 is almost wrapped up, we’ll keep rocking on 0.7, filling in the missing pieces and bringing seamless networking to the masses.

Hey VMware, SET_NETDEV_DEV wants a word with you

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.

Who’s your daddy? NetworkManager is…

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.

T-Mo got no spec-trum

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.