Thanks Andre - that works great for SSH.

How do you enable telnet or ssh on a LinkSys running version 1.0 or 1.1.  I can't get it to work on either.  Telnet works on Ubiquiti devices.  I am sure I have overlooked something but all I get is connection refused.

Thanks and 73

Frank - K0FEI

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.

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.

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.

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.

I am a short drive from the Ohio Area (Southern California) so i can't tell you a lot about what is going on in Ohio. I can however speculate  A lot of persons may be running WRT54 based setups because of how long the project has supported Linksys hardware, but I would strongly recommend looking into the Ubiquiti hardware. It is newer, has higher power RF capability and a stronger receive.  It can sit out in the sun, rain, snow,  (Just don't throw it in a lake) without needing to make a box, and heat it up or cool it down (-40c to  80c rating).

I've seen established networks that have run Linksys gear go out and replace all of it with Ubiquiti (and see significant improvements by doing so)

While we won't likely see Linksys gear disappear,  if you are going to spend money on new hardware I would recommend looking at the Ubiquiti gear. When I look at the cost of a new WRT54GL and compare it to a NanoStation I end up with the NanoStation each time.

The one plus I will give of the Linksys gear is the fact that it does have 5 ports switch inside the case (though we just recently saw an issue where that switch seems to have issues so i would have to add an external switch anyways) instead of needing to add one yourself, this can be nicer than a second piece of hardware to allow multiple computers.

Welcome to the world of mesh, I hope you find it enjoyable.

Just curious what everyone's setups look like that are running in the Columbus area. I live in Dublin and might look into setting up a node. Do people mostly use a variation of the WRT54G?

~Ben

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!

Hello everyone!

This message is to notify potential London meshers that we are starting to build a mesh in London, Ontario.  If you are in the area and want to get your kit going, drop us a message.  We are in the early stages but some equipment has been ordered, received, and we are playing with the software.

The more people that get involved the better.

Thanks for listening!

I originally posted this in the Firmware forum as a follow on to another question, but thought it might help to put it out here under "Problems"...duh...so if you think you're reading this twice, you're probably right!

I have two nodes, a WRT54GS v1 and a WRT54G v3. I upgraded both from BBHN v1.0.0 to v1.1.2 using my home PC, and both of them come up on it and work just fine. However, the GS is used in my shack and is connected to a repurposed HP Compaq t5000 thin client running Windows CE .NET 4.2 as a dedicated terminal. With release 1.0.0 the GS and the t5000 worked together beautifully; now after the 1.1.2 upgrade, they won't talk to each other. But, if I connect the G to the thin client it works just fine on 1.1.2, so there's definitely something different in the GS that's keeping it from working exactly like the G, but I can't figure out what it is or if I can correct it in some way. I really would like to get this resolved; I want to take advantage of the extra memory in the GS to support applications, but maintain the direct access to it using the thin client.

If this will help the discussion... I have two nodes, a WRT54GS v1 and a WRT54G v3. I upgraded both to BBHN v1.1.2 using my home PC, and both of them come up on it and work just fine. However, the GS is used in my shack and is connected to a repurposed HP Compaq t5000 Thin Client running Windows CE .NET 4.2 as a dedicated terminal. With release 1.0.0 the GS and the t5000 worked together beautifully; now after the 1.1.2 upgrade, they won't talk to each other. But, if I connect the G to the thin client it works just fine on 1.1.2, so there's definitely something different in the GS that's keeping it from working exactly like the G. I really would like to get this resolved; I want to take advantage of the extra memory in the GS to support applications, but maintain the direct access to it using the thin client.

I have two GS routers. One was configured as normal node and the other as a mesh access point. I successfully used that to reach the mesh via localnode:8080/cgi-bin/status. I could reach the MAP to configure it with 172.27.0.2:8080/cgi-bin/status.

Today I updated the node router to ver 1.1. I can still connect to the MAP wirelessly and reach the mesh, but I can't reach the status page for the MAP with the 172 address. How can I reach the MAP or force it to revert to a node? Thanks for any help.

A year late.  But just stumbled upon this type of technology, and realized I have a WRT54 style router, a raspberry pi, and a high gain antenna. Im in Windsor Locks. Anyone else in the area?