For those who don’t know, I was a hardcore Symbian user for years, mostly S60 devices, though I had a fleeting stint using a Nokia 9300 (my only S80 device ever).  That’s what you get when you spend the better part of 10 years working at Nokia.  Nokia has historically done a very good job of producing smartphones – it’s been their bread & butter for years.  I had a brief stint using an N97, followed by a loaner of an N97 Mini from the Womworld guys, and I was never wowed, heck, never even liked S60 v5.  For me, the last great S60 was v3.  FP1 or FP2 were both good to me.  Heck, I still have an N85 that I use for my home line.

These days, it seems like everyone’s in iLove, going absolutely gaga over the iPhone, including the latest incarnation – the iPhone 4.  Deathgrip aside, I was never a huge fan of the iPhone.  I had a 3G for a day, and returned it.  Bad battery life (like in the 3-4 hour range), and the walled garden – don’t get me started about locking out developers – I maintain that it’s bad for business in the long run.

I got my Nexus One in the AT&T variant, so it’s got quad-band GSM/EDGE and tri-band (850/1900/2100) UMTS/HSDPA support, as well as the 802.11g WLAN, Bluetooth and GPS radios.  That’s a lot of RF in a small case.  Physically speaking, the Nexus One feels great in your hand.  There’s some sort of coating on the metal parts that’s just slightly tacky, not metallic at all.  It just feels great in your hands.  The RF performance on the Nexus One is very good in my experience.  I don’t notice any lower coverage than I saw with my prior Nokia E72.  All in all, very good.

Connectivity is where Android 2.2 really shines.  On my Nexus One, I’ve got my home Google Apps account sync’d, as well as my corporate Exchange ActiveSync.  The phone keeps track of where the different bits of data came from and only tries to sync the appropriate data to the various accounts.  It’s very well thought out and I didn’t wind up with lots of data duplication.  Further, Android 2.2 implements the much sought-after mobile hotspot feature.  If you’re unfamiliar, you use your WLAN radio to setup an Access Point, then connect WLAN devices to that AP, which shares your phone’s 3G (or even EDGE) wireless data connection.  Pretty slick.

On the ActiveSync front, the client is very good, and fairly complete, though a couple of what I consider to be key features aren’t there yet.

Rather than the App Store, Android uses the Android Market.  Same idea, essentially, though it seems that you need to do substantially less hoop-jumping to get your app in the Market.  While yes, Apple definitely has a wide margin of available apps, I’ve yet to be disappointed when I got searching for an Android app for a specific task.  This review focuses on the device itself, not the apps, so I’m not going to go too deep there, but suffice it to say that I’m happy with the app selection.

Overall, it’s a great device, and the future for Android is indeed bright.  Go make the jump, you won’t be disappointed.

Our firewall is a Juniper Networks SRX210, which lends itself very well to this task, as it supports ethernet switching natively.  First up was creating a couple of VLANs & RVIs on the firewall and assigning them to security zones.  These RVIs will need to have dhcp allowed on their as an inbound system service.  Next, some security policies will need to be created to allow devices in the new zones to talk out to the untrust (i.e. Internet) zone.  Next, you’ll need to configure a VLAN trunk on the port connected to the wireless AP (fe-0/0/6 in our example).  Finally, you’ll need to setup DHCP helpers for each of the RVIs to direct their DHCP requests to your DHCP server.  If you use the SRX as your DHCP server, you would instead configure a DHCP scope for these networks.  Here’s an example of what that might look like:

set vlans vlan2 vlan-id 2
set vlans vlan2 l3-interface vlan.2
set vlans vlan3 vlan-id 3
set vlans vlan3 l3-interface vlan.3

set int fe-0/0/6.0 family ethernet-switching port-mode trunk
set int fe-0/0/6.0 family ethernet-switching vlan members [ vlan2 vlan3 ]
set int vlan.2 family inet addr 192.168.2.1/24
set int vlan.3 family inet addr 192.168.3.1/24

set forwarding-options helpers bootp interface vlan.2 server 192.168.1.20
set forwarding-options helpers bootp interface vlan.3 server 192.168.1.20

set security zones security-zone guest interfaces vlan.2 host-inbound-traffic system-services dhcp
set security zones security-zone guest interfaces vlan.2 host-inbound-traffic system-services ping

set security zones security-zone dsnet interfaces vlan.3 host-inbound-traffic system-services dhcp
set security zones security-zone dsnet interfaces vlan.3 host-inbound-traffic system-services ping

But that’s only half of the battle.  We still need to setup the AP.  In our example, I used a Fonera Fon 2100.  Instructions for how to reflash it with OpenWRT can be found on their wiki.  Once you’ve got that together, you’ll need to make some mods to their stock network configuration to make it work, but it’s not so bad.  Essentially, you’ll make 2 SSIDs, and bind them to 2 VLAN-tagged sub-ints of eth0, forming 2 bridge groups.  In OpenWRT, when you create an interface of the form eth0.X, where X is in the range 1-4094, you’ve just created a tagged sub-int.

/etc/config/network:

config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'

config 'interface' 'guest'
option 'ifname' 'eth0.2'
option 'type' 'bridge'
option 'proto' 'static'
option 'netmask' '255.255.255.0'
option 'ipaddr' '192.168.2.2'
option 'defaultroute' '0'
option 'peerdns' '0'
option 'stp' '1'

config 'interface' 'dsnet'
option 'ifname' 'eth0.3'
option 'type' 'bridge'
option 'proto' 'static'
option 'netmask' '255.255.255.0'
option 'ipaddr' '192.168.3.2'
option 'stp' '1'
option 'defaultroute' '0'
option 'peerdns' '0'


/etc/config/wireless:

config 'wifi-device' 'wifi0'
option 'type' 'atheros'
option 'channel' 'auto'
option 'disabled' '0'
option 'diversity' '0'

config 'wifi-iface'
option 'device' 'wifi0'
option 'mode' 'ap'
option 'ssid' 'dsnet'
option 'encryption' 'wep'
option 'key' 's:myWEPkey12345'
option 'macpolicy' 'allow'
list 'maclist' 'e8:4e:ce:xx:yy:zz'
option 'network' 'dsnet'

config 'wifi-iface'
option 'device' 'wifi0'
option 'ssid' 'notyourhouse'
option 'network' 'guest'
option 'mode' 'ap'
option 'encryption' 'psk2'
option 'key' 'guestWPAkey'

Now you’ve got both SSIDs up, each bound to a different VLAN, and can enforce different security policies on each!

IDS Install with Tap

I wanted to install a small network ids on my home network using Snort.  I wanted to stick the nids outside of my firewall, so it would be able to examine all Internet traffic coming in & out of the network.  Of course, putting a device online outside my firewall without any protection isn’t terribly attractive, so I decided to install using a tap.  Ignoring the fact that this is really the only possible configuration, given my home ISP (FiOS), it allows me to do a completely stealthed deployment of a nids.  Unfortunately, this type of deployment also precludes the ability to interact with any traffic seen on the wire, so flexresp is out of the question.

Construction of a passive tap

The other bad part about using a tap is that simply by the nature of the tap, you need to have 2 Ethernet ports to sniff on.  Why?  Check out the Snort docs on the subject.  When you setup a tap, you can only push one direction’s worth of traffic onto a single port.  This means you have to combine the traffic on the sniffing device.  Since you can only receive traffic and can’t send on these ports, you must have a third Ethernet port to connect to your internal network, or if you’ve got a larger network, a management LAN.

So, building your tap is pretty simple, when you’ve got the picture here on the right to work from.  Need the parts?  Head over to Home Depot and grab yourself the following parts:

1. A plastic electric box (get one marked for “Old Work”).  An 8 cubic inch box will probably not be deep enough, so go for the one of the 14 cubic inch ones.  Unscrew the little anchor flaps and toss them in the trash.
2. A 4-jack faceplate.  Whatever color you like.  I used white.
3. 4 Cat 5e Ethernet jacks.  I got 2 white and 2 blue.  The white jacks are the Host jacks, and the blue ones are Tap A & B, as shown in the figure at the right.
4. About 6 inches of Ethernet cable.

Strip off the jacket and remove the 8 wires.  Wire up the jacks as shown in the figure.  I found it easiest to wire up one of the host jacks, then run the wires through the tap jacks and finally up to the other host jack.  Try to keep the twists in the wire as much as possible, to prevent NEXT (Near End Crosstalk).  Cap off the jacks and screw the thing into the electric box.

I made two, one to use for the NIDS, and another to carry around for work if I need a tap.

I’m not going to go into how to install Snort, ACID, or any of that stuff.  There are already enough guides out there on that topic.  I will, however, address the need to join the two sniffing interfaces into a single full-duplex interface for Snort to sniff on.  You’ll be using the Linux kernel’s bonding module for this.  I’m going to assume Debian or Ubuntu here.  Add the bonding module to your /etc/modules file, then execute the command modprobe bonding.  In the /etc/network/interfaces file, you’ll need something like this:

auto bond0
iface bond0 inet manual
  up ifconfig $IFACE 0.0.0.0 up
  down ifconfig $IFACE down
  post-up ifenslave bond0 eth0 eth1
  pre-down ifenslave -d bond0 eth0 eth1

Obviously, you’ll need to configure Snort to sniff on the bond0 interface.  Don’t forget to install the ifenslave package.  It’s not installed by default on Ubuntu.

The biggest concern lots of tap novices have is accidentally introducing traffic onto the wire via the tap.  Let’s be clear.  This is simply impossible.  Can’t happen.  At all.  Why?  The only pins that are live on the tap ports are 3 and 6.  Guess what happens on those pins?  It’s only RX, not TX, so you can’t transmit on the tap ports.

I am a PC!

I’m reformatting our Macs at home, and they will henceforth run nothing but Windows Vista.  Ultimate 64-bit, of course.  No Boot Camp, VMware Fusion or Parallels.  Just Windows Vista.  The sheer beauty of the Vista desktop, laden with all of those oh-so-cool gadgets, the Aero Glass look, and the Control Panel, oh, the sheer bliss of it all!  So what if I’ll need to run full-time anti-virus and anti-spyware apps to protect us and our data?  Honey, I’m home.

And the server, what a colossal mistake it was running Ubuntu’s Intrepid Ibex 64-bit release on there.  What on earth was I thinking???  All of that idle CPU time just going to waste doing nothing.  Why, by installing Windows Server 2008 on the system, I can give that CPU an actual workout.  You know what they say about muscles that go unused..  I figure the same thing applies to the CPU’s power starting to atrophy from lack of use.  So what if I run my phone system out of Asterisk, and have a VPN server that runs in a VMware Server instance?  Again, I’ll have the blissful joy of Windows at my disposal.

And the phones.  We’ve suffered for too many years with S60 devices.  Back when I worked at Nokia, I didn’t have an excuse, but now I can finally break free after all these years!  By moving to Windows Mobile devices, I can now take the nirvana that one can only experience with that stunningly gorgeous Blue Screen of Death out and about with me, right in my pocket.  That BSOD is so invigorating, I think we should change it to the BSOL, Blue Screen of Life!

˙looɟ lıɹdɐ  ¡ʇɥƃıɹ ɥɐǝʎ

The installer is largely unchanged from Hardy Heron, 8.04.  One new & welcome change is the newly integrated support for installation to dmraid devices.  These devices are largely SATA RAID controllers, such as the Intel Matrix controllers, largely software-driven.  I preferred this to the Linux RAID code, since replacing a drive/rebuilding a mirror seems more straight-forward this way.  As my server includes an Intel Matrix controller onboard, I went for this option.  It worked very well.  The device names are a bit long (/dev/mapper/isw_diaedigfhd_Volume03), but that’s fine.  I did a pretty basic layout, with 250MB of ext3 for /boot, a 4GB swap partition and the rest as JFS for /.

Also new in Intrepid is DKMS.  What’s that, you say?  Your lucky day, I say.  At least, if you use software that requires special kernel modules.  Back in the good old days, when you did something like that, every time you upgraded your kernel, you had to rebuild your custom kernel modules as well, a largely manual process.  DKMS takes the manual part out of the picture here.  You install a DKMS package, and when you update a kernel, the drivers from you DKMS packages are automagically built and installed.  I’m excited about the possibility of vmware module and DAHDI (the new name for zaptel) DKMS packages!

I’ve already installed VMware Server 2.0, which went well, aside from a bit of trouble compiling the vsock module.  I suspect this will get worked out before too long as well..

Intrepid Ibex, it’s worth the trip.  If you’re  looking to update an existing server, change your sources.list and dist-upgrade away.

So far, it’s pretty smooth.  Adamm’s even got a new kernel spun for Intrepid.  This time, I skipped over using the very good UNetbootin, in favor of connecting a USB DVD drive.  Mind you, my eee 1000 is no longer in a stock configuration, having changed out the wifi card in favor of an Intel Wifi Link 5300, so I don’t have to worry about the rt2860 driver.  That said, someone’s already created a package that uses dkms to install the driver on Intrepid.  For me, the driver is now in the box.  No more downloading snapshots of drivers and building them myself. Yay.

So, what’s working?  Everything.  No, really, at least hardware-wise.  In truth, I didn’t try the microphone, but I’d bet it works, since Adam knocked that one out in a previous kernel release for Hardy.  What’s not working?  Hotkeys.  Newer ACPI drivers, so different interface (no longer under /proc), so scripts && utilities need to be rebuilt/adjusted a bit.  That’s bound to happen over the next few weeks, as this release heads out the door.  I’ve hacked a bit on the scripts I was using for my Hardy install (courtesy of elmurato), and I’ve got CPU scaling and control of the webcam working with the hotkeys.  More to come later on that.

What’s new & cool?

Network Manager 0.7 – Now your 3G devices should work automatically.  At least mine (Pantech UM175) does.

Xorg 7.4 – Hotplug support for pretty much everything you’d want to throw at it.  Most users can run without an xorg.conf with this release.  Speaking as someone who’s spent years hacking away on XF86Config and xorg.conf files, that’s mighty cool.

DKMS – This one’s a monster.  So, you’ve got some kind of special bit of hardware that requires a special driver of some sort.  In Hardy & earlier, you’d have to install new packages for the driver each time, or rebuild it every time you installed a new kernel.  With DKMS, the modules are automagically recompiled for each new kernel version.

GNOME 2.24 – The latest & greatest.

So far, Intrepid’s behaving pretty well for me.  By the time it rolls at the end of the month, it should be pretty solid.  I do wish that the Ubuntu gang would swap out Usplash for Splashy though..  Oh well, I’ll wind up doing that myself in the end, I suppose..

Conventional wisdom calls for (as many others have done previously) an Intel 4965 MiniPCIe card. The 5300 seems to be the successor to the 4965, boasting up to 450 Mbps of 802.11n performance.  Not having any 802.11n APs, I wouldn’t know about that just yet.  We’ll see.  Unfortunately, this card doesn’t have drivers in the mainline Linux kernel until version 2.6.27.  As I’m running Ubuntu Hardy (until Intrepid Ibex rolls out), and on kernel 2.6.24, no drivers exist, outside of the backported ones from compat-wireless guys.  Well, since the drivers exist, I decided to give it a go.

First up, grab the firmware and the drivers package.  Unpack the firmware and drop it in /lib/firmware.  Next, you’ll need to install the “build-essential” package, as well as the linux-headers packages appropriate for your kernel.  Unpack the drivers, check the config.mk file.  You should probably (as I did) uncomment the lines that enable support for the RFKILL code.  This is what gives you the ability to toggle the wifi on & off.  Do a make & make install (as root) to load the drivers up.  It will not overwrite existing mac80211 modules, and that’s a good thing.  Halt your machine and do the card swap.

Installing the card was pretty easy.  Pull the battery and unplug first.  After all, you don’t want to short things out, right? Ok, now remove the two screws that hold down the existing Ralink wifi card and pop the two antenna leads off.  Now install the Intel card and put the screws back.  Connect the white wire to terminal 1, and the black to terminal 2.  Terminal 3 is where you’ll need to connect the extra antenna.  I opted for a small antenna, typically used for a bluetooth radio, but since it’s a 2.4 Ghz antenna, it also works fine here. I snaked the wire through one of the small gaps in the plastic housing adjacent to the wifi card, and used the adhesive backing on the antenna to stick it in the hole where the hard drive goes on a 1000h.  Not sure where you’d want to put the antenna on a 1000h, but then again, that’s not my chief concern, as I’m working on a 1000.  Put back all the screws and you’re done.

Boot the system, and you should be all done.  The card should be automagically detected and have the iwlagn module loaded.  You’ll likely want to gently massage your /etc/acpi/eeepc-wifi-toggle.sh script to work with the proper modules.  Removing the module and echoing a 0 into /proc/acpi/asus/wlan (to power down the card) results in the card going into “deep sleep”.  My last bit is to figure out how to wake it from deep sleep, other than a reboot.

Enter the NetworkManager PPA.  This is the development ground for what’s going to be included in Intrepid Ibex, aka Ubuntu 8.10.  It only takes a few minutes to get it started.

1. Add the PPA repo to /etc/apt/sources.list:

deb http://ppa.launchpad.net/network-manager/ubuntu hardy main
deb-src http://ppa.launchpad.net/network-manager/ubuntu hardy main

2. apt-get update and upgrade the packages, be sure to install the unauthenticated ones.  You may find it easier to do this part with Administration > Update Manager, from the menu.

3. It will probably ask for a reboot when all is done.  Don’t do it yet.  You need to patch one file to make the UM175 work.

4. Open up /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi

At line 175, add a couple of USB ids, specifically 0×3711 and 0×3714, so the line looks like:

<match key=”@info.parent:usb.product_id” int_outof=”0×3701;0×3702;0×3711;0×3714″>

5. Reboot, now you’re nearly done.

6. After login, right click on the Network Manager icon in the notification area.  Edit Connections.  Go to the Mobile Broadband tab, add a new connection.

7. I only filled in a name for the connection, used the following parameters:

• Phone Number: #777
• Username: <phonenumber> @vzw3g.com (use your device’s phone # here)
• Password: vzw
• Check the “System Setting” box.

8. ???

9. Profit!

To connect, plug in the evdo device, click on the NM icon, select your 3G connection.

Just today I traded in my old Verizon Wireless V740 ExpressCard for a shiny new UM175 USB EVDO device.  Sure, both are Rev-A devices, but the new device gives me a bit more flexibility, and is nowhere near as huge as previous USB EVDO devices.  I’ll spare you the shtick on the folding and rotating USB connector, oh wait..  The Windows XP software worked pretty much as you’d expect.  Stay tuned for a similar guide featuring this device with Mac OS X.

Mind you, I only tried doing this on Ubuntu Hardy and the Desktop version at that.  I’m sure it would work much the same on Kubuntu or Xubuntu, but you’d need to use a different application than I used (gnome-ppp).

Before you get started, be sure you’re up to date on updates.  At the time this was written, the current -generic kernel for Hardy Desktop was 2.6.24-19, though I’m sure it will work much the same with other reasonably similar kernel versions.  Also, install gnome-ppp (apt-get install gnome-ppp) before you get rolling.  The last bit of information you’ll need before starting is the phone number of your device.  For the sake of this guide, let’s assume your device’s phone number is 212-555-1212.

Step 1. Plug the device in.  Ok, you’re done Step 1.

Step 2. Launch gnome-ppp, configure settings, other than the defaults:

• Modem Tab
  • Device: /dev/ttyACM0
  • Type: USB Modem
  • Speed: 460800
  • Phone Line: Tone
  • Volume: Off

• Options Tab
  • Minimize: checked
  • Dock in Notification Area: checked

Click Close.  Fill in the fields in the main Gnome PPP window:

• Username: 2125551212@vzw3g.com
• Password: vzw
• Phone Number: #777

Step 3. Click Connect

Step 4. There is no step 4.  You’re connected.

Congratulations, you’re online, EVDO style.

Details on the installation procedure are here..  Relatively simple stuff.  Add a repo, install 4 packages, add 1 to your gnome session, massage panel widgets, done.

It’s really quite a nice setup.  Check it out…