Another talk at Mississauga ARC tomorrow, May 28, 7 pm. (location: http://www.marc.on.ca/marc/club/club_map.asp )

This time I am planning to do a hands-on demo session with a heavy focus on applications. Please bring your laptops/tablets/cellphones to take part in the demo. You will see a number of things that have never been shown nor published before.

See you there,

73 Anthony VA3IDL

I now have a working node using a WRT54 with v3 firmware. I am roughly 4 miles west of Neyland Stadium.

I would like to setup a tunnel since I am not in RF range of any other nodes.

Anyone willing to offer access to their mesh?

Thanks,

Daryl

N9YIW

It sounds like you hit all the steps. Here are my notes on how I got M9 working. Maybe you will see something that helps.

NOTE

Ben K0JBH

Hi

I am wonder haw many nodes you have in local networks ? and how many hops ?

I am asking about this because we have see that in Mesh network bandwidth changing with follwoing

• 1 hop - 50% of the possible bandwidth.
• 2 hops - 25% of the possible bandwidth.

• 3 hops - <10% of the possible bandwidth.

• 4 or more hops - it stabilizes at 7% of the available bandwidth.

How to solve problem bandwidth with many nodes in local network  ?

73 Waldek

Check you email!

73

Dave

good job!  BTW, I would highly recommend moving to v3 due to known issues in prior versions.

Are BroadbandHamnet-v1   and -v3 compatible?   I can't get my new v3 model talking to the other 2 on v1.0 software.

Found a like new WRT54GL with new DD-WRT software on eBay at a steal, had it 'hammed' in minutes.

Still trying to get an old WRT350n going, but everything fails.

Bo

The technical implementation of the 'gateway' is such that if there is no route on the mesh to an IP address, then send traffic to the 'gateway'. Here's what this 'default' route looks like on the gateway node (there's more complexity with policy routing we'll ignore for the moment):

Destination      Gateway        Genmask      Flags Metric   Ref     Use   Iface

default          192.168.1.1      0.0.0.0       UG        0      0       0     eth0.1

Thus, any IP address that mesh traffic is being routed to, and the mesh has no specific routing definition, will go to 192.168.1.1. Changing the netmask to 255.255.255.254 for a 192.168.x.x route, bumps it to the default route.

All, please consider that this design and behavior is how all your home netgear, linksys, etc. routers work. The same scenario occurs when you connect 2 netgear devices back to back, for example:

Netgear_A_WAN_port -> Netgear_B_LAN_port/Netgear_B_WAN_port -> ISP_Internet_port

10.x.x.x_network -> 192.168.x.x_network -> internet

It is a design choice for the 10.x.x.x network to openly talk with the 192.168.x.x network (and venders' default is 'yes'). If the design choice is to not have access to the intermediate network, then a config setting can be made given know-how (on ether side of the fence). There are a few options for the intended behavior, DMZ, don't daisy chain, and more.

Joe AE6XE

I was able generate a key that was accepted on a linux system but when I upload the key it still says key file sanitized and the key does not show up in the "remove keys" drop down. When I ssh in to the node I am still asked for a password. I have attached a screenshot. Hope this additional info is helpful.

Thanks

Edit: attachment

Attachments
 ssh-key-upload.jpg [34 KB] ::

In looking over what is happening and what is wanted, Im thinking if you crank down the subnet on the mesh node WAN/route to only allow ONE IP might give what you want easily.

Try changing 255.255.255.0 to 255.255.255.254 on the node's WAN subnet mask and/or in the static route .

KTF

Owncloud is decent, but, haven't played with the sync capabilities.

Also, this looks promising:   http://sourceforge.net/projects/freefilesync/