Clearing my browser's cache fixed it, thanks!

Works here. Delete your browser's cache and try again.

I had purchased this filter prior to the release of bbhn for ubiquiti.

http://www.l-com.com/bandpass-filter-rf-splitter-24-ghz-ultra-high-q-8-pole-outdoor-bandpass-filter-channel-1-2412-mhz

Joe AE6XE

I have a Linksys WRT54G V.3 it has firmware version 1.0.0

I was told I needed to down load firmware version 2

when I look at the download page I can not tell which one I need

I don't understand the method used all I see are version's 1.something not version 2. something

would someone help this old man to understand what I need to do?

thanks Larry KB8EMD

Thank you for your reply. I am now in a much better position to understand what is going on. I have copied your reply to my fellow ham and will discuss what to do to resolve our difficulties . In fact we have been looking at the ubiquiti routers especially because we need to create a bridge of some 10 km. thus we are considering getting the air grid model.

what type of filter have you used to filter channel 1?

Yes it is, but as done it would be a regression of the BBHN->ticket:35 (a tunnel link could force its way to use  your internet because of rules 30290,32766   It also leaks the nodes when in nat mode too.

The 30200+ rules are meant to be used by the node itself for finding everything it may need to connect to, not to be used by traffic actually traversing the mesh itself (which a vpnlink side would be)

re: /etc/hotplug.d/iface/11-meshrouting

Conrad, Looks like it is still catching default rules to see the olsrd routes for these new interfaces, DEVICE=tun0:

30210:from all lookup 29

30220: from all lookup 30

30290: from all lookup main

30299: from all lookup 31

32766: from all lookup main

32767: from all lookup default

Ah I see why it works, rules 30200-30299 that I set to all interfaces when the loopback comes up allows it to traverse the node.  So not so surprising it works.

A new 12-vpnrouting policy should still be created however following similar to the dtdlink policy to ensure we don't have a regression and introduce the security flaw previously seen in 1.0.x

Max flight time for a battery powered multirotor drone would be 25min and fixed wing about 45min. With a gas powered fixed wing you can get 24 hours.

The commercial versions have the ability to carry +2 pound payload and autonomous fligh but have a price tag of $50,000! A tethered RC blimp or balloon is ideal. Also no issues with FAA.

I once mounted a wifi hotspot to a multirotor but wasn't satisfied with the results.

I am also looking in to using a Mesh Node mounted to a tethered balloon.

Take a look at /etc/hotplug.d/iface/11-meshrouting

I'm actually surprised your getting across 2 hops at the moment, that should not be the case on quick thought as the right table should not be being consulted.

This was part of securing the network from inadvertent routing done in 1.1.0 release (and is the biggest reason why the document needs to be re-written from 1.0.0/1.0.1)

Joe:

Quick glanced your tar file.

I don't see any handling of the routing table entries in your setup files. might of missed it, but important to look into otherwise routes will likely not work correctly except for one hop nodes if it isn't there.

Request For Feedback

Version: 3.0.0 beta

Any feedback users have on using in the real world with 5MHz and 10MHz channels compared to 20MHz channels and the effect on the Link Quality and SNR readings woudl be appreciated.

I believe somebody posted a cure for this on this forum earlier this year but cannot find apprpriate document.

An experimental aircraft would be fun, but this might be better done by a drone. Have you thought about that approach?