Ok, will give it a go, tnx..

I see a wrt54g3g image under the Linksys downloads as well.

Yes you can load an older firmware if you want I to the node

Thanks Conrad

Can't flash the others in my set up as they are Linksys WRT54G3g ones, can I revert the 3.0  to the earlier non beta version

Andy

Version 3.0.0 beta will be running  protocol version 3 and is not compatible with previous versions.

Make sure to flash at least one other device 

Hi, I have two WRT54G3G modems with single aerial (sma), I have them running on a local mesh ok but what worries me is that the software allows selection of left/right/diversity but no single aerial facility.

Does anyone know if this modem with the current firmware is putting its o/p into the single aerial. I do not have anyone locally at the moment I can confirm signals with over a reasonable distance.

Hi, just updated my M2 to v3.0, that went ok, however I am not seeing any received s/n ratio or other modem on my local mesh. If I do a wi-fi scan I see about 25 locations so it is receiving ok but does not appear to be transmitting, any ideas?

good discussion.  sounds like GRE is "potentially" more NAT-unfriendly but lighter, and vtun is very NAT friendly but slightly heavier.  Sounds to me to be more "user friendly", vtun may be the way to go as it reduces the number of potential problem points.

D.

We may be all be thinking of 2 different scenarios for this discussion:

1) Production designed solution: Everyone build in DTDLink for this scenario and optimize the mesh infrastructure. Very bad idea to "jury-rig", need to be able to trust our mesh.

2) Incident/Emergency: Using duct tape to get something to work with the tools/parts available.

In the spirit of #2, what can work and what does one need to be aware of? While the relay node of 2 antennas in 2 directions on the 2 node's antenna channels 'works', what do we all need to be aware of? Is there a lot of re-transmission due to lost broadcasts on the wrong channel? 50% extra handshaking traffic? How do we quantify any deficiencies?

You might also want to set it up to use G729 instead of G711 (alaw and ulaw). The amount of bandwith drops by a factor of 10. G729: 8kbps (inc. overhead) vs. G711: 80kbps (inc. overhead) per each audio channel. Each call has two audio channels (1 send + 1 recieve). This also helps drasticly with call quality and chop. Plus, G729 does a passthrough with Asterisk so efficiency also improves too.

Each antenna port is basically a transmit receive chain.

They have always been intended to work in tandem to cover the same area.

The individual ports have been used (abused) by some in the past to create links that do not cover the same general coverage area as it was the only way at the time to link distant networks. This is a habit I'm looking to see to be broken.

The much better and really only reasonable method (based on hardware design) is to use DTDLINK to link nodes together.   Both antenna ports (on those devices that have them) can then be used to cover the same area letting you do dual polarity which can increase the performance of the network.

Also it may be wise for any real deployment to look towards the Ubiquiti gear over Linksys (use Linksys only for in lab experimentation and learning while the real nodes get that better RF performance of Ubiquiti)

For field day this past summer, I setup a UBNT rocket M2:

channel0: 24db grid antenna pointing 8 miles to another node and connecting into mesh.

channel1: 90 degree ~10dB sector panel pointing in another direction to support the field day site.

There was a hill and water tank blocking direct line of sight to the field day site. We were streaming video over this hop link. I didn't notice anything unusual or any unexpected degradation.

Most home and corporate firewalls in my experience muck up GRE when NAT is involved even when it is the initiator side.

GRE passthrough only really started appearing a few years ago on commonly sold routers. GRE does not play well when NAT is involved in my experience (Its been a while since I setup one but years gone by I've set up hundreds).

Also our friends at a very well known ISP that loves to filter traffic across their backbone and prioritize traffic has been reported in the past to flat out block the GRE protocol (by protocol number ) (they might of come off of that policy since but the fact they did it once)

If your attaching to some random network somewhere your going to want the most flexible you can get.

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”

--------