I have several WRT54G’s running Broadband-Hamnet 1.0.  They’re all in 5 host direct mode, and they can all see each other.  I have a Raspberry Pi directly connected to one of the LAN ports on one of the mesh nodes.  The Raspberry Pi also has a wifi connection to my home (non-mesh) access point.  The Raspberry Pi’s wifi interface is getting a 192.168.1.x address from my home access point’s DHCP server.  Its Ethernet interface is getting a 10.217.95.250 address from the directly connected mesh node.  From the Raspberry Pi I can make an ssh or http connection to the directly connected mesh node using its 10.217.95.249 address.  But a DNS lookup of the directly connected mesh node’s name returns its other address (10.59.43.255), and I can’t make a connection to that address from the Raspberry Pi.  I also can’t connect to the other mesh nodes from the Raspberry Pi.  All of their addresses are in the 10.x.x.x range.

The Raspberry Pi’s routing table has a default entry pointing to the home access point and an entry for 10.217.95.248 with a netmask of 255.255.255.248 that points to the Ethernet interface.  So that explains why I can’t access the mesh nodes via their 10.x.x.x addresses.  There is no routing entry for those addresses, so it’s trying to use the default (wifi) interface to reach them.  I solved the problem by adding a static route to the Raspberry Pi’s routing table like this:

route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.217.95.249

I was a bit surprised that I had to manually add this route to make things work; I thought the mesh would “just work”.  Maybe it just wasn’t designed to handle the case where an attached computer has a second (default) network interface.  Was the route I added the best way to resolve the problem or is there a better solution?

I think the BBHN network is working just fine.  Your Pi just isn't configured properly. 

Are there any devices that autoconfigure "properly" when connected to two upstream DHCP sources like that? 

I don't think the necessary routing information is available in the DHCP protocol.

Depending on what is connected in the mesh, you may be able to route just 10.x.x.x through the mesh, or you may be able the entire internet through the mesh.   The mesh can't tell whether it has to best connection to, for instance google.com, or whether the "other" link on your Pi has a better connection. 

The mesh node has no way to figure out what network is available on the other link into your Pi.  All the mesh can tell your Pi is Client IP, Router IP, LAN subnetmask, DNS server IP, and domain name.  The routing happens in your Pi, so it would be up to the Pi to look at the DHCP information and decide what routing to use. 

DHCP is going to tell the Pi to use router IP of, for instance, 10.217.95.249, and a netmask of 255.255.255.248.  How is the Pi supposed to automatically figure out that you really want routing to 10.x.x.x with a netmask of 255.255.255.0?  Then if your wifi connection goes away, it will be up to your Pi to figure that out.

I guess you could configure your Pi as an OLSR mesh node and configure it to connect to BBHN. 

I think you can connect two BBHN nodes through their LAN ports, not just through RF. 

I guess you could write some scripts to run on your Pi, but I don't think there's any kind of general purpose dual uplink routing options.  Your script would be specifically for BBHN and a separate internet connection. I guess you could look into the routing table for an address like 10.215.95.249 and then formulate an appropriate route add 10.0.0.0 ... entry when needed. 

Thanks for your thoughts on the issue, wx5u. I guess my expectation was that the mesh node's DHCP would have given the Pi a netmask of 255.255.255.0 since that node was providing access to all the 10.x.x.x addresses. But I don't know enough about routing to know if that makes sense.

I also have a question about DNS in an environment like this. How does the Pi know which interface it should send DNS queries to? It appears that sometimes it's able to resolve names in the mesh like n7ego-1002.local.mesh but it's not able to resolve names on the internet like www.google.com. Other times it's the opposite; it's able to resolve internet names but not names on the mesh. So apparently at any given time it's only sending DNS queries to one interface and not the other. What determines which interface it sends DNS queries to? Is there a way to configure it to send them to both interfaces? It's fun to be experimenting and learning more about how networks function at this level, especially within the context of ham radio.

I'm a bit rusty on DNS.   I think DNS is a little more capable of handling stuff like this, but I suspect it may not do the "right" thing automatically.  It may need manual configuration.  

I presume DNS on your computer can be configured to use one nameserver for a certain set of domains and another nameserver for other domains.  I doubt it's set up to do this automagically, and don't know how to configure this without some further research.

What does your /etc/resolv.conf look like on your Pi after you connect it to both networks?

DNS tends to handle this with multiple nameserver entries in /etc/resolv.conf.   If the first nameserver in resolv.conf doesn't know how to route to a particular address, such as "local.mesh" it's supposed to return an error and your computer can then try the next nameserver in the list.

Unfortunately, many ISPs do fraudulent DNS service and send you to an advertising web page if you enter a hostname it can't resolve, instead of returning the correct "not found" error code.  That may prevent name service from trying the second nameserver in the list and screw up having multiple nameservers in your list.

I thought multiple nameservers were used the way you described, but I learned today that that is not the case under Linux. If the first nameserver returns "not found", the system does not query the second nameserver; it just stops looking. The only time it queries the second nameserver is if it doesn't get a response from the first nameserver. But http://www.unix.com/ip-networking/133552-howto-linux-multihomed-dns-client.html describes a method of configuring things so that queries for names in one domain are sent to one nameserver while queries for names in other domains are sent to a different nameserver. I'll try configuring things this way in the next few days and see if it resolves the problem.

Currently the /etc/resolv.conf on my Pi contains the following:

domain local.mesh
search local.mesh
nameserver 10.217.95.249

10.217.95.249 is the address of the mesh node it's connected to. It looks to me like the network it connects to last overwrites whatever was put there by the first network. Sometimes the wifi network gets initialized and responds to a DHCP request first and sometimes the Ethernet network is first when the Pi is booting, which explains why I sometimes can resolve names on one network and other times on the other network.

I've also noticed that my routing table gets set differently sometimes, and I think that's also related to which network gets initialized first and which comes second. I think the bottom line is that if you connect a Pi or other Linux machine only to a mesh node, things will work correctly by default. But if you connect to a mesh node plus another network then you will have to do some manual configuration to make everything work smoothly.