Getting Raspberry Pi DHCP working with internet sharing from OS X

My sons asked to learn more about computers, so we got a Raspberry Pi. We also got Adafruit's Pi Cobbler kit. Using Adafruit's Occidentalis distro of Raspbian, I had to do a little configuration to make the following setup work, and it turned into a little bit of a networking lesson for my kids, too. I figured I'd write it up in case some other Googling Pi user needs to learn & solve this particular combination of problems - or in case I forget and need to re-do this sometime. :-)

Mac running Lion (OS X 10.7) connected to Internet via wifi.

Pi connected via Ethernet cable to Mac.

Share the Mac's Internet connection: on the Mac, System Preferences - Sharing.

• Check the box Internet Sharing from the list of services. 
• Confirm that that the sharing status is On. 
• Confirm that Ethernet is check on the list of ports to share to.

Now power on the Pi. It should get an IP address assigned via DHCP, and it should be on the network. Thanks to Occidentalis, the P is registered with Rendezvous using the name raspberrypi.local. If  DHCP and Rendezvous are both working, you can reach the Pi from the Mac using that name. This is great, because you can plug in and access a headless Pi quite easily this way.


Macintosh:~ dan$ ping raspberrypi.local
PING raspberrypi.local (192.168.2.2): 56 data bytes
64 bytes from 192.168.2.2: icmp_seq=0 ttl=64 time=0.720 ms
64 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=0.982 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=64 time=0.919 ms
^C
--- raspberrypi.local ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.720/0.874/0.982/0.112 ms

But, it wasn't working for us. The Pi wasn't registering its name, we couldn't reach it from the Mac. Tried the suggestions on the FAQ and troubleshooting wiki, but cable swapping, reflashing the Pi's software, swapping power supplies, all did not help.

There were two problems: the Pi's network configuration needed to be changed, and the Mac's Internet Sharing needed to be restarted.

Fixing the network configuration on the Pi,


David Singleton's web page gave me a clue about needing to enable the Ethernet interface on the Pi to make it get configuration from DHCP.

This is the original network interface configuration on Occidentalis:


pi@raspberrypi:~$ cat /etc/network/interfaces
auto lo

iface lo inet loopback
iface eth0 inet dhcp

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
        wpa-ssid "my-network-ssid"
        wpa-psk "my-wifi-password"


Using nano, and opening the file as superuser because it is a restricted system file,

pi@raspberrypi:~$ sudo nano /etc/network/interfaces

we make the following additions (in bold):

auto lo

iface lo inet loopback
auto eth0
iface eth0 inet dhcp

#auto wlan0 allow-hotplug wlan0 iface wlan0 inet dhcp
#        wpa-ssid "my-network-ssid"
#        wpa-psk "my-wifi-password"

Here, eth0 is the Ethernet interface,  lo is the loopback interface, and wlan0 is the wireless interface.

We don't have a wireless adapter on our Pi, so we commented out the three lines of wireless interface configuration.

Then, we restart the network, forcing it to load the new interfaces file.


pi@raspberrypi:~$ sudo /etc/init.d/networking restart

That worked better. The Pi was now coming up and making a DHCP request. But it wasn't getting a response. That's not a Pi problem, that's a problem with the Mac's Internet Connection Sharing.

Off to Google again - this thread showed other people had problems with ICS in Lion. Easiest suggestion was to simply stop and restart the service, and this worked. One more restart of the Pi's networking, and as David says: "yay, network!"

Vell, massivelyuseful.com's just zis domain, you know?

I started blogging here in 2005, before Google bought Blogger. (My first blog was on Dave Winer's original editthispage.com, which blew my mind the first time I saw it, and there were others in-between.)

A few years back I needed a domain for my first app, a silly little Hitchhiker's Guide to the Galaxy tribute app called Towel. And I think I found the perfect one.

In case you're not familiar with the Hitchhiker's Guide to the Galaxy - first, go read it. All the original 5 books of Douglas Adams' increasingly-inaccurately named trilogy. Then you'll see this line:

A towel, it says, is about the most massively useful thing an interstellar hitchhiker can have.

Then I got jealous of Towel. How come my silly app had a better domain name than my blog? 

After a while I realized I didn't have to be jealous. 

So, I'm going to start using Massively Useful as my primary blog outlet.

So long and thanks for all the fish, all you hoopy froods!

And always keep your towel handy.

Coping with metadata problems in book searches

I'll soon be facing the same issue and using the same workaround that findings.com did:

Whenever we can, we will supply WorldCat with an ISBN or other identifier to bring you straight to a book…but sometimes you will see a number of search results based on an author and Title. We would like this to be as seamless as possible, but the world of book publishing metadata is riddled with information gaps and geographic thorns.

ebooks need skimability

Stephen Johnson, talking to Findability:

If you could move one feature of paper books to digital books, what would that be?

Skimming. It’s a funny thing with print vs. ebooks; the digital age is supposed to be all about attention deficit disorder and hypertextual distractions, but ebooks lock you into reading them in a linear fashion more than print books do. It’s much easier to pick up a print book and flip through the pages, get a sense of the argument or structure, than it is with an ebook (or magazine.) It’s a very interesting interface challenge: I think it’s probably solvable, and I know many smart folks are working on it, but we don’t have a true solution yet.

I agree. It's one reason browsing in bookstores is still better than shopping online, even with Amazon's "look inside this book" - since flipping through the pages hasn't yet been implemented.

It's just a matter of time, though - I'd guess next year or two. Might just need the next generation of mobile CPUs & GPUs to ship. Flipping pages in a book requires some serious framerates!

The New Aesthetic

Bruce Sterling:

The evidence is impossible to refute. Anybody with a spark of perception who looks through this thing:
http://new-aesthetic.tumblr.com/
must recognize that modern reality is on display there. What we think about that, or do about that, is another matter. That it exists is not in question.

Also, be sure to read James Bridle and also this:

People are “acting” in ways we may or may not understand, which may or may not have an effect in the real world, whether it’s signing petitions, organising riots (on BBM), clicking, ‘liking’ KONY, whatever, the correct (maybe) response is not to have an opinion (default internet response, still) or a moral position, but to live inside the thing as it unfolds.

And there's even more!

We Are Creators, Not Consumers

My class reading this quarter is Mobile Design and Development, which you can read free online.

Author Brian Fling says:

We Are Creators, Not Consumers

The final principle of Mobile 2.0 is recognizing that we are in a new age of consumerism. Yesterday’s consumer does not look anything like today’s consumer. The people of today’s market don’t view themselves as consumers, but rather as creators.

He's talking about "user-generated content" as creation. But to me, "create" doesn't feel like the right verb for what makes social constructs happen.

Still, my reaction - being bothered by that equation and needing to probe at it like a sore tooth - tells me I should take a closer look at what is happening there.

Ok, brain, whatever you say.

(That's right, Pinky.)

IT buzzwords and memes of the moment: cloud & consumerizarion

Peter Kretzman, IT Consumerization, the Cloud and the Alleged Death of the CIO:

Let me be clear once again: this frequent linking of cloud and IT consumerization to the looming demise of the CIO and IT is not just misguided, but actually gets it completely backwards. In fact, I argue that IT consumerization and the cloud will actually elevate the importance of IT within a company, as both a service and a strategic focus.

Let’s list and then discuss some of the ways that combining these memes (IT consumerization, cloud, and the ensuing heralded death of the CIO) falls down when measured against common sense and reality:

It fails to understand the full range of what a CIO (or IT) actually provides for modern-day companies.
It fails to recognize the profound pitfalls of a decentralized and fragmented approach for company systems and technologies.
It erroneously equates IT consumerization with the BYOD trend, missing the larger important picture that underscores the strategic need for IT.
It misunderstands the interplay of commoditization and competitive strategic advantage.

Writing in "Wired Cloudline sponsored by IBM."

IT is hard enough already - why do things you don't need to?

Galen Gruman in Infoworld:

I don't get why IT itself takes on so many management challenges unrelated to technology operations or strategy.

Yes, it's not a good use of limited resources. But I don't think the problem of taking on things that don't need to be done is unique to IT.

Looking at IT for an answer to this is misplaced; instead, I'd start by looking at psychology, both organizational and individual.

Close Encounters of the Collaborative Kind

Good article in this month's IEEE Computer magazine, Close Encounters of the Collaborative Kind:

The participants in a collaborative interdisciplinary project found that developing a shared, project-specific communication style helped them overcome cultural barriers, understand the nuances of each other's work, and enhance the accuracy, interpretability, and utility of their models.

Taming Complexity and Tesler's Law

I always have a good think when I read Don Norman. Just started reading his Living with Complexity and it's holding true to form. It's worth reading the whole book just to be reminded of Tesler's Law.

Complexity can be tamed, but it requires considerable effort to do it well. Decreasing the number of buttons and displays is not the solution. The solution is to understand the total system, to design it in a way that allows all the pieces fit nicely together, so that initial learning as well as usage are both optimal. Years ago, Larry Tesler, then a vice president of Apple, argued that the total complexity of a system is a constant: as you make the person's interaction simpler, the hidden complexity behind the scenes increases. Make one part of the system simpler, said Tesler, and the rest of the system gets more complex. This principle is known today as Tesler's law of the conservation of complexity. Tesler described it as a tradeoff: making things easier for the user means making it more difficult for the designer or engineer. “Every application has an inherent amount of irreducible complexity. The only question is who wil have to deal with it, the user or the developer.” (Tesler and Saffer, 2007) With technology, simplifications at the level of usage invariably result in added complexity of the underlying mechanism.

If you are a Don Norman newbie, start with The Design of Everyday Things, that's a classic. I liked the first edition's title better, Psychology of Everyday Things. He called it POET for short.

I also just read an article Don wrote for core77: Act First, Do the Research Later, where he demonstrates that pragmatism matters, and there are many paths to good design.

Today we teach the importance of doing design research first, then going through a period of ideation, prototyping and iterative refinement. Lots of us like this method. I do. I teach it. But this makes no sense when practical reality dictates that we do otherwise. If there is never enough time to start with research, then why do we preach such an impractical method? We need to adjust our methods to reality, not to some highfalutin, elegant theory that only applies in the perfect world of academic dreams. We should develop alternative strategies for design.

Why it is not necessary to start with design research: Here are five very different arguments to support the practical reality of starting by designing, not through design research. First, the existence of good design that was not preceded by research. Second, the argument that experienced designers already have acquired the knowledge that would come from research. Third, the research effort of a company ought to be continually ongoing, so that results are available instantly. Fourth, and most controversial, research might inhibit creativity. And fifth, when the product is launched and the team assembled, it is already too late. 

That's particularly fun given that I'm taking a course right now which is all about design research. I do enjoy holding two opposed ideas in my head at the same time. (No one should think F. Scott Fitzgerald was literally setting this as a true, singular test of a first-rate intellect; it's a necessary quality, but not sufficient on its own.)

Hey! I just found the whole quote, and there's two more sentences to it that I've not seen before.

Before I go on with this short history, let me make a general observation – the test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function. One should, for example, be able to see that things are hopeless and yet be determined to make them otherwise. This philosophy fitted on to my early adult life, when I saw the improbable, the implausible, often the "impossible," come true.

Seeing that things are hopeless and yet being determined to make them otherwise. Yup. That's worth doing.

If you want to investigate more about reconciling opposing ideas, I suggest The Opposable Mind.