See what happens when one looks at the clutter and ignores the important text on the screen? Sigh ... that was it. BTW: A 30 second reset does nothing to the router. Interesting.

First router updated to BBHN second in-progress ...

Thanks!

It was present in that release too. After telnetting into the node, did you type "mount_root"? You will be presented with something similar:
root@KF5JIM-VPN-49:~# cat /etc/httpd.conf
/cgi-bin/setup:root:password
/cgi-bin/ports:root:password
/cgi-bin/admin:root:password

Username is root. Password is whatever you set it to be. If you forgot the password (or username), follow the instructions to put the router into failsafe mode and telnet into it.  Once you are in failsafe mode and mount the rootfs, type "cat /etc/httpd.conf" to see the username and password in plain text.

The user name is usually "root," unless you've done something strange.

Once you're logged in with failsafe mode, you can probably look in /etc/password and all the user names will be there.  (Maybe.  That's the standard Linux setup, I haven't tried it on one of our routers.)

If you've somehow set another user name, you could probably change root's password, and then log in as root and figure out what user ID's are on the router.

Or just reload with the Installing Firmware with TFTP instructions. (Toward the bottom of the page.)

These instructions explain how to change a forgotten password - what about a forgotten User Name, please?

http://hsmm-mesh.org/documentation/71-using-safe-mode-to-reset-a-forgotten-password.html

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.

Tom,

Have you noticed the HSMM-MESH SSID 'going away' when using the AWUS036NH? I'm wondering if this is some power saving mode of the unit as there aren't any other mesh nodes for it to talk to at present.

Restarting networking on the Pi (/etc/init.d/networking restart) seems to resolve the issue.

Maybe this issue will go away once I have another node online at home.

Also: Have you had any luck configuring the kernel module to take advantage of the full 2W output?

73
Mike
K2MTS

You're welcome. 

Sometimes the PC remembers some old network information and unplugging and replugging the cable will make it reconfigure itself correctly.   Of course, a bad cable would explain it too.

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 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. 

Get a WIRED ethernet connection to the internet.

Plug the ethernet cable into the WAN port of the mesh node.

Log into the mesh node.  Turn on "Mesh Gateway" on the setup page of the mesh node.

Every mesh node that has a connection to you now has internet. 

------

I haven't done the following, but it should work.

If you don't have a wired ethernet connection, but have a WiFi connection available you can use another BBHN router in Wireless Client mode.   The wireless client router converts the wireless to wired ethernet.  You can then use that wired ethernet connection to provide internet to the other mesh node. 

It does require two BBHN routers to do this from a wireless internet source.

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?

Should that be localNODE, not localHOST?

"If one mesh node has it's WAN port plugged into an Internet feed, and a config change, it can provide Internet to all mesh members"

Can I get some specific examples of Internet feeds (other than directly from a DSL or cable modem)?  What is the source and how is it connected?  Can the one mesh node simply be connected to a network with Internet access?

What is the config change?

I have an iPad mini with a Personal Hotspot.  Can that be used as an Internet feed?  How would that be done?

Thanks

Dan

K6DPY

This website goes back to 2004, but given the recent developments with the Raspberry Pi's use as a MESH node, I believe that this once again bears revisiting. There are some really good photo designs for using DIY antennas with the USB wi-fi dongles. As well, how there is literally NO loss in a USB cable for a few meters length, which would go well with being connected to a Pi router....

http://www.usbwifi.orconhosting.net.nz/

Gary-KI4WPI

I am unable to log into either of my routers. I'm trying to update to Broadband-Hamnet v 1.0 If I use the Console -> telnet 192.168.1.1 method as linked above the computer sees the router fine - but via a browser neither 192.168.1.1 or localhost:8080/ is recognized. Any idea as to why this might be, please?

BTW: Telnet says ad5oo Build 126 Version 0.4.3