thanks John.

I don't think the forums allow/support PM.

email me at my callsign @ arrl.net

Darryl

K5DLQ

I have my first release of a web admin page for managing a virtual tunnel server.

Currently, it consists of a script to install everything (via ssh), and a new page in the web server to manage client connections.

The CLIENT side of things has a script and page as well.  However, I am still working on the web page side of it.

Would anyone be willing to poke holes in it for me?

A few notes:

• the server's starting "Network" number is derived from the eth0 interface mac, but, does allow for changing if you decide to change which node runs your vtun server.
  
• limited to 10 clients listed (due to tun0-tun9 being pre-defined)
• you cannot remove a client from the list, but, you can disable, or change the name/pass.  This is so that the network number allocation doesn't change.
• the network is a 172.31.0.0/30.  (1st ip is network, 2nd is client, 3rd is server, 4th is bcast)
• when you save, it regenerates the vtundsrv.conf file with "enabled" clients only, then restarts vtund.
• the tunnel names need to be the NODENAME of the remote client. (at least, that's what my client script/page will ensure).
  

73, K5DLQ - Darryl

Richard, you'll want to read up on this forum about DtDLink (cat5 cable between nodes) to connect them together across bands and channels. This acts as a bridge to route traffic between all nodes and distribute traffic on additional frequencies/bands to scale up.

Commotion Wireless and bbhn are both a) same hardware; b) mesh implementations that both use olsrd to route traffic; c) based on linux OpenWRT. The 'engines' are the same. But, they're packaged for different purposes. I think you'll find that bbhn is easier to setup and use with the capability as is with the ham communities' needs in mind. Commotion wireless comes with a number of ways to configure and deploy for a variety of needs--would require higher level of IT/networking skills.

Well, I have you to thank for using the NanoStation  -- It was one of your blog posts that helped me decide. In fact, I had bought a WRT54GL last April, just before I left the US for 6 months, intending to set it up as soon as I got back. When I got back, in doing a little looking around, I was convinced I had made the wrong choice (bbhn canceling support didn't hurt that decision) and sent the WRT54GL back to Amazon (they are SO good about returns) and got the Ubiquiti.

In my case I have trees blocking the center of my open view. So, I wanted greater coverage, but not in a continuous arc, thus the question.  I suspect that in the end, the NanoStation will be deployed elsewhere and I will end up with a Rocket here. But, I want to see what I can do at "the low end" first.

My experience with the NanoStation M2 is that if only need to cover 40 degrees then one node will cover that just fine.

The spec sheet I have from Ubiquiti shows a 55 degree H-Pol/53 degree V-Pol Horizontal beam width with a 27 degree vertical beam width.  I have had stations connect from the side over a long distance. 

If you need two nodes to cover a larger area, a couple feet of separation has worked for me

I commend you for starting out with the NanoStation. You will find it is a great device.  I have had NanoStations connect where nothing else we tried would.  The best part is you only have to add a shielded cat 5 cable and you are ready to put it up.  My math says it is about half the cost of setting up a node with a WRT54GL.  Our experience with the Nanostation here in Waco has made it our favorite device for new installations.  I recommend that people starting out with BBHN start with a NanoStation.

There is a kit made by rfarmor that can be used to add some shielding.  I have not tried them but have heard good things.  I have some on back order to evaluate.

Clint, AE5CA

1) There are a few things you can do to mitigate frequency contention with multiple nodes adjacent to each other. As long as the traffic demand does not exceed the limitation imposed by these nodes competing with each other, it will work:

    1a) there are sites which sell metal shielding between antennas;

    1b) use different bands with a 2.4ghz next to a 5ghz antenna;

    1c) use different channels on same band.

2) I recommend that you check out http://commotionwireless.net/, if the intent is to stay part 15 and build a local "community" mesh with non-hams. These guys and the firmware are built exactly for this purpose. I currently have one of these commotion community nodes joined as a node on my bbhn mesh for evaluation. Using a bbhn node for a part 15 usage would be problematic. Don't want to say that you can't legally do so, just that it raises confusion that can be avoided.

3) I've not looked into the Mac issue, but sounds like a domain search path problem on the Mac. Try adding "local.mesh" to the domain search path? Joe AE6XE

I am just in the process of setting up a node and have a few questions/issues I ran into. Hopefully this is the right place to post these...

For background I am using the NanoStation-M2 and have 2 of them at the moment.

1. Can I use more than one NanoStation node on the same mast? Or, maybe I should ask, what are the considerations of doing so. The idea would be to increase the coverage from ~20º to ~40º
2. The goal is to create a community emergency response network. If all equipment is kept to off-the shelf (part 15) equipment and no traffic is forwarded to any ham service, are there any licensing (ham license) considerations for using hnbb?
3. Any particular notes or tips on using the hnbb software with a Mac? I did see that the Zero-Config DNS entries (e.g. http://localnode:8080/) did not work.

Thanks for any help.

Richard

One could write a book on testing results of they had the time.

i can think of the following test scenarios off the bat

Based on RX signal level

Based on SNR

Based on set distance

etc.

 I belive the Ubiqutit are better all around, and I suspect the lower CPU speed and onboard chips have some decrease on performance overall at the high end, it may not be relevant for average in the field deployments. 

i do suspect that is a large part of (having not witnessed the test and not knowing all the ins and outs of your environment) why you saw a significant slow down between the direct and the 2hop.  I do expect some decrease though (50-60%) as the channel becomes a half duplex link that has to repeat the content (same as 1200 baud through a digipeater) but would expect it to taper off the more hopes you get as you get to a point where one set of nodes is receiving while another is transmitting.

Careful planning of core links as you mention (like the local 2.4 with 5ghz backbone to get to far points) will certainly help this as can using a different channel when you have multiple nodes at a site.

Whomever does test may want to consider iperf, it is made for speed testing and may help remove any web server performance issues as well.  I've used it for unscientific testing of different rf paths but nothing scientific as of yet.

One could write a book on testing results of they had the time.

i can think of the following test scenarios off the bat

Based on RX signal level

Based on SNR

Based on set distance

etc.

 I belive the Ubiqutit are better all around, and I suspect the lower CPU speed and onboard chips have some decrease on performance overall at the high end, it may not be relevant for average in the field deployments. 

i do suspect that is a large part of (having not witnessed the test and not knowing all the ins and outs of your environment) why you saw a significant slow down between the direct and the 2hop.  I do expect some decrease though (50-60%) as the channel becomes a half duplex link that has to repeat the content (same as 1200 baud through a digipeater) but would expect it to taper off the more hopes you get as you get to a point where one set of nodes is receiving while another is transmitting.

Careful planning of core links as you mention (like the local 2.4 with 5ghz backbone to get to far points) will certainly help this as can using a different channel when you have multiple nodes at a site.

Whomever does test may want to consider iperf, it is made for speed testing and may help remove any web server performance issues as well.  I've used it for unscientific testing of different rf paths but nothing scientific as of yet.

It tells the lower layer hardware (wifi chip) how long it should wait for reply on messages it sends.  Time is calculated based on the fact that RF takes time to travel through space.  Internally the hardware has some items it expects to happen within a certain time window and that is usually based on the signal being within a short distance of the hardware (feet vs miles.). Providing this value let's the hardware know it needs to wait longer. 

Too low and you can end up where data either gets sent multiple times or that the connection doesn't establish.

I understand to set the distance in K to the farthest node you would like to contact and have performed this operation.

What actually does this setting do is my question?

As perhaps not setting it correctly could hinder operation etc. I have no idea as to what it changes,

Thanks,

Marc

Km6b

You are correct, I should have verified that by SSHing into the node and issuing the iwinfo command

Perhaps I'll redo the test later down the road, or maybe this thread will inspire someone else do further throughput testing

Hello Steve,

Yes the WRT54GS is included in this.  Essentially any device that is a WRT54 or variant (any device using a Linksys firmware image at this time) will be ending support in April 2015.

The devices will continue to work after this date, it's just this is when we have chosen to announce as the end of  newer firmware image development. This means if you have a node in the field you will still have time to upgrade it even after the end of support date. This also means you can still use them to test and demonstrate mesh networks with as the firmware files will still be downloadable.

Plans are also circulating around on documenting how the devices can be repurposed for other uses such as local access points or as a smart switch to break out the additional ports from a Ubiquiti device and should start becoming available as we move closer to end EOS date.

We don't expect to see them disappear, just to find a new purpose in the mesh environment.

Am I to assume that support for the WRT54 GS series of LinkSys routers will also end in April 2015?

Steve

Correct, when you use an unmanaged switch (a 'dumb' switch) they will generally (i won't say always, but I have never seen one yet that doesn't) forward the entire Ethernet frame through the switch.

802.1q vlan tagging is done inside the data portion of the frame. An unmanaged switch only cares about the Source and Destination MAC address (some don't even verify the packet is not corrupt while others do but that is just a CRC check.)  Knowing the source and destination an unmanaged switch can forward the packet out the correct interface (in the case of an OLSRD packet it should be broadcast to all ports as a broadcast frame)

A easy image of this is: http://en.wikipedia.org/wiki/IEEE_802.1Q#mediaviewer/File:Ethernet_802.1Q_Insert.svg

A smart/managed switch on the other hand actually looks into the frames (to one degree or another) and performs additional actions.   Layer 3 managed switches will go all the way up to IP address parts of the frame while others will only act on Layer 2. Cisco has both these options available.

A managed switch can go "the extra mile" of setting and checking policies.  In the case of a Cisco switch if the interface is not tagged as a trunk port it will STRIP the trunk data off (this acts as a method to prevent an end user from feeding 802.1q up the interface and bypassing your routing/firewall systems) to ensure the data transiting the port meets the ports policy setup.

So if you use an unmanaged switch you end up in a situation where the tagged frames can pass as the switch knows nothing about it, when you use a smart switch you end up in a situation where it 'violates policy' to let the frame pass unless the switch has been specifically configured to permit it. 

I'm sure some managed switch out there is more permissive in that regard, but I haven't had one in my hands yet.