I have found an odd thing with the [OLSR Status] link.  All of the other buttons link to the node by IP address.  The [OLSR Status] button links by node name.  If you are not using the mesh as your primary gateway, the DNS will not resolve nodes names which means the link fails to display the web page.

I respectful suggest changing that button to work the same as the others and link by IP not by name.

Thank you for listening!

Since I began working with the project the systems have always been referred to by name.

The Mesh Status page is fully name based as are the links inside OLSR Status page. For getting to node to node, having  easy access by name is considered to be a functional component of a easy user deployment

Most the links on the interface are actually 'relative' links, where we don't specify the node name or ip, we just specify "its at this path" and the browser knows to use the same way the user typed it (IP or Name -- though by name is preferred) to get to the page. We can get away with this when we  need to use an alternate port or server name. The OLSR Status page needs a port number.

One does not actually need the mesh node to be the default gateway to get DNS to work,  if you add the node into your DNS server list name resolution should work and take you to the page correctly.  Name resolution functioning is to my knowledge considered a core component of making the mesh user friendly.

At the moment I'm not sure how easy it would be to change the link that takes you to OLSR Status to follow the name as typed in dynamically (requires a few items to be passed along as part of the cgi interface that would need to be verified they exist correctly in the current builds).  We would still be left with the links after that to other nodes would still not work and would need DNS up and operating anyways  for anything other than just looking at the node itself. 

I can understand where our are coming from though. I have had some very complicated (non standard  not for actual deployment) setups in the test lab where that had annoyed me a time or two, but it was always because I had disabled DHCP and DNS lookups for testing and had not set my routing paths correctly for my PC to browse the mesh.

I'm not aware of anything that would break if such a patch were submitted to mainline at this time.

Oh and of course the OLSR page isn't exposed on the WAN side at all (the only place where we expect node DNS resolution to not work as part of the design) so we don't need to worry about that either.

Thanks for the detailed reply.  I run 3 DNS servers at home (1 x primary, 2 x secondary) and quickly resolved it by simply adding the entry for the device.

I am not sure how to make this seem transparent in a setup where the mesh is the 2nd gateway out of your home lan.  It all works ok when it is the only gateway. However I predict many people will plug this into a free port on their existing wired network.  Adding a route  (route add -net ....) makes the IP traffic flow but the DNS is an issue.

I'll work on it to see what I can devise.  Maybe the solution is to read the mesh nodes list to update Linux bind and also configure DNS forwarders.  That would give both public and mesh resolution.

Various posts have been given on integrating into an existing network so I will not rehash them in this thread other than to say you are looking at the right areas.

Multiple ways exist to do this but you have to look at the risks and advantages if each method. Browsing through the forums should give you some more info.

Integrating into an existing network is an advance deployment option and depends a lot on ones existing network on how to handle it.

If you know how to run your own DNS, or know how to populate (/etc/hosts) (\windows\system32\drivers\etc\hosts), the problem is trivial. Unfortunately not everyone is aware of those 2 solutions.

My initial question was based on the fact that the menu buttons seem to point to http://172.27.0.1/blah/blah/blah except for one particular button that points to:  http://hostname/blah/blah/blah

Since the hostname is itself, it should already know the local IP address.  If that button was changed to use IP instead of hostname, DNS resolution is not required.

I already solved it for "me", just trying to reduce potential support requests from local hams.

So far everything is good.  Glad to see the project in a healthy state.

I have fixed the issue.
Log into OpenWRT.
Edit/vi /www/cgi-bin/status

near line 52
original: (1 line)
print "<button type=button onClick='window.location=\"http://$node:1978/\"' title='See the OLSR routing details'";


change to: (now 2 lines)
($ip, $mask, $bcast, $net, $cidr) = get_ip4_network("eth0");                                                      
print "<button type=button onClick='window.location=\"http://$ip:1978/\"' title='See the OLSR routing details'";

Now when you display the status screen, clicking on the [OLSR Status] button displays the webpage by calling the IP address instead of the name.  DNS resolution not required

Note:

As written will not work across the mesh in NAT mode (eth0 ip would be non mesh accessible) it also does not work on Linksys (eth0.0 vs eth0)

Understand on being new and being willing to help, that is how I got involved myself and had to figure out some of these items and we are looking for people being willing to help.

A 'properly working' BBHN network has DNS working, if DNS resolution isn't working the network isn't considered functional from our end. DNS is a key component for the 'ease of access' all the Advertised URL's will always be name based not IP based, so even if you can get to the OLSR Status Page your still not going to be able to click any of the links there without DNS resolution.  Ease of use is a core feature of the builds and names are needed for that

All the links except the olsr link are relative links, they don't include a server path the browser just adds it on itself. I fi connect at http://localnode:8080 the browser uses locanode, if I connect at http://mynode:8080 it uses the my nodes full name, and if connect by IP  it would use IP.

If the button was to be made to follow it would want to be looked at HTTP_HOST ENV variable to dynamically set the hostname similar to how relative URL's are done in the browser..  I don't know off hand if the Linksys microperl supports this (newer microperl do not and have to run full Perl like we do in Ubiquiti build)

You should be able to get to the status page of any node across the mesh by http://nodename:8080 . If you use the eth0 ip as described in your post a  user will be able to get to your status page, but when they click your OLSR status they will get a can not connect error, or worse, if ip's collide they will see their own OLSR status instead of yours.

You should also be able to access any service by its nodename:port combination.  IP addresses are not considered the 'ideal' way to access the mesh.  The local node you are plugged into is always at localnode byname.  If  a user say "hey checkout this its at http://mynodename/   you would have the same problem without getting dns working.

ok, you have sold me on the fact that DNS and all needs to be functional.

Is there a best-practice for guys that have an existing SOHO router connected to their ISP and want to plug the mesh node into a spare port?

In my case, I added a static route for 10.0.0.0/8 that pointed to the mesh node wired address.  I also added some DNS entries to my local server.  All "seems" to be ok for me. My linux machine has a custom mesh webpage (based on your inbound IP address being 10.0.0./8) as well as a few other services (and they work 100% via the mesh!)

Not everyone has access to a local linux machine but everyone has a home router.  I am trying to predict the potential support questions from our club members.

Always happy to listen to how other groups have managed to implement their kit.

Trying to integrate to an existing network qualifies as an advanced deployment from the standpoint of BBHN.

Every network will be different and will depend on how it's laid out and what tools they have so the only real answer that can be given is "set a route for 10.0.0.0/8 through the mesh node and to set DNS to query the mesh node". 

How you do that will depend on your existing network layout, how you wish client setup to go, etc. I can think of several topologies off hand in this scenario and each has it's advantage and disadvantage but they all depend on the tools and the desired layout.

If it's a new user the best thing is to plug directly into the node and not try and complicate the deployment by integrating into an existing network.