Spin Class

6970907095_f9560f3740_b
via Roadsidepictures (CC BY-NC 2.0)

We’ve recently binged on making NetworkManager work better in more places, mostly enterprise and virtualization related.  But one thing we’ve wanted to do for a long time was make things more modular.  And that got landed this week via the dev-plugins branch, which makes ATM, Bluetooth, and WWAN into shared libraries loaded optionally at startup.

Distro packagers can now create separate NetworkManager-atm, NetworkManager-bluetooth, and NetworkManager-wwan packages, each with their own dependencies, while the NetworkManager core goes forward a slimmer, smaller, more efficient version of its previous self.  If you’re installing NetworkManager into minimal environments, you can just ignore or remove these plugins and revel in your newfound minimalism.

The core NM binary is now about 15% smaller, and there’s a corresponding 7.5% RSS reduction at runtime when no plugins are loaded.  What’s next?  Possibly WiFi, which would save about 6 – 8% of the core binary size.

N950 charging WTF

Courtesy of Zeeshan I came into an N950 last year, so that I could make the N9/N950 work great with ModemManagerMission accomplished.  And one of the most annoying things about it is that when the battery is charged, it stops charging even though it’s still plugged in.  So, of course, I wake up in the morning and since it’s stopped charging while plugged in, the battery is now down to 75% or even lower.

So I humbly ask the Internet, is there a way to tell the N9/950 not to drain the battery when it’s done charging and still plugged in?

Got EVDO? Help me out!

I’m trying to reverse engineer the EVDO Pilot Sets V2 QCDM log item so we can get EVDO signal strength while connected with ModemManager.  I’ve got most of it figured out, but half the battle of reverse engineering is getting enough variation in the data to see the patterns.  That’s where you come in.  I’m specifically interested in getting results from EVDO on 850MHz (Americas), 450MHz (Europe and Russia), and 1700MHz/AWS (North America), so if you’re in the US and you have Leap, Cricket, MetroPCS, US Cellular, C-Spire, nTelos, then you get bonus points.  But even if you have Verizon or Sprint, the data is still useful.

You obviously have to have an EVDO-capable WWAN data card or phone that uses Qualcomm chipsets and exposes a DIAG port, but luckily almost all devices that speak CDMA/EVDO are Qualcomm-based.  You don’t even need to have an active subscription, as the tool is read-only.

So if you’re game, grab this tarball and run ‘make’ in the extracted directory.  That’ll give you an ‘evdolog’ binary which when run dumps out the data I’m interested in.  When you’ve got the dump, mail it to me.  There’s a README in the tarball that has more detail on everything.

The tool doesn’t dump any personal data, just information about what radio channels your modem is listening on and information about what radio channels the modem might jump to if you move around.  The output looks like this:

SS: State: 1
SS: Band Class: 1
S: Channel: 75

L: PN:      3
L: AS ct:   1
L: AS win:  60
L: AS chan: 2123 (0x084B)
L: UNK 1:   63 (0x3F)
L: CA ct:   0
L: CA win:  0
L: RE ct:   14
L: RE win:  100
L: UNK 2:   0 (0x00)
L: Act 0:   PN: 30   6f 01 11 00 03 00 ba 3b
L: Rem 0:   PN: 33   00 00 4b 08 64 00 00 00
L: Rem 1:   PN: 36   00 00 4b 08 64 00 00 00
L: Rem 2:   PN: 402  34 00 4b 08 64 00 00 00
L: Rem 3:   PN: 279  06 00 4b 08 64 00 00 00
L: Rem 4:   PN: 27   00 00 4b 08 64 00 00 00
L: Rem 5:   PN: 21   00 00 4b 08 64 00 00 00
L: Rem 6:   PN: 126  00 00 4b 08 64 00 00 00
L: Rem 7:   PN: 399  00 00 4b 08 64 00 00 00
L: Rem 8:   PN: 318  00 00 4b 08 64 00 00 00
L: Rem 9:   PN: 24   00 00 4b 08 64 00 00 00
L: Rem 10:  PN: 300  00 00 4b 08 64 00 00 00
L: Rem 11:  PN: 504  00 00 4b 08 64 00 00 00
L: Rem 12:  PN: 507  00 00 4b 08 64 00 00 00
L: Rem 13:  PN: 510  00 00 4b 08 64 00 00 00

Which, if you know CDMA, you know there is no channel 2123 in band class 0 or 1, which is one reason I’m asking for data dumps here 🙂

Thanks!

I never go jogging, it makes me spill my Martini.

"Martini, take 2" by Niklas Morberg (CC BY-NC 2.0)

And why are we sipping sophisticated cocktails with an air of restrained joy, you might ask?  The answer is that we don’t need a reason.  But if we had one (and I’m still not saying we do), it would involve a couple of great releases we’ve made over the past few weeks.  Thanks to everyone how contributed!

NetworkManager 0.9.6

Lots of great stuff in this update to the NetworkManager stable series.  Tons of fixes to the glib bindings, enhanced IPv6 functionality, more capable nmcli tool, support for ADSL modems, on-demand WiFi scan support, new Vala bindings, documentation updates, and a lot more.  This release is recommended for anyone using older 0.9.x versions.

Where do we go from here?  Bridging support is scheduled to land in the next release, as are some cleanups of the D-Bus and glib APIs that make it easier for app developers.  We’ll probably also have real hotspot support (AP-mode, yay!), bring back WPA Ad-Hoc mode for kernel drivers that actually support it, toss in an enhanced connection editor with support for bridging, bonding, VLAN, WiMAX, ADSL, etc, and yet more fixes all around.  We’re hoping to release this next version a bit later this fall.

ModemManager 0.5.4 and 0.6

Finally a 0.6 release, which adds support for Cinterion devices and Iridium satphone modems.  Plus an enhanced API for things like PIN/PUK retry counts, facility locks, network time and date indications, and better support for devices that want PPP on specific ports.  It also includes all the enhancements that are also present in 0.5.4 such as more compatible SMS handling, support for more ZTE, Ericsson, and Sierra devices, and random bug fixes.  They’re also the most tested ModemManager releases ever!

Next up for ModemManager is beating git master into shape, which will debut as 0.8 sometime later this year.  It properly supports multi-mode devices that can talk CDMA/EVDO and GSM/UMTS and LTE all at the same time, including all the new Qualcomm devices that use the QMI protocol.  It also drastically reworks the D-Bus API to ensure things stay working with future hardware capabilities.  Yes, a huge D-Bus API break, but it’s properly namespaced so that supporting both the old and new APIs can be done in the same binary without compile-time switches.

So cheers!  And play the *Manager drinking game: whenever it works, take a drink!  You’ll be wasted in no time…

I’m Doing My Part

Land of Modems

There’s a major ModemManager release coming up soon, and that means testing.  What better to do on a Friday than test a @#%!-load of modems and phones?  But hey, I know what’s better…  drowning your incredible frustration with firmware and hardware in a kiddy-pool full of cheap booze.  Isn’t hardware great?

dhclient infinite lease follow-up

Further analysis clarifies some of the actual bugs in dhclient/dhcp code.  The ‘infinite lease’ problem only happens on 64-bit hosts due to the size of time_t.  Plus the problem isn’t just an ‘infinite’ lease issue, it’s a ‘infinite lease minus seconds since the epoch’ problem due to how the dhclient code internally handles timeout calculation.  Remember, an ‘infinite’ lease is 0xFFFFFFFF, or UINT_MAX.

On IA-32, where time_t is 32-bit:

  • after the lease is ACK-ed, some code adds the lease seconds to gettimeofday() seconds to determine the lease expiry time, which of course is now wrapped
  • this same code then checks if the lease expiry is less than gettimeofday() seconds (which of course it is, since it just wrapped around to gettimeofday() – 1) and helpfully resets the lease expiry to INT_MAX
  • checks in isc_time_nowplusinterval() which guard against 32-bit overflow (by checking expiry seconds plus gettimeofday() against UINT_MAX) succeed and everything works

On x64, where time_t is 64-bit:

  • adding gettimeofday() seconds to the lease seconds does not wrap, thus the lease expiry is larger than UINT_MAX
  • since the value did not wrap, the checks for negative lease expiry do not trigger, and the expiry is still UINT_MAX + gettimeofday()
  • the overflow checks in isc_time_nowplusinterval() trigger because our values are already larger than UINT_MAX, and the lease fails

The core problem is that most of the dhcp/dhclient code simply doesn’t deal with large time values that may occur on 64-bit platforms.  A few suggestions for dhclient:

  1. Change the TIME define to ‘u_int64_t’ instead of ‘time_t’; that makes the relevant client_lease structure fields large enough to survive a wrap
  2. Change the fields of struct isc_time_t to ‘u_int64_t’ instead of ‘unsigned int’; maybe even change ‘struct isc_interval_t’ to use 64-bit values just to ensure wrapping doesn’t happen there too
  3. Stop using ‘struct timeval’; instead use the fixed ‘struct isc_time_t’
  4. Wrap gettimeofday() in a utility function that returns a ‘struct isc_time_t’ instead of ‘struct timeval’
  5. Then you don’t need the 32-bit checks in isc_time_nowplusinterval() or at least you could change them to be 64-bit safe instead.

For Fedora, fixed test packages are available here.  Not sure about other distros.

GUADEC PSA: WiFi fails due to dhclient lease miscalculation

The DHCP server at GUADEC apparently gives out infinite leases, which have a value of 0xFFFFFFFF (in seconds).  Leaving aside the question of whether infinite leases are actually a good idea at a conference where many people come and go (hint: they usually aren’t),  why won’t it just @#%@#%!&&* connect?

By default NetworkManager uses dhclient for DHCP, and that usually works fairly well.  It’s a well-understood program developed by the ISC that’s used by millions every day.  But dhclient apparently fails with infinite leases.  Here’s the dhclient code:

    #define DHCP_SEC_MAX  0xFFFFFFFF

/*
* The ISC timer library doesn’t seem to like negative values
* and can’t accept any values above 4G-1 seconds so we limit
* the values to 0 <= value < 4G-1.  We do it before
* checking the trace option so that both the trace code and
* the working code use the same values.
*/

sec  = when->tv_sec – cur_tv.tv_sec;
usec = when->tv_usec – cur_tv.tv_usec;

<…>
} else if (sec > DHCP_SEC_MAX) {
log_error(“Timeout requested too large ”
“reducing to 2^^32-1”);
sec = DHCP_SEC_MAX;
<…>
}

isc_interval_set(&interval, sec & DHCP_SEC_MAX, usec * 1000);
status = isc_time_nowplusinterval(&expires, &interval);
if (status != ISC_R_SUCCESS) {
log_fatal(“Unable to set up timer: %s”,
isc_result_totext(status));
}

The code attempts to add a timeout that triggers when the lease expires; “when” is the lease interval coming from the DHCP server (which is 0xFFFFFFFF, remember).  “cur_tv” is just gettimeofday().  Let’s enumerate the fail purely for pedagogic purposes:

  • Despite the comment and logged error, the code makes no attempt to limit the value to UINT_MAX – 1.  Even if it did, this wouldn’t help; see below.  So now we’re passing UINT_MAX into isc_time_nowplusinterval() as interval->seconds.  Condensed code for that function:

isc_result_t isc_time_nowplusinterval(isc_time_t *t, const isc_interval_t *i) {
struct timeval tv;

if (gettimeofday(&tv, NULL) == -1)
return (ISC_R_UNEXPECTED);

/* Ensure the resulting seconds value fits in the size of an
* unsigned int.  (It is written this way as a slight optimization;
* note that even if both values == INT_MAX, then when added
* and getting another 1 added below the result is UINT_MAX.)
*/
if ((tv.tv_sec > INT_MAX || i->seconds > INT_MAX) &&
((long long)tv.tv_sec + i->seconds > UINT_MAX))
return (ISC_R_RANGE);

<…>

  • tv.tv_sec could be greater than INT_MAX since time_t is often 8 bytes wide.  So this code is much more likely to fail in early 2038.
  • Oops!  i->seconds is UINT_MAX, and clearly that’s larger than INT_MAX.  So onward to the next bit.
  • Oops I did it again!  I played with your timer!  The second check passes (unless you have a time machine and you like 1970) because tv.tv_sec is the current time (clearly a large value) and i->seconds is already UINT_MAX.
  • An error is returned, and your lease fails.

Looks like this code just doesn’t expect to deal with large values of Unix time; hopefully that’ll get corrected soon.  The Red Hat bug report for this is bug 662254.

What can I do?

NetworkManager supports two different DHCP clients, selectable at runtime.  Install dhcpcd, set dhcp=dhcpcd in the [main] section of /etc/NetworkManager/NetworkManager.conf, restart NM, and voila, DHCP.

Blue sky, white sand, and NetworkManager 0.9.2

The view as I type 'git tag 0.9.2'... (shazwan cc-by-2.0)

There’s no better way to celebrate the release of NetworkManager 0.9.2 than a sip of ice-cold cocktail.  It’s something pink-colored — I don’t know what — and it’s phenomenal.  And if I ever run out, I just ring a bell and somebody fills it up!  It’s basically like Paradise, except Paradise doesn’t have the latest version of NetworkManager.  Here’s a hot tip: make your first half billion and buy yourself a private island.  Then move there and write open-source software for fun.  It’s a pretty great life.  After a hard day on the beach bending networks to my will, I wind down by building buried hatches solely to confuse the island’s next owner (I’m trading up to a private archipelago in a few years).

But I digress.  So many people contributed to this release.  Unfortunately they couldn’t all fly out to my private island for the release party so I’ll just have to call them out by name instead.  I’m sure they’ll take Internet fame as a consolation prize, right?  So a huge thanks to Alfredo Matos, Colin Walters, Dan Winship, David Rothlisberger, Evan Broder, Florian Echtler, Gary Ching-Pang Lin, Jirí Klimeš, Larry Reaves, Ludwig Nussel, Mathieu Trudel-Lapierre, Michael Stapelberg, Thomas Bechtold, Thomas Graf, Thomas Jarosch, Tore Anderson, Michael Biebl, Vincent Untz, Anders Feder, Giovanni Campagna, Murilo Opsfelder, David Woodhouse, all our translators, and all our testers.  It wouldn’t have happened without you.

This release packs in some great stuff aside from the usual bug fixes and pixie dust: translated country names in the mobile broadband provider wizard, VPN details in the applet’s Connection Information dialog, auto-unlocking of GSM modems, support for libnl2 and libnl3, better IPv6 handling, enhancements for nmcli, rfkill fixes for EeePCs, GObject Introspection updates, better cooperation with unmanaged devices, timestamps for VPN connections, increased dnsmasq cache size, and more.  Get your tarballs on:

http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.9/
http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.9/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openconnect/0.9/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openswan/0.9/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openvpn/0.9/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-pptp/0.9/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-vpnc/0.9/

0.9.4: a Smörgåsbord of Freaking Awesome

What’s even more exciting is what’s all piled up for 0.9.4.  We’ve killed WEXT and now use the more robust nl80211 for talking to well-behaved kernel drivers.  We’ve uncoupled IPv4 and IPv6 addressing so that when one completes the connection is usable while we wait for the other one to complete or time out.  We’ve added bonding support, and VLANs and bridges are next.  We’ll have better firewall interaction.  We’ll probably have connectivity detection as well.  Many of these features are finished and merged to git master already.

Hey, 0.8.6 is out too!

If you’re into anachronisms, then we’ve got another release for you too.  0.8.6 got tagged earlier this week, and it’s got IPv6 fixes, auto-unlocking of GSM modems, improved usability of IP address and routing entry in the editor, notifications of mobile broadband changes, VPN information in the Connection Information dialog, better handling of gadget devices, retry of Ethernet connections on carrier bounces, allowing certificate paths in keyfile plugins, MAC address blacklists, on-the-fly recognition of newly installed VPN plugins, subject verification of 802.1x certificates, builds without PolicyKit, and much more.

So really it’s just raining NetworkManager goodness.  Except here on my island, where it’s always sunny, breezy, and absolutely perfect.  Time for another drink.  Cheers.

They’re moving into the street

The conversation around the Occupy Wall Street protests, lack of jobs, and the widening income gap in the US reminds me of Disturbed’s Land of Confusion video.  Hopefully the future doesn’t come down to wars in the street, and hopefully some shadowy dark superhero doesn’t show up, but he’s probably a metaphor anyway.  At some point society needs to agree that the capitalist drive for maximizing shareholder value also includes certain moral/ethical behavior instead of profits-at-all-costs.  But the harder part is agreeing on how to enforce that behavior, since “The Market” doesn’t really encourage it.  Which I think is one of the real issues in the world today, and has been for a long time.

When the Sun Shines We’ll Shine Together

Everyone loves NetworkManager 0.9 (Beverly & Pack, cc-by-2.0)

Hurray!  It’s finally out: NetworkManager 0.9.  Thanks to a ton of help from almost 150 contributors and countless testers we’ve reached a new level of awesome.  Let’s drop some recap on y’all:

Peace be with your network

Fast User Switching

This release debuts full support for fast user switching, a long-requested feature that makes the networking experience on multi-user computers butter-smooth.  As a result of the simplified 0.9 architecture, each user gets their own network applet and each applet can control networking independently, provided that user has permissions to do so.  If you switch and the new active user doesn’t have permissions for a connection, it’s terminated.  It’s as simple as that and works just like you’d expect.

 

Roam Free (by raneko, cc-by-2.0)

Optimized WiFi Roaming

When connected to a large unified WiFi network, like a workplace, university, or hotel, NetworkManager 0.9 enhances roaming behavior as you move between locations.  By using the background scanning and nl80211 features in wpa_supplicant 0.7 and later, you’ll notice fewer drops in connectivity and better signal quality in large networks.  Most kernel drivers will now provide automatic updates of new access points and enhanced connection quality reporting, allowing wpa_supplicant to quickly roam to the best access point when the current access point’s quality degrades and not before.  Yay!  Fewer dropped frames when you’re watching the YouTube Top 100.

 

WiMAX

Are you one of the 70 million and growing WiMAX users?  Got an Intel WiMAX card in your laptop?  Great!  NetworkManager 0.9 lets you jump on blazing fast WiMAX speeds while you’re on the go.  Put that hardware to work: simply pick your provider from the menu, and you’ll be connected automatically when WiMAX is on.

 

Made of Easy (katieharbath, cc-by-nc-sa-2.0)

Flexible Permissions

Wait, you haven’t taught little Tommy the value of hard-earned cash? Well until you do, you can restrict your metered 3G to everyone but Tommy so he doesn’t run up the bill playing stupid Flash games or poke around with your work email over the VPN.  Or if you’re a sysadmin, you can roll out the same network configuration to multiple users and be sure that unauthorized users can’t connect to networks they shouldn’t be able to.  The combination of connection permissions and flexible PolicyKit-based authorization lets you manage your computer the way you want.

 

Consolidated Configuration

No longer do we have multiple settings services storing information in different formats and locations.  Instead, all network connection information is stored by NetworkManager itself leading to faster network connections and simpler configuration.  Applications now have one place to look for network configuration instead of two; one place to update instead of two; one place to monitor for changes instead of two; you get the picture.  More features in half the code, yo.

 

It'll be our little secret (katietegtmeyer, cc-by-2.0)

Flexible Secrets

Passwords for any connection can now be stored securely in each user’s session or in privileged system connection storage.  If you’re a bit paranoid you can choose to enter any password every time you connect instead of saving it.  For system administrators this means you can have one connection for all users even if each user’s password is different or they use On-Time-Pad tokens.  By default sensitive secrets (like VPN and 802.1x passwords) are stored in the user’s session while generic ones (like WiFi passphrases, etc) are stored system-wide to balance privacy and usability.  If you’ve got a different idea of balance, it’s trivial to open it up or lock it down just as much as you like.  If you’re on a mobile device and you just don’t care, you can leave everything to NetworkManager and ignore user sessions completely.

 

Simplified D-Bus API

Consolidation of the API makes it radically simpler for applications to respond to network changes, be smarter about what networks you’re connected to, and how you’re connected to them.  It’s trivial to figure out if you’re at home or at work and to do the right thing, so now there’s really no excuse to make your application do what your users expect.  And it’s easier to write cool new network applets and configuration UI too.  Go wild.  Make your apps sing.

 

GObject Introspection

Want to use NetworkManager from applications that aren’t written in C or C++?  With the GObject Introspection it’s trivial to use the NetworkManager convenience libraries from Python or JavaScript or any other introspection-enabled language.  Start writing lickable new applets or make your app network aware in the easiest way possible.

const NMClient = imports.gi.NMClient;
client = NMClient.Client.new();
if (client.state == NetworkManager.State.CONNECTED_GLOBAL)
    print "You're connected!"

 

Developers and Distros

Because it’s a change in D-Bus and libnm-glib API, we’ve prepared a migration guide for developers.  If your app just cares about whether you’re connected to the network and how, here are some example patches.  Distro packagers should check for the latest versions of chat, backup, browser, mail, etc programs since they probably have had NM 0.9 support for months.  As always, there’s a bunch of developer information and API documentation on the website and wiki.  If you don’t find what you’re looking for, tell us how to improve!

 

Networking is never done (j4hnb, cc-by-2.0)

120 Proof for the Future

But this much awesome just isn’t enough.  Always looking forward, NetworkManager is primed for great new features like connectivity detection, captive portal auto-login, network zones, automatic firewall and proxy management, new hardware support, and more.  As a result of the API cleanup done for 0.9, NM is ready for the next wave of great features that will actually make your life better.  A faster, more robust release process will ensure these features get to you more quickly.  If we’ve done our job, you won’t even notice that NetworkManager is there; but it will be, saving the planet one network at a time.