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!

I like playing with power – do you? :) [tangent warning]

I have an old Pontiac whose speedometer stops at 120mph. At the track, when the lights count down, and you release the trans-brake, it will bury that little needle in short order. When passing the finish line, the big sign lights up with something over 140 mph. But that may have something to do with the blower sticking out of the hood and the nitrous being sprayed into the intake manifold... That car does NOT do traffic on the highway... Ever... It only goes in a straight line, for short distances, very quickly...

Hot rodding a Linksys router is kind of like tossing dual turbos on a VW bug... It's kinda cool! But don't expect to be worth much in 5 o'clock rush hour... (And yeah, I have seen this done MORE than once! Those were some SCARY little bugs!)

I fiddled with bumping up the power output of the Linksys routers... In the long run, it was a waste of time. They were never meant to become high performance RF links. It's like strapping rocket motors on a bicycle...  Bump it up just a little and it starts to distort and splatter all over the place!

With that being said... I have been experimenting with bi-directional amplifiers. Amazon LOVES ME!

Here is ONE I have found that works as advertised, and I have tried several...

http://www.amazon.com/gp/product/B00CR6V0GS/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

Installed in my mobile unit (Toyota FJ with a 120VAC converter plug in the back) with a Ubiquiti bullet M2 driving it and a 9db omni mag mount on the roof, my range to my tower mounted node went from barely 1 mile to 3-5 miles omni antenna to omni antenna. With a 24db BBQ grill dish, I always wondered if birds will fall out of the sky... :)

NOTE to the masses: Microwave radiation isn't anything to mess around with... If you get a headache and your eyeballs go fuzzy, TURN IT OFF! And NO, I am NOT kidding! The damage to your eyes will be PERMANENT! For testing, I put my stuff OUTside the metal barn, go inside and close the doors and make sure nobody is around my test antennas when I am “playing” with my toys...

But much like those dual turbos on a bug... Hot rodding your gear may not be the most reliable way to go. Amps DON'T work miracles, but they CAN make a difference. Gain at the antenna will get you more bang for your buck and be more reliable in the long run...

But hey – I like playing with 140 mph hot rods... :) It keeps me out of the bars. I'm still waiting to zap that pesky mockingbird on my tower though...  One of these days...  I want to find a crispy mockingbird in the grass...

Bill – N5MBM