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.

Andre, yes exactly I didn't get that dropbear was already on 2222. For now I use 5-host direct and put my node in /etc/config/local, just noticed it can get overwritten :(

iptables -t nat -A prerouting_wan -j DNAT --to (ip)

iptables -A forwarding_wan -d (ip) -j ACCEPT

I would like to help but without a repo or a way to ssh in to the router I feel stuck. (stock 1.1.2 has no space to add the openssh-server package even on the 8mb wrt54gs). I have an nfs server I could attach to for space to develop in if there were a way.

Is there a way to re-install LinkSys firmware to a Linksys WRT54GS router from a Windows based computer (Windows Vista. Windows 7, and/or Windows 8)?

Thanks much.

Steve

KE6WEZ

The secondary port is not currently utilized (mentioned in other posts)

You would want to follow BBHN->ticket:56 for the progress on the feature request to add it.

I too have been trying to get the secondary lan port to work. I see that the Ubiquiti firmware has a way to enable the secondary lan port.  This makes me think that it is disabled by default.  But now that I have the HSMM firmware, I can't figure out how to flash the Ubiquiti firmware to see if I can turn it on.

Plus, I don't know if it will stay on after I flash the HSMM firmware.

Any ideas?

Anyone else building mesh nodes in Clinton?

Hi Jack, As you have already discovered ,the section of the band we are about to lose in the UK is at the lower frequency range. This does not affect the use of Broadband Hamnet as this is at the opposite end of the band. Whilst you are correct in saying the band plan suggests this part of the band is for satellite use, it is only a guide, not law or cast in stone. Any satellite operator worth his salt knows that this part of the band is used by every wifi user in the world and as such the noise floor is much increased. As a general rule most sat operators will avoid this part of the band for this reason. After all, if you have gone to the trouble of putting a satellite into orbit, it would be shame if no-one on the ground could hear it due to local interference/background noise. You will be operating quite legally in this part of the band if you choose, and due to the nature of the frequency in question, any interference caused would be extremely localised. Also remember that as a licenced user of this part of the band, other unlicensed users have to accept any interference arising from your use of the band. This might as a worst case scenario result in them having to change channel. Not the end of the world I think you will agree. Regards Eddie G7DNM

I ran a couple test this week with my mesh network and connecting it to the internet. This was specifically for port 14580 for APRS and DNS. my setup was ISP, Cisco 2600 Router Cisco 2950 switch configured with vlan 1,2,20( 1 WAN, 2 BBHN, 20 ISP).  a nano Bridge M5(AE4ML-504) connected to the trunk port.The WAN picked up an IP 192.168.20.1 with gateway 192.168.20.254 as expected.

  At the other end was an un-managed switch with a nano bridge M5(AE4ML-501). I connected a laptop and WX3in1 APRS Igate device.

On a third setup(AE4ML-503) was a Nano station M5 with a PC. The entire setup initially it worked. no internet access .

The Igate was passing traffic out and then in about Oh about 5 minutes. it came to a stop. 

I did a reboot of AE4ML-504 (Im not a fan of reboots unless it is needed and it came backup only to slow down and fail again.

My ISP is a 10 network. and that side is stable. it never failed. I had a third laptop on that point and that will be my wireshark capture point.

Curious though. From my ISP router I had a static route to 10.0.0.0/8 to the mesh. On the router  I could ping my local and internet networks however I never could ping out over the mesh. when I went to  AE4ML-504 and I pinged the entire mesh except for the default gateway  on the inside of my Cisco router. Mesh gateway was checked and the address from the router was set to DHCP. I had an IP from the cisco router on AE4ML-504

There seems to be something going on. I need to run some wireshark captures and see what is going on. I did notice one thing. Something said for the email message about the script. Let me say this. I'm not a fan of the idea nor do I want to go down that road.

Mike AE4ML

Has anyone experienced any damage from near lightning strikes on their gear at the end of the cat5? I've experienced problems in the past with ports being blown on the switches/routers and even sometimes carried through the chassis to the computers. A long run of cat5 even if it's shielded somehow always was suceptible to this. We found a nice surge protector to place on the towers designed to protect the equipment below. What's wierd is that is the stuff that usually went bad, the unit up top seldom went bad unless it was a direct hit which usually did a boatload of damage including knocking chunks of concrete out of the base of the tower near the grounds!

In any case I had a bunch of these things left over. I listed some on Ebay here:

http://www.ebay.com/itm/1114181708789

You can purchase them direct from mfg here:

http://www.l-com.com/surge-protector-outdoor-10-100-base-t-cat5-lightning-surge-protector

Peter - KF7PSM

I'm all for it...    :)

The BBHN Source Repository is now available to interested developers at our development site.  

You may browse the source code repositories by visiting the source tab at http://ubnt.hsmm-mesh.org .

For those wishing to assist with development, a code repository may be checked-out with:

    git clone git://ubnt.hsmm-mesh.org/<repo_name>

Where <repo_name> is the name the repository you wish to checkout.

These checkouts may then be used with the appropriate openwrt toolsets to build your own image.  Note that we are not prepared to support the inexperienced developer, so please remain within your personal comfort zone here.  Relevant development questions and bug reports should be posted to the development site.

73,

Andre, K6AH

Hello,

great website!

Can you add a geographical location for Northern Virginia? I am a member of the Ole Virginia Hams, we are actively testing BBHN at local sites (Manassas, Centreville) starting next week.

thanks,

David, kk4zuu

Understood, thanks for the additional input. The firmware asks for the antenna config for each chain, I assume your suggestions imply staying in diveristy mode on both chains. Seems logical better gain could be realized using RX on one chain and TX on the other, if in fact the internal split is truly switched around. I appreciate the same antennas fed in diversity mode on TX or RX should be equivilent, however, assuming imprefect phasing that may not be the case and separating TX and RX may in fact improve S/N. Just a theory, I'll do range testing in both diversity on both vs. separate RX & TX. Do you have any empirical data between the different chain config modes? And yes, I do have 2 identical grids to experiment with on both chains vs. the hybrid config I'm using now. I'll post the results.

Thanks again & 73,

Bob AF5RS

As far as we know, on all the dual chain devices the max power is split between the two ports when in diversity.  The units may not let you go above maxpower-3dbm as it derates max power for the fact that only one antenna is in use (at least this was what was seen during initial testing on some models)

When running a dual chain device (Linksys, Ubiquiti Rocket, etc)  you always want BOTH chains to share similar antennas and be pointed in the same direction.  You would want one to be horizontal polarity and one to be vertical polarity (or some other combination)

A dual polarity dish would be best, they are high gain, high front to back ratio, tight beamwidth (aiming can be hard and you have to have a secure mount for long paths to avoid wind movement.)  An advantage of the tight beamwidth is it may reduce the noise floor a bit as well since local nodes no longer are in the beam path of the node.

Mixing an Omni and a directional is generally going to be a less than optimum, the nodes will take the STRONGEST signal and decode that without making a calculation as to  being different nodes.

Dual Chain tends to run better so the Rocket M2 with a RocketDish or any other dual polarity dish (I like StreakWave for its antenna selection on wifi gear) would be good for a backhaul.

I don't know how 2 grid antennas will work, but if using one vertical and one horizontal you do gain the dual chain feature at that point and theoretically it should work. Or even if both anteannas are same polarity if they are at offset from each other they may catch signals different based on atmospherics.  If you already have the 2 grids i would say it would be worth a trial.

The NanoBridge may also work but its 5db less than your grids (18dbm) and its also 5dbm output lower (10dbm total difference) so if loss is already a concern this would likely not be ideal.