Hey, AA3JC, you ready to test that yet?  I'm new to mesh, but am relatively close to you.  I finally got some equipment to test with, a couple of WRT54GL units.  I just have the stock antennas at the moment, but will tinker with that in the near future.

-WS3O

If my PC is typically connected to my ASUS wireless router,

and the ASUS router connected to one of the Linksys routers via Ethernet cable,

Will the PC the Hamnet access? 

I am not sure if this is a possible configuration,

definitely would be interested in understanding why or why not ?

R~

I have two Linksys WRT 54GL routers with two windows 7 PC's on the Hamnet.

I also have an ASUS AC-RT68U wireless home router.

If the Linksys Internet port is connected to the ASUS LAN port via Ethernet cable,

and the ASUS is connected the internet,

will the PC's have internet access through the Hamnet?

Thank you

ROGER
KD2CRS

Assumption is that you are using the 1.1.x version of the firmware.

There is a current bug in this firmware with the secure feature added. The conditions for this defect (on both ubiquity and linksys) are:

1) a time window of 5 seconds when 2 nodes are in a handshake to authenticate with each other,  to confirm they both have the private 128-bit key (which is distributed with our image) and thus can allow the link.

2) If the handshake of #1 fails during this time, then all subsequent packets will be dropped and the node ignored. The handshake can fail due to:

2a) The clock on one of the nodes (via NTP or other) jumps more than 3 seconds (50/50 chance of failure).

2b) Lost packets on RF channel

Options available to workaround:

1) comment out the secure plugin in the config file hostUBN:/etc/config/olsrd hostLinkSys:/etc/config/olsrd.confi and reboot (but all nodes in your mesh must do this to connect)

2) upgrade to bleeding edge experimental images released on the download page (but some other changes to be aware of in these images and all nodes must do this in your mesh)

3) revert to 1.0.x images (no ubnt, 5Ghz, etc. and all nodes...)

If you are not running this on a production (served agency) network a beta release of version 3.0.0 has been posted to the Software Downloads section of the website under "Experimental Builds".

3.0.0 uses a V3 protocol so it will not link with older networks.  It is believed to resolve a number of issues (including a removal of secure module while we spend more time looking into the issues)  however as a beta build it has not been fully tested so unknown issues may exist in it so if you have a few nodes you use for testing you may want to install it with those to see if it will fit your needs.

If you are not running this on a production (served agency) network a beta release of version 3.0.0 has been posted to the Software Downloads section of the website under "Experimental Builds".

3.0.0 uses a V3 protocol so it will not link with older networks.  It is believed to resolve a number of issues (including devices not working off a Linksys router)  however as a beta build it has not been fully tested so unknown issues may exist in it so if you have a few nodes you use for testing you may want to install it with those.

Myself and another ham are working on setting up a mesh node between our house.  I have three routers: wrt54g x2 and wrt54gs x1.  All were working fine but suddenly they don't see each other.  1 box is connected to a computer with FreePBX/Asterisk Server, Node 2 is connected as a mesh gateway, and the last will just be connected to an IP Phone.  I can access each of them via localnode:8080 but they just don't see each other and they are currently in the safe room together.

Any ideas?

Nodes reset to initial configuration mode upon upgrade.  You need to log back in to your node (dhcp) and configure the node to the settings you want.

I just upgraded both my wrt54g routers and I am not able to connect to either of them. I am using static addressing I have connewcted to both the wan ports and the lan ports and I am not able to ping the addresses.

What did 1.1.2 change my addressing to:

Thanks

KK6IVW

Peter

Might be better to ask a Mac forum as they will know better than me (I don't use mac)

normally I would just set a priority (on Linux/BSD/windows ) would use the route metric variable to change which route is higher priority but MAC doesn't support that 

http://superuser.com/questions/472454/how-does-mac-osx-prioritize-network-interfaces-when-routing

Looks like you can set higher priority on the first interface and lower on non mesh interface making the main mesh interface the main route.

That's about all I can give you as I don't use or have access to a Mac.

DNS only deals with turning it into an IP address

Routing and interface selection is done at the IP stack level.

All the mesh nodes will handle being assessed by their FQDN.

odds are you have multiple issues going on

1) Default gateway 

2) no route for 10.0.0.0/8 to the mesh gateway -- normally this is done by the fact the mesh gateway node is the default gateway (by default the interface is on a /28 )

3) IP route level priorities not set in correct order

4) possibly not all dns severed  in the resolve.conf file 

The issue of having two networks with overlapping subnets is an issue WAY below the DNS layer. DNS has no relevance on the issue. Also the reason for a full. 10.x segment is that it's designed to be used in isolation (we are using it in isolation) and having. 2^24 address space matches up with fairly unique data set size to avoid IP address collisions.

Ultimately the fact you are running a network that conflcts with the mesh address space mean you will always have to loose some access to the full mesh 

Theoretically (assuming mac lets you, I know the BSD base does) You can set the port with the. 10.19.n.n network to always route 10.19.* out that port and route the rest of the 10.n.n.n address space out to the mesh.  You will loose all access to mesh 10.19.* hosts.  All a matter of route setting commands and priority levels.

I wouldn't recommend a deployment like that for an emcom network due to the fact it would not be fully reachable.