Hello, I am very new to this and should stick with small projects but here is what I want to build. A mobile site (car or boat) transmitting video. Then, that signal being received by the network and available to the users.

It sounds so hard right now but I think the HSMM could do it. I read about all of these crazy networks. What do you think?

Josh

Thanks you for all of your help. I am stumbling through this. I purchased two WRT54G (Version 1.1) and upload the software. It worked.

Now, what do I do with them???

Back to the manuals….

Feel free to help with whatever is next.

Josh

Sorry for the delay. I was TDY to Portsmouth, Va. (Coast Guard stuff) I just got back and read ae5ae's post. He is soooo correct! I was reading the version number from the 192.168.1.1 page. Not the sicker in the bottom of the router. I must have missed that part somewhere but it makes me fell better. I was going crazy with the project.

The Goodwill down the street has about 10 of them sitting on the shelve for 8.00 each, so I will pick up two new ones in the morning.

Thanks again,

Small note -- those version numbers that Josh mentions are LinkSys FIRMWARE version numbers and not the HARDWARE version numbers that we generally go by. The 54G's that Josh obtained may not have sufficient FLASH & RAM to load the regular OpenWRT let alone the HSMM-MESH configuration.

The hardware version for a particular 54G is located on a sticker on the bottom of the unit in the little box that says WRT54G Version.... Only Version 1.0 did NOT have a version listed.

Again, if the hardware version for a 54G or 54GS is 5 or greater then the HSMM-MESH firmware can not be loaded.

Correction, I did not try OpenWRT. Mine are not supported via it.

Well, I have tried so many frimware options that I made myself a little confused.

If you have the time I will write what I have and maybe you can help point me in the right direction.

Two Linksys:

WRT54G v.1.00.9

WRT54GS v.7.2.06

I have tried OpenWRT and DD-WRT. Both did not work. It is must likely my fault, I do not have any IT background. If it was a T/R or radar I would be all over it. (Coast Guard ET1)

Which should I try again and any pointers?

KI4UOE

Good morning,

I ran across the HSMM artices and it got my attention. Now, a few trift stores later I have my WRT56G's and am trying to upgrade the firmware via this site. I have a WRT56G V1.00.9. It should upgrade easily, but it is not. It fails every time. I double check the right software (hsmm-mesh-0.4.0-wrt54g.bin)

If you have tips or know what I am doing wrong, please speak up.

Thanks in advance

Josh

This was first reported using a proven file. Its MD5 value was ce9f3cfcf9a429ac34b9c8131c8dbbe1

The file for 0.4.0 firmware now posted is unchanged from first release (MD5 above) and works with browsers other than Chrome.

From time to time I ponder using 900MHz or 3.4GHz wifi devices for hsmm, and one of the things that gets in the way is the ARRL band plan. On the 900MHz band, some of the available wifi devices use channels that are on fm inputs, ATV, and fm outputs, and basically aren't compatible with the band plan. It finally dawned on my to see how the 2.4GHz wifi devices adhere to the 2.4GHz band plan.

Kip's spreadsheet shows this clearly.

Should I have any misgivings about not adhering to the 2.4GHz band plan? And if so, why not?

While an hsmm-mesh node automatically configures itself to connect to other hsmm-mesh nodes, sometimes you might need to make changes to its configuration using the command line interface. One of the packages that is installed on the node is busybox, which includes a number of tools. One of these tools is an editor called vi.

The vi editor has been around since the early days of UNIX. A short history of the vi editor can be found here: http://www.softpanorama.org/Editors/Vimorama/history.shtml.

Today, there are lots of editors being used on linux, wysiwyg editors, context sensitive editors, extensible editors. Unfortunately, none of those editors are available on the hsmm-mesh nodes (to my knowledge). The problem with fancy editors is that the more features they use, the bigger they are, and the more burdened the CPU becomes.

When I was at UT/Austin, I started off with the emacs editor. It was wonderful. I could write macros in lisp and spend more time playing with emacs than with the program I was supposed to be writing. Alas, as the end of the semester approached, more and more people were online, and the editor became slower and slower. In the end I was forced to use vi just to get my work done.

The vi editor isn't that difficult to use. Unforunately, hsmm-mesh nodes lack the usual online documentation (man pages), so there's no help available for vi. However, there are tutorials available online. Here's one: http://www.eng.hawaii.edu/Tutor/vi.html. As you start to use the vi editor on your mesh node, just remember that the vi editor that comes with busybox has a reduced feature set. Even a small editor like vi has too many features for use on a mesh node.

Elsewhere, others have posted some information on useful items to take into the field. As some SETs are coming up, I thought a reminder would be useful:

• Laptop
  
  • power supply or extra battery
  • wireless nic with pre-installed drivers
  • netstumbler, kismet, other wireless software
• Antennas
  
  • suitable coax
  • N/SMA/TNC/MMCX adapters and pigtails
  • tripod or other mount
• Routers
  
  • power supply or battery
  • POE injectors
  • ethernet cables
  • loginid and passwords
• Other
  
  • sun shield for you (hat, long sleeve shirt, sunscreen)
  • sun shield for the laptop screen
  • GPS and compass
  • table and chair
  • water
  • AC inverter
  • HT, power supply or extra battery, antenna if necessary
  • screwdrivers, pliers, wrenches that any of the above need
  • notepad and pen

While hsmm-mesh for linksys routers is currently based off of 7.09, openWRT has more recent code that provides support for newer models of wifi routers such as the Ubiquiti devices. There are two newer openWRT branches: 8.09 and 10.03.

One of the nice things about 8.09 (particularly when your callsign ends in OSX) is that it can be built on a Mac.

First off, when you first get your mac, the filesystem on it is case-insensitive. Coming from a UNIX background, I've always found this strange, particularly because OS X is UNIX underneath the glitzy user interface. Unfortunately, openWRT builds require a case-sensitive filesystem. There are two ways to resolve this:

• reinstall OS X and select the option for a case-sensitive filesystem.
• create a hard disk image in which to perform the builds.
  
  • Applications->Utilities->DiskUtility.
  • NewImage
  • Size->Custom->5G
  • Format->Mac OS Extended (Case sensitive)
  • Partitions->Hard disk
  • SaveAs->whatever
  • Create

Then, when you want to use it, mount it with DiskUtility, and you'll see it in your Finder windows. After it is mounted, cd into it at /Volumes/Disk Image (or whatever mount point you selected), and run the svn commands, etc, in that location.

(Conversely, if you filesystem is case-sensitive, you may need to create a disk image to play games like WoW which require a case-insensitive filesystem.)

You can, of course, select any size you want. My current build directory for 8.09 is slightly over 2gig in size.

There are some tools that you'll need to install. These include the following:

• Apple's Xcode development environment (free): http://developer.apple.com/technologies/tools/xcode.html
• macports: http://guide.macports.org/#installing
• sudo port install getopt
• sudo port install coreutils
• cd /opt/local/bin && sudo ln -s gmktemp mktemp
• sudo port install gawk
• sudo port install wget
• sudo port install findutils # os x /usr/bin/find not compatible with openwrt makefiles
• sudo port install gnutar #  (for r14898, but not top of branch)
• cd /opt/local/bin && sudo ln -s gnutar gtar
• cd /opt/local/bin && sudo ln -s gnutar tar

When macports is installed, it modifies the $PATH environment variable for the account used to install the tools to include /opt/local/bin. Because some of the tools that are installed are incompatible with OS X tools of the same name (stored in a different location), it'd be best to install the tools with a separate loginid that will only be used to build openWRT. (That or set up an alias that will modify your $PATH environment variable when you build openWRT.)

The Mac that I'm currently building on is running 10.6.4 and is Intel based. However, given that openWRT is based on a cross compiler, PowerPC Macs can also probably build openWRT.

Note however, that the hsmm-mesh development environment includes binaries (eg, the gcc cross compiler toolchain) that were built on linux for use on linux systems. These tools cannot be run natively on a mac system. (You could, however, set up a linux virtual machine on OS X that will allow you to build using hsmm-mesh's development environment.)

While hsmm-mesh binaries are only supported on certain models of linksys routers, some of ubiquiti's devices, such as the bullet, have successfully been used to connect to an hsmm-mesh. Doing so requires modifying the software on the ubiquiti by hand. I thought I'd post some information on the picostation 2 that others might find useful.

There are four models of the picostation:

• picostation2: 2.4GHz. 12V, 1A. 100mW. (wrt54g is 60mW I believe)
• picostation2hp: high power (800mW) version of the picostation2
• picostation5: 5GHz, up to 24V input. half the memory of the picostation2.
• picostation M2. I think this is 802.11n, but I could be wrong.

Data sheets for these models are available here: http://www.ubnt.com/picostation and here: http://www.ubnt.com/picostationm.

They range in price from $70 to $100. (You get to pay more for Open Mesh to be installed.)

These wifi routers come with AirOS installed. A software development kit is available for this OS, so that you can add extensions to it. Documentation for AirOS can be found here: http://www.ubnt.com/wiki/AirOS_5.2.

With respect to olsrd and AirOS I've read conflicting things:

• AirOS lacks adhoc mode, and olsrd requires adhoc mode, so …
• olsrd will run on AirOS, but the latter lacks VAP, causing olsrd not to work, so ...
• olsrd doesn't require adhoc mode and someone has written a wiki about how to run olsrd on AirOS, and all you need to do is google for "olsrd wiki" and you'll find the necessary information.

With openWRT available for the picostation, I'm not inclined to pursue AirOS, though it does have a nice web interface.

The picostation includes a serial port. Instructions on how to access this can be found here: http://www.ubnt.com/wiki/PicoStation2_RS232_Connection. (The cheapest place I've found for the usb/serial cable is DIYdrones: http://store.diydrones.com.) And yes, the drivers work on OS X.

Netgate (and probably others as well) has a DC PoE lighter plug for use with the picostation2 (and bullet and other devices): http://store.netgate.com/-P274C116.aspx. (Hunh. last week there were over 1000 units available for sale for $3, but this week there are only 7 available at the standard price of $10.)

AirOS has a web page that allows you to upgrade the firmware to either openWRT or AirOS. After the unit is upgraded to openWRT, and you find yourself unable to scp a new image to the unit (or use a web interface), you can use the following procedure: http://www.ubnt.com/wiki/Firmware_Recovery. I've used this a number of times (cough) and it works fine.

The bootloader for the picostation is redboot. A manual for it can be found here: http://ecos.sourceware.org/docs-latest/redboot/redboot-guide.html. More information on redboot: http://ecos.sourceware.org/redboot. In spite of being GPL'd, I haven't seen any source code from Ubiquiti for redboot. They might be using a version that predates the 2002 GPL license for ecos (on which redboot is based).

As you can see from some of the web pages listed above, Ubiquiti has a pretty good wiki page for the support of their products. They also have some forums in which questions can be asked and are answered.

Someone asked, on a mail list I'm on, how to get started doing firmware development for hsmm-mesh. I thought I'd post my reply here.

It is probably easiest to approach firmware development for your linksys routers using the hsmm-mesh software. One problem that I've experienced with openWRT is that the latest software available in any particular release (either backfire or kamikaze) isn't guaranteed to work on the routers that I'm using. In contrast, the hsmm-mesh software will work with your linksys routers. So, using the hsmm-mesh source development environment, you won't get a headache finding a tree that will both build and work.

There is some developer documentation for hsmm-mesh available here: http://hsmm-mesh.org/developer-documentation.html. One of the first things that you'll need is access to the svn repository for hsmm-mesh, which is described here: http://hsmm-mesh.org/developer-documentation/86-svnrepos.html. You should probably request both an account/password and a branch. That way, once you get the hang of things, you can submit modifications to the svn repository. ad5oo reviews changes on developer branches before merging them into the main trunk.

Besides working with a code tree that is known to work on the linksys routers, the svn repository also includes a binary cross compiler toolchain (eg, gcc, linker, librariest, etc). When you work with the openWRT svn repository, the cross compiler environment is built entirely from source. In a sense, openWRT is a linux distribution for which you build everything; in contrast, when you installed debian on your computer, the distribution included all the binaries required for the install.

(As an aside, if you are interested in tutorial on building linux, rather than openWRT, from scratch, I'd encourage you to look at http://www.linuxfromscratch.org. There are several different subprojects on this website ranging from the most basic (LFS) to a cross compiler environment (CLFS) which you could use, say, to build linux on an intel system for installation on MIPS processor. But, linuxfromscratch is not openWRT. It can be a good introduction to building software and describes many things that are handled automatically by the openWRT build environment such as:

• why a cross compiler build environment is necessary
• introduction to utilities that openWRT uses, such as busybox
• what needs to change in the build process for an embedded environment as opposed to on a desktop system

Again, linuxfromscratch isn't openWRT and can't be installed on your routers.)

After you download hsmm-mesh from the svn repository, you can build your own hsmm-mesh firmware. With all the pre-compiled tools, software packages, and kernel, the build takes little time. http://hsmm-mesh.org/developer-documentation/87-using-the-imagebuilder.html describes how to do this. (Note that the hsmm-mesh development environment comes with a 'make' perl script, and must be invoked using "./make". Without that '.' you will invoke your system's 'make' binary, and you will not end up with firmware that you can install on your router.

Once you've built your own hsmm-mesh software, and have become familiar with the configuration environment on the router (say, to cause your routers to provide a smaller number of dhcp addresses on the LAN ports where the default is 190), you could modify the hsmm-mesh build environment on your debian system to limit the number of allocated IP addresses to 10 say. In my local tree, the dhcp limit is specified in a number of files:

myhost:etc k5osx$ pwd
/Users/k5osx/HSMM/trunk/files/etc
myhost:etc k5osx$ grep dhcp_limit config*/_setup{,.default}
config.ap/_setup:dhcp_limit = 190
config.client/_setup:dhcp_limit = 190
config.mesh/_setup:dhcp_limit = 190
config.mesh_ap/_setup:dhcp_limit = 190
config.router/_setup:dhcp_limit = 190
config.ap/_setup.default:dhcp_limit = 190
config.client/_setup.default:dhcp_limit = 190
config.mesh/_setup.default:dhcp_limit = 190
config.mesh_ap/_setup.default:dhcp_limit = 190
config.router/_setup.default:dhcp_limit = 190
myhost:etc k5osx$

So, to implement this change, I'd modify the above files and set the limit to 10, and then rebuild the software, and then if my router was ever used at an MRC POD, I might cause some consternation if a switch was ever connected to my router's LAN port, because a max of 10 IP addresses would be allocated by the DHCP daemon. (There are multiple config directories because the routers can be used in different modes, such as an AP, or a mesh node, etc.)

Once you've played with modifying the hsmm-mesh configuration somewhat, you might consider adding your own binaries to the files directory. For example, on a unix system, I often use the 'view' command to give me read-only access to text files. I've been using the vi editor for a long time, and i prefer to look at some files using vi rather than the 'more' or 'less' commands. The 'view' command is simply an invocation of vi with the -R option. So, I created a little script files/bin/view:

myhost:~ k5osx$ cat view
#!/bin/ash
exec /usr/bin/vi -R  $@
myhost:~ k5osx$

Now, when I build hsmm-mesh firmware, my routers always have a 'view' command that does what I expect, rather than a busybox shell that goes "hunh unh." (Now, if I could just get ash to understand what !$ means when used on a command line.)

From there, you might want to install some additional openWRT packages in your default hsmm-mesh build, or perhaps modify the existing packages in some way. To do that, you'll need to build openWRT from source, but i'll leave that tale for another time.

robert

It's even better when you can do the frequency converter in the chip itself.
http://www.patentgenius.com/patent/7772932.html

http://kb9mwr.blogspot.com/2010/09/miscellaneous-hsmm.html

By the way, unlike the ARRL I am serious about trying to get hams to make better use of our microwave allocations. I am putting out a bounty, and figure since there is an active group here, I'd let you guys know. http://kb9mwr.blogspot.com/2010/10/interesting-article-bounty.html

Hello all,

After several months (over a year), I'm finally getting my feet wet in the mesh.  Unfortunately, I'm up here in Cedar Park and have been unable to get into the Austin mesh.   For now, I guess I'll keep being an island in Cedar Park until we can get to the top of the water tower and get that node up and running.  Hopefully, we can get a signal into "Austin Proper".

I'm using the mesh as the communication backbone for some robotics experiments and managed to build my own olsrd (5.3) and successfully join the hsmm-mesh.  My target platforms are x86 and arm.  I did x86 last night and expect to have arm working tonight.

I had a question about the fcc_id, but realized my own bone-headed oversight.   For now, I'll just leave it at hello.  If anyone is running a node in Cedar Park I might be able to hit, please let me know.  I'm over by Cedar Park HS with antenna restrictions.