While UBNT is the preferred option... If you are deferring this cost, an alternative quick-and-dirty workaround, if you or a friend know ssh and vi, is to edit the /etc/config/network file and separate the ports to be in a unique vlan 0, 1, or 2 for your needs. This defect occurs when mixing vlans on same port--a desirable feature to plug any cable in any port. In my case, I had a UBNT AirCam that was completely ignored. I edited the file this way to get it working:

config switch eth0

    option vlan0 "2 3 4 5*"

    option vlan1 "0 5"

    option vlan2 "1t 5t "

vlan2 = DtD = port 1 (which may be port 4 label on the back depending on version)

vlan1 = WAN stays the same

vlan0 = LAN ports with the Aircam.

Joe AE6XE

Conrad,

Thank you for your answer. Where do you want me to send you the files?

Quote:

This is just another method of making sure we do our due diligence of ensuring we talk with only other hams (You know the secret key so you should know the rules behind using that key is the logic)

Whatever comes default takes no thinking. Most people don't know the secret key nor the fact it's even there. And if a non-ham wants to talk to the mesh, they have to download the software from this site. Without the firmware you can not join the net. And this firmware would equally let them in regardless whether the mesh is not using a key, or has a key that already comes with the firmware. Anyway, I made my point, but the decision is with you guys so I don't think we should argue on this one any more.

1) We have received confirmation on that from olsrd that it is not recommended on 64bit. Basically this makes this an OLSRD bug, but considering all BBHN hardware currently is 32bit we haven't focused development resources on this yet.

2) We would be happy to receive the data on this output. The more data we can get on the subject the closer we can get to resolving these tickets and get back to moving forward.

3) Sounds like it could be BBHN->ticket:62 which is  being worked on (though at last check it had been identified and was just looking for testing and final solution)

Quote:
"I also wonder how many networks have actually changed the default encryption key in all of their routers? For running with the default key adds zero value to security, but brings a lot of headache."

I believe several items in play here where value still comes in even if one doesn't change the key.

1) We want the software to be there and available for those networks whom need to have some control over who is allowed to access a mesh but still needs to run under part 97  Best way is to leave the module always on so one only needs to change the text in a single file. This goes with the goal of keeping the configuration simple.

2) This module also acts as a reasonable method for ensuring NON Amateur radio operators are not operating on your mesh environment (USA Part 97 we are not to respond to devices not operating under part 97, I can't speak for the rest of the world on the regs related to this). This is just another method of making sure we do our due diligence of ensuring we talk with only other hams (You know the secret key so you should know the rules behind using that key is the logic)

Most of the issues were seeing now seem to be related largly to the fact were now creating bigger meshes.  Were in that pain point where adoption has finally grown to a point where what once worked no longer does work.

It takes time to fix the issues and fix them right but that is what we are committed to do. This is not the old BBHN where issues were large issues (like the byteorder bug) were not dealt with for 2 years, we are actively working this set of issues to make BBHN and its related software stronger. J

As for a new release without OLSR: I can't speak to that from a project standpoint. I can say though I know making one image does take away from the time that can be used to work the issues and it becomes a balancing point  to resolve issues vs just 'rolling back' I'm sure the subject of how to handle all this is being looked at and considered from all angles.

At the moment the simple better solution is to go with Ubiquiti gear with those concerns mentioned.

I personally would not recommend using Linksys as part of an EMCOM deployment for numerous reasons including Power draw, Operating Condition support (temp and moisture), Performance of the hardware (cpu speed and packet forward ability), Performance of the RF Hardware (stronger RF output, no loss installation, higher quality receiver)

I've already seen multiple networks do full rip and replace on older generation Linksys gear to Ubiquiti as early as the 1.0.1 release.

A fix is in the repo but its holding because we are working much bigger tickets right now but if you have access to the backend and an unaffected device you can change it manually if need be, all details are in the code repo (note: we do not have the resources to walk users through this procedure at this time)

There is a FAQ entry on this at

http://www.broadband-hamnet.org/section-blog/36-network-faqs/94-i-changed-my-unit-to-mesh-ap-and-i-cant-get-back-in.html

I would recommend you set your computer to static address of 172.27.0.x where x is not 1 or 2.  I normally use 5.

Disconnect the access point from the node and connect the access point to your computer to one of the LAN ports using an ethernet cable.

From your browser go to 172.27.0.2:8080.  Yes you need the :8080

That should get you in to the web interface. 

I was able to verify the above steps on a WRT54G v4 running 1.1.2

Clint, AE5CA

strangely, the system seems to be lacking the dns information to resolve localap, as whenever I look for it, I get "server not found". Should there be a standard ip address and port for localap?
For clarity, I can access localnode:8080/, but not localap:8080/

Hi,

We are running a small mesh consisting at this point of 3 Linksys nodes, 6 Xagyl nodes (xagyl.com, OpenWRT 12.09, olsrd, manual configuration, 1W output) and one VM with Debian Linux as a VPN concentrator. Ever since we have migrated the mesh to BBHN-v2 and firmware 1.1.2, we do experience the troubles somewhat similar to the ones described in your news bulletin, and all of them seem to relate to olsrd_secure module.

1. First just like it was mentioned in the other thread, the Debian VM did not connect to the mesh with a 64 bit version of olsrd, and it was specifically olsrd_secure module that did not want to connect. Once I have rebuilt the VM with the 32 bit version of os, everything connected just fine with the same config copied over, so please consider this theory confirmed.

2. However this was not the end. Once in a while olsrd crashes at this VM. After running it with strace, it showed that it crashes with the "stack smashing detected" error in olsrd_secure module right after "[ENC]Received timestamp 14096805" message. You can google "stack smashing detected" message, there is a nice explanation to it on the web. This might be the same case with UBNT problems.

3. Another thing happens on all the nodes, including Linksys. After some point they start ignoring OLSR packets from their neighbors. olsrd is still running, but when restarted with "-d 4" parameter, olsrd_secure keeps saying: "[ENC]Timestamp missmatch in packet from 10.251.51.50! [ENC]Rejecting packet from 10.251.51.50". Strange thing, it does not help to simply restart olsrd, you need to reboot the node to fix this. Also, most of our nodes do not have access to NTP servers which might or might not be necessary for the stable operation of olsrd_secure module.

I could send you the debug logs from which I quoted the error messages if you really want to troubleshoot olsrd_secure. However I just believe the whole olsrd_secure thing is no good. This module is known for having bugs, just remember the old version of it that came with BBHN v.0.4.3 firmware - due to a bug in the module code it was incompatible with the later versions of olsrd_secure. I also wonder how many networks have actually changed the default encryption key in all of their routers? For running with the default key adds zero value to security, but brings a lot of headache.

The reason I am writhing this is to maybe help you with your troubleshooting, but also to ask you if you have any short-term plans on releasing the new FW version without olsrd_secure. Otherwise we'll probably be rolling back our network to v.1.0.0 for now.

Thank you and 73

Anthony VA3IDL

Unfortunately, the laws of physics still apply to BBHN.  I can tell you that I have used NanoStation M2's at 13 miles and they work well.  A friend of mine has gone closer to 20 miles but it was a week connection.  The trick is line of sight including the Freznel zones.  The NanoStation is my favorite device right now. 

The map only includes people who have registered.  I suspect that there are a couple of other hams in Stephenville that are or could be convinced to use BBHN.  I would suggest you try some of the local clubs such as the Tarelton Area Amatuer Radio Club and ask. 

It usually takes one or two people to start using BBHN in an area for it to catch on. We have a decent network going in Waco.  It started out with one person putting up a node and someone else connecting to him.

Clint, AE5CA

From a computer plugged into the access point, from a web browser use http://localap:8080 or http://localap.local.mesh:8080.

If you can get into the access point using putty you could use the command

Has anyone setup their network using the Uverse internet router 3600HGV? (I have a Bullet.)

The DNS on the UVERSE can't be changed and it has no static routing capability.

I tried an outboard Netgear router WGT624 V4.  But could not configure the DNS to work except on the WAN port.  (I need the WAN port to connect to the UVERSE router)

If someone has successfully configured a multiple PC system with UVERSE, let me know which outboard router they used and how they configured it.

Other than than that the node is operational in Beavercreek, Ohio as N8JJ-1

Thanks

JJ

I'm running the firmware V 1.1.2, and am having difficulty accessing the admin page on a router configured as a mesh access point.
I've tried to access it via http://172.27.0.2, which I thought was strange considering my localnode resolves to 10.153.47.49, and there was no luck there.
I've also tried http://10.153.47.50:8080/, and there is nothing there.
Here is the information from the mesh node:
WiFi address 10.19.37.230 / 8
fe80::212:17ff:fe13:25e6 Link
LAN address 10.153.47.49 / 29
fe80::212:17ff:fe13:25e4 Link
WAN address 192.168.1.104 / 24
fe80::212:17ff:fe13:25e4 Link
default gateway 192.168.1.1
your address 10.153.47.53

The Mesh access point is functioning. When I connect via wifi, my laptop gets an IP address of 10.153.47.50, and the Default Gateway is 10.153.47.49.

With the Mesh node configured as a gateway, I can even browse the Internet with the Access Point. So it seems that things are functioning - I just don't know how to access the status / configuration pages on the Mesh Access Point router to turn it back to a standard node.

Any help would be appreciated.

Dee, AB1ST 

Greetings! 

I am a new Ham (general class) and a new mesher with a nanobridge M2 all the way down in Stephenville, TX.  I am curious about the advertised 18 mi range of the M2 and whether the BBHN firmware boosts this range any significant amount for Hams of different licenses. 

According to the google map, the closest (registered) node to me is about 60 mi away outside of weatherford.  Does that map include all mesh nodes or just the mesh nodes that have manually registered their presence on the map?  Am I basically SOL to connect to any broader mesh until I can figure out how to move to civilization?

Thanks!

I'm having trouble with the IRC server on my WRT54G.
I followed the instructions and installed ngircd 20.2 on a WRT54Gv.3 running the 1.1.2 version of the firmware. I got the "Installing ngircd (20.2) ..." message and ngircd 20.2 shows up in black print under Remove Package.
I rebooted the router as a precaution and tried to connect to the IRC server.
This is where I ran into trouble, I'm confused as to how to connect to the server. I've tried irc://w6jwp-104:6667/mesh on my browser (Firefox) when I hit enter a window opens allowing me to select my IRC client (Hirc). Hirc opens but doesn't do anything until I click "connect". The Hirc Status window shows that it's trying to connect but it times out with no connection.
I've tried connecting directly from Hirc using the Lan address but I get "Access denied: Bad password?". I've tried the password that I changed to on the node as well as the old hsmm password with no luck.
I see lot of references to accessing the ngircd.conf but no information on how to get to the file so I have made no changes to it. Any idea what I'm missing?

- Joe W6JWP

I have a IBM computer running Linux, I've installed Asterisk and FreePBX but I can't seem to get the router to show a link for the PBX System.  Do I have to have a raspberryPi to run a VOIP system or do I just have some settings wrong?

Thanks: Zack