Ok, I figured it out by reading the thread on how to connect remote geographical mesh areas via gre tunnel over the internet. This is what I did with the latest software.

I configured both units by disabling the WAN interface and turning off the DHCP on the LAN interface because I was connecting these to an internal lan hooked to my computer. My computer's interface has an ip address of 172.27.0.5 and so I setup 1 unit with 172.27.0.1 as the gateway device and the other as 172.27.0.6. This way I could get into both units from my computer by moving the ethernet cable to and fro. I also put a default route on my computer for the 10.0.0/8 network to 172.27.0.1 (the gateway device to the mesh for my local lan). This way when I click on my browser and it wants to go to 10.0.0/8 address (I.E. A MESH ADDRESS) it knows how to get there!

I then logged into each unit one at a time and did the following:

In /etc/config I edited olsrd.conf and removed the # comment designator from the line that read

InterfaceDefaults {
   #Ip4Broadcast      255.255.255.255
}

This tells the routing daemon to broadcast routes out every interface. This was suggested in the tunneling example. I also changed the line below that that read

Interface "wl0"

And added the Ethernet interface to it so it looked like this:

Interface "eth0.0" "wl0"

Then I edited /etc/config.mesh/olsrd.conf

I changed the same InterfaceDefault line like above by removing the # sign from Ip4Broadcast thereby uncommenting the line. Then a slight bit below that I changed

Interface <olsrd_bridge>

by adding the ethernet interface to the list of interfaces so it looks like this:

Interface "eth0.0" <olsrd_bridge>

Then reboot and Voila. I changed the SSID on the 172.27.0.6  node so they could not see each other over wireless, plugged an ethernet cable between them and wham the mesh propagates properly.

The only annoying thing is that the OLSR daemon publishes the interface links onto the mesh, so when you look at the mesh status page you see the 172.27.0.100 on one and 172.27.0.1 on the other. If someone knows how to tell olsr to ignore those then it would be 100% Perfect!

73 de KF7PSm

Hi,

I have replace file http://hamnet.ugu.pl/download/obcm-rpi-full.tar.gz

new version full package contain binary "bcm" for RPI and Linux after restore archive

please copy bcm.linux to bcm for Linux and bcm.rpi to bcm for RPI

Archive include 2 version terminal to login OpenBCM bct.rpi and bct.linux

73 Waldek sp2ong

If try setup of AmprNet GW on RPI you can use ampr-ripd download from

http://www.yo2loj.ro/hamprojects/

and create script to run like me below and change from 44.165.32.xx to own IP

#!/bin/sh
# SP2ONG amprnet routing including rules.
##################################################################
## This script was developed by KB3VWG on a standard Ubuntu 12.04.1 LTS PC
## with IPv4 forwarding enabled in /etc/sysctl.conf by changing the
## net.ipv4.ip_forward variable to 1, eth0 configured to the Public facing
## LAN and eth1 to the 44LAN. It is designed to enable an AMPR Router using the
## rip44d_table44 file, the standard rip44d, using the -t switch to add routes
## to routing table �44�� with no fruther configuration needed (firewall optional)
##################################################################
## This script was modified by LX1DUC to automate even more tasks.
##################################################################
########################################
### ENABLE IP FORWARDING ###
sysctl -w net.ipv4.ip_forward=1
########################################
### ENABLE IPIP TUNNEL INTERFACE tunl0 ###
### you must enable the tunnel before specifying routes using the tunnel
modprobe ipip
# My server AmprNet IP
ip addr add 44.165.32.1/32 dev tunl0
### gives tunnel its own TTL of 64 enabling traceroute over tunnel
#ip tunnel change ttl 64 mode ipip tunl0
ip link set dev tunl0 up
ifconfig tunl0 mtu 1480
########################################
### FIREWALL TO COMPLY WITH AMPR ROUTING RULES ###
########################################
### LAN ROUTING RULES (required if used as the LAN�s gateway) ###
### Allows 44LAN to use main routing table to access LAN (optional)
### (NAT/masquerade from 44.60.44.0/24 to must be configured
### if LAN hosts do not use AMPR Router as their LAN Gateway)
#ip rule add from 44.165.32.0/24 table main priority 1
#ip rule add to 44.165.32.0/24 table main priority 1
########################################
### AMPR ROUTING RULES ###
### Per PE1CHL: �This is �required� to get routing of the net-44 traffic correct ###
### and have a default route for the tunneled traffic different from the default ###
### route of the system. It may be possible to get it working without this, but ###
### policy based routing is so much easier.� ###
### Packets to and from the 44 Network use Route Table 44
ip rule add to 44.0.0.0/8 table 44 priority 44
ip rule add from 44.165.32.0/24 table 44 priority 45
####### TABLE 44 ROUTES ###
### Default Route [Internet Access] using AMPRGW for 44/8 hosts (optional)
### do NOT change the IP 169.228.66.251, this is the central AMPR Gateway
### and all traffic leaving AMPRnet towards the internet MUST pass this router.
ip route add default dev tunl0 via 169.228.66.251 onlink table 44
# link to WRT54 Mesh Node where WRT have IP 44.165.32.254 and 192.168.1.5
#ip route add 44.165.32.254/32 dev tunl0 via 192.168.1.5 onlink table 44
### Leave the 44.0.0.1 route below commented if the default route is used,
### in which case, RIP44 will create it automatically
#ip route add 44.0.0.1 dev tunl0 via 169.228.66.251 onlink table 44 window 840
### Adds 44LAN Network to Table 44

# Network for OpenVPN tunnell
#ip route add 44.128.1.0/24 dev tun1 table 44
#ip route add 44.128.2.0/24 dev tun0 table 44
#iptables -t nat -A POSTROUTING -s 44.128.0.0/16 -o tunl0 -j MASQUERADE

 ####################################

iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP
########################################
### STARTS THE rip44d ROUTER DAMEON � removing the WAN IP address of the local gateway ###
### (rip44d announcements, 44LAN route, and removing local WAN IP with -a switch
### equals full AMPR routing table)
/usr/local/sbin/ampr-ripd -s -r -t 44 -i tunl0 -p password -a 44.165.32.0/24

The password in ampr-ripd you must know from porta.ampr.org or ask me when you register amprnetGW

Hi,

Ok you can download my working OpenBCM on RPI:

http://hamnet.ugu.pl/download/obcm-rpi-full.tar.gz

Add user and group "bcm" with home dir /usr/local/bcm. Restore archive below in /usr/local/

chmod -R bcm.bcm /usr/local/bcm

Change in file /usr/local/bcm/init.bcm own call and port number for services default is:

http 9080

smtp 9025

pop3 9110

nntp 9119

copy to usr/local/bin file /usr/local/bcm/bct

BCT is terminal login to OpenBCM

add in /etc/rc.local command

su bcm  /usr/local/bcm/startupbcm

to start up OpenBCM on RPI up

when you start up OBCM you can access to OpenBCM

http://you_ip:9080 and login with your call but before this you must login via on terminal use "bct" to create account and add password with command after login

A TTYPW

You can see own setting use command:

A

Change language:

A S GB

You can find manual (90% translate to english) in /usr/local/bcm/msg

OpenBCM_1.07_Docu_English_29.12.2006.pdf

You can download sources OpenBCM modify by me to compile on RPI

http://hamnet.ugu.pl/download/sobcm-1.07b12-rpi.tgz

and complie with "make"

I thing that instead GRE link is better you cna run on RPI AmprNet GW (you can register on http://portal.ampr.org) after this your RPI will part of global AMPRNet network with ip addres 44.xx and your server and other local users via this amprnet will be have access to others amprnet network.

When you setup AmprNet GW you can simple connet to my server http://sp2ong.ampr.org

You can setup OpenVPN or RPI to make tunnel to users ham radio to access from Internet.

73 Waldek sp2ong

Hello all,

I was posed a question this evening by a ham who has 2 mesh nodes on a tower. One at 90 ft. and another at 60 ft. The one at 90 feet has a parabolic pointed in one direction for sake of discussion. The other has a parabolic pointed in a different direction and also an omni for local coverage. Because of the vertical separation and antennas used, neither unit can see the other!

Question: Is there a way to use either the wan ports or one of the the switched ports and tie the 2 units together so that they become part of the mesh and route traffic to and fro?

My thoughts would at first be to get into each unit with ssh and do some command line magic. Maybe setup a bridge device br0 between the wireless lan device and one of the ethernet devices in effect bridging the traffic. Doing this on both units and connecting with a cat 5 cable?

What I'm wondering is if the OSLR router will know if the adjacent node is a close neighbor or not, and what will happen to the routing entries learned in the OSLR routing tables.

Any insight, thoughts, ideas would be appreciated, I just started to think about this tonight, I'm a network engineer and have worked on linux routing schemes in the past, but nobody works good in a vaccum so anyone with experience please send me ideas.

73 de KF7PSm

Don,

You will need two things to get your Bullet M2 running.

1. A suitable antenna and lead-in to match the N connector on the Bullet.
2. A 10BaseT (twisted pair - CAT5 or 6) Ethernet cable and a PoE injector.  The only connection for power is via the RJ-45 socket in the base of the Bullet.  PLEASE NOTE: the Bullet uses pair 4,5 for +V and pair 7,8 for Ground.  Some of the cheap power injectors on eBay reverse this and will fry your new toy.  The injectors that I've seen on eBay that do this are generally black in color (not trying to be racist here - this is just what I've observed :).  Pull out the old multimeter/DVM and scope out your injectors before applying power!!!!!

If you're going to attach your Bullet to a router providing PoE please be sure the voltages are on the right pairs and the voltages don't exceed those accepted by the Bullet.  Be careful when using PoE-supplying Cisco equipment.   ALSO NOTE: Pairs 4,5 for +V is the IEEE standard and Ubiquiti.  Pairs 7,8 for +V is the Cisco "standard". 

        -Rusty-

Will look into OpenBCM on a separate rPi... I already have Postfix, Dovecot and Innd2 installed and working on my local mesh and don't want to lose the work already done. I'm probably doing it the hard way, but I can already send mail between users on the rPi using Postfix/Dovecot and already have local working newsgroups on Innd2. I chose these apps because they are widely available, easy to configure and for the most part industry standard.

Will contact you when I'm ready to set some tunnels up.

Thanks for the reply.

You didnt see the MD forum over here?

http://www.broadband-hamnet.org/hsmm-mesh-forums/view-topiclist/forum-39-maryland.html

:-)

Can anyone provide any iinsight into use of and any issues with the Ubiquity M2 bullet systems?

I see they are now supported but looking for advice.

Already have system on order, so any help in getting it running/prepping for its arrival would be appreciated!

Thanks in advance!

73,

AB1PH

Don Rolph

Also, the gateway is "one way" only.   Stuff on the LAN or mesh can get to the WAN side, but access to the LAN or mesh from the WAN side is very limited.

Did you log into the router and check "mesh gateway" on the setup page?

I understand the ramifications of having the WAN connected to the internet but this has gone beyond that and is simply wanting to understand what is happening or more to the truth what is not happening.

I setup my home router so I can access my BBHN gateway node from the comfort of my lounge chair and play with it, adding packages or whatever.  Essentially experimenting and learning about the system better.

I can access the gateway node only by using 10.230.5.145:8080.  This gives me the status page.  Bring up the mesh status page and clicking on another node Firefox errors out stating it cannot find the node by name.  This I understand this because it can't resolve the name.  Now if I try to go there using 10.192.32.193:8080 it simply times out.  Is this because 10.192.32.193 doesn't know how to get back to the system running Firefox?  I would think the gateway would handle that.

I guess the next question is does DNS cross the gateway?  I'm assuming not because of the actions I have seen. Is there a way to enable it?

I'm suspecting that this may be the design of the BBHN mesh.

Any help is greatly appreciated.

Beam me up!

'Captain' Kirk - N6SXR

I've had three nodes up and running in Laurel, Maryland USA for a couple months now and not seen any other activity yet. Hoping others will join in and grow the mesh in Central Maryland.

OOPs. This got posted in Virginia's folder. Can't seem to find the function to create a folder for Maryland.

I need to link via a 19 mile RF path and need some advice and guidance.

Near site is on top of a building with 3" pipe available up to about 25'. Far end is on top of a mountain at 2500'. Clear shot, no fresnel issues.

I was considering the Ubiquity Air Mesh with the larger grid, however the specs put it near its maximum range. 

Anyone with real world experience that can provide suggestions? 

Ron, N1AHH

I am interested in your project. However I am a newbie at this mesh stuff. Fair IT background, but been out of the business for 15 years now so all information subject to brain scramble.

I live in a remote desert community. Few hams local, however we are trying to do some long range RF hops to expand the mesh.

Interested in news feeds, e-mail and tunneling.

I will be here in the southern AZ desert until May or so when we move to Maine. Again a very rural area. From there we will head to my daughters farm in Brazil sometime in January. Again a very remote area. so setting up news, email and tunneling would be of great interest.

How do you suggest we proceed?

I have Pi and stack of meshed routers in hand.

N1AHH