I personally tend to think of 2.4 as an access layer where you feed it to areas you want to cover, and. 5.8 as the backbone connecting access sites (aka a 2.4ghz cluster in one area fed to a 5.8 back haul which feed down to a  subsets of 5.8 sites). This way you keep all the major noise on 2.4 (lots of users comming and going) and design your local area repeaters (like a node the can feed a section of a city ) to uplink on 5.8 and let users access on 2.4.   You also get the advantage that Linksys users can still get in as well. Of course that is just my personal thought on it at the moment, I can't gurantre it's the right way for everywhere and is ultimately something each area will need to decide on and evaluate as more feedback is given about 5ghz.

In regards to the frequency range the units currently only operate on the normal frequencies ranges that the hardware is designed and tested for.

The power is adjustable on all units, the maximum power is determined by what the hardware is rated for and varies based on model and band, you should reffer to the Ubiquti data sheets for more information on the hardware capabilities.

Thank you Conrad,

I ended up doing a HARD reset (per your directions) and did a TFTF with the original UBNT firmware.  Under the UBNT tab "SYSTEM" I did a Factory Reset.  Once I was confident that the UBNT firmware was working as it should, I loaded the MESH firmware.  I found that if I did NOT do the FACTORY RESET that the MESH firmware did NOT address properly.  Don't quite understand this yet. 

Once the MESH firmware was uploaded via the UBNT ubgrade GUI, I did a successful initial login with the http://localnode.local.mesh:8080.  From here it is pretty straight forward. ROOT / hsmm and I am in.

Maybe a section could be added in the forum listing procedures such as this.  I am sure this is not the first time this has happened.

I cant tell you how much I appreceate your help

Again Thank you

Paul

WD6EBY...

Hi all my name is Marcus - KE6RHV ARES DEC High Desert Section Antelope Valley and we are getting ready to put out our network to cover our area with Bullets for the back bone. The question becomes 2.4 GHz or 5 GHz for our back bone? also  ......

Will the flashed Ubiquity units, 2.4 or 5.8 operate in the Part 97 spectrum, outside the ISM band?

Is the power adjustable on both bands?

What is the maximum power level of both bands configurable via the firmware?

Thanks,

Marcus

If you are in the node command line run "firstboot"

This will wipe out the volatile partition and restore the node to "just flashed" status,  you can then reboot. You will have to go through setting up the node again.

Also if you ever fully loose access and can't get in you can always use a TFTP install to restore the node http://ubnt.hsmm-mesh.org/products/BBHN/wiki/HowTo/FlashUbiquiti 

Hello all,

I installed the latest MESH firmware onto a UBNT Rocket M2.  All went well.  I had it configured and was connecting fine via the network cabling.  I mistakenly disabled the DHCP check-box and now I can not access the Rocket M2 via the WEB.

I tried the 172 address...no joy.  I tried the 192 address...again no joy. 

I have tried http://localnode.local.mesh:8080 again no joy.

I am able to do a sudo reset and log-on via telnet at 192.168.1.1 to access OPENWRT.  But I can not access the standard WEB interface.  Can you please provide some guidance.

---
Suggestion...I saw in the WEB interface a "RESET" button, is there a way to activate this "RESET" from the OPENWRT command line? As I understand this would bring the installed firmware to a known factory install, thus enabling DHCP.

Or secondarily, a procedure that I can reload the mesh.bin file from the OPENWRD command line so I can start with a fresh install.
---

Please, any assistance would be greatly appreciated.  Thank you for your time.

Paul

WD6EBY

I have a couple mesh nodes up, but no activity nearby.  Any meshers in Northern Calvert?

Mike - K3MAW

Thank you for the explanation. I know that the correct IP:port was being used, as it was a cut and past. Just finished working the camera and exploring the status with the same access as before and all is well. I enjoy what you have done.

That is quit the high tech temperature probe being used. I hope that it is sun exposure creating a 120 deg + reading and is not the ambient air temperature.

Just like to confirm the the WRT54G-TM, which is a renamed version of WRT534GS v3.0 hardware & special firmware runs just fine (as far as I've tested) when flashed with bbhn-1.1.2.-wrt54gs-2.4-squashfs.bin. (Mine was previously running DD-WRT).

73,

Mike

M0MLM

Running the wrt54g and up until this weekend, all went well.  Checked things out this morning and the node had stopped functioning.  Have attempted to log back into ithe wrt54g but, no go? I have tried, localnode:8080, 172.27.0.5 and the fallback IP address of 192.168.1.1.  NADA!

Wirelessly, the node seems to be transmitting or at least I can see my callsign-HSMM SSID.  Since I am still building and learning.....well if I cant login, I can't make any changes. 

Have read all sorts of articles on the forum as well has infomation from many users but, nothing has proven to be successful. 

So,  I would like, or I think I would like, to start over again from a reset, however, I haven't found a good procedure to follow.

Wes

I am not really sure what is going on then.

As noted there is no antenna gain selection in the BBHN user interface, if you see an "Antenna Gain" selection it isn't the BBHN firmware.  You also make mention of an "Available update"  1.1.2 is the latest BBHN release, there is no new update beyond 1.1.2. We do not currently prompt that a new update is available either.

Also how are you determine there is no RF output? (2.4ghz Spectrum analyzer?  Peak reading waveguide power meter?)  Did you run the same test under AirOS? It  is possible that you have a units with a bad power amplifier, but that wouldn't be software related.

This does not sound like your unit is flashed.

We do not currently have an antenna gain parameter in the BBHN user interface.

You may want to flush your browser cache to be sure your not seeing an old page.

http://ubnt.hsmm-mesh.org/products/BBHN/wiki/HowTo/FlashUbiquiti has the steps to flash a node and the expected outcome (Showing a simple interface with unconfigured status on it)

Thank you for the report,

This sounds like it is similar to BBHN->ticket:55 and likely is from the same root cause.

http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-3-firmware/topic-1038-v10x-to-v112-one-pc-discovered-other-not.html

http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-3-firmware/topic-1050-v10-to-v112-no-dhcp-for-wrt54gs-v10.html

Release notes: http://www.broadband-hamnet.org/documentation/195-bbhn110-firmware-release

1.1.0 was basically a compatibility only upgrade to make the Linksys units work in a similar fashion to how the Ubiquiti units would be working,  1.1.1/1.1.2 were bugfixes to initial release of items broken in 1.1.0.  No 1.0.0 bugs have been fixed in the 1.1.x line for Linksys and there is no known bug list for 1.0.0 Linksys builds (The Ubiquiti build however has all its known bugs from its 1.0.1 in the ticket system)

Mid refers to the use of Device to Device Linking (DTDLINK) created for the Ubiquiti devices and ported to the Linksys devices.  It is a signal that means the node is connected on 2 or more  mesh interfaces,  on the stock build this is WIFI and the DTDLINK virtual interface that is created at boot.

flashed a hp-m2 w/ bbhn-1.1.2 - ar71xx [generic] --- appeared to be good done deed  --- however [there is usually a however] it has no RF output  --- I assume I set something wrong ?? I wonder about the proper setting for 'antenna gain' which I left on auto - maybe it should be -3 or -6 db for full power out ?? also what would be gained by applying the available update ??  73 de MikE [aka W7WVC]

I've verified a somewhat obscure bug in the new mesh 1.1.2 upgrade on WRT54GS ver 1.0 (S/N starts with CGN1).  It has to do with certain NICs on certain computers connecting to the LAN ports.  My routers were on 1.0.0 and all LAN ports were working fine with all computers and devices.  However after upgrading to ver 1.1.2 two of my Dell computers (with Broadcom NICs, although I don't know if this is indicative of the issue) cannot talk to the router when connected to the LAN ports.  They do not get DHCP addresses, and if set for a static IP in the proper LAN range for the router, they do not communicate to the router or other devices on the LAN.

I have two of these WRT54GS ver 1.0 and both experience the same issue.  I've reloaded both twice with ver 1.1.2 and same issue.  I have a WRT54GS ver 2.1 and a ver 1.1 and both of these work just fine.  The real strange part of this is that the 1.1.2 upgrade works fine with these same computers right after it is loaded when it is in the "interim" mode, where the IP range is 172.27.0.X.  These Dells, one on Windows XP and one running Centos Linux ver 5.7, get an IP fine in the 172.27.0.X network.  It's after I name the node and set the password for the first time (making no other changes to the config), it reboots and comes up as an active node that the issue occurs.  Other devices like a Polycom SIP phone and an HP laptop on Windows 8 get DHCP just fine.  And all other functions of the node seem to be fine; they can be seen on the WAN side by other nodes running 1.1.2 firmware and can be connected to and managed, and those devices that are properly getting an IP address can be seen as well.

Like I said, it's a pretty obscure issue but is a bug none the less so I thought I'd post it.  I'm willing to do any testing anyone would like, just let me know.  Also, is there a definitive version listing, as I'd like to see what other changes were made in 1.1.2 versus 1.0.0, as I have other LAN and WAN networking scenarios that changed between the these releases.  By the way, what is the meaning of the "(mid)" seen next to neighbor nodes now with 1.1.2?

73, Bill, N4SV

Here are the iptable commands I use (on the gateway node). Your home router also needs to forward, in this example, port 8088 to your hamnet gateway node. As a live example, feel free to try out and access a remote control pan-tilt ipCam looking over Orange County, CA on this link (I reserve the right to change the password :) ). This access is over a 5 mile 2.4G link into the mesh. Note, "IR" mode icon to click and turn on if night time.

http://72.194.78.152:8088 <- User = "view" Password = "view" requires Windows Plugin http://72.194.78.152:8081 <- To see mesh status of node

[linksys-host:/etc/config/firewall.user]

iptables -A input_wan -p tcp --dport 8085 -j ACCEPT

iptables -t nat -A prerouting_wan -p tcp --dport 8085 -j DNAT --to 10.182.194.173:80

iptables -A forwarding_wan -p tcp --dport 80 -d 10.82.194.173 -j ACCEPT

iptables -t nat -A postrouting_wan -p tcp -d 10.82.194.173 -j SNAT -dport 80 --to-source <your gateway node's mesh IP address>

[ubnt-host:/etc/config/firewall]

config 'redirect'

option 'name' 'cam1'

option 'src' 'wan'

option 'proto' 'tcp'

option 'src_dport' '8088'

option 'dest_ip' '10.182.194.173'

option 'dest_port' '80'

option 'target' 'DNAT'

option 'dest' 'lan'

config 'redirect'

option 'src' 'lan'

option 'dest' 'wifi'

option 'dest_ip' '10.182.194.173' 

option 'src_dip' '<your gateway node's mesh IP address>'

option 'dest_port' '80'

option 'target' 'SNAT'

Note, the SNAT entries are needed so that the device "inside the mesh" (this doesn't have to be a device on the gateway node) will route the traffic back out the same gateway. In this live example, we have multiple gateways. Routers by default typically won't allow internet traffic to come in one gateway and back out another--a security issue.

To ensure your entries don't get overwritten, also put these definitions in /etc/config.mesh files.

Please read the release notes available here http://www.broadband-hamnet.org/documentation/195-bbhn110-firmware-release

Only the M series Ubiquiti devices are supported at this time.