Felipe Alfaro Solana

NOTE: This post is a based on Mac OS X, Bluetooth and Nokia UMTS phones that I wrote some days ago, but adapted to Motorola 3G phones.

This brief post explains how to pair Mac OS X with a Motorola 3G/UMTS phone in order to access the Internet via a data packet connection. In my case, I’m using a Motorola RAZR V3xx phone but any other Motorola 3G phone should work.

Before you start, please make sure that your phone is properly configured and that you can browse the Web via a GPRS/UMTS connection. Also, make sure that Bluetooth support in your phone is configured and activated and, for phones that have temporary visibility (are only visible via Bluetooth for a limited period of time), make sure to enable Bluetooth just before the pairing process.

Initial configuration

First, download the Motorola 3G Modem Scripts for Mac OS X from Ross Barkman’s Home Page (the official site) or from here.

Second, uncompress the file and copy the files named “Motorola 3G CID1” and “Motorola 3G CID2” into “/Library/Modem Scripts“.

Next, pair your Mac OS X computer with the Motorola phone by clicking on the Bluetooth icon in the menu bar and then Set up Bluetooth Device…. When pairing make you sure you choose Use a direct, higher speed connection to reach your Internet Service Provider *GPRS, 1xRTT).

Enter guest as the Username, guest as the Password, the APN (CID String or Telephone number) and make sure Motorola 3G CID1 is selected as the Modem Script. For example:

For a detailed list of possible combinations of username, password and APN CID for a lot of providers around the world visit Ross Barkman’s GPRS Info Page.

Dialing out

To dial out, open Internet Connect, browse to the Bluetooth tab and make sure the right entry is selected from the drop down menu. Then click Connect. Mac OS X will authenticate to the remote PPP server and a new dynamic PPP subinterface should be configured:

$ ifconfig ppp0
ppp0: flags=8051 mtu 1500
        inet 10.142.15.9 --> 10.6.6.6 netmask 0xffffff00

In my case, browsing speed is very good (around 384Kbps), but it might vary according to placement, coverage, whether you are moving and so on (by the way, UMTS network planning, deployment and coverage is something not trivial).

Troubleshooting

Make sure all the information for the connection have been entered correctly, specially the APN/Telephone number. If it doesn’t work, try using Motorola 3G CID2 as the Modem Script instead.

It turns out that the Motorola RAZR V3xx cell phone is not yet supported by iSync 2.3. Fortunately enough, David has created an iSync 2.3 plugin.

David wrote a post named iSync and a Motorola RAZR V3xx and the iSync 2.3 plug-in that can be downloaded from here or from here.

Unfortunately, the version that is available at the moment of this writing is version 4 and, while it does support synching contacts, iCal synching is not yet supported or working. Anyways, thanks for the plug-in, David

This brief post explains how to pair Mac OS X with a Nokia 3G/UMTS phone in order to access the Internet via a data packet connection. In my case, I’m using a Nokia 6234 phone but any other Nokia phone should work.

Before you start, please make sure that your phone is properly configured and that you can browse the Web via a GPRS/UMTS connection. Also, make sure that Bluetooth support in your phone is configured and activated and, for phones that have temporary visibility (are only visible via Bluetooth for a limited period of time), make sure to enable Bluetooth just before the pairing process.

Initial configuration

First, download the Nokia 3G Modem Scripts for Mac OS X from Ross Barkman’s Home Page (the official site) or from here.

Second, uncompress the file and copy the files named “Nokia 3G CID1” and “Nokia 3G CID2” into “/Library/Modem Scripts“.

Next, pair your Mac OS X computer with the Nokia phone by clicking on the Bluetooth icon in the menu bar and then Set up Bluetooth Device…. When pairing make you sure you choose Use a direct, higher speed connection to reach your Internet Service Provider *GPRS, 1xRTT).

Enter guest as the Username, guest as the Password, the APN (CID String or Telephone number) and make sure Nokia 3G CID1 is selected as the Modem Script. For example:

For a detailed list of possible combinations of username, password and APN CID for a lot of providers around the world visit Ross Barkman’s GPRS Info Page.

Dialing out

To dial out, open Internet Connect, browse to the Bluetooth tab and make sure the right entry is selected from the drop down menu. Then click Connect. Mac OS X will authenticate to the remote PPP server and a new dynamic PPP subinterface should be configured:

$ ifconfig ppp0
ppp0: flags=8051 mtu 1500
        inet 10.142.15.9 --> 10.6.6.6 netmask 0xffffff00

In my case, browsing speed is very good (around 384Kbps), but it might vary according to placement, coverage, whether you are moving and so on (by the way, UMTS network planning, deployment and coverage is something not trivial).

Troubleshooting

Make sure all the information for the connection have been entered correctly, specially the APN/Telephone number. If it doesn’t work, try using Nokia 3G CID2 as the Modem Script instead.

NetBSD ports collection includes audio/mt-daapd, a nice and straightforward implementation of Apple’s DAAP protocol for streaming music to iTunes. The only problem is that audio/mt-daapd is not compiled with Zeroconf support by default. In NetBSD, net/howl provides an implementation of Apple’s Zeroconf (also known as Rendevous or Bonjour).

In order to compile audio/mt-daapd under NetBSD with Zeroconf support, I first had to compile and install net/howl:

# cd /usr/pkgsrc/net/howl
# make install

Once net/howl is installed, I had to modify the Makefile file for audio/mt-daapd such as that howl support is enabled. This involves passing --enable-howl to the configure script and pointing it to the non-standard directory where the howl include files are — /usr/pkg/include/howl.

So, I edited /usr/pkgsrc/audio/mt-daapd/Makefile and after the line that reads:

GNU_CONFIGURE=  yes

I inserted:

CONFIGURE_ARGS+= --enable-howl
CONFIGURE_ARGS+= --with-howl-includes=${LOCALBASE}/include/howl

Before the line that reads:

.include "../../mk/pthread.buildlink3.mk"

I added:

.include "../../net/howl/buildlink3.mk"

Then,

# cd /usr/pkgsrc/audio/mt-daapd
# make install

I had to make some changes in order to get howl and mt-daapd start automatically during boot.

I added the following lines to /etc/rc.conf:

howl=YES
daapd=YES
daapd_flags="-c /etc/mt-daapd.conf"

Next, I copied /usr/pkg/share/examples/mt-daapd/mt-daapd.conf to /etc/mt-daapd.conf and customized it — for example, to change the server name, specified by the servername directive.

I also had to create the /etc/rc.d/mt-daapd rc script to get mt-daapd started automatically during boot. It looks like this:

#!/bin/sh
#
# $NetBSD: howl.sh,v 1.2 2006/01/01 18:27:53 tron Exp $
#

# PROVIDE: daapd
# REQUIRE: howl
# REQUIRE: NETWORKING

. /etc/rc.subr

name="daapd"
rcvar=$name
command="/usr/pkg/sbin/mt-daapd"
sig_stop=KILL

load_rc_config $name
run_rc_command "$1"

A sample configuration file that I’m using for mt-daapd — /etc/mdaapd.conf — looks like this:

web_root         /usr/pkg/share/mt-daapd/admin-root
port             3689
admin_pw         mt-daapd
db_dir           /var/cache/mt-daapd
mp3_dir          /mnt/mp3
servername       NetBSD
runas            mtdaapd
playlist         /usr/pkg/etc/mt-daapd.playlist
#password        mp3
extensions       .mp3,.m4a,.m4p
#logfile         /var/log/mt-daapd.log
#rescan_interval 300
# always_scan    0
# process_m3u    0
# scan_type      0
# compress       0

Finally, either start both howl and mt-daapd, or reboot:

# /etc/rc.d/howl start
# /etc/rc.d/mt-daapd start

To test whether mt-daapd is working you can run the following command as root under Mac OS X:

# mDNS -B _daap._tcp

or the following command on Linux:

# mDNSBrowse _daap._tcp

Now that KQEMU has switched to the GPL v2 license, I’m starting to get interested on it.

One problem with KQEMU is that modprobing the kernel module, kqemu.ko, doesn’t automatically create /dev/kqemu unless the proper udev rules are defined.

A cannonical udev rule file to get /dev/kqemu created automatically when kqemu.ko is loaded is:

# cat /etc/udev/rules.d/60-kqemu.rules
KERNEL=="kqemu", NAME="%k", MODE="0666"'

Creating this file will tell udev to automatically create the corresponding special device file with permissions 0666 and owner root.root, but this can be easily changed to specify a different user group so that only a limited number of users, members of that group, can access KQEMU.

Xen is one of the coolest pieces of software I have ever used. It allows me to partition my box into manageable pieces, for increased security and increased resource utilization. I have been playing extensively with Xen for more than a year and have also written some posts about it.

NetBSD is a lean, mean, fast free, open source operating system and is nicely supported under Xen, has nice features like the PF packet filter and the pkgsrc ports-like collection and runs in nearly every single hardware architecture on earth. Because of this, I decided to run NetBSD 3.1 on Xen. NetBSD can run either as the privileged domain (called dom0) or as an unprivileged guest (called domU) domain. Since I was already running Linux under Xen as a domU, I am mostly interested in running NetBSD 3.1 as a domU guest on Xen. dom0 can be either Red Hat Enterprise Linux 5.0 or Fedora Core 6, but feel free to use any other Linux distribution as most of them are Xen-ready.

As far as I know, there are some restrictions between the Xen hypervisor + dom0 kernel and domU kernel:

• You cannot mix PAE-enabled and non-PAE kernels.

  For example, you cannot run a PAE-enabled dom0 kernel and/or PAE-enabled hypervisor and a non-PAE dom0/domU kernel.

  This is currently a problem since Fedora Core 6 and Red Hat Enterprise Linux 5.0 both ship with a PAE-enabled Xen hypervisor and Xen-enabled kernels, but NetBSD does not currently ship a PAE-compatible, Xen-enabled kernel.

• You cannot mix 64-bit and 32-bit kernels.

  You cannot run a 64-bit Xen hypervisor and 64-bit dom0 kernel and a 32-bit domU kernel.

Since both Fedora Core 6 and Red Hat Enterprise Linux 5.0 ship by default with a PAE-enabled (36-bit addressable memory space) Xen hypervisor and dom0 Xen-enabled Linux kernel, the first thing that I had to do in order to run NetBSD 3.1 as domU under Xen was to recompile the Linux kernel and the Xen hypervisor with PAE support completely disabled. This is described next.

Build Xen hypervisor and dom0 kernel without PAE

You can skip to the next section if you already have a non-PAE, working Xen installation.

The first thing I had to do is to downl the SRPM (source RPM) for the latest Linux kernel, for example kernel-2.6.19-1.2895.fc6.src.rpm, then install it by running:

# rpm -i kernel-2.6.19-1.2895.fc6.src.rpm

In file /usr/src/redhat/SPECS/kernel-2.6.spec replace the following:

%ifarch i686
%define buildpae 1
# we build always xen HV with pae
%define xen_flags verbose=y crash_debug=y pae=y
%endif

with:

%ifarch i686
%define buildpae 0
# we build always xen HV with pae
%define xen_flags verbose=y crash_debug=y
%endif

This will cause the Xen hypervisor to be built without PAE support. Additionally, no PAE-enabled extra kernels will be built. The Xen kernel, however, uses its specific configuration file that has to be changed in order to disable PAE support. To disable PAE support for the Xen kernel, I reconfigured the kernel with no PAE support by running:

# rpmbuild -bp /usr/src/redhat/SPECS/kernel-2.6.spec
# cd /usr/src/redhat/BUILD/kernel-2.6.19/linux-2.6.19.i386
# cp configs/kernel-2.6.19-i686-xen.config .config
# make menuconfig

Make sure PAE is disabled by navigating to Processor type and features, then High Memory Support is set to either off or 4GB (but not 64GB).

Next, I copied the updated configuration file back to /usr/src/redhat/SOURCES, where it belongs. Also, we need to insert # i386 at the beginning of the file so that the RPM build process can derive the exact processor architecture from the config file when building the RPMs:

# cat <(echo "# i386") .config > ../../../SOURCES/kernel-2.6.19-i686-xen.config

The processor architecture is supplied to make during the build process in the form of ARCH=i386.

Now, let’s build the RPMs:

# rpmbuild -ba --target i686 ../../../SPECS/kernel-2.6.spec

We need to specify i686 as the target architecture since Fedora and Red Hat don’t use i386 anymore for kernels themselves — i386 is now only used for some common RPMs like kernel-headers.

Once the RPMs have been built, check the files under /usr/src/redhat/RPMS/i686. At least there should be a file called kernel-xen-2.6.19-1.2895.i686.rpm. This RPM contains several files, but the ones that we are interested in are:

• /boot/config-2.6.19-1.2895xen

  Contains the kernel configuration. Make sure either CONFIG_X86_PAE is set to n or is undefined.

• /boot/vmlinuz-2.6.19-1.2895xen

  The Linux Xen-enabled kernel.

• /boot/xen.gz-2.6.19-1.2895

  The Xen hypervisor. In the most recent versions of Fedora Core and Red Hat Enterprise Linux, the Xen hypervisor and the Xen-enabled kernel are packaged in the same RPM. This is the right thing to do since both are tightly coupled.

Install the new Xen kernel and hypervisor:

# rpm -ivh --force /usr/src/redhat/RPMS/i686/kernel-xen-2.6.19-1.2895.i686.rpm

Reboot:

# reboot

I assume the system will boot correctly and into the new Xen hypervisor and Xen-enabled Linux kernel. You can check that by running:

# uname -a
Linux xen 2.6.19-1.2895xen #1 SMP Sat Feb 3 16:56:34 CET 2007 i686 i686 i386 GNU/Linux

The next step is installing NetBSD 3.1 as a domU. This is covered next.

Installing NetBSD 3.1

The first step is preparing the Xen’s domU configuration file and its corresponding storage backend. Xen can use file-backed storage for a domU or block-backed storage (i.e. a disk partition or logical volume). Typically, block-backed storage is faster than file-backed storage, so I set up a 10GiB logical volume for NetBSD:

# lvcreate -n netbsd xen -L 10G

I also used NetBSD’s Internet-based installation since it’s the easiest way to get a working NetBSD installation and the NetBSD community have built Xen-enabled NetBSD kernels:

• netbsd-INSTALL_XEN3_DOMU

  A Xen-based, domU kernel used to install NetBSD.

• netbsd-XEN3_DOMU

  A Xen-based, domU kernel used to run the installed system.

Both files can be downloaded from /pub/NetBSD/NetBSD-3.1/i386/binary/kernel. Download and uncompress both of them:

# wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-3.1/i386/binary/kernel/netbsd-*XEN3_DOMU.gz
# zcat netbsd-INSTALL_XEN3_DOMU.gz > /boot/netbsd-INSTALL_XEN3_DOMU
# zcat netbsd-XEN3_DOMU.gz > /boot/netbsd-XEN3_DOMU

If you are running SELinux, you will need to relabel these files properly or xm will be unable to load them into memory:

# chcon root system_u:object_r:boot_t /boot/netbsd*

Next, create the Xen configuration file for NetBSD. In my case, it looked like this:

# cat /etc/xen/auto/netbsd
kernel = "/boot/netbsd-INSTALL_XEN3_DOMU"
memory = 256
name = "netbsd"
vif = [ 'mac=00:16:3e:00:00:11, bridge=xenbr0' ]
disk = [ 'phy:/dev/xen/netbsd,hda,w' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Now, we will install NetBSD by starting the domain:

# xm create -c /etc/xen/auto/netbsd

This will start the new domain and will attach to its console. You can follow the Example Installation NetBSD document to assist you in installing NetBSD and also Xensource NetBSDdomU Wiki page.

Once the installer has finished, do not reboot. At the end of the installation process, you’ll be brought back to the main install screen. Select e: Utility menu, then a: Run /bin/sh, then type the following at the shell:

mount /dev/xbd0a /mnt
cp -pR /dev/rxbd* /mnt/dev
cp -pR /dev/xbd* /mnt/dev
halt -p

This will copy the required special device files and shut down the guest. Now, you will have to modify the domain config file in order to use the standard NetBSD domU kernel, /boot/netbsd-XEN3_DOMU. Edit /etc/xen/auto/netbsd and replace:

kernel = "/boot/netbsd-INSTALL_XEN3_DOMU"

with:

kernel = "/boot/netbsd-XEN3_DOMU"

And boot the domain again:

# xm create -c /etc/xen/auto/netbsd

During boot, you will see some errors like:


wsconscfg: /dev/ttyEcfg: Device not configured


This is due to the NetBSD guest only having access to one physical console. To kill those errors, edit /etc/ttys from within the NetBSD guest and turn off all terminals except "console", like:

console "/usr/libexec/getty Pc"         vt100   on  secure
ttyE0   "/usr/libexec/getty Pc"         vt220   off secure
ttyE1   "/usr/libexec/getty Pc"         vt220   off secure
ttyE2   "/usr/libexec/getty Pc"         vt220   off secure
ttyE3   "/usr/libexec/getty Pc"         vt220   off secure
...

Also, comment out all screens in /etc/wscons.conf:

#screen 0       -       vt100
#screen 1       -       vt100
#screen 2       -       vt100
#screen 3       -       vt100
#screen 4       -       -
#screen 4       80x25bf vt100

That’s all. Now we have a fully functional NetBSD 3.1 domU guest running on Xen

References

The information and instructions on this post are based on:

1. NetBSDdomU — How to install NetBSD as a domU on a Linux host.
2. Example Installation — NetBSD example installation.

I have always though that ssh-agent has some limitations. One of those limitations is that when invoked from .bashrc or .zshrc in the following way:

`eval ssh-agent`

will cause one ssh-agent instance to be spawned for every shell, which is a waste of resources. An easy solution is to use Keychain, which is also described here.

Basically, Keychain is a wrapper for ssh-agent. Keychain will start a ssh-agent and tell it to load one or several private keys. Additionally, Keychain will create two shell scripts into ${HOME}/.keychains named ${HOST}-sh (for SH-compatible shells) and ${HOST}-csh (for CSH-compatible shells) that can be sourced, for example, from within .bashrc, .zshrc or .cshrc, in order to set up the environment variables required for ssh-agent to be usable by other tools like ssh.

A typical ${HOME}/.keychains/${HOST}-sh file looks like this:

SSH_AUTH_SOCK=/tmp/ssh-AIVkg1MfHH/agent.942; export SSH_AUTH_SOCK;
SSH_AGENT_PID=943; export SSH_AGENT_PID;

Adding the following lines at the end of .bashrc or .zshrc will get Keychain invoked automatically by the shell:

### KEYCHAIN ###
/opt/local/bin/keychain ~/.ssh/id_dsa
source ~/.keychain/${HOST}-sh

Keychain will search for an existing ssh-agent process. If no existing ssh-agent process exists, Keychain will spawn one telling it to load one or several private keys (passed as parameters to Keychain). Next, Keychain will update ${HOME}/.keychain/${HOST}-sh and ${HOME}/.keychain/${HOST}-csh to set up the proper environment variables and their corresponding values.

Kudos to Daniel Robbins — the original author — and Aron Griffis — the current Gentoo mantainer. This neat piece of software is extremely useful to me and I use it every day