Willing to try! Send the information. It's useless the way it is.

Denis  

No additional changes should be needed for Ubiquiti nodes.

DTDLink is always active on Ubiquiti devices when in mesh mode.

You should see them show up as dtdlink.nodename.local.mesh and a cost of .1 if it's connected via dtdlink.

If they are going to be on an unmanaged switch the best way is to disable the dhcp server on all but one node so it is the only server to issue dhcp leases, otherwise the node that will issue dhcp address is determined by which node comes online first. This doesn't break anything just that any local clients could jump from node to node.

You will still see that the nodes have an rf connection because they hear each other but they will choose to use the ethernet cable whenever possible as it's a more cost efficient (.1 vs 1.0 minimal).

Grid antennas may not have the best front to back ratio as they have a lot of space where signal can "leak"  so you will see that a bit .. Any physicical isolation with metal between may help clean up some co-interference or jumping channels between nodes.   That's just advantages to make the final links better it's not required for functional necessarily.

Dear all great and powerful gurus,

We are trying to improve network efficiency and are running into some issues I hope you can provide answers for. We currently have a network link that extends via multiple hops. The issue is that the nodes are connecting via RF on Airgrids so one airgrid is talking to another off the backside to continue the hop. 

It was my understanding the 3.0.0 firmware supports connecting through the Ethernet ports using a basic switch and not requiring a managed switch to extend the network. Doing this the DHCP servers seem to fight each other with the computer running into this switch as well.

How does one configure this setup? So for instance in my office I have one AirGrid M2 pointing towards Denton and another one pointing towards Highland Village. Currently it appears that even though connected to a switch they are talking off the backside of the beams to connect.

What settings need to be made and where? Some step by step instructions that are repeatable would be greatly appreciated.

Thanks!

There is a bit more to it currently than just the web UI, it's a combinations of external packages (including custom patches), kernel patches, the GUI, and hardware specific customization in the GUI for each device to be sure accurate information is displayed ( if you don't mind inaccurate info about RF power for example this may not apply to you or if the device accurately reports all info ) 

I found out the hard way myself when I though "oh I'll dump it on a single Ubiquiti and be done fast maybe a small tweak or two" has turned into a year of tracking down each device because there are minor differences in each and the the occasional change even in the same series of device also comes up.

Oh heads up, we found the Rocket and NanoStation work better on receive than Bullet and AirGrid because they are MIMO instead of single input (allows them to pickup signals that may have rotated on travel).

Have you considered the Ubiquiti nodes and maybe helping out with them over the TP-Link?

Ubiquiti devices are already ready to mount outside, an issue the Linsksys and the tplink you suggest both suffer at not being ready to go outdoors. The 4mb of flash is also a limiter (we already hit issues with 4mb being too small with Linksys). In addition I see a lot of hardware hacking needed to add external antennas, etc that the TP-Link device in question would quickly require more time and effort  cost than other solutions. 

We are looking to see additional hardware lines, but I'm not sure that this device would pass muster to live up to near, or even better exceed, what we have with Ubiquiti devices.

I've got 3 Linksys nodes running V3 firmware, and they all are talking to each other just fine. I've got a TP-LINK WR703N running OpenWRT that I'm trying to to get to connect to the mesh as well, and I have it to the point where it can see and is seen by the Linksys nodes, even shows up in the list of other nodes, but is unable to communicate with them. I gave the TP-LINK node an address of 10.234.106.6, which is consistent with the last half of the wifi mac address of that node. I know I won't get the nice interface on that node that I get on the true BBHN nodes, but I'd like to get it working, especially since that router is physically tiny, and can be set to a much higher power level. It would be really nice if there were a package to just add BBHN to an OpenWRT node. Once I have this figured out, I might try putting one together...

Thanks Paul, the wndw.net site and their manual are a great resource. I have some reading to do :)

What do you all normally do with the un-needed second antenna socket on a WRT54?

I will note that using one horizontal and one vertical would create an H+V dual polarity setup.

This is part of what helps the Ubiquiti devices, the Nanostations have a built in H+V dual polarity patch antenna. The Rocket is same where it has two ports and is intended to be used with a dual polarity antenna (sector or dish most common)

This is how the Linksys devices were intended to work originally as well, though they usually used antennas at at alternate 45's creating a pattern similar to a cross polarized X pattern it was still a dual input/output system with different  paths of signal allowing for better coverage.

Trying to load BBHN on the above router but it is always failing.

Firmware version 4.21.1

Any ideas on how to get around this?

73

Chris, M0XRS

Thank you Conrad for confirming what I was seeing.

Yep this (well any anomalous behavior) is expected when two networks of different protocol versions come together.

RF and DTDLink does not bridge between versions, 1.1.X was protocol version 2, starting with protocol version 3 the protocol is the first number of the release so you can more easily see compatibility. Upgrading the 1.1.x nodes to 3.0.0rc1 should solve the issue you are seeing.