Hi,

We have a mesh network up and running on both sides of the Forth Estuary in Scotland. The VOIP works very nicely on nodes that are within a few hundred yards of the one containing the asterisk server.

However VOIP on nodes at around 10 miles distance is poor. We brought about a significant improvement by changing the distance setting from automatic to a suitable fixed value but audio is still broken up at times.

Default ping tests show good performance.  But pinging with a 10K payload gives us times of around 100-130ms and alarmingly, some 6 percent packet loss.  The latency is just within spec for a VOIP link but this packet loss is what I guess is doing the damage.

Just wondering if others have had the same experience ?

73

Bernie

GM4WZG

Thanks that helps a lot. It explains that the radio simply transmits back on the aerial it last got the best signal on. This would normally work OK but would not necessarily work very well for a station with two high gain aerials pointing in different directions as some have suggested. (well at least not when it was required to pass traffic from one direction to another). It would seem that two radios (one on each high gain aerial) connected by a cable would be a much better system.

GRE and NAT: This is a valid issue in terms of supportablilty and complexity to package a tunnel solution. The typical home/business network is NAT and additional manual setup outside the Mesh node would be needed for the hub GRE tunnel to establish.  

Although to put into perspective, vtund also needs to port forward the connecting port default 5000.   1 forward (vtund) vs 3 forwards (GRE).  

Referring to Johan, SM7I's, documentation of bbhn-GRE:

--------

Since GRE tunneling uses protocol 47 (GRE) and TCP 1723 this needs to be opened / forwarded in any firewall or NAT device, used in between the Internet and the HSMM node, towards the HSMM GRE node. Decide which node will be the responding device and open / forward protocol 47 and TCP 1723 to that node. This is normally called PPTP and often available as a preconfigured service in most routers / firewalls.

The other nodes can be seen as initiators and will thus be “calling” in to the node that you decided to be the “hub”

--------

Two item overlooked are the NAT problem and the filtering problem.

GRE through many routers won't work if NAT is involved, those that do support GRE may may have it disabled and at the moment directly exposing a node on the public web wouldn't be wise in my opinion.

vtund  has a better chance of working as it's either TCP or UDP based on config and can't be blocked based on protocol number(as GRE can) this may mean it is more likely to work on random networks as well, of course a true layer 7 firewall may be able to block it but that's even more rare.

GRE - by itself no encryption, light weight kernel mode tunnel, performance edge. Add on top ipSec for encryption also in kernel mode (or other designed encryption techniques/strengths over this tunnel). Googled internet posts claim it is more complicated to do encryption over GRE and depending on technique may limit the protocols.

vtund - on top of vtun kernal driver with everything else in user space. Packaged with basic level of 128 bit encryption->easier to setup. Doesn't limit protocols in use. I'd call this the middle ground solution.

What is best for our community? Depends... If we have no need to encrypt data carried over the internet, basic GRE with no encryption is lighter weight and straight forward. If we need to do encryption (let's say a city EOC has requirements to encrypt their data if going over the open internet), then vtund. If 'strong' encryption is required, then we'd want to look at something like openVPN (over vtun driver) and 1024 bit keys.

All, What do we as a community think are our requirements? What level of security (for the purpose of tunneling traffic over the internet to connect MESHes) should be packaged in a future release of bbhn? This need is likely the significant factor (while still considering options that are easy, supportable, and work). Any opinions?

For the sake of discussion, what are the advantages/disadvantages in vtun vs gre tunneling? 

I've setup gre tunneling before have not had the opportunity to play with vtun.

Corby

kd5aeq

got it

Not true. This is what is happening in the background: http://wiki.openwrt.org/doc/howto/generic.uninstall. You have to do it manually.

Zl4DK, Your answer can be found in Chapter 10 of WNDW on pages 7 and 8.

Hi,

Well, we are using GRE tunneling as we wanted to keep the footprint of implementation to such minimum that it could successfully be run on even the GL models.

I will be releasing the latest docs soon, but please feel free to look at the documentation found at http://www.ssra.se/upload/hsmm%20scripts.pdf

Here's my setup of vtun with instructions to install on both server and client. untar and check out the README files. Anyone that would like to connect to the mesh in Southern CA, send me email to exchange a password. My internet IP is already in the config files here...  ae6xe@cox.net 

Note, I've not tested my instructions with a fully clean test run.   let me know if I may need corrections. (but not with basic linux command line, etc.)

Download tar file here:

https://dl.dropboxusercontent.com/u/58390217/vtun_install.tar