I can say I am seeing a bit of the same out where I am, though at the same time I am lucky in I'm seeing a  selection of local operators whom are supporting the project as well.

Out here in San Diego where we have a significant terrain problem we are going with trying to get a backbone built first that we can feed off of to provide more localized access.  This makes it s lot more like a typical repeater build in theory if you can find a high site that can feed out to lower level feeder nodes whom than provide acess out to users.

We still have to proceed and see how well this works out, but that is our concept right now out here. Once we have the backbone than it becomes s bit more of a build out and areas that want/need the network can invest.

The other item I see a lot of is explaining what can be done with the network, to many it is not obvious what benefit they have by moving to it, I think the key to this will be finding some unique content.  I've been thinking of things like recording of meeting videos that may only be available via the mesh until they are a year old for those whom can't make club meetings,  project documentation, etc.

I also suspect in our local case convincing the CERT (Community Emegrncy Response Team) and the other users of Winlink (send s 1mb file that should cause an issue) in our case will be where some of the build out will be.  

Thought his is all speculation at this point we will have to wait and see how it actually plays out.

We have started to create a mesh in our city.  Some significant issues.  The terrain (especially with tall buildings) means we need lots of nodes for infrastructure. I am getting a strong 'have you build it yet' from the local ham population.

How have other areas financed (or convinced the local hams) to be involved (AKA donate kit) ?

Unlike a repeater which only needs 2 or 3 guys to do EVERYTHING, a mesh needs to be a community project.  What if the community is not ready? Do we cancel and use the existing kit for other purposes or keep pushing slowwwwwly forward? Even when we setup the packet nodes & PBBS 25 years ago, it was only a few hams that really got involved.

Any words of wisdom are welcomed.  Even doom and gloom are welcomed. Will the mesh catch on with the general ham population or is this going to be the pet project of a select few?

Antenna gain doesn't directly relate to power consumption, it only relates in the fact with higher gain antennas the beam is more focused and it is possible the RF transmitter could use less RF energy (and by extension less DC energy) to go the same distance.

Antenna selection is a whole category of its own.  There have been discussions in the forum on this about Polarity, gain, etc that would be a good read as well as the WNDW book would likely also have some good documentation on this to get you started.

1) You can't connect wirelessly to a mesh node, only other mesh nodes can connect to each other.

1a) Both nodes need to be mesh nodes (but need to have different call signs)  by default we use a directly reachable IP address so you would not need to open ports unless you change to NAT mode.

1b) See answer to 1.

2) See 1. Once you are hard wired yes you are connected to all the other nodes (note: you need to think of it as a routed network not a single broadcast domain aka you can't do an auto find from most printer drivers)

3) we don't use 255.255.255.0 anywhere on the network in direct mode it is either 255.0.0.0 for the wifi/dtdlink interface or 255.255.255.<matches number of hosts in direct>.  By the mode where you can change up address I assume you mean NAT mode? If so you can set however you want however you should avoid using a 10.x address as it will route your away from the mesh meaning you won't have full mesh access. NAT mode is not recommended if you can avoid needing to use it.

5) yes you should see all other nodes if they are in RF range.

5) See user documentation at left side of screen for some initial guides you should read. Especially the QuickStart and using the user interface guides.

When I get to the point of tweaking with power settings on the mesh nodes and installing omnidirectional antennas, how would I figure out the optimal configurations. I want the ability for each node to have their own dedicated power source...of course. If I recall, the higher the gain on an antenna, the more power it will require. Ideally, you would want your mesh to cover as much space as possible and likely with the least nodes as possible. So what is an ideal gain for an antenna (for distance and power requirements) and what power would be needed? Granted, we're probably not talking about pushing 10 miles from one node to another, so I get that, Im kind of trying to figure out what all I will need, in hardware and what I should expect for distances (to figure coverage) between nodes.

So, over Christmas eve and day, I had time to play with my two mesh nodes that I am experimenting with. Both are up and running, I see both on my available networks on my laptop but I do have a few questions that I cant seem to answer. I am an IT guy but certain parts of this mesh network stuff still appears to be wizardry at work. Here are my questions:

1.I was wirelessly connected to "mesh node 1" and then had my printer...oh my word I think it just hit me what I did wrong. Let me play this out and find out for sure from one of you. I had my printer hooked up to "mesh node 2". Both nodes setup as "mesh node" in the firmware. I wanted to try printing through the mesh. I couldn't get the printer to even connect to "mesh node 2". Here is what just hit me:

1a. If I physically hook the printer up to the LAN port, I will need "mesh node 2" to be in a different mode (I forget the name of it atm) that will open those ports up for use don't I?

1b. I can connect to routers wirelessly, which is how I have it now with my home network. So if I didnt use a LAN port, perhaps that would work?

2. Lets pretend I have 5 mesh nodes, if I wirelessly connect to any of the 5 mesh nodes I'm technically connected to all nodes, is that correct since a mesh is one big interconnected network?

3. I noticed the IP addresses for each node are 10.x.x.x (which is a class a) and have a subnet mask of 255.255.255.x (which is a class C subnet) and cant be changed, but with the IP address I can change can I assign any class IP, and does the subnet have to be a class C subnet?

5. When I am browsing through the firmware on one of my nodes and go to the screen that shows other nodes, I am assuming I should see all of my other nodes on the screen right? If I don't what would be some possible reasons for this?

5. Lastly, are there some certain setting I need to make sure of when I configure each node? Like I said, all appears to be working fine, other than what I have mentioned in my comments, so I may already have established those configurations.

Thanks in advance for all the help. I greatly appreciate it.

latest news on mesh effort in Md

www.remoteamateur.com

The workshop last week went well.
There were about 8 folks in attendance, and we got probably about as many nodes loaded and configured.

Afterward, visited the location of our next node to make the hop to the BARK repeater site. Made the connection with a 20dB AirGrid 15 mi away from the ground just roughly pointing in the repeater direction.

The node will go up about 30 feet on a tower, as soon as I can assemble the mounting hardware.

Joe

AG6QO

The big questions are:

How do these look on a spectrum analyzer?

Did you manage to extract cal data or are you just running these open loop? if you did what frequencies did you add for the control points and would you be willing to provide the code for the cal eprom reading files.

Are your running low power because the units have been seen to push the PA high as you go down in frequency or are you running it low just for testing?

Have you you tried these to see if there is any difference in RF modulation/demodulation performance as we push the chips out of band?

Hi,

I spent many hours on the code openwrt and I received the opportunity to use channels Between 2312 - 2407 MHz with numbering 237 to 255 like use AIrmax OS for superchannels.

Below result of command iw and iwinfo on my openwrt UBNT M2 to show channels available in my openwrt version. I have start from 2362 Mhz because in Europe it is first frequency on which we use digital communication for Hamnet but it is not problem to add start from 2312 Mhz with channel number of 237

========================================================================

root@HamNET:/# iwinfo
wlan0     ESSID: unknown
Access Point: 00:00:00:00:00:00
Mode: Client  Channel: unknown (unknown)
Tx-Power: 12 dBm  Link Quality: unknown/70
Signal: unknown  Noise: -86 dBm
Bit Rate: unknown
Encryption: unknown
Type: nl80211  HW Mode(s): 802.11bgn
Hardware: 168C:002A 0777:E012 [Ubiquiti NanoStation M2]
TX power offset: 12 dB
Frequency offset: none
Supports VAPs: yes  PHY name: phy0

root@HamNET:/# iwinfo wlan0  freq
2.412 GHz (Channel 1)
2.417 GHz (Channel 2)
2.422 GHz (Channel 3)
2.427 GHz (Channel 4)
2.432 GHz (Channel 5)
2.437 GHz (Channel 6)
2.442 GHz (Channel 7)
2.447 GHz (Channel 8)
2.452 GHz (Channel 9)
2.457 GHz (Channel 10)
2.462 GHz (Channel 11)
2.467 GHz (Channel 12)
2.472 GHz (Channel 13)
2.362 GHz (Channel 247)
2.367 GHz (Channel 248)
2.372 GHz (Channel 249)
2.377 GHz (Channel 250)
2.382 GHz (Channel 251)
2.387 GHz (Channel 252)
2.392 GHz (Channel 253)
2.397 GHz (Channel 254)
2.402 GHz (Channel 255)
root@HamNET:/# iw list|grep "MHz"
* 2412 MHz [1] (18.0 dBm)
* 2417 MHz [2] (18.0 dBm)
* 2422 MHz [3] (18.0 dBm)
* 2427 MHz [4] (18.0 dBm)
* 2432 MHz [5] (18.0 dBm)
* 2437 MHz [6] (18.0 dBm)
* 2442 MHz [7] (18.0 dBm)
* 2447 MHz [8] (18.0 dBm)
* 2452 MHz [9] (18.0 dBm)
* 2457 MHz [10] (18.0 dBm)
* 2462 MHz [11] (18.0 dBm)
* 2467 MHz [12] (18.0 dBm)
* 2472 MHz [13] (18.0 dBm)
* 2484 MHz [14] (disabled)
* 2362 MHz [247] (18.0 dBm)
* 2367 MHz [248] (18.0 dBm)
* 2372 MHz [249] (18.0 dBm)
* 2377 MHz [250] (18.0 dBm)
* 2382 MHz [251] (18.0 dBm)
* 2387 MHz [252] (18.0 dBm)
* 2392 MHz [253] (18.0 dBm)
* 2397 MHz [254] (18.0 dBm)
* 2402 MHz [255] (18.0 dBm)
root@HamNET:/# iwinfo wlan0 tx
* 12 dBm (  15 mW)
13 dBm (  19 mW)
14 dBm (  25 mW)
15 dBm (  31 mW)
16 dBm (  39 mW)
17 dBm (  50 mW)
18 dBm (  63 mW)
19 dBm (  79 mW)
20 dBm ( 100 mW)
21 dBm ( 125 mW)
22 dBm ( 158 mW)
23 dBm ( 199 mW)
24 dBm ( 251 mW)
25 dBm ( 316 mW)
26 dBm ( 398 mW)
27 dBm ( 501 mW)
28 dBm ( 630 mW)
29 dBm ( 794 mW)
30 dBm (1000 mW)
======================================

I have use Nanostation2 and Nanostation M2 to configure local hamnet network with Mesh node base on 802.11s

http://en.wikipedia.org/wiki/IEEE_802.11s 

https://github.com/cozybit/open80211s/wiki/HOWTO

instead OLSR

It is example how this work with NS2 and M2 UBNT:

root@OpenWrt:/#
Station 68:72:51:06:39:b1 (on mesh0)
inactive time:  20 ms
rx bytes:       15043
rx packets:     258
tx bytes:       8639
tx packets:     61
tx retries:     7
tx failed:      0
signal:         -24 dBm
signal avg:     -26 dBm
tx bitrate:     48.0 MBit/s
rx bitrate:     54.0 MBit/s
mesh llid:      933
mesh plid:      1578
mesh plink:     ESTAB
mesh local PS mode:     ACTIVE
mesh peer PS mode:      ACTIVE
mesh non-peer PS mode:  ACTIVE
authorized:     yes
authenticated:  yes
preamble:       long
WMM/WME:        yes
MFP:            no
TDLS peer:      no
root@OpenWrt:/# meshp
DEST ADDR         NEXT HOP          IFACE       SN      METRIC  QLEN    EXPTIME         DTIM    DRET  FLAGS
68:72:51:06:39:b1 68:72:51:06:39:b1 mesh0       8       171     0       4970    100     0       0x15
root@OpenWrt:/#

Merry Christmas

73 Waldek sp2ong

Thanks again,

looking at the LAN router, but there is no link to the switch. I do find both the NS2 & NS5 on the LAN.

I think I will reset the switch and start over. I believe I need a path to VLAN 1 (as you suggested from the LAN.

Looking at the book (RTFM) the first 3 VLAN are default and all others are created as static. I also need to better understand the routing. At present I have the admin, all flags set.

When I get this fat fingered out, I will post the final configuration.

Merry Christmas

mike

Most likely the switch obtains its IP Address from VLAN 1 meaning it is now obtaining its IP address from your LAN (you will need to check your local network DHCP server) instead of your NanoStation.

A setting may exist to choose what network it obtains IP address from, or to manually set the IP address or to choose what network the switch can be managed from. I am not familiar with your specific switch to know any of these for sure, just that these are very common config options that may or may not exist on your specific device.

I would generally suggest keeping it if possible on an IP address that doesn't consume an IP address from the Mesh as you may want to use those some day for another device.

Your first comment seems a bit off as your netbook on port 8 should be able to connect to the Internet (and I would assume the switch)  Check to make sure you haven't misconfigured the port, though that said in order to do the 2nd part of your request of how the port 8 netbook can access the node you need to move its Primary VLAN ID (PVID) or what you appear to be calling an LVID to be 10, it should be a member of port 10 untagged, and should be a member of no other vlans.

For the back to back dtdlink you need to setup a port to have a tagged vlan of 2 active on it, You could use 20 for the PVID to allow the node to be 'isolated' from the other nodes lan ports.  You would also need to add tagged VLAN 2  to the port 2 as well.

VLANS are basically virtual networks,  you can think of them almost as if they were on different switches  even though they use the same wire.

There is currently no method for easy configuration of backhauling over another service.  I know a VPN project/gui is being worked on (see forums) but I don't think it is done yet.

Greetings!  I'm Jerry A. Goodson from Atlanta, Texas.  I was in Little Elm yesterday when I heard the announcement on the 145.170 for the BBHN net on the 146.920 at 1400.  I delayed coming home earlier to check in on the net, but I first wanted to know what the heck BBHN meant.  Now, I know!

I am EXTREMELY thrilled this has become an Amateur project, and I'm wanting to participate.  I've already thrown out some local buzz about in on my home repeater once I got home.

I'm hoping to have an IRC server up on my radio, as well as a Wiki.

OK, Working with V3 NS5 connected to a netgear 108tv2 swtich.

Goal - create a series of vlans to match Clint's description (see ubnt firmware).

(1) boot ns5 connected to port 2 of switch

(2) port 3 connected to linux desktop

(3) port 8 connected to windows 7 netbook

(4) port one not connected - targeted for connection to home network to provide internet

Both computers can access the node and the switch but no connection to the internet

(1) access switch on the assigned ip

(2) using switching/vlan tab

(3) define vlan 10 (named N504)

(4) change membership of vlan one = port 1 = U / port 2 = T / port 6 = T (all  others blank)

(5) set membership to vlan 10 = port 2 = U / port 3 = u / port 4 = u ( all others blank)

(6) set VLID  for vlan 10 for g2/g3/g4

(7) leave all other VLID set to 1

(8) connect cable from local network to port one

At this point the laptop connected to port 3 can access the node and the internet, but not the switch. The netbook on port 8 can connect to the switch but to nothing else (node or internet).

what do I do to access the node/internet via the netbook connected to port 8?

I would like to put a NS2 back to back on this switch, as well, but when I tried the configuration I lost the switch from any computer.

Another question is can you create a vlan to connect a BBHN node to a UBNT Airmax back haul?

Ah I do love a challenging subject.

The function of "broadcasting" across a mesh won't be doable with just a script.

Typiically in an IPv4 network broadcasting is done by sending to the broadcast address of the network  (10.255.255.255 or 255.255.255.255 for the mesh network.) These packets will not be forwarded past a mesh node as each one is a broadcast break point.  This is also true of the LAN to MESH connection as the nodes are acting as IP routers at this point so you can't just flood the packet from a device on the lan port to a broadcast IP address and have it go out over the mesh interface.

This leaves you with needing to run a program on every node that will participate that will receive your broadcast and regenerate it (OLSR has to do this itself already)

Ultimately you have the following options that I can see.

• Create a daemon and install it on each node
  Any node that is not running the daemon will be a block point
• Use the OLSR daemon to distribute the messages
  -- Create a custom module (olsr sends messages it doesn't understand on without modification meaning no node becomes a block point) and provide a way to submit the messages into the system.

I tend to be weary of broadcasting packets over the entire network if it can be avoided (I've had the discussion of add data to OLSR come up a few times and its a cost/reward discussion in my mind), one should analyze the data they are sending to see how much traffic it will take.  It also should be noted that messages via OLSR are not a guaranteed delivery, they are sent with the expectation they may be lost. This may mean that you need to code a resend system in place for critical items and may need to write your own daemon as noted above (or find one made for Linux already)

Once you figure out what you need you can better evaluate the options for sending messages.

Another less indepth option (if the data in question can work with this) may be to use services to advertise a location, and have a script pick up on the service database to know where to query information from to get its updates. Of course if the information can afford to be lost (similar to a broadcast on a repeater not everyone will always hear it) than an actual broadcast can be much more efficient than constant querying of a central location and can e worth the effort to build in.

This may change whenever we get IPv6 In as MultiCast routing is part of the protocol, but we are not there yet so we can't utilize that solution yet, though MultiCast may provide an option under the install software on each node method in the current version.

Ah I do love a challenging subject.

The function of "broadcasting" across a mesh won't be doable with just a script.

Typiically in an IPv4 network broadcasting is done by sending to the broadcast address of the network  (10.255.255.255 or 255.255.255.255 for the mesh network.) These packets will not be forwarded past a mesh node as each one is a broadcast break point.  This is also true of the LAN to MESH connection as the nodes are acting as IP routers at this point so you can't just flood the packet from a device on the lan port to a broadcast IP address and have it go out over the mesh interface.

This leaves you with needing to run a program on every node that will participate that will receive your broadcast and regenerate it (OLSR has to do this itself already)

Ultimately you have the following options that I can see.

• Create a daemon and install it on each node
  Any node that is not running the daemon will be a block point
• Use the OLSR daemon to distribute the messages
  -- Create a custom module (olsr sends messages it doesn't understand on without modification meaning no node becomes a block point) and provide a way to submit the messages into the system.

I tend to be weary of broadcasting packets over the entire network if it can be avoided (I've had the discussion of add data to OLSR come up a few times and its a cost/reward discussion in my mind), one should analyze the data they are sending to see how much traffic it will take.  It also should be noted that messages via OLSR are not a guaranteed delivery, they are sent with the expectation they may be lost. This may mean that you need to code a resend system in place for critical items and may need to write your own daemon as noted above (or find one made for Linux already)

Once you figure out what you need you can better evaluate the options for sending messages.

Another less indepth option (if the data in question can work with this) may be to use services to advertise a location, and have a script pick up on the service database to know where to query information from to get its updates. Of course if the information can afford to be lost (similar to a broadcast on a repeater not everyone will always hear it) than an actual broadcast can be much more efficient than constant querying of a central location and can e worth the effort to build in.

This may change whenever we get IPv6 In as MultiCast routing is part of the protocol, but we are not there yet so we can't utilize that solution yet, though MultiCast may provide an option under the install software on each node method in the current version.