Thanks!

At the moment there is no other method for making all nodes receive the time.

You could go into individual nodes and configure them to use a local NTP Server instead of the pool server, this is discussed in other threads on the forum. 

LandOps 4x4 Offroad Club conducted a land navigation exercise near Cuddeback Dry Lake in the Mojave Desert on January 17, 2015. Participants communicated with each other via FRS, 2 meter ham radio, APRS and for the first time, by broadband mesh. (21 of the 28 participants in the exercise were licensed ham radio operators; seven of the ham operators brought a total of 15 mesh nodes which were deployed at various locations around the lakebed).

Background:  LandOps is a 4x4 Offroad Club with a special interest in land navigation, teamwork and communications.  In June 2014, the club held a general membership meeting at a site that happened to be adjacent to the South Orange (Orange County, CA) Amateur Radio Association’s Field Day site.  The members saw SOARA’s Field Day demo of a webcam video link over broadband mesh.  The demo piqued several members’ interest.  At LandOps’ next general membership meeting in October 2014, John Emig (W6CYS) brought two Linksys routers, a Linksys access point and a Foscam webcam which he had acquired over the summer; he gave an overview of broadband mesh networks and then he demonstrated how he controlled the remote webcam over the mesh network from a laptop which was connected to a local node.  Following the demo, a number of members began to acquire equipment and setup their own mesh nodes.

Terrain: Cuddeback Dry Lake is located in the northern Mojave Desert at an elevation of approximately 2500’ MSL. The lakebed is approximately 6 miles long and 2-1/2 miles wide at its widest point. LandOps base camp for this operation was located on a plateau approximately 4 miles northeast of the lakebed at an elevation of about 3500’. The ground slopes down toward the dry lakebed except that there are low hills of about 3300’ elevation (about 300’ higher than the surrounding terrain) midway between base camp and the dry lakebed. The edge of the plateau has direct line of sight to about half of the lakebed however, the base camp was located several hundred yards from the edge of the plateau, so it did not have direct line of sight to the lakebed.

Mesh Node Deployment: Based on an analysis of the terrain, a plan was developed to pre-position mesh nodes at various locations around the area in order to provide mesh connectivity between basecamp and mobile mesh nodes during the land navigation exercise.

Unfortunately, we only had time to establish a mesh node at location Bravo before the start of the exercise. Location Bravo was on high ground approximately ¼ mile from basecamp and it had line of sight to the lakebed (about four miles away). The node consisted of a Linksys router with a vertically polarized Yagi antenna connected to one antenna port and an omnidirectional antenna connected to the other antenna port. The node had good connectivity to the nodes located at basecamp, however, we were unable to establish a connection to it from the mobile mesh nodes on the lakebed. As a result, the mobile nodes deployed around the dry lakebed were able to connect to each other but were unable to connect to the nodes at basecamp.

Wi-Fi Access Points: Two fixed Wi-Fi access points were located at basecamp and connected to mesh nodes. One laptop computer was used as a mobile Wi-Fi access point and connected to a mobile node.

Applications:

• 1. Webcams. Five webcams were deployed during the exercise. One camera was in a fixed position at basecamp and four cameras were mounted in vehicles. The Foscam cameras performed well, and users could connect and control the camera from across the mesh (but the results were unpredictable when more than one user tried to control the camera at the same time). The D-Link camera required an Active-X or a Java plug-in so smartphone users were unable to view the video feed and laptop users received security alerts when they tried to access the camera. Two of the webcams were advertised on the mesh status page and were easy to access with a single click; the other three webcams required users to enter the URL in order to access the cameras. All of the cameras required a login or a login and password. To make it easier to use, recommend that all webcams be shown in the services section of the web status page, be given a consistent user login, and no password.
• 2. Email. An IBM Domino webmail server was located at basecamp. The server was intended to test the practicality of using web based email to send status reports to basecamp. An IBM Domino server was chosen because it was easy to setup, a host machine was available and an adequate number of demo licenses were available for this exercise. Unfortunately the lack of connectivity between the mobile nodes near the lakebed and the fixed nodes at basecamp prevented the use of email once the users left the vicinity of the basecamp. Future tests may involve establishment of more than one email server so that the servers can store and forward the email messages when they can connect to each other.
• 3. Document Library. The IBM Domino server hosted a document library. For this exercise, the document library contained copies of the topographic maps of the area and a copy of the communications plan for the exercise. The documents could be downloaded by a web browser as long as the user could contact the server.
• 4. IRC server. An IRC server was installed on a server located at basecamp. We did not have time to install, configure and test any IRC clients.
• 5. Network printer. An Epson 645 network printer was installed at basecamp. The printer was connected to an access point by Wi-Fi. Computers, tablets and smartphones, which were connected to the access point, could use the printer. We did not have time to configure the printer for remote access across the mesh.

Node Range: While enroute to basecamp, my Ubiquiti Bullet M2 with an Engenius EAG-2408 Omni antenna was able to make contact with KJ6DGG’s Ubiquiti Nanostation M2 at a distance of 12 miles. I was located on high ground west of the dry lakebed and KJ6DGG was at basecamp. As I descended to the dry lakebed, we lost the connection due to the terrain, and I was unable to regain the connection until I was one mile from basecamp.

The day after the exercise, I attempted to establish a connection between my Ubiquiti Nanostation M2 located at Bravo and a Linksys node with a vertically polarized Yagi antenna located on the lakebed four miles away. We were able to connect to each other’s nodes. However, when we attempted to experiment with two Yagi antennas on the Linksys router, one vertically polarized and one horizontally polarized, we lost the connection and could not regain the connection even when we switched back to one antenna. We need to conduct more testing to determine the practical range of mesh nodes using various combinations of hardware, directional and omnidirectional antennas.

This mesh status screen shows 11 of the 15 mesh nodes which were online at basecamp before the start of the exercise.  The other four nodes were offline.

Foscam webcam at basecamp:

KJ6DGG's mobile node setup:

KI6MLU's mobile node setup:

Cuddeback Dry Lake as viewed from Fremont Peak.  Basecamp is behind the low hills at the right of this picture, approximately 10 miles away.

Network operations.  The Epson 645 printer is on the left, next to it is the MacBook Pro which hosted the IBM Domino email server and IRC server, the large display and black laptop on the right were used to monitor APRS.

If I understand the problem correctly that from node 1 you see node 2 and 3 over the medh status page but clicking on the link you can not pull up their stays page than it sounds either like a computer routing issue (make sure your computer wifi card is turned off) or a DNS resolution failure (try using nodename.local.mesh:8080 instead of nodename:8080) 

Any node that is connected to the Internet on its wan port will update it's time automatically using NTP.

In addition if a mesh gateway is available the node will automatically use that node and update it's time as well though care should be used as meshgw opens the network up to all traffic and may be hard to control.

Dear Members,

I was using my IRC CHAT server installed in my LOCALNODE WRT54... and I noticed that the time was way off ... years even... How can I update the time on mine and others on the BBHN?... Has anybody tackled this?...

Any ideas appreciated...

73 Dave WA5DJJ

Hello All,

I am having a puzzling problem here.  From my node (1) I can directly see two other nodes (2 and3).  I can not connect to them and I can not see anything they are seeing.  When I open OLSR under the ALL tab, and look at Neighbors, I can see the stations that should have been repeated through Node 2 and 3.

Additionally, again under OLSR, in the TOPOLOGY field, I can see everything repeated my Nodes 2 and 3.  The same holds true under the OLSR MID entries.   Again, no resolution when I try to view under the MESH STATUS tab.

I can also see this OLSR data on other nodes connected ( 4-5-6-7) via DTDLINK, but again does not show up under the Mesh Status Tab.

It also appears that at least one other person in our group is having the same issue

This network is running Ubiquity devices and using a mix of version 3.0.0 and 3.0.0. beta which through a command line operation, disabled the Watch Dog timer.

History,  This network was working just fine using UBNT a 5.8 GHz network as a backbone with the UBNT Tough-Switch's having its own VLAN-2 named DTDLINK.

I look forward t hearing from you.

Respectfully,

Paul Strauss

WD6EBY

Update... There are now two Ubiquiti nodes at the repeater site on Mt. Berryessa, AG6QO-600 is a 120 sector antenna and AG6QO-900 is a 20dB AirGrid pointing at K6JAC. At K6JAC, we have another AirGrid AG6QO-700 pointing at Berryessa Peak and an omni, AG6QO-800. The two air grids have LQ of 100%. These are permanently installed on battery backed power. This is a 16 mile link with stock power and antennas.

K6WLS-100 is able to connect to both Berryessa nodes with another AirGrid in Woodland. A 21 mile link! But we are still trying to determine a permanent location for his nodes.

Joe

AG6QO@AG6QO.#NCA.CA.USA.NOAM

Waldek,

Thank you for the great set of links on 802.11s, that's very useful reading. I should add that 802.11s meshing basically uses very similar protocols to olsr, but does that on L2, using MAC addressess instead of IPs. Read "switching" instead of "routing". And indeed, that's how it is supposed to be done in the small/low range environment, like meshing all the "Internet of Things" at home.

Broadband-Hamnet is using L3 routing instead, which works better for larger installations, and if the developers were to convert it to 802.11s for some reason, it would be easier to just rewrite the whole thing. Also, DTDlink would not be available with 802.11s, and it allows people to interconnect 2.4 GHz network with 5 GHz and 3GHz links, as well as using VPN tunnels. On the other hand, if you have a 802.11s mesh (really?) that you want to connect to Boradband-Hamnet, it can easily be done, as OpenWRT has support for it.

73 de VA3IDL

Hi Andre,

I thing that UBNT devices M2  will working good blow 2400 Mhz because in original firmware AirmaxOS in Compliance Test mode you can select channels 255-237 (see attached scren dump from AirMAXOS) and you can  see in my last post with attached screen dump where I show SNR and signal strength for different  channels

73 Waldek SP2ONG

Attachments
 airmax-ns2.jpg [103 KB] ::

This is really the same as you would deal with it in any IP network.

If the system is suppose to be accessible by others the best bet would be to actually advertise a name under the DHCP Lease setup.

Second to that assuming you have admin permissions on the remote node in question looking at Setup > Port Forwarding, DHCP, and Services >  DHCP Leases  will let you see each IP address that has a current lease (and can assign a name to it if you choose)

Failing that the best way to get the details would be from the PC itself  using ipconfig/ifconfig (depending on operating system)

NetBios names will not be passed over the mesh as each node is a router break location which stops broadcast NetBios advertisements

Of course all this assumes Direct mode, if your in NAT mode you will have to setup port forwards as the PC's LAN IP will not be routed over the mesh.

Let's say I have a pc connected to a node.  On another node, I have another pc.  I would like to use VPN or even access a share on the first pc from the second.   How can I find the ip address of that machine?  

Will bbhn pass netbios names?

I have looked in the node status and olsr pages but can't find what addresses are being assigned to machines attached to nodes.   

Thanks.

I have updated my nodes to the latest firmware.

I was able to establish internet access through the mesh.

Looking at applications for EMCOMM support.

Sometimes it's just about knowing where it is hidden in the website. iOS 8 bug won't let me post the URL but it's under Table of Hardware (TOH) -> Ubiquiti -> AirMax M 

This is a curiosity query. I clicked on the Open WRT link to their website and perused the supported hardware list for Ubiquiti products. I do not see the Rocket (any version) listed as supported hardware. I am curious as to how the Rocket managed to become a BBHN supported device.

Hi Andre,

Thanks for info I will looking on this ART (Atheros Radio Test) (http://wiki.openwrt.org/doc/techref/flash.layout)

At current I can do very simple test show how is signal strength for a few different channels with display of SNR. Please look attached screen dump

Attachments
 pwr-channels.jpg [164 KB] ::

You don't need to go to Tomato, then Linksys, then something else, unless you don't have access to TFTP software and failsafe mode.  The wiki steps for reverting with TFTP don't work because the router isn't configured to listen for TFTP requests by default.  In order to turn this on, connect to the router in failsafe mode and enter the following commands:

nvram set boot_wait=on
nvram set boot_time=10
nvram set wait_time=10 
nvram commit

Have your computer's IP set to 192.168.1.2/255.255.255.0.  Have a Terminal or Command Prompt window open pinging 192.168.1.1.  Connect your computer's Ethernet port directly to the router's switch ports.  Power cycle the router.  As soon as you see pings respond, you have 10 seconds to initiate your TFTP transfer, either by command line or by some GUI or whatever.  The point is that you have 10 seconds and that it will work reliably.  All you have to do is connect to the device within those 10 seconds for it to hold in failsafe mode and wait for you to send the firmware over.

You can use this to directly install any compatible firmware to the device, but use files that end in .bin.  I don't know if .trx files will also work.

Caveats:

• These instructions are for Linsys devices and have been tested on WRT54GL.  They should work for other WRT54G devices.
• Failsafe mode and the commands above are specific to OpenWRT and its descendants (BBHN, etc)
• Be sure that the firmware you're using will fit on to the device!  Standard disclaimers apply - if you put the wrong firmware on, you're going to permanently brick the device.