Dan Williams’ blog

Or, how NetworkManager 0.7 transcends decadence and totally respects your distro’s persistent network configuration if you want it to.

With NetworkManager 0.7, the system settings service provides system-wide network configuration, allowing network connections at boot time and across login or fast user switches.  It also reads your distro-specific config files (there are plugins for Fedora and OpenSUSE right now, and an Ubuntu one in-progress) and thus integrates with your normal workflow doesn’t try to re-invent the wheel.  So to put it differently, NetworkManager 0.7 does not ignore your distro configuration unless you really want it to.

Full of Easy

Tambet fully anticipated the decadence of which Alberto Ruiz speaks and wrote the ‘keyfile’ system settings plugin.  We’ve said that if you want a cross-distro persistent, human-readable, text-based network configuration format for interfaces, VPN, 3G, PPP, etc, you can use the keyfile plugin instead of your distro’s format.  A certain class of users really benefits from this.  The other class can just get on with their life and not care what the backend format is, because it simply doesn’t matter to them.  Everyone is happy.

Time for Change

During the 0.7 cycle the new features we added (connection sharing, multiple active devices, 3G to name a few) were pushing the applet’s menu-based design to the limit.  It neither looks good nor behaves well to cram multiple devices and multiple connections into the menu.  Thus, back in January 2008, we asked Bryan Clark and Mike Langlie to come up with some design ideas for an nm-applet that doesn’t suck.  The most intriguing mockup was window-based, which allows for much more streamlined interaction than the menu:

It’s a mockup.  It deserves your love, not your flames.

Right away you’ll probably notice:

• Simple yet convenient: you have both a general overview of your system, but you’re not punched in the face with stuff you don’t care about.  Just like the current applet, but better.  If you want more info, it’s just a click away.
• Disconnect at will: you can already disconnect devices in NM 0.7 (the D-Bus API is there), but adding a disconnect option for every device in the current menu sucks.  Since this isn’t a GtkMenu, there’s a lot more room to play with.
• Dynamicity ™: since it’s not a  GtkMenu, it can update things like device state, signal strength, and addresses dynamically.
• Only shows what you care about: the current applet shows everything around you.  99% of the time, you care about only one or two of those networks, the ones you actually use.  The other 1% of the time, you want to connect to a network you’ve never connected to before.  Why show all 32 other networks all the time, and make you search for the one you want?  Uncool.
• More information if you want it: but not if you don’t.  Becuase there’s more space to work with, we can show stuff you might care about, like the IP address of the device, or the security features of the wifi network you’re current connected to.
• Streamlined Connection Sharing: given the larger layout and ability to tie relevant actions to a specific device, it’ll be a lot clearer to “Share this connection” than the current applet allows.

But as always, it’s a delicate balance between making the stuff you use every day prominant and easy to get to, and keeping the stuff you use only a few times a week out of your way.  I like the fact that I don’t have to care about what I’m connected to, I just want to stay connected and keep working on making stuff awesome.  I don’t want or need to know what the IP address of my VPN server is, for example, or whether my AP uses AES+CCMP for both the pairwise and group ciphers instead of AES+CCMP for the pairwise cipher and TKIP for the group cipher.  But if you really want that information, you should be able to find it within a click or two.

But windows don’t just go away when click outside them.  We could grab the pointer and close the window when you click elsewhere, but that might be weird.  It might also be weird to make this window act like and be positioned in the same place as the current popup GtkMenu, a la gnome-main-menu.  Maybe we should use effect bling to make the window genie out of the NM icon.  It’s something that needs to be prototyped and tested so we can figure out how it feels before we commit to it.  But we’ve been so busy making NetworkManager 0.7 Just Work for you that it’s taken longer than I’d like to start rewriting the applet.  Comments?  Jump #nm on freenode and discuss.

Pedal to the metal on the way to NetworkManager 0.7.

Connection Editor

Tambet and I have landed the last real bits of Add/Edit and gotten the pages pretty much finished. The applet and the connection editor retrieve and fill in your passwords too.

Contribute Back to the Community (or, Unmanaged Devices)

A few weeks back, I added an unmanaged devices interface to the system settings service. With 0.6.x, the most often asked question is “I’m an Ubuntu user; why can NM find my network device?”. This was for two reasons: (1) because Ubuntu ships a bunch of shady out-of-kernel wireless drivers (at76, prism2_usb, acx, madwifi, ndiswrapper) that often just don’t implement WEXT correctly and therefore won’t work well with wpa_supplicant, and therefore won’t work with NetworkManager, and (2) Ubuntu patched NetworkManager so that most devices in /etc/network/interfaces are ignored by NM, instead of helping to fix up the Debian backend to proxy that configuration so NM could have a chance to manage the device. So when anything goes wrong, the user is encouraged to configure the device in “Manual” mode instead, and it disappears from NetworkManager.

With 0.7, the system settings plugin for your distro will recognize these devices, tell NetworkManager they aren’t supposed to be managed, and the applet will make you aware of the horror of what you’ve just done

(as an aside, distros need to help push drivers and patches upstream, not stuff random bits into the kernel and hope everything is kittens and roses and puppy dogs tails and bright copper kettles and warm woolen mittens)

Network Before Login

So this time around, distros can write much more capable plugins to proxy their native config files to NetworkManager connections, and they will just show up in the menu. It also makes the connections available at boot. Static IPs, custom DNS servers, and whatever other crack you’d like to inflict on your network adapter. Both Fedora and SUSE have plugins, and Tambet just wrote a GKeyFile plugin that stores connections in a legacy-free/crack-free format too.

Other Hotness:

• Users are notified of VPN failures and what might have gone wrong
• Static WEP keys on indexes other than 1
• PPPoE
• Wired 802.1x
• Your Mom

Next up: making the serial driver code more robust, fix bugs, fix up ad-hoc Wifi, and fix more bugs. But 0.7 is already cooking MCs like a pound of bacon.

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.

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.

 http://people.redhat.com/dcbw/NetworkManager/0.6.6/

Gnome.org 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

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>
          </match>
        </match>
      </match>

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

I’ve just rolled NetworkManager 0.6.6 rc2 (ie, 0.6.5.99).  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.

you invent a Tivo clone that automatically mutes acceptance speeches.  That is all.

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.

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.