W5LMM, I feel your pain.

My LAN used to be 10.X.Y.Z, until I got into mesh.

There is no real way around it, and I ended up changing my entire lan to a 192.168.X.Y for it to work (about 30 devices to change the 1st 3 octets !). You might be able to use the 172.X.Y.Z, as long as it doesnt conflict with 172.27.0.X, the default NAT LAN on every node.

With it this way, I can add static routes and let ANYTHING on my LAN talk to anything on the mesh and vice versa. If you are on my mesh, you can hit my webserver, mailserver, WL2K server, VoIP system, etc.

If you go look under Applications for the Mesh in the menu here to the left, then hit the Towercam over mesh, that is a cam, up 50', attached to K5KTF-50foot, which then comes down via mesh, across my LAN, over to the webserver in the corner, and out to you, LIVE and STREAMING..

Yes, it sucked getting off the 10 network, but well worth it in the end.

73

KTF

I've seen reference to using IRLP over the mesh and am actually starting to think of a couple of situations where this might be quite convenient. I've had some moderately extensive to IRLP but am new to the mesh.

I haven't experimented with it yet, but here is what I know and understand and the scenario as I see it:

This IRLP node will have to be connected to a hsmm-mesh node (we will call this mesh node A). At some point, there are/will be other ways to integrate into the mesh more directly, but for the sake of this discussion let's declare that the only way to be a part of the mesh is by using a WRT54 device flashed with the hsmm-mesh firmware.

The mesh node that the IRLP node is connected to (mesh node A) may be using NAT or Direct mode. If the mesh node is in direct mode, no port forwarding will be required on that mesh node. If the mesh node is using NAT, the appropriate ports will need to be forward per IRLP specs from the mesh node to the IP of the IRLP node.

The other consideration then is the mesh node somewhere else in the mesh connected to the internet (mesh node B). The appropriate ports on that mesh node will need to be forwarded from the interface connected to the internet (WAN or LAN) to the mesh IP of the IRLP node. This will be the IP of the IRLP node itself if mesh node A is in direct mode, otherwise if mesh node A is in NAT mode then it will be the IP of the mesh node.

It is my understanding that if the “Mesh Gateway” box is checked on mesh node B, this is all that would be required and everything should work just fine. The “Mesh Gateway” advertises an internet connection that the IRLP node can use for it's outgoing connections and the port forwarding provides for the incoming connections.

I have two questions regarding this setup though. The first is whether there is a way to allow the outgoing requirements for the IRLP node without broadcasting “Mesh Gateway” and opening the internet connection for the rest of the mesh. The second question is somewhat related and is if there is some way to force mesh node A or the IRLP node to use mesh node B for an internet connection and simply fail, and try again later if mesh node B is unreachable or no longer has an internet connection.

Due to the way IRLP works, if the IRLP node were to have access to the internet via multiple “Mesh Gateways” the public internet address of the IRLP node would change each time a different gateway was used and I am certain that there would be undesired results. Also, the port forwarding for the IRLP node would need to be set at each mesh gateway or else a successful IRLP connection would not be able to be made using that gateway.

Anyone have any experience or insight into using the mesh as a way to get internet access to an IRLP node? Thoughts, comments, and suggestions are appreciated.

This post is going to get way too long anyway, so I am going to skip any discussion regarding the importance of accurate timekeeping or reasons for wanting it.

While it is nice that the nodes will update with ntp servers when they have access to an internet connection, I think it would be nice for them to be able to get a time-set without a connection to the actual Internet.

I haven't done any extensive testing or experimenting just yet and this is my first foray into NTP aside from using it on nearly all of my machines pointing to pool.ntp.org to keep time set. My admittedly limited research has given me some education into some of the terms and methods of NTP. For those who are unfamiliar with it:

- There are 16 “valid” levels of NTP (0-15) referred to as strata, NTP stratum 16 is used to refer to a device that is considered unsynchronized.

- A GPS is considered a Stratum 0 time source and can be used as a reference clock for NTP.

- A machine connected to a GPS and set to serve time to the network would be considered a Stratum 1 NTP Server. Stratum 1 servers may peer with other stratum 1 servers for sanity checking and backup. These are considered primary time servers.

- Stratum 2 are machines that are synchronized over a network to stratum 1 servers. Often a stratum 2 computer will query several stratum 1 servers. Stratum 2 computers may also peer with other stratum 2 computers to provide more stable and robust time for all devices in the peer group.

- Stratum 3-15 are the same as Stratum 2, using the level above and peering with others at the same level to get their time and acting as a server for devices in the next level down.

What I'm thinking of is a GPS connected to a computer (the Stratum 1 server) connected to the mesh. My initial thought is that this would be a great use for a Raspberry Pi, but I do not yet have one for testing and will be using another old computer I had lying around and an older GPS that I'm not currently using for some testing/proof of concept. I currently have the machine getting it's time from the GPS but have not done any testing beyond that.

In the simplest form, the configuration of a mesh node would be edited to point to this NTP server, and all would be complete; no big deal. I've even seen the configuration file on a mesh node that would need to be edited. However, this doesn't keep in the spirit of the self-configuring aspect of hsmm-mesh and also would require each node in the mesh to be configured to point to each NTP server (at least until 2-4 are active in the config file) as it is brought online. These additions to the configuration file would then be irrelevant when that server leaves the mesh.

Starting with NTPv4, the Manycast Scheme was added, and this looks promising for use in the mesh. There are also Broadcast and Multicast Schemes, but at this point and from the information I was reading I think Manycast looks most promising for our purposes here.

So my vision then is that users can have a GPS connected to a computer (I've seen tutorials for using a Raspberry Pi as a NTP server like this) and then configure it for the Manycast protocol. Get 2, 3, 4, or even more of these throughout the mesh as the Stratum 1 servers. They can automatically detect and peer with each other.

The second step would be to have the hsmm-mesh nodes look to these servers to set their own time. I'm not sure if the implementation of NTP that the firmware currently uses supports manycast or if there is some reason that ntpd is not the default, but I have notice ntpd in the available packages list and will likely be using that as I continue experimenting. Ideally, the node itself will use manycast and find the Stratum 1 servers described above and also have fallback to the pool.ntp.org servers in the event that an internet connection is available and none of the described Stratum 1 servers are. For the time-being, each node will have to be individually configured to support this implementation. Perhaps and ideally, if we get this working well, future versions of the firmware will have this as the default setup, eliminating the need to make this change on each node.

The third thing, and this might be a bit of a stretch/pipe-dream would be that once the hsmm-mesh node receives a time-set, it determines it's stratum (stratum 2 if from a stratum 1 on the mesh, stratum 3 if from stratum 2s on the mesh but no stratum 1 or whatever it would be from pool.ntp.org) and becomes an NTP server itself. Would have to make sure that it does not become a server until it receives a time-set from somewhere else though.

Extrapolate on this a bit and we see that then devices connected to the mesh (IP cameras, IP Phones, Laptops, etc) could be pointed at the mesh node they connect to for the NTP time and not need to support manycast or know the name/IP of a NTP server, and if they did support manycast they too could get the time directly from the stratum 1 server itself.

If we can get this working, it would support the philosophy that mesh nodes (and the GPS connected computers attached to them) would be able to join and leave the mesh and provide improved time-keeping while they are there without causing major disruptions when they leave. It would also allow for a level of redundancy that would scale well without requiring central administration (that might occasionally be unreachable from certain areas of the mesh)

So now that I've gotten this far, if you're not completely confused, if this seems like a reasonably feasible idea, and if I'm not completely mistaken on how things work, has someone already gotten something like this already setup? Is there anyone around interested in assisting with some collaboration and experimenting?

The lack of consistent time across the nodes of the mesh has kinda bothered me since I started reading and learning about hsmm-mesh and I am only just now starting to experiment with the mesh and learn about some of the inner workings. Please, share your thoughts, ideas, and comments regarding this and thank you for taking the time to read it.

Hello,

Let me start out by saying that I am very new to the Broadband Hamnet solution and mesh networking in general.  My experience to date consists of converting 4 Linksys routers (I had to bring one back from a brick) and running them throughout the house.  I have been able to successfully connect an internet gateway and have setup a v5 router (running stock Linksys firmware) as a wireless access point to one of the nodes.  I plan on experimenting with IRC chat, integrating with the home LAN, adding a file server and other solutions that others have previously setup. Unfortunately there are no other active nodes in Minneapolis so experimenting with range and antennas is on the back burner until I get more familiar with the firmware aspects of the technology.

That said, in the summer I volunteer for a Search and Rescue organization in North Idaho that provides communication support for local multisport events (triathalon, marathon, mountain bike races).  The organization has only used VHF radios and these can be unreliable (especially the 5W HT's) in the remote areas of the events.  My thought is that a mesh hinternet would be just the thing to improve voice communication and allow for adding video communication.  It's a pretty ambitious idea.  

What I'm hoping for from the group is an assessment of and help with building a mesh plan.  In the attached Google Earth .kmz file I have mapped out the locations that I want to connect.  In the file the push-pins labeled AS #x are aid stations on the course.  The main location is the Command Post (CP) located at the finish line by a local resort.  The goal is to tie these 11 locations together.  

To facilitate the linking I have picked 5 additional locations to put nodes.  Three nodes are on high points that surround the event course.  Two nodes are on high points that look down on the CP and which are visible to the 3 perimeter nodes. I have plotted paths and checked if they have line of sight and all look pretty good (a couple are iffy and are labeled with ??).

Since I have no field experience I'd like feedback if people think this is even feasible.  Some things I am worried about

• Is 16 nodes too many?
• The perimeter nodes need to hit other nodes in a field of vision that is 60, 90 and, in one case, nearly 180 degrees - is this even feasible?  
• How do you keep from having a choke point? I'm worried about the CP node.  I figured if it was visible from only one perimeter node then that path has to carry all inbound traffic from all the course nodes.  For this reason I thought adding a couple of nodes with view to the CP and the other perimeter nodes would give alternate routes and help relieve congestion.  Is this a good idea or does it cause more problems that it would solve?

I will not be able to experiment on-site until next June.  The first event is the end of August so there is some time to try out antennas and locations.  The winter will be spent acquiring more nodes and assembling weatherproof, battery powered, portable mesh node/WAPs so there is plenty of work to do.

Thanks for any and all replies.  

Bill

AC0LV

Hi,

We have plan to built high speed network for hams. I have found 2 solution

- Europe Hamnet v2.0 http://hamnetdb.net (database of hosts  Hamnet) where use mostly Mikrotik Devices with Point-to-Point Links. and hardware ubiquiti other page in english :  http://db0fhn.efi.fh-nuernberg.de/doku.php?id=projects:wlan:hamnet  and http://de.ampr.org/dokumentation/hamnet

Map of EU Hamnet http://hamnetdb.net/mapwindow.cgi?as=64695&site=

- Broadband Hamnet (Mesh Nodes) where is use routers like wrt54 etc with replaced firmware.

It will be interesting to more compare 2 solutions on one page with name http://hamnet.ampr.org

whre will be useful information for other countries which decide about  kind of hamnet network to use.

73 Waldek sp2ong

Hello everyone.

Just an update from here :)

Just updated the OS (raspbian) on My Pi and loaded up the hsmm-pi software.

Everything seems to be working nicely even after a couple of reboots that I needed to do to get some software to work that I wanted on it. Did this at the local library this afternoon and the software found my wifi usb card (a Airlink Awl3205 if I remember correctly) and did a scan and saw all the other access points that the library uses plus a few others.

Now to go and update the firmware on both of my wrt54g v.2 routers and see how they talk.

Found out how to get a ntp server up and running on the Pi using a gps for the time bas. Going to be a nice addition to my own personal network here :)

Seriously considering another Pi for the car for mobile and rovering.

James W8ISS

Lincoln Park, MI

EN82jg

Got one now

Ok I guess I posted a bit premature... but instead of deleting it, I will explain what I did to fix it

First Set your ip address static to 192.168.1.2 sumnet 255.255.255.0
Power off router and plug back in.
Now my router doesn't have the DMZ light. Instead the Wireless light will turn on while the power light is flashing.
At that point is when you press and hold the reset button until the wireless light (or DMZ light) start to blink
Now open a command prompt and enter "telnet 192.168.1.1"
Then type "Mount_root"
root@(none):/#
then type "uci get network.lan.ipaddr"
it will then give you an IP address. In my case it was "172.27.0.2"
Power cycle your router.
Set your computer to a static address in the same subnet ie. 172.27.0.xx (24)
subnet is still 255.255.255.0
default gateway 172.27.0.2

Now in your web browser enter 172.27.0.2:8080 (or what ever the system told you the ipaddress was

From here you can change the nat settings I found out as a router it doesn't hand out dhcp

I changed the setup to mesh AP (or something like that) after reboot it no longer gives out Dhcp

the model is a wrt54gs-tm  (tmobile version of the gsv3) there is no DMZ light. it was working fine until I changed that setting. Suggestions?