Now that the endian problem has been dealt with by removing the secure plugin, many wireless platforms could be configured to run BBHN. I understand that it is "not an easy task" to configure a differnent device, and that the current priorities are to support the listed LinkSys routers.

If it is not too much trouble, could someone post a list of the steps people would need to take to configure a random Linux distro to make a BBHN node? Eventually maybe a cookbook recipe that anyone could use, but for now, just a list that a knowlegable, experienced computer/network person could use, including a specification of what the node should be able to do.

I appologize if this already exists and I missed it in my search.

73 de KG1L

Currently this document does not exist.  In fact, a "cookbook recipe" will never exist.  There are far too many considerations needed to cover the various Linux (or whatever) distributions.  All of the complexity that has been removed from using the network has not gone away, it has just been transferred into the software that the routers run, thus making any set of instructions necessarily high level and the details will have to be worked out by the person interested in making any given platform work.

That being said, a set of high level descriptions will be coming at some unspecified time in the future.  However, the firmware is open source and freely downloadable from the svn repository.  Examining the contents of the files that have been laid on top of the stock OpenWRT firmware, and logging in to a running node through ssh, will give the sufficiently motivated person all they need to know to bring some other platform on to the mesh.

73
ad5oo

Be sure you understand and make clear the difference between:

1) Running Broadband-Hamnet™ on a new piece of hardware.

2) Configuring a device to the point that it's able to connect to a BBHN network.

I get the impression that installing OLSR and some extra configuration will theoretically allow many devices to connect to a BBHN mesh. 

Simply being able to connect is good, but there's a lot more to the BBHN system than that, especially in terms of ease of use.

I don't know the details to answer your original question.

I'm currently banging my head against the wall getting OLSRd on Ubuntu to register itself via nameservice (including service advertisements).  Once that's hammered out, connecting anything to the mesh is basically:

1) Associate to BroadbandHamnet-v1 on channel 1, Ad-hoc mode.

2) Assign a static IP in the 10.x.x.x space. If you want, use the last 3 bytes of your NIC's ethernet address to do this like mesh nodes do, otherwise, any arbitrarily picked IP address will probably be fine in all but the largest of meshes.

3) Get OLSRd up and running. Completely unconfigured, olsrd -i <interface> will work and get your routing tables synchronized, and will allow you to extend the mesh with whatever hardware you're using.

Once OLSRd is properly configured, your machine name will show up on the mesh (versus just an IP address), as well as any services you wish advertised (e.g. a file share or something for others to use). Note: this is where I've run into problems, and would appreciate help. 

4) Get your own DNS synchronized with OLSR. This should be pretty straight-forward, especially on Ubuntu or Debian where NetworkManager runs a local dnsmasq instance similar to how the BBHN firmware does it. 

5) Make certain that your callsign is periodically beaconed. You can do a broadcast ping that includes the hex representation of your machine's name. You could put this in cron to run every 5 or 10 minutes:

ping -c 1 -p `echo $HOSTNAME | xxd -p` 255.255.255.255

It looks like this when it runs. KD0NRC-Laptop is 0x4b44304e52432d4c6170746f70 in hex.

PATTERN: 0x4b44304e52432d4c6170746f70
PING 255.255.255.255 (255.255.255.255): 56 data bytes
--- output truncated. multiple machines return ping ---

You can clearly see my callsign in the traffic. This is similar to how the mesh nodes do it, but a little different method. Sniffed with tcpdump, the traffic looks like this:

$ sudo tcpdump -nvXs 1514 -i en0 "icmp"
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 1514 bytes
15:45:29.222720 IP (tos 0x0, ttl 64, id 49845, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.42.102 > 255.255.255.255: ICMP echo request, id 61984, seq 0, length 64
	0x0000:  4500 0054 c2b5 0000 4001 cce5 c0a8 2a66  E..T....@.....*f
	0x0010:  ffff ffff 0800 b9d2 f220 0000 5204 0369  ............R..i
	0x0020:  0003 65a1 4b44 304e 5243 2d4c 6170 746f  ..e.KD0NRC-Lapto
	0x0030:  700a 4b44 304e 5243 2d4c 6170 746f 700a  p.KD0NRC-Laptop.
	0x0040:  4b44 304e 5243 2d4c 6170 746f 700a 4b44  KD0NRC-Laptop.KD
	0x0050:  304e 5243                                0NRC

Once you have all that figured out, actually browsing and utilizing the mesh becomes the only problem. If configured properly, olsrd_Nameservices will create files (on the mesh nodes, you can look at them: /var/run/services_olsr and /var/run/hosts_olsr), so you could either manually look at the files, or create a web script similar to the cgi-bin scripts on the mesh nodes to render them into something useful.

Having done this on numerous machines I would HIGHLY recommend using the olsrd.conf file from the /tmp directory of a V1.0.0 WRT54G's and use it for the config file on your Ubuntu system.  While most of it is comments this file does cause a number of OLSR plugins to be loaded at startup.  You may have to download and install each plugin (usually libraries or .so files for Linux) mention in the file.

A couple of things you'll hafta edit in the olsr config file:

1. Change the line 'MainIP yer_ip_addr'  to use the machines WiFi IP address.
2. Near the end of the file there's a line 'Interface "wl0" -- change to use the name of the Wifi network interface you're using for the mesh; usually wlan0  & keep the double quotes!
3. Check each file that's mentioned in the config file.  If you're porting to an embedded Linux system then most of these files you will want to put into a RAM-based filesystem instead of FLASH-based. This will keep the FLASH memory from getting wore out because these files tend to be re-written fairly often.
4. Make sure that the secure plugin config is COMPLETELY commented out or removed *IF* you are using v1.0.0.

And put this file away in the place that your version of 'olsrd' expects it to be placed, usually the /etc/olsrd directory but sometimes in /etc.

I think you'll find that Ubuntu will mesh a little nicer with these modifications.

If you add the following to your dnsmasq config, you will get proper DNS resolution of the machines, as well as browseable links from the OLSR-httpinfo plugin, port 1978 on your OpenWRT node, assuming you have httpinfo configured as well.

/etc/dnsmasq.conf
...
# include olsr nameservice
addn-hosts=/var/run/hosts_olsr
...

The services are also configured in the olsrd_nameservice plugin section of olsrd.conf. I've gotten service entries to show from my OpenWRT nodes.

/var/olsrd.conf
...
LoadPlugin "olsrd_nameservice.so.0.3"
{
    PlParam "sighup-pid-file" "/var/run/dnsmasq.pid"
    PlParam "interval" "30"
    PlParam "timeout" "300"
    PlParam "name-change-script" "touch /tmp/namechange"
    PlParam "name" "AD7PE-101"
    ## Example Service
    PlParam "service" "http://AD7PE-101:9000/|tcp|Test1"
}
...

Keep in mind that adding the service entry won't fix the firewall settings to allow access, you will need to do that manually. The node history page and service links in the HSMM UI appear to be built by perl scripts scattered around the filesystem. I've not had time to look in to them, but the SVN tree at \wrt54g\trunk\files is where you will find the answers.

I've been playing with this on a La Fonera. It works running Backfire 10.3, but the networking is a bit odd because La Fonera only has one ethernet port, so DMZ/WAN/LAN don't really exist except as vlans.

FCC ID in BBHN is performed by \wrt54g\trunk\files\usr\local\bin\fccid

...
#!/bin/sh

[ -f /etc/config/run-fccid ] || exit

# stagger the beacons between nodes
N=`ifconfig wl0 | grep "inet addr" | cut -f4 -d. | cut -c1-3`
sleep $N

netmsg 10.255.255.255 "ID: `hostname`"
...