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.

Since Andre has mentioned me in this thread...

The NanoStation is my favorite device.  I tend to prefer the M2 for general use.  The M5 is also good. With the M5 you have to make sure to get an older unit using the XM firmware.  The M3 needs some more work  to be viable. The  M9's are called NanoStationLoco's.  They load the 3.0.0 firmware great, I have not done a lot of distance testing yet but I suspect they will be a very useful devise as well

I have used both the NanoStation M2 and M5 at 13 miles NanoStation to NanoStation. This is over a very good path with clear Fresnel zones.  The NanoStation will connect to another node when a Linksys with any antenna combination I have tried will not.

I will NOT use a Linksys in an outdoor setting any more.  

Two NanoStations make for a great starter network.  Much easier and less expensive than the WRT54GL and accessories to make the WRT54GL work.  Start with NanoStations NOT WRT54G's you will have a much better experience.

If you need a wider coverage area then you should look at a Rocket with a proper matching antenna.

I like the Bullet with the right antenna, but for most uses, the NanoStation is a better unit.

And I concur with Andre, move up to 3.0.0.  In my opinion it is best version of BBHN out there.

The opinions expressed above are mine and your mileage may vary.

Clint, AE5CA

Two security  exist in 1.0.1 and below

1) An input validation which could allow injecting arbitrary settings into olsrd.conf (must be authenticated to do) BBHN->ticket:34 

2) As Joe mentioned a flaw in the routing where a remote user could access the WAN network even when meshgw was disabled or the LAN network (in case of NAT node) as BBHN->ticket:35

Both is these are reasons to avoid 1.0.1 and below, and based on current status 3.0.0 looks to be the best choice for networks.

And +1 on reporting on the side for security flaws, allows us to get a patch together to resolve the issue before we disclose it publicly to reduce the impact to users as is normal for IT software (reasonable fix period before public disclosure).  This may be a HAM network but it still is wise for us to follow normal security methods to protect from malicious sources.