I connect to my Mesh router using an Ethernet cable connected to my laptop.  The laptop connects to my home network and hence to the internet using the WiFi port on my laptop.

I find that I cannot be connected to both networks at the same time.  What I would like to do is for my browser session connected to the Mesh to connect only to the mesh node through the Ethernet cable and for all other network connections to take place using the WiFi port thus allowing me to be connected to both networks at the same time.

How do I make this happen?

If you are using Windoze, you can all but forget it trying to figure out which way is which. It gets confused very easily between the RJ45 and the wireless..

http://www.broadband-hamnet.org/documentation/96-using-the-mesh.html gives instruction on tying your mesh and LAN together, where a PC on the LAN can talk to the mesh and vice versa. I know this works, as I am using it right now. But it still wont help the wifi/LAN dilemma. Windoze will still get confused and almost always do it wrong.

KTF

Just to be clear, I am talking about physically connecting one Windows 7 computer to a BBHN node on a wired Ethernet interface and to another network (presumably the Internet) using a separate wired or wireless interface.  The objective are:

1.  Don't screw up the existing Internet connection.  It has to work the way it did before we started.

2.  Provide access to the BBHN node and network.  Doing everything by IP address is not acceptable.  If my node can see another node by name, I want to use that name to connect to the remote node.

3.  While others are free to make their own choices, I do not want to create an open bridge between the Internet and the BBHN network.

I accept that the BBHN network owns the 10. class-A address space.  The 10. address space is not used on my LAN.

Given these objectives and constraints, it is possible and I have it working.  I can open my web browser and connect to QRZ, ARRL or eBay just like I always have.  My email client and other network applications work.  I can still open and use a VPN to my corporate office.  I can connect to my BBHN node as localnode.local.mesh:8080 and through it to a remote node using a URL like ko2f-503.local.mesh:8080.

The only think I cannot do is click the KO2F-503 link on my BBHN node.  This is because when you do this the URL provided by the BBHN node is not a FQDN the link is actually just KO2F-503, not KO2F-503.local.mesh.

In the days of old Windows used simple computer names to communicate between networked computers.  Fifteen years or more back they discovered that NetBIOS wasn't going to be enough and they switched over to the use of DNS server and fully qualified domain names (FQDN).  When you use your web browser on a Windows system and enter eBay in the address bar, there is a complex set of actions that take place in the background to discover you really mean eBay.com.  Windows then does all of its network communications using the FQDN.

This is significant because Windows allows you to specify a primary DNS server for each interface on your computer and it also allows you to specify a DNS suffix for each interface.  By configuring your system correctly, everything works as long as you are using FQDNs.

For more information about how Windows actually resolves names, you can refer to the following Microsoft TechNet article:

http://technet.microsoft.com/en-us/library/cc961411.aspx

I spent a lot of time lately figuring this out and writing a How-To for setting up the configuration.  It needs to be sanity checked by someone else before I release/post it.  And frankly, I would like to discuss my findings with the BBHN development team and see if the FQDN issue can be addressed before release.

One final point.  This reply and my comments are specifically focused on connecting a BBHN node to a Windows 7 workstation.  I respect and play in the Linux work as well but this is not the topic being discussed and I have no interest in discussing or debating the merits of using Linux or whit it might be better or worse for some purpose.  This discussion is about accommodating the Billion plus users that still use Windows.

Bob, KO2F

Discussion on the FQDN in links had already begun prior to your message though I don't have a ticket number off hand for it.

It will not make it into the next build however as it is already well into feature freeze and testing.

The work around for now would be to fully qualify links when you visit them(note: this also will trigger higher security settings in some web browsers, Internet Exloirer included --- difference in Internet and Intanet zones).  I've seen a couple of scenarios where this is needed, usually because how the device that inspired into the node is configured.

Using multiple interfaces though always brings up "complex" routing (everything is relative on the word complex ). --- you also have on worry about what order Windows queries the DNS servers as if it gets a NXDomain it will stop querying. Obviously .mesh is not a registered GTLD so it will NXDomain to public servers.

I completely understand the DNS system. I run 2 copies of BIND9 (primary and secondary servers in chroot jails)  myself on CentOS (redhat upstream) with a multitude of domain names registered through my GoDaddy account. Do a rDNS on www.broadband-hamnet.org and you will see it reverses back to an IP that has its main DNS as web.leandercomputing.com, my company :-)

Im not saying having dual-homed NICs WONT work. Whenever I have done it, It did work for a while, but then Windows 'forgets' which route to go, and I would have to restart the networking services/DNS for it to start thinking again, which would last for a while, rinse and repeat.. Been there, done that. Maybe they have fixed it in Win7, I just havent tried it past XP, since I have it working this way already.

If you go into Windows Network TCP/IP settings, Make sure that your mesh node is set as the primary server. Then go into Advanced DNS, and where it says "Append these DNS suffixes (in order)" add  local.mesh . Having it as the primary DNS will not break the ability to surf the internet. If Windows cant find it ont he mesh node, it will fallover to the secondary, being your router or ISP's DNS. In the Advanced section, you can also add tertiary or more DNS servers.

That will then let you click mesh links and surf the mesh without needing to add the rest of the domain all the time manually.

But do not be surprised if it does work for a while, and then at some point you cant surf one or the other and start pulling your hair out what broke..

If you get this working on win7, and it doesnt 'forget' over time, let me know, as I will be very interested if M$ got that fixed.

Bob,

I'm not sure if it came across forums or came across my desk direct, just that's I know I've seen it.

I'm sure the software will continue to evolve to fit the needs as it becomes more popular and more feedback is given.

Just wondering - what drove the decision to use non-FQDN's in BBHN in the first place?

I'm no network expert but I saw this right away when I'd try to click on services links in my own mesh and they'd come up broken.  Hard to imagine the development would get this far before anyone noticed.

Mark K5LXP

Albuquerque, NM

I'm not sure why the decision to use short domains vs long domains in links as it predates my joining the project

I can speculate that it would be easier for users to remember http://node/ vs http://node.local.mesh/ but that is speculation only.

In regard to "broken" lInks right out if the box if you are using a single connection hard wired with wifi off it should work as the computer SHOULD get the local.mesh part from the DHCP lease.  I have seen at least 1 case where a corporate controlled PC did not accept the search root from the mesh node, but this is distinctly an issue with how the computers are setup and not with the mesh itself. Switching to FQDN's will reduce the likelyhood of single system issues displaying themselves, but is not suppose to be strictly requeired since all systems are currently in the same namespace.

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.

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 

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.

Just seeing this thread. Here's what I do, which may meet your needs:

1) laptop plugged into linksys Mesh node LAN port (windows, apple, linux, whatever)

2) linksys WAN port plugged into home network -> Internet

3) You can choose to NOT advertise the linksys to be a gateway out to the mesh in setup to not expose the gateway-internet to other nodes (but on your linksys it still routes from your LAN ports).

End result: Your laptop is fully able to community to all 10.x.x.x addresses freely. Your laptop is able to communicate with the internet freely. No internet traffic is going over RF. No other mesh nodes are aware of and do NOT have routing entries that would enable them to use your gateway to the internet. Joe AE6XE