March 2015 – Matt Simerson

Bandwidth shaping on Mac OS X

By what dark magic has Apple accomplished this task? Inspecting the network interface didn’t turn up anything special so I checked the firewall rules (sudo pfctl -sa) and found dummynet rules! In the PF ruleset! And increasing dummynet packet counters.

A few years ago I sampled each of the “All My Music In the Cloud” services (iTunes Match, Amazon Cloud, Google Play). For them to stream my music back to all my devices, I first had to first upload all my music (82 GB of data) to each service.

The iTunes Match upload was far smaller because Apple has the worlds largest music library and iTunes Match only uploaded my songs that weren’t already already in their collection. That should have made the upload process quick, except that something about the upload mechanism Apple uses caused severe network congestion and network stalls of 5 full seconds. I blamed it on iTunes and used the built-in IPFW firewall to plumb a 256Kbps pipe so that iTunes Match uploads would stop erring out and I could use my internet connection during the long upload process.

ipfw pipe 1 config bw 256KBytes/s
ipfw add 1 pipe 1 src-port 443
ipfw add 2 pipe 1 dst-port 443

That IPFW solution worked just as well for throttling the other cloud music services.

Fast-forward a couple years to Mac OS 10.10.3 and the new Photos app that stores all my photos in the cloud. There’s a process named photolibraryd and it seems to have that same nasty behavior. The symptoms are identical but I can’t use IPFW because Apple removed it in OS X Yosemite. I understand, as I too stopped using IPFW years ago in favor of PF. But Apple doesn’t provide ALTQ, the PF bandwidth shaper. So the PF firewall has no bandwidth shaping abilities. Or so I thought.

After a bit of hunting, I found the Network Link Conditioner within the Hardware IO Tools for Xcode. Even better, a GUI interface for accomplishing my goal. I downloaded it, set up a 256Kbps upload limit and I could once again let photos upload while I use my internet connection.

Dummynet is part of IPFW, so apparently rather than implementing ALTQ, Apple decided to modify PF to support dummynet. The man page for pf.conf doesn’t even contain the term ‘dummy’ but I expect that’ll come eventually. In the meantime, the intarwebs can help you find documentation for how to write rules for it.

An auspicious start to DOS programming

In 1992 I was a young geek of 19 years. My programming experience consisted of the BASIC programs in the manual that came with our Commodore 64 and a few others in our schools Apple II lab. I had also written a few HyperCard and FileMaker apps on the Mac in my bedroom, where I did all the typesetting for my Dad’s print shop. [Thanks so much dad, for buying that first Mac Plus instead of a Compugraphic typesetting machine].

My vocational training in Mechanical Drafting had landed me an entry level position at Kysor/Cadillac as the blueprint clerk. Before long I rearranged the print room to maximize the efficiency of the engineers and myself, leaving me with hours of spare time each day. Often I would roam the engineering department, in search of engineering projects, much to the delight of the engineers who could often find drudge work to offload.

During one of these lulls, I was chatting with David, a bright young lad who worked in the QA department. David was also quite fond of computers and told me of an escapade in which some students at his school had written a login simulator that captured and stored passwords when users logged into an system infected with their program.

Our engineering files were stored on a Novell Netware server connected by a token ring network. Each DOS computer logged in using a Novell program (login.exe, IIRC). The password capturing program seemed like an interesting challenge so I acquired my first DOS compiler (Qbasic or PowerBasic, I can’t recall which I used for this task) and wrote login.bas. I simulated the login screen perfectly, stored the passwords to a file, and then passed them on to the real login program, logging the user in. It offered the user no indication that foul play was at hand.

Pleased with my results, I showed Rick, our network admin. I explained that I hadn’t inspected the contents of the file, knew what was in it, and turned my back while he inspected it. It turns out that Rick wasn’t terribly fond of being informed that his network security wasn’t all that secure. A few of his heated words I recall were, “that’s not your job!” He immediately escalated the matter to Keith, our VP of Engineering, intent on having me fired.

On that day, it was quite fortunate for me that I had set a precedent of doing a lot of engineering work that was not my job. Unbeknownst to me, the wheels of my first promotion were already set in motion specifically because of the extra-curricular not my job work I had been doing. That day ended with me getting a stern talking to. Soon thereafter, I was promoted and my new job involved writing software for Kysor.

Me too!

The scene: It’s a brisk mid-winter Seattle morning. Lucas has decided that we’re riding our bikes to school today. As we emerge from the garage, the sky is brilliant blue and the sun is streaming down in our faces. The lawns up and down the street are all brilliant green as this is our rainy season. It’s a lovely morning and all is well with the world. On this morning, after a night with no cloud cover, it’s still quite chilly and the shaded lawns are all still frost covered. Both kids eagerly accept the gloves that I had thought to bring for them.

A very short ways from home, Kayla asks us to pause so she can tie her skirt up, keeping it well clear of her back tire. I comment, “hmm, we should get you a rear fender to keep your skirts off that tire.”

Lucas, not wanting to miss out on getting one of anything pipes up, “Should we get one for me too?”

I replied, “Of course, we don’t want your skirts getting dirty, do we?”