Thank you both for your replies. Being a novice I am assuming that an injector is a device which plugs into the Poe  which allows a way of feeding power to the system from an external source. This is an excellent way of doing it but I would have to ensure the pin connections are properly observed. To date I have not found ubiquiti as being forward in providing technical information on their products. Can you suggest a site I can use for the purpose.

having said this the second option of feeding the node with 12volts or 24volts for that matter, need a detailed explanation of how to go about it. I would be obliged to receive more information regarding the matter.

thank you again.

chris 9h 1bw.

You would need that block on 100% of the nodes in the mesh network, not just the gateway nodes. In otherwords it would have to be in mainline. I'm not sure I see that happening, I know I would personally oppose such a patch on the grounds it interferes with global internet routing.

Every node will need to see the IP address as part of the routing table method for how OLSRD works it goes out in the MID packets (and it has to be in them) to advertise route paths.

Every node on the network can connect to the WAN and would possibly forward the packet out to the WAN this is why the block would have to be on 100% of the nodes and not just the GW nodes.

Unless your planning on heavily modifying OLSRD to have each node remove some of the data (and I'm not sure how much that would confuse the daemon off hand if one node knows the route fully and the others don't)

I would caution you to verify the pin out of your POE injector.  There are several different schemes in use and if your injector puts the voltage on the wrong pins it releases the "blue magic smoke" that makes the nodes work.

I have used several ubnt nodes running of a 12 vdc battery with no problems.  If you are using 12v I would suggest you keep your cable distances shorter.

Clint, AE5CA

Well, I agree with you partly, but it´s a small issue to address by the means of some extra code to implement as a failsafe to ensure that 1.1.1.0/24, 1.2.3.0/24 and so on, never reaches the WAN or RF interfaces of the nodes.

This is something that I can implement rather quickly and will do so during next week.

Our GRE solution is implemented in a "package" like way, so this extra code will be part of future releases. The rather small footprint of this solution gives us the benefit of having som more addendum of different features without growing significantly in code. For example, we have already implemented the UCSD ripd connection for anyone wanting to use it. It´s still small enough to be harboured in the GL model though :)

As I said before, the recomendation is to use RFC private address-spaces, but I see this addition of code as a failsafe.

I'm not sure you can guarantee that.

As I noted we do not filter on the mesh nodes the 1.1.1.0/24 network. (Nor do I believe we should as it's a public network that could be put into service)

I can speak for myself and say in my current network setup leakage is 100% possible.  Even with my Checkpoint/Palo Alto/Cisco/Custom firewalls in line 1.1.1.0/24 doesn't appear to be in my bogon lists by quick glance (likely because it is technically allocated)

Every mesh node advertises it's VPN IP address as one of it's IP's.  This shows up in links on various pages of the BBHN/OLSR UI.

An example leakage possibility:

If the route goes down all of a sudden the fallback would be to send the packet out the nearest WAN GW. This by definition is leakage by crossing the bearer from BBHN to Local "WAN" network. Most home routers will likely not block it and on corporate routers it's not suppose to be blocked either. This causes further leakage into the routed internet.

Here is what happened in the past:
"While network 1.0.0.0/8 was an unallocated and unadvertised network any such traffic directed to an address in this block that “leaked” into the public Internet would follow a “default” routing path to the point where there was a “default-free” routing element, where the traffic would be discarded.  As soon as any such address in 1.0.0.0/8 was advertised as reachable into the public Internet, instead of being discarded as the boundary of the default-free zone (DFZ), the packets would be passed onto the destination rather than being discarded."

As seen once they advertised it it was routed. Also I notice you have a USA tunnel, can you guarantee that persons ISP won't route it ? How about every other node on that users mesh and their ISP's ? What about nodes that VPN into a node that's connected via rf to another node to another to one on the tunnel?  As you can see this very quickly becomes a can of worms that becomes hard without positive control over 100% of the nodes in the system.

Will it physically harm anyone, no, has it caused APNIC to declare space unusable,for the time being yes, will it likely be a lot of leaked traffic, no-but  a lot of small traffic adds up to 800mbps spikes.

And yes I believe Google was brought in for some capacity based on that doc to help test, what they are/were testing I don't know, but if APNIC told them to do something then it's within APNICS's authority to do so as the allocating authority (I see the advert is currently associated to Google under their AS15169 in the BGP tables: http://bgp.he.net/AS15169#_prefixes ). Google does make sense in a lot of regards due to their number of peering points, get the data off the 'uncontrolled' net as quickly as possible and into the 'controlled' infrastructure where it can be accounted for sooner reducing the chances of some router blocking it giving false readings.

**note: not intended to be a fight, just trying to point out why I am concerned about this as a networking person who has spent a fair amount of time with the BBHN code, and why in a global project like this some assumptions that have been made can't be made and why we should avoid this from the start rather than risk issues in 5 years.

Well, it would appear that MnSwept is going a different direction with their data communications. Honestly, this is kind of a relief for me.

 However, several members of our local Ham community are still very excited about BBHN and are ready to start a much more local network networking between three towns 7 and 12 miles apart. We still need to cover a fair amount of ground, but since this is simply for the love of the hobby I'm really looking forward to it.

 Andre, thanks for pointing me in the right direction with BBHN and Radio Mobile. I just wanted to give you an update since you were generous enough to give me some of your time (especially when you were on vacation) Thanks for your help so far, and I'm sure i'll be back soon with more questions.

KG6JEI

We always encourage hams to follow RFC, but in the end it´s up to everyone to decide what fits into their existing IP -plan. In this case it´s of no big issue since the IP´s will never be exposed to the Internet, only through the tunnel.

Also here, with my ISP, this particular IP network is not routed outside by them. And from what I understand this IP network is used isolated by Google to perform certain scientific tests.

But, once again. We encourage hams to follow RFC for private address-spaces suitable fo their needs.

I have just bought a ubiquiti Airgrid m2 hp router and would like to run it on batteries. Has any body carried out such a modification to the Poe.?

Also, a quick follow-on question for Joe (et al)...
Would this configuration work on Linksys (other than ipkg instead of opkg)?
I'm guessing no as the config files look like they are different formats between versions of openWRT.

k5dlq - Darryl

thanks Joe.
Ok, I'm taking a different approach... putting the wrt54gs vtun server on hold...

I'm trying on my Bullet M2 now. I followed your instructions for setting up vtund server on a UBNT Bullet M2.

I used your instructions and did the following:
ran opkg commands...
cp vtundsrv.conf after editing it for a new remote client name/pass (the remote client is a Linksys, so, I commented out the compress and encrypt lines as they don't appear to be compatible with UBNT version of vtun)
appended your network to both my /etc/config/network files
appended your firewall to both my /etc/config/firewall files
appended your olsrd to both my /etc/config/olsrd files
cp vtundsrv to init.d and chmod'd it
vtundsrv enabled (verified rc.d symlink)
reboot

Results:
vtund starts upon boot as expected.
i stopped it to run it as a non-daemon.
ran it: vtund -s -n -f /etc/vtundsrv.conf

I get no vtund connections until I issue a '/etc/init.d/firewall reload'
I then see the remote client connect.
I can ping the remote client 172.31.201.253
In olsrd routes page, i see one additional entry:
172.31.201.254 (mid1.K5DLQ-LGS2-DESK) 10.46.103.163 (K5DLQ-LGS2-DESK) 1 1.000 wlan0

BTW, K5DLQ-LGS2-DESK is another one of my RF MESH nodes (not wired).
My vtun server is on K5DLQ-UBM2-100

Could it be the configuration of the remote node causing no olsrd routing updates??

I would love to have someone else try to remote into my server. (begging/grovelling) ;-)

73, Darryl

P.S. I am running the UBM2 thru a Netgear GS105E with vlans configured.

Darryl: 

(Oops while I was typing Joe got to you so I've cleared my comment)

SM7I:

I took a look at your link. I'm concerned about the address space you are using for your VPN service and how it does not match reasonable internet standards.

1.1.1.0/24 is a public address space and should not be used on the mesh nodes without and assigned allocation from APNIC.

The nodes are not configured to block routing 1.1.1.0/24 out to the public internet.  

You may be causing packet leakage by operating in this manner.

APNIC has had serious issues with this http://www.potaroo.net/studies/1slash8/1slash8.pdf

perhaps moving the the 172.31.x.x space BBHN is promoting for VPN's would be wise.

Ok.
Further troubleshooting...
I can ping from the server to the client.
when i run tcpdump on the tun1 interface, i am seeing the following:
16:13:28.450171 IP 172.31.201.253 > 172.31.201.254: ICMP 172.31.201.253 udp port 698 unreachable, length 92 E..pPW..@.=;................E..T..@.@.M..............@cY.8i8.,.. .g...b..... ...

Looks like the OLSRD packets aren't being accepted. (port 698 unreachable).

in my /etc/config/olsrd.conf file, I do have:
Interface "tun1"
{
Ip4Broadcast 172.31.201.253
}

Where would change the config to allow olsr to accept these packets from the tun1 interface?

Thanks, Darryl

VA3WPN

Try again, there was a slight routingissue, but it´s taken care of now.

Daryl:

start at the simple parts, verify ping , verify olsr packets being recieved and transmitted (tcpdump) etx on the interface first and work your way up.  

OLSR has to have the data before routing can become a question and so on so work the issue from the bottom up or top down on each item.