Skip navigation

Following up on my article on single booting Solaris on a MacBook Pro, what follows are almost identical instructions for single booting Ubuntu 10.04 Lucid Lynx on a MacBook Pro. There are two key differences with this procedure:

  1. A Master Boot Record (MBR) partition table is not necessary to boot Ubuntu.
  2. The hard drive must be blessed after installation.

Prerequisites

  1. MacOS X Install DVD (any version, OEM or full)
  2. Ubuntu 10.04 Install CD (server or desktop)

Overview

  • Using a MacOS X Install DVD format the disk with a single partition. (Phase I)
  • Boot from the Ubuntu 10.04 Install CD and install Ubuntu. (Phase I)
  • Boot from the MacOS X Installation DVD once more and bless the hard drive. (Phase II)

Read More »

I’ve encountered this error several times while running daemons (or detached processes) in Mac OS X – most recently within a Python scripted called from our continuous integration daemon:

gaierror: [Errno 2] Temporary failure in name resolution

Initially I thought I was facing a glibc bug. However, according to Python’s Build Bot system, I’m not the first person to run encounter this error. Luckily there is hope. The fix: Run your process as group daemon.

Here’s an example launchd plist for a Mac OS X Bamboo Agent running as group daemon:
Read More »

The following steps describe how to get Solaris 10 (or any other Intel based OS, including FreeBSD (tested), Linux (tested) and Windows) installed as the primary (single boot) OS on a MacBook Pro. After fighting with the non-trival method of installing Mac OS X and setting up Boot Camp, it turns out you can simply format the disk with a Master Boot Record (MBR) instead of the default EFI. Please read through this entire procedure before you attempt this method.

Overview

  • Using a MacOS X Install DVD format the disk with a single partition MBR.
  • Boot from the Solaris 10 Install DVD and install Solaris.
  • Download and install Marvell Yukon Ethernet drivers using a USB stick.

Read More »

My associate Comm-Lead (aka http://curikim.com) and I performed a FRS radio check on our way home from downtown. We used store bought 12 (14?) channel Motorola talk-about FRS radios. We took two different routes from work to home, here’s a map:


View FRS Test Route in a larger map

The map is somewhat self explanatory, but here’s some notes. We had very good coverage until Curi hit Duboce and Market. At that point I could pick her up if I turned the squelch all the way down. For the remainder of the trip I could tell there was a background signal but I could not make her out out until she reached the hill on 17th  and Clayton at which point I was at Masonic and Fell and received an excellent signal.

It seems from our test that in a flat part of the city, the expected range of FRS is about 4-6 blocks.

The idea to consume tcptrace with Splunk came to me after seeing Darren Hoch‘s OSCON 2009 presentation Linux System and Network Performance Monitoring. In his talk Darren shows how he diagnosed home networking issues using tcptrace. Here’s his description of tcptrace:

The tcptrace utility provides detailed TCP based information about specific
connections. The utility uses libpcap based files to perform an analysis of
specific TCP sessions. The utility provides information that is sometimes difficult
to catch in a TCP stream. This information includes:
• TCP Retransmissions – the amount of packets that needed to
be sent again and the total data size
• TCP Window Sizes – identify slow connections with small
window sizes
• Total throughput of the connection
• Connection duration

The data coming out of tcptrace looks like this:

TCP connection 1:
        host a:        gba-ubun810-amd64.splunk.com:40739
        host b:        spreader.yandex.net:80
        complete conn: no       (SYNs: 0)  (FINs: 0)
        first packet:  Wed Jul 22 19:58:34.489567 2009
        last packet:   Wed Jul 22 19:58:35.164233 2009
        elapsed time:  0:00:00.674666
        total packets: 395
        filename:      testdump1000
   a->b:                              b->a:
     total packets:           147           total packets:           248
     ack pkts sent:           147           ack pkts sent:           248
<snip>

Complex? Yes. Edible by Splunk? Hell yes.

Read More »

Awe! Memories! My first ‘sploit:

GARBAGENET EXPLOIT: SW-1 SOFTWARE
——————————
Date: 1/23/97
Author: servo@garbage.bridge.net
System: MacOS
Application: TrueBasic

A error has been found on any system running MacOS and any
version of TrueBasic that includes the “unsave” command. The unsave
command is used to erase or delete any file on the Macintosh HD. What this
allows any user to do is erase ANY file even if behind security programs
such as “On Guard” and “At Ease”.

IE:

! Begin Kiss Off v1.0 by Xservo <servo@garbage.bridge.net>
!       NOTE: Replace "MacHD" with the name of your Macintosh Hard Disk
!
unsave "MacHD:System Folder:Control Panels:On Guard"
end
! EOF

This program will erase On Guard from the Macintosh Hard Drive named
“MacHD”. Such a exploit can also be acccomplished with the “OPEN” and
“ERASE” commands.

EOF SW-1

++
Xservo <servo@garbage.bridge.net> {*} http://garbage.bridge.net
Powered by RHS Linux 4.1 {*} PGP Key on request (and do use!)

The total cost for this project is less than $50. The parts you’ll need are:

  1. 1x Musicians Gear Standard Speaker Stand @ $29.99
  2. Radio Shack 5-foot Antenna Mast @ $14

To assemble:

  1. Remove the inner steel tube from the speaker stand and flip it over so that the open end is facing up and the capped end is facing down.
  2. Orient the antenna mast so that the narrower section is facing up and the wider section is facing down.
  3. Push the antenna mast into the open end of the steel tube until you feel the mast hit the end cap on the steel tube
  4. Place the joined mast and tube, cap end first, into the speaker stand.

Done. You’ve now got a portable collapsable emergency antenna tripod.

Here are some steps I took to detect the MTU of some of our off-site DSL users.

The MTU for Ethernet is 1500. This is a typical setting for office LANs where there’s no traffic traversing links of smaller size. However, traffic that must cross non-ethernet links, such as DSL, will encounter MTUs of different sizes. When a network device receives a packet larger than its MTU two things can happen:

  1. If the packet has the ‘do not fragment’ flag set the device will drop the packet and reply back to the packet originator with an error message.
  2. If the packet does not have the ‘do not fragment’ flag set the device will break the packet down into identical-but-smaller sterilized packets that fit within the MTU requirements of that link.

Here’s how you can test to see what the MTU is between your computer and a remote computer.

  • In this example I’m going to use my Mac at home to test the MTU to yahoo.com.
  • I’m going to use the ‘ping’ command with the ‘-D’ (do not fragment) and ‘-s’ (packet size) flags.

Normally when I ping yahoo.com I see:

playpig(~)$ ping -c 1 yahoo.com
PING yahoo.com (66.94.234.13): 56 data bytes
64 bytes from 66.94.234.13: icmp_seq=0 ttl=47 time=256.573 ms
--- yahoo.com ping statistics ---
 1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 256.573/256.573/256.573/0.000 ms

Now I’ll ping yahoo.com with a packet size of 1492bytes:

playpig(~)$ ping -c 1 -D -s 1500 yahoo.com
PING yahoo.com (66.94.234.13): 1500 data bytes
ping: sendto: Message too long
--- yahoo.com ping statistics ---
 1 packets transmitted, 0 packets received, 100% packet loss

Next I’ll ping yahoo.com with a smaller packet size:

playpig(~)$ ping -c 1 -D -s 1300 yahoo.com
PING yahoo.com (66.94.234.13): 1300 data bytes
1308 bytes from 66.94.234.13: icmp_seq=0 ttl=47 time=172.396 ms
--- yahoo.com ping statistics ---
 1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 172.396/172.396/172.396/0.000 ms

From our testing so far we can safely assume that our MTU is less than 1500bytes and more than 1300bytes. We can continue testing until we find a happy medium. Lets try 1329bytes:

playpig(~)$ ping -c 1 -D -s 1329 yahoo.com
PING yahoo.com (66.94.234.13): 1329 data bytes
ping: sendto: Message too long
--- yahoo.com ping statistics ---
 1 packets transmitted, 0 packets received, 100% packet loss

Lets try 1328bytes:

playpig(~)$ ping -c 1 -D -s 1328 yahoo.com
PING yahoo.com (66.94.234.13): 1328 data bytes
1336 bytes from 66.94.234.13: icmp_seq=0 ttl=48 time=288.600 ms
--- yahoo.com ping statistics --
 1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 288.600/288.600/288.600/0.000 ms

Bingo. Our MTU is going to be a number less than 1336bytes that is a multiple of 8:

  • NO 1336 / 8 = 167
  • NO 1334 / 8 = 166.75
  • YES 1332 / 8 = 166.5

The MTU between us and yahoo.com is 1332bytes.

Here’s some more information on fragmentation:

“Internetworking with TCP/IP”
Pg 81 – 6.7.6 Fragmentation Control
http://tinyurl.com/6xunt8

Hi, My name is Greg and I work in IT.

I was born and raised in Fayetteville Georgia. I hope you’ll believe me when I tell you that Fayetteville in the 1980′s was no cultural Damascus. At the time, if you had asked me to conceptualize a rice-cooker I would’ve probably imagined a guy in a chef’s hat running around a kitchen screaming ‘bork bork bork!’ Alas, times have changed, and I’ve moved on…

Read More »

If you’ve ever changed the IP of a computer host – or setup a new computer with the IP of an old computer – you’ve probably noticed that the host has no network connectivity for a short time. While frustrating, this is by no means a unsolvable mystery. What’s happening is that a gateway network device – such as a firewall, router or switch – has cached the old MAC address (ethernet hardware address) associated with the host’s IP address. This cache will persist on the network device until one of two things happen:

  1. The ARP (address resolution protocol) cache on the gateway network device expires.
  2. You manually clear the ARP cache on the gateway network device.

Normally the ARP cache can be cleared on networks devices using commands like arp -d on Unix, or clear arp cache on Cisco IOS & CatOS. However, on devices for which you do not have administrative access, it may not possible to clear the ARP cache using these methods. If that’s the case, below I’ll show you a way to force a remote network device to clear its ARP cache entry for a host’s IP address.

Here’s an outline of the steps we’ll take:

  1. Install arping (portable version or FreeBSD Ports).
  2. Use arping to arping the IP address of the remote network device.

Example 1:

In this example (Example 1) the default gateway for my network is 10.10.1.1 – this is the device who’s ARP cache we’re going to clear. The IP address of my new computer is 10.10.1.2, the MAC address of my old computer was 00:1a, and the MAC address of my new computer is 00:1b (neither MAC is important, they’re just here for reference).

Read More »

Follow

Get every new post delivered to your Inbox.