Double Tall Iced Mocha, Lite on the Chocolate

So I occasionally post some food related things. I think this weekend has inspired me to do some more. I was honored through a string of coincidences have my house be a stop on the 2006 West Coast FoodHacking tour.I was introduced to Marc via a good friend. After discussing the possibility of Hack Lab this weekend, discovering Marc’s recent espresso deviriginization and newfound coffee lust it was on.

Marc mentioned he had just read one of David Schomer’s books and itchin to work on some coffee hacks among other things. Luckily I was able to round up some coffee geeks friends, including Chris the roaster from Zoka and Jacob from La Marzocco. Everything said and done I think we had ten participants over the course of the day. It was a kick ass time, everyone consumed waaaay too much espresso, I learned a ton although its just the tip of the iceberg concerning Molecular Gastronomy. Mucho props to everyone involved for sharing their food, gear, humor and knowledge.

I will go lite on the details here as I imagine the diligently kept notebook of Marc and Jules will be transcribed to the wiki shortly. Here are a few highlights from memory, although this does not nearly cover everything that was done:

• Omlete Hacks:
• Instruction on preperation of an omlete Frances style
• Making omlette’s with eggs that have been soaked or rubbed with ingredients including vodka and chocolate
• Poaching an egg yolk inside a cooked omlete. When the omlete is cracked open it oozes like an egg over easy… Yum
• Rosetta Hacks:
• Cream and Sassafras mixture for pouring Rosetta
• Preparation of a tomato cream to use in place of Milk for rosetta design
• Salmon Smoking:
• Salmon smoked w/Alder wood soaked in Arak Haddad, a liquor made from grape and anise
• Salmon smoked w/Alder wood and green (unroasted) ethiopian coffee
• Salmon smoked w/Alder wood and green Sumatra beans that were vacum infused with essential oils
• Cuban shots
• A portafilter of ground espresso roast coated with ground glucose and/or sucrose and pulled as a shot
• Coffee Roasting
• Roasting of columbian, sumatran, and ethiopian coffee beans in a columbian ball roaster over open fire
• Roasting of ethiopian coffee beans with essential oils
• Education of the cupping (tasting) method employed by coffee roasters/purchasers
• Cupping of all the different coffees roasted at the hacklab

There are some questions being asked about the Google wifi project in Mountain View, CA. It appears that the real world performance is not acceptable from some user complaints and the network appears to buckle under pressure! Imagine that, a wireless network buckling under pressure!

The wireless portion of the network is powered by Tropos, a “mesh” wireless vendor. Tropos has responded.

We know that wifi was not designed with these deployments in mind, however its “what we got” and its in everyone’s laptops. Alot of these problems could be caused by the standard issues with wifi deployment such as interference from other Part 15 devices and attenuation caused by physical obstacles such as houses and their pesky walls or roofs.

At the Community Wireless Summit I watched an informative presentation by Jeffery King of Northrup Grumman describing the Corpus Christi Tropos deployment.

My one question at the end of the presentation was something like this “Did your due dillegence cover assesing the risk of going with a propreitary solution and the vendor lock in that happens?”. Most people don’t think of something like Tropos as being proprietary because it talks 802.11 to the end user. But all of the backend/backhaul mesh is proprietary, its what makes them in Jeffery’s words “infinitely scalable”. The problem being that extending the mesh requires buying tropos equipment because they do not use an open standardized routing protocol. Jeff’s answer was an honest “I don’t know if that was investigated”.

So now my question is why is the google project Tropos powered? There are open source mesh solutions that could really benefit from an injection of cash to move development forward. In addition these technologies need large scale deployments to help move them forward and make them better. This seems like it would be right up googles alley. Additionally deploying an open source mesh network would also mean that it would be possible for the users to extend the network themselves in MANET fashion.

You could say that my opinion is such because I am an owner of a company that sells wireless gear based on Open Source software. However I think we have already learned of the Internet that prorietary protocols in infrastructure devices does not go very far. I think this particular issue gets overlooked as a result of people assumming the network is standards based because its 802.11a/b/g. Most commercial mesh implementations are proprietary ,Google is in a position where they could help out the Open Source mesh networking world and change that. It’s not too late.

So we are at hacknight messing with some old Arlan 630 900mhz wireless access points we got off ebay. Our goal is to upgrade them to the “bridging” firmware so the devices can talk to each other and not just client cards.
On a side note the boxes were bought off ebay. The access points came with a configuration already on them:

ARLAN 630 V4.2C Configuration Ident Menu da521ap2
Option Value Description
1 - Name [ “da521ap2″ ] - Node name
2 - Nid [ 00409610b998 ] - Network address
3 - Inaddr [ 030.117.028.034 ] - Internet address
4 - Inmask [ 255.255.255.000 ] - Internet subnet mask
5 - Ingateway [ 030.117.028.001 ] - Internet default gateway
6 - Location [ “” ] - SNMP system location
7 - Contact [ “” ] - SNMP system contact name
Enter an option number or name, “=” main menu, previous menu
>
Hmm 30.117.28.34…

ken@averacrap> whois 30.117.028.034

OrgName: DoD Network Information Center
OrgID: DNIC
Address: 3990 E. Broad Street
City: Columbus
StateProv: OH
PostalCode: 43218
Country: US

NetRange: 30.0.0.0 - 30.255.255.255
CIDR: 30.0.0.0/8
NetName: ARPAX25-TEMP
NetHandle: NET-30-0-0-0-1
Parent:
NetType: Direct Allocation
Comment: Defense Information Systems Agency
Comment: Washington, DC 20305-2000 US
RegDate:
Updated: 2002-10-07

OrgTechHandle: MIL-HSTMST-ARIN
OrgTechName: Network DoD
OrgTechPhone: +1-800-365-3642
OrgTechEmail: HOSTMASTER@nic.mil
Poke a little deeper in the configuration…

ARLAN 630 V4.2C SNMP Communities da521ap2
public - Read Only, Any NMS IP address, Any NMS NID
proxy - Read Only, Any NMS IP address, Any NMS NID
private - Read Only, Any NMS IP address, Any NMS NID
regional - Read Only, Any NMS IP address, Any NMS NID
core - Read Only, Any NMS IP address, Any NMS NID
barney - Read-Write, Any NMS IP address, Any NMS NID
Enter space to redisplay, q[uit] :
barney, cute.

Last ShmooCon we started the Hacker Arcade. This dude Ethan brought down a skill crane that was hooked up to a pc and available to control over the local wireless network and the Internet. Someone ended up winning most of the skill crane prizes by writting an automated script to hit every spot, it kicked ass, it was huge, it was awesome how much effort went in to whole thing. Anyways its back online now.

So I am probably the last person to post something about Field Day 2006 but eh, better late then never. The main idea behind field day is to rapidly deploy a wireless network at various points in the city and do so without relying the grid for communication or power. We do it mostly for a reason to geek out, but being able to this in a state of emergency would be very usefull.

There were three physical sites that participated:

• Magnolia Park
• Alki Beach
• Elliot Bay

All sites were powered via battery. At Alki we have a deep cycle battery that powered our wireless node and 5 or so laptops for the entire day. We arrived at the site around 11am and had the tent, power and network up and running by 12:30.

Probably the most interesting part of the day was playing with OLSR in this situation. Most nodes were Soekris based Metrix boxes running Pyramid Linux. We used OLSR to handle routing for the network. OLSR is the “Optimized Link State Routing” protocol it is a link state routing protocol that is intended for use in MANETs (mobile ad-hoc networks) also commonly referred to as “mesh” networks. It advertised all the host routes for individual nodes running OLSR and provided HNA for subnets that contained hosts not running OLSR. In addition it also provided HNA for networks that Internet gateways. HNA stands for Host and Network Association messages, which are basically routing advertisements for non-mesh nodes.

One major technical issue we spent a lot of time trouble shooting was the Elliot bay node. It was primarly connected via a 802.11 client bridge device. This device had at least one machine behind it. The problem was quite confusing we could ping a node behind the client bridge no problem, we recieved routing information from it, however when we attempted to route packets through the node behind the client bridge they were silently dropped. We verified via packet traces that they left one radio interface however they never reached the machine behind the client bridge. This was because packets being routed through the client bridge had a destination address of a host the client bridge did not know about. Since 802.11 has no specification for bridging in client (STA) or ad-hoc mode, client bridges get around this by using proxy arp and since it knows nothing about the destination address in the packet to be routed it does pass it. A work around was to set the mac address of the bridge to match the mac address of the host behind it running OLSR. I am still not sure why this worked, but have not had the time to think it through.

Other field day posts:

• Brian
• Casey
• Eric
• Matt
• Dan

I have been using Isimoin for a couple of weeks now and am quite happy with it. It does a couple of things:

• makes it really simple to setup some stand alone MoinMoin instances on your desktop without having to configure a web server
• allows you create a “slave” copy of wiki you have hosted somewhere else, assuming you have an account that allows you to rsync the MoinMoin filesystem

create-farm)
create_farm
;;

create-instance)
name=”$1″
create_standalone_instance “$name”
;;

create-slave)
name=”$1″
master=”$2″
create_slave “$name” “$master”
;;

synchronize-slave)
name=”$1″
synchronize_slave “$name”
;;

run-instance)
name=”$1″
run_standalone_instance “$name”
;;

I would like to add another function that assumes your local desktop wiki is the Master and the remote is a slave. Since I keep my primary personal MoinMoin instance on my laptop but like to back it up to a remote MoinMoin farm I have so I can access it from any computer if I need to. It would basically be reversing the synchronize-slave function. This is mainly because I cannot always guarantee that my laptop will be available via ssh for the rsync due to NAT/Firewall situations.

It would be cool to a simple tool like this that can use MoinMoin RPC Syncronization.