After some more experimenting, I have not had any dropped calls and two-way audio on a call between one of the 3CX softphones on a laptop and one of the Linksys SPA941 phones connected to the same node.  Seems to drop calls only when calling a hardwired phone or softphone/laptop combo that is connected to another node.  For testing purposes, each node is simply in a different room in the house and most of the time have 100% or near 100% link quality.  Does anyone know if there is something that I need to change on the nodes to help?  Thanks....

I just updated my WRT54GS to 3.1.0. It's set as a gateway, and hooked to my router via the WAN port. My nodes cannot connect to the internet.  They're all still on 3.0.0. 

Any ideas from the Gurus?

Ok so I am missing the boat here, how in the world do you install the patch to take the node from3.0.0 up to 3.10? I tried to upload the file to the node but don't like it, can someone tell me please what I am doing wrong....

         Thanks, W4WWS

The release notes for 3.1.0 say to download HamChat from the Download Package options on the Administration page.

I just loaded 3.1.0 on a Nano, refreshed the Packages, but do not see HamChat as an option to download.  Am I missing something or is it called something else?

Hello All,

I now have two ubiquity units, Nanobridge M5 and a Rocket M2, that will not allow me to save the MESH configuration.  I have tried every possible setup choices and still no joy.  I have setup may of these units with success, the process is pretty straight forward.  Furthermore, I have tried to re-flash the Factory Ubiquity code back into these units with tftp2, again I have done this many times before with great success.  But this time in flashing UBNT factory load, it never takes.  The MESH program remains loaded in the unit in the initial setup mode.

Have you seen this before?  Do you have anything else I can try?  These units were both working just fine with the Ubiquity load before this Plague came upon me.

Please Help...

Paul Strauss

WD6EBY

Hi,

I have seen this issue pop up every so often. I think its from the cookie expiring or something weird going on, but cant quite trace it down.

If you log out then log back in, that should clear it up and you can then hit the map.

73

Hi everyone,

We´ve now built new lightweight VTUNd binaries in our 'code factory' for the WRT54GL models as well as for x86/x64 Linux.

This VTUNd has been implemented in our existing VPN solution aside with GRE, but enables NAT traversal without all the hassle, still FCC Part 97 compliant though.

Flawless communication between WRT54GL models as well as cross-communication between WRT54GL and x86/x64 Linux hosts.

Anyone interested in this can drop me a PM.

ACARES (Alcorn County Amateur Radio Emergency Services) MS. is attempting to build out a 900Mhz

mesh network utilizing Ubiquiti  NanoStation Loco units with bbhn firmware 3.0.0 installed.   We find

that we need more gain out of these units to establish our beta link (about 4 miles).  With the current 

version of firmware the only options that we can see is to utilize the internal antenna.  The factory 

firmware gives the option of utilizing the internal antenna or an external antenna (via the SMA 

connector).  Are there any plans to incorporate the option to utilize the external antenna option

in future builds of the firmware?

73,

Bob / K0RIS

Dave,

The UPS man brought me an Airgrid M2 today and I've flashed it. It's chatting up my 3.0.0 WRT54G units here just fine. Will probably get them all upgraded to 3.0.1 soon.

Once it's safe to go up on the roof again (soon? snow tomorrow!) I'll get it positioned and oriented in your node's direction.

I'm not overly optimistic, but we have to start somewhere, right?

73

Mike

K2MTS

I was debating whether to put this in Applications or the Developer's Forum.  Well, here it goes.  I posted a small tutorial about adding shell scripts so that the Reset and/or the SES buttons can activate scripts and other programs.  If yer not up to editing and creating shell scripts... sorry, but there's not much I can do to help you at this point.

Go to the menus on the left side (you may have to go back to the main page) and find 'Applications for the mesh' in the Resources menu. Click on that link and you should find my tutorial in there.

Have at it!  Have fun!

        -Rusty- 

I made a modification to this today to see if it would be more stable.

In olsrd.conf instead of modify the existing interface settings, I added a section:

#Mesh tunnel specific settings
Interface "tun0"
{
Mode "ether"
Ip4Broadcast   255.255.255.255
} 

I now have a pi setup as both a client and a sever.  Currently I have a Nanostation M2 connected as a client and I will monitor the connection and olsr routing info to see if there are any issues.

I am not a developer but I beta test most of the firmware before it is released. I have not seen Broadband- Hamnet firmware for XW devices yet.

The core team is aware of the progress the OpenWRT community has made regarding XW. It looks like their leading edge versions can support XW.  The current firmware is based on Attitude Adjustment and will need to be moved to Barriar Breaker or beyond for XW. 

It is being worked on but will take a while. There are a lot of demands on the time of the Volunteers working on this.

I have two NanoBeam M2's just waiting for the firmware to be available. I was one of the first people to get bit by XW.

I was able to get M5 XM hardware by calling a distributor and asking for old stock. I am not sure that is still an option.

Clint, AE5CA

I am also interested in hearing more about this.  Locally it seems 5 GHz is the way to go, less crowding and noise.  And around Christmas 2014 we started to see the XW problem with stuff we were ordering.

I think I already know the answer lies in the underlying OpenWRT support:

http://wiki.openwrt.org/toh/ubiquiti/nanostationm5

But it would still be nice to have one of the developers chime in on the matter.

As there seems to be some interest in this, here is what I did to get tunneling working from hsmm-pi 0.4.0 client to a BBHN 3.0.1 server.This did connected and I could see remote nodes and services listed but it did cause some problems that I haven't worked out yet.

BE WARNED! THIS DID CAUSE SOME PROBLEMS WITH OLSRD SENDING TRUNCATED DATA. DOING THIS MAKE BREAK THE MESH YOU ARE CONNECTING TO SO ONLY USE ON A TEST/DEV NETWORK

Preparation

When connecting to a BBHN tunnel server you are provided with a network IP.  This IP address is used to obtain the client and server IPs.

If your network IP is 172.31.15.152 it breaks down to:

Network = 172.31.15.152
Client = 172.31.15.153
Server = 172.31.15.154
Broadcast = 172.31.15.155

You will also need your password for the server and the external IP or server address to connect to.

All of the info below assumes you already have a working hsmm-pi node that is connected to an internet connection as a gateway/wan link

Install and configure vtun

Install vtun

sudo apt-get install vtun

Edit /etc/vtund.conf

Here is an example

options {
port 5525;
timeout 60;
syslog daemon;|
}

#Tunnel to server
AB1CDE-172-31-15-152 { #Use your own callsign and network IP to create the tunnel name
passwd MyPaSsWoRd; #Use the password provided by the tunnel server admin
type tun;
proto tcp;
compress lzo:9;
encrypt yes;
keepalive yes;
up { #Replace the IP below with your own IPs.
ifconfig "%% 172.31.15.153 netmask 255.255.255.252 pointopoint 172.31.15.154 mtu 1450";
route "add -net 172.31.15.152/30 gw 172.31.15.154";
};
down {
# Connection is down
};
}

In this example you will need to use your own callsign and network IP based on the info above

Modify the OLSRD config

In the file /etc/olsrd.conf

Find the following line:

Interface “wlan0”

Replace this with:

Interface “tun0” “wlan0”

Find the following line (it occurs twice):

Ip4Broadcast   0.0.0.0

Replace it with:

Ip4Broadcast   255.255.255.255

I left the Mode setting as "Mesh"

Connect to the tunnel server

To connect to the tunnel server run the vtund command

sudo vtund AB1CDE-172.31.15.152 tunserver.callsign.com

In this example you need to change the command to use the tunnel description from vtund.conf and the server IP or address provided by the tunnel server admin

Once the command has been run you should see a new interface called vtun0 if you run the command ifconfig

This will not automatically run at boot so the command will need adding to a startup script.

Troubleshooting

If it doesn’t work, try rebooting the Pi.  You will need to run the vtund command again to reconnect the tunnel.

You can check if OLSRD is sending data over the tunnel by running the command:

sudo tcpdump –i vtun0

You should see broadcast traffic from the 2 IPs for client and server.  If you only see the server IP then it indicates that OLSRD isn’t running correctly locally.  Check the config file and reboot the Pi

I managed to get this working to a degree.

vtun is straight forward and seems to work 100% The OLSRD side is a bit more tricky and although I managed to get OLSRD working but it was sending truncated data across the tunnel and breaking some of the other nodes on the mesh. Still need to figure out why so be careful!

In olsrd.conf I added vtun0 as an interface and changed the broadcast address to 255.255.255.255 A quick reboot and it worked. I

ts possible but be careful you dont propogate issues across the mesh.

I need some pointers.  I have an HSMM-Pi island that is meshing fine, and a BBHN island also meshing fine. If I bring the two together physically, they mesh together and everything is happy.

When apart, if I connect the islands via vtun, I am unable to route packets to other other nodes on the network.  I can ping the tunnel client/server from each side of the tunnel just fine, but packet routing (and name resolution) isn't happening.

I assume there are some changes I need to name to the olsrd.conf.  I added a section for the tun0 interface, but that didn't solve it.

Any suggestions? Thanks!