Andre, on your benchmark test exactly what was the chain to grid configuration on the M2s on both ends of the path? Single chain 0 with a single 24dBi grid for TX & RX, not using chain1? Or, dual 24dBi grids using diveristy, or what? We seem to be getting unrepeatable results with different configs. Can't tell yet what's best so curious about you exact chain to antenna configs.

Bob AF5RS

Thanks for the reply. I've got to bring it down from the tower to the bench to attempt this is a more "controlled" environment ;-). I been attempting this with me on the tower and another on the ground cycling the POE supply. I thought I could pull it off, but obviously not. Exactly how do the LEDs change? I see power and network activity under normal conditions on power up boot now.

Thanks again.

Bob AF5RS

The TFTP method works, I've done it 50+ times personally to restore to factory image.

You have to hold the button until the indicator lights change to indicate it's in TFTP mode.

The BBHN firmware takes no action to enable or disable the TFTP recovery mode. This is handeled before we boot our software.

No luck here using the latest 1.2.1 firmware on a Rocket M2 using the OEM "Recovery" method of depressing the reset switch during power up for 8 to 15 seconds. Unit still boots up normally to normal BBHN operation. Using the firmware upload method aborts with "firmware not recognized". I can feel the tactile depression on the reset button, but no luck after several attempts. Does anyone know if this method really works? It appears the BBHN firmware has disabled this recovery method. It normally should revert back to the factory IP (192.168.1.20) to allow TFTP upload of the OEM image, however, it appears this is only true if you have factory OEM firmware in the M2 already. So, how do we get back to OEM firmware?

Thanks in advance for an experienced answer,

73 Bob AF5RS

The downtilt and the beamwidth are indepednet of each other.

If it ships with 2 degree of down tilt and the antenna is vertically plumb than the center of the beam is at -2 degrees. With a 4 degree beamwidth this means it covers between 0 to -4 degrees with center again at -2.

So if you want to cover -2 to -6 you would need to shim it from the top to add an additional 2 degree of physical downtilt to give you a center at -4 ( -2 physical and + -2 electrical )

Note: Ubiquiti (like a lot of wifi antenna vendors) use -6dbm figures for beamwidth as compared to normal HAM antennas which use -3dbm. This data sheet calls out that it is -6dbm but some do not and it's easy to overlook as well. 

We have a solar powered linksys node on a hill. I am able to get in from 6 miles out with a Bullet M2 HP with 25 dbi grid and my friend is able to to get in from 9 miles out with M2 HP and 35 dbi grid. Hope that info helps.

Sounds like this is the same as BBHN->ticket:53

I believe a node reboot after saving will cause it to advertise the service as a work around until the changset in that ticket gets incorporated into a full release. 

After upgrading my firmware and setting things back up a little differently, I am not able to get advertised services working again.

My setup consists of a WRT54GL running 1.1.2 firmware. It is set as 5 host direct. I have a laptop host setup with DHCP address reservation.

On this host I have a webserver listening on the standard port 80.

I also have another WRT54GL attached to the first as an access point.

I can connect to the host web server by typing the hostname into the browser HOSTNAME/

and the web server launches fine, however, if I try to set it as an advertised service:

Web Server: Link :http://hostname(selected from drop down) port: 80 

I get the Configuration saved, however:
problem with port setup and therefore doesn't end up showing as an advertised service on the mesh.

I also have ngircd package running on the node and it works fine, but i get the same error if trying to set it up as an advertised service, even if it is the sole advertised service.

Any help would be greatly appreciated.

The numbers are indeed important they have to match. 

The first major issue I see is you removed vlan1 from ports 7 and 8. This vlan needs to be there and it needs to be there in a tagged format so the node can read the traffic as being on it's "WAN" port.

DTDLINK sounds like it should be setup correct so that if you plug a Ubiquiti into 7 or 8 they would talk to each other on VLAN2. 

This post may help http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-18-how-we-used-hsmm-mesh/topic-1021-ubiquiti-radios-and-providing-internet.html#ccbp4595

I am running 1.1 firmware on a Bullet M5-HP and trying to set up a DHCP WAN connection. I picked up a small HP Procurve 1700-8 managed switch and am attempting to sort out the VLAN settings.

The HP has a default VLAN set with a VLAN ID of 1 that all 8 ports are assigned to. I created a second VLAN with an ID of 2 and assigned the last 2 ports (7 & 8)  of the switch to it. I also un-assigned them from vlan 1. So ports 1-6 are on vlan 1 and ports 7-8 are on vlan 2. No trunks were created. Ports 7-8 were marked to pass tagged only traffic and  ports 1-6 to pass all traffic. No ingress filtering was set.

I am unable to pick up an address for the WAN with a external DHCP server attached to either port 7 or 8. I am missing something here. Does a trunk need to be created?

The release notes in the firmware mentions untagged = LAN, vlan1 = WAN . and vlan2 = DTD Linking. Are these actual id numbers critical?

Anyone have an HP switch setup they can share?

Thanks, Dave,  K7DMK