CUWiN Homer Mesh Project
The CUWiN folks spent some time recently adding new equipment to the Homer mesh network. My company Metrix has provided them with all the gear for this project to provide the Village of Homer with a low cost tubes.
The CUWiN folks spent some time recently adding new equipment to the Homer mesh network. My company Metrix has provided them with all the gear for this project to provide the Village of Homer with a low cost tubes.
While at WWDC John and Daniel turned me on to EaKiu. Its a cool piece of software for the Wi-Spy 2.4Ghz USB Spectrum Analyzer. It touts some pretty cool 3D graphs. Unfortunately its OS X only. For Windows you can use manufacturer provided software, and for Linux you can use Dragorn’s software. Which both sport cool and helpful graphs, just not the same 3D eye candy.
At work we just carrying this cool new device, an access point that fits in a wall box. Looks like it would be great for outfitting apartment buildings and/or condos with wifi coverage. It supports all the usual AP/Bridging/WDS, POE, SSL web management etc… Even supports remote syslog and SNMP.

I mentioned in this email a little while back that I released a new Pyramid LiveCD Installer with the 1.0b5 version of Pyarmid. This CD provides a simple method for boot strapping a Soekris net45XX/net48XX single board computer.
Some models accept normal compact flash cards for the operating system media in which case you could easily install an OS image using another machine and compact flash card reader. However some of the models have soldered on flash and on these systems the PXE boot strap method is the only way to install on the board.
Setting up a “PXE boot” environment can be a little cumbersome if you have never done it before. With the LiveCD everything down to the IP address is configured out of the box so you should be ready to flash images onto boards in 5 minutes or so just by following the simple instructions.
Decided to try and get a friend’s u730 cellular data card working in Pyramid Linux last night. I thought it would pretty trivial since the card appears to use the same chipset as other EVDO/HSPDA cards already supported in the airprime module. But it turns out the device/vendor id combo is not in airprime. This simple patch should fix it for you.
This patch adds vendor/device id combination for the Novatel Merlin u730 hspda
card. Tested with a cingluar branded card.
Signed-off-by: Ken Caruso ken@ipl31.net
diff –git a/drivers/usb/serial/airprime.c b/drivers/usb/serial/airprime.c
index f2ca76a..00fa8b2 100644
— a/drivers/usb/serial/airprime.c
+++ b/drivers/usb/serial/airprime.c
@@ -24,6 +24,8 @@ static struct usb_device_id id_table []
{ USB_DEVICE(0×1410, 0×1430) }, /* Novatel Merlin XU870 HSDPA/3G */
{ USB_DEVICE(0×1410, 0×1100) }, /* ExpressCard34 Qualcomm 3G CDMA */
{ USB_DEVICE(0×413c, 0×8115) }, /* Dell Wireless HSDPA 5500 */
+ { USB_DEVICE(0×1410, 0×1400) }, /* Novatel Merlin U730 HSDPA/3G */
+
{ },
};
MODULE_DEVICE_TABLE(usb, id_table);
Just sent this email to the Pyramid Linux mailing list. Make a long story short there is a new image of Pyramid available. As well as a live CD that can PXE bootstrap and install the following Operating Systems on Soekris (and potentially other) hardware:
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.
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:
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:
Myself and Matt will be doing a workshop at Toorcon 8. It will be a one day workshop covering the basics of boot strapping an embedded wireless device ( Soekris based ) and setting up a wireless mesh using OLSR. Participants in the class get an embedded wireless device from my company Metrix that they take home with them in addition to learning the skills required to continue hacking on it. Pre-registration ends this Friday and is currently $1200, after Friday it will be $1500 at the door any open seats will likely sell out fast. There are currently 5 seats left. If you have a group of people (3-5) interested, we might able to get you group discount ( email me: ken at ipl31 net ). But you need to act before Friday midnight!