Sorry but the WAP54G will not be able to load the BBHN firmware as it doesn't have the CPU nor sufficient memory as it's a simple access point, not a wireless AP/router like the WRT54G.

Insofar as using amplifiers -- unless you ABSOLUTELY POSITIVELY **NEED** it for a distant node, you are doing more harm than good, especially at 8-watts. This is not HF and more power does not always equate to a better signal. Use of quality antennas and better placement thereof will get you a far better link as history and experience has shown.

Andre, if it helps the effort, our networks is not large, however, the links are weak at this time due to experimentation and poor paths. I suggest it has to do with links coming in and out often which most likely is more probable in larger networks, however, it's happening on intermittent small networks. i.e. 2 to 3 nodes.

Bob AF5RS

We're finding the latest firmware (1.2.1 (-v2)) for the Rocket M2 shows differing link results on a known prior good link. We have confirmed link may re reappear on a warm boot, may not. But a cold boot (POE power down and back up), the link most likely reappears. It also seems to be time related, the longer the link is up, the more likely it will become unstable, a warm boot doesn't seem to help, but then on a cold boot,and  presto! back to normal. What's happening here? Kernel leak? Seems to take about a day of up-time before a cold boot is required. We're seeing this on multiple nodes with the -v2 firmware. Also, can't seem to reconcile the LQ with the S/N. Any body else seeing this?

Bob AF5RS

I have a WAP54G version 3.1. Is this supported for use with the mesh?

It has 2 detachable antennas with N connectors. I have seen some 2.4GHz amplifiers (up to 8W) on eBay.  Has anyone had any luck using amplifiers?

It was discovered as existing in 1.1.2 and a changset committed to the 'develop' branch of the code base to resolve it.

The 'develop' branch is the "may be less than stable, not everything 100% works or is 100% tested, not production ready" code line we use for the program development. Its a step on the way into being part of an official build.

http://ubnt.hsmm-mesh.org/products/BBHN/ticket/55

All the dev related process is currently being tracked in bloodhound located at http://ubnt.hsmm-mesh.org/

Hi Conrad,

I have been trying to find the place where Ticket #55 is tracked, but cannot find it. Can you please provide a link to Ticket #55? Thanks a lot and 73. Bert, VE2ZAZ

If I understand the concern correctly (node with a path one way show as  a neighbor ). This sounds correct behavior to me.

The node is indeed a neighbor (as defined by our routing service olsrd). It is a neighbor with a 1 directional path.  Currently the software will not use such a route however it does keep track of it as a neighbor it can hear and could possibly become a bi directional neighbor if the RF path changed.

Sounds like a duplicate of BBHN->ticket:55 discussed previously in the forums.

I've also been having problems since upgrading (I see this has been happening).

Nearly went the TFTP route, then I tried something- it doesn't much fix the problem, but at least you know it's not totally bricked:

(this assumes you have a "regular" network in your house) 

1. On a computer connected to the home network, open your home router's status page which shows locally connected clients and their MAC/IP addresses. 
2. Connect the Internet/WAN port of the BBHN router to one of the LAN ports on your home router.
3. Watch the home router's status page. You may have to refresh manually. A new device should pop up in the list.
4. Open up the new IP address with port 8080. So, if the new device appeared as 192.168.0.103, type 192.168.0.103:8080 into your browser.
5. You should be looking at the BBHN status page.

Now, this isn't solving the problem yet, just letting you know that it is alive and (almost) well. I tried to telnet and ssh to the BBHN router, no luck. I ran nmap against it, and the sole open port was 8080. Sounds like something puked during init.

I plan on adding a serial port to see if I can get in that way and see what is going on.

/Ben 

Thanks for the clarification Eddie. I just assumed you couldn't use the satellite frequencies as it didn't state otherwise.

Hopefully I can get some Linksys routers at some point to set up a network.

Thanks,

Jack.

Dont forget that with the Ubiquiti equipment they only have one RJ45 port. This means you'll need a managed switch that supports 802.1q VLAN tagging if you wish to connect it to your existing home network.

The cheapest one I've been able to find is around $50, here: http://www.newegg.com/Product/Product.aspx?Item=N82E16833127450

I'm new to VLAN stuff so this is definitely a learning experience.

Hi,

First of all, let me thank you all for the excellent work you have been putting on BBHN. Keep on the good work!

OK, now the issue. I am seeing a DHCP bug with a WRT54G v2 unit running the latest firmware BBHN 1.1.2. Linksys ATA (Analog Telephone Adapter) SPA2002 or SPA3000 units will not receive a DHCP lease under any circumstance. My netbook and the raspberry Pi will get a lease, but not the ATAs. When connected to a WRT54GL v1.1 with the latest firmware, DHCP is working fine with the ATAs. Actually, all is fine under DD-WRT or the original Linksys firmware. It is only with 1.1.2 that this WRT54G v2 is showing this DHCP issue. I have tried a manual IP configuration on the ATA but that too does not seem to work.

Thanks in advance,

Bert, VE2ZAZ