Hello Michael,

I'm not sure you correctly understand how the devices already function for your plans.

The processes described in Michaels post is more likely if you were to use the WAN uplink (meshgw) and not dtdlink traffic.

DTDLINK is intended for when you want to combine multiple mesh devices together (you would generaly not filter here for internet as this is a mesh to mesh connection) such as using a 5.8 backbone throughout an area  and feeding to local 2.4ghz access layer, or multiple devices at a site like when you having 3 120degree sector units at the same site on the same band and need to combine them (creating a digital omni)

No managed switch is needed for DTDLINK

In all cases:  Local PC generated Broadcasts are already filtered at the mesh node because of how the nodes work. In addition  RF broadcasts are not propagated past the first node either.  The only broadcast you would have (by default) on the dtdlink interface is the OLSR packets which you do want to go across untouched for the network to expand across multiple devices.

Flashed the first of 7 nodes after an email from another sysop said his camera wasn't being discovered after a flash of one of his nodes that it was previous connected to. 

The upload from my desktop went smooth, default 5 host direct, DHCP Server set.  The desktop shows up in "Current DHCP Leases", ipconfig verifies IP in proper range.  However a DHCP-enabled laptop is not being discovered and the laptop's ipconfig shows 169.254.x.x. Swapping LAN ports; desktop works in any, laptop works in none.  Laptop was discovered fine in the previous version.  Cables are good.

Any idea what's up?

Not via the interface at this time.

Using a different VLAN ID other than VLAN ID 1 is no more secure than using a VLANID of 87. This VLAN does not need to populate past the first vlan capable switch it is plugged into and can be untagged after that and routed through the network as a wire (or tag changed if  your switch happens to support it)

In case you are wondering: the choice of VLAN 1 was actually made because this is what the Linksys switches use internally so to keep the code sane they use the same VLAN -- You are already using VLAN 1 if you use a Linksys device and just realize it.

As a network person I don't use VLAN1 for security reasons. Just like you dont use the standard SNMP strings. The question is simple , Is it possible to use any other VLAN tags ? That is other than 1 & 2.  How can we set what vlan numbers to use ? 

Mike AE4ML

You are correct.  Netgear calls the GS105e, GS108e and GS116e  Unmanaged Plus Switches.

To connect the internet to a UBNT device the thing you need to look for is 802.1q.  This will let you configure the switch to add a tag to the internet signal going into the BBHN device.

Clint, AE5CA

DUH!  I guess it helps to read the files others have placed on this site.  Indeed I was not loading the BBHN firmware into the right place in the Bullet.  Once I loaded it properly all is well, thanks to those who provided the helpful information to get me on the right track.  And WOW, the Bullet looks like it will be much more sensitive than the Linksys WRT54Gs!  With the Bullet sitting on a chair directly next to one of my Linksys routers (with it attached to a Directive Systems 1221LYMR loop yagi) I am hearing twice as many wi-fi systems as the WRT54G, so I am hopeful I might now actually be able to hear my nearest BBHN neighbor a little over a mile away when I get the Bullet up on the roof.  Here's hoping!

73, Bill, N4SV

FWIW, Netgear refers to the GS108E as an "Unmanaged Plus" switch, but apparently, it does work.

I believe you will still need the DHCP server activated.  The WAN port gets its IP from your Internet Connection.  The computers plugged into the LAN port will not be served from the Internet DHCP.  

The DHCP server provides the IP addresses to the computers plugged into the LAN port.  Otherwise you will need to set a static ip for every device on your LAN.

If it is working correctly for you then leave it alone. 

Clint, AE5CA

http://ubnt.hsmm-mesh.org/products/BBHN/wiki/HowTo/FlashUbiquiti

It sounds like you are uploading it as a config file and not a firmware file.

Bullet problems continue.  I sent back the Bullet2-H and got a "supported" BulletM2-HP.  Tried loading the older 1.0.1 load and am still getting the same error "Uploaded configuration file is too big.   Maximum allowed size is 65535 bytes" as I was getting in the Bullet2-H?  The BulletM2-HP is running AirOS XM 5.5.6.  I guess I can try a TFTP load but I'd like to understand why I'm getting the error.  Is there a way of telling how much memory this BulletM2-HP has?  Very frustrating because I have flashed well over a dozen WRT54G and one Ubiquiti Nano M2 Loco with BBHN and have had no issues.  I was hoping to strap this BulletM2-HP on a 21 element 2.4 GHz Loop Yagi by Directive Systems and see if it works any better than my current WRT54G with a part of 25db Chinese stick yagis, but with no BBHN load in the BulletM2-HP I'm stuck.

Thank you for the help on the internet access step. I do agree with 100% that this is NOT meant to replace normal WIFI access.  The next step in my process is to setup Squid on a firewall device to act as a Proxy server.  The intent is to allow only very specific sites to be accessed, for example, NOAA, NWS, Winlink. 

For others later down the road here is what I did on a HP Procurve 2650.

On the Switch:

Created a second VLAN, 10.  VLAN 10 is called HAM-LAN

VLAN 1 is called WAN (internet access)

Changed the default LAN for management sake to VLAN 10.

Port 1 is the WAN connection.  It is untagged on WAN and set to NO for HAM-LAN.

Port 2 is for the Rocket.  It is tagged on WAN and NO on HAM-LAN.

On the Rocket:

WIFI I left to the defaults, no changes.

LAN: Left at 5 host direct.  Disabled DHCP server.  Badness happens with 2 DNS servers on at the same time.

WAN: Protocol set to static, manually assigned it an IP address on my network.  Gave it Google's ip addresses for DNS.  Checked mesh gateway box. 

I am now able to access the internet on my RocketM2 via my Airgrid M2.  Like I said, the proxy server and IRC are next.

73

KC5GOI

I am wondering if any thought has been given to expanding the firmware to support the Ubiquiti NanoStation M3 and their similar products? To be clear I am not talking about the 3.65 GHz product intended for Part 90. They manufacture a line of products that cover 3.4 - 3.7 GHz that are intended for export.

These products would be 100% USA legal if operated between 3.4 - 3.5 GHz under Part 97 and not require an FCC homologation process for Ubiquiti. Ubiquiti and their VARs gain a new albeit small market. We would gain equipment that operates in an area of the spectrum free of WiFi and other Part 15 noise.

Just a thought... Comments?

de WA2KWR

I am not sure I have enough information to solve this but if I understand your problem correctly, I would suggest you set a static IP address on our PC you use to connect to one of your mesh nodes. The ip should me in the 10.x.x.x range.  If you changed to NAT it would be in the 172.27.0.x range. 

You should be able to get into your node by going to localnode:8080 then you should be able to connect to your other nodes through the mesh. 

A worst case senerio would be to do FTP reinstall on one of your nodes. Ubnt is easier to FTP than linksys. Once you reinstall on one node it should be able to connect to the others.  FTP instructions are on this web site. 

Clint, AE5CA

You shouldn't need an MX record, and we don't have an ability to publish them.

The email standard is lookup an mx record, if none found lookup an A record (which we do publish IF your advertising the name as a reserved name). If A record found deliver to that IP address.

Can these Ubiquiti devices be used the same way as a WEB router?

I ordered one for my home station and was hoping to use it with a 16 port cisco 2960 switch up to the maximum number of ip's for system servers for my local HSMM group.

I have a full Asterisk VOIP server, XMPP chat server , and email server ready to roll.