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.

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

Dear Hacker:  Thank you for the information--the note about linking with my home unit was about how i knew it was working--i had been meshing with other unit using the wrt54, amp and tp-link omni--

it might be helpful to know what link quality means, how is it calculated

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.

Aah, but Wes, I consider code practice a-tonal music (one that lacks a tonal center). A-tonal or not, code practice is music to my ears! Under your definition, I'd best not do code practice either.

Thanks for reviving a dead thread.

Well, this has been an interesting weekend with raspbx.

Got things working finally for the extensions a little bit ago. For some reason, the android sip would not

accept incoming calls but could send them. As for text messages, could send both ways.

The other extension is for the windoze laptop. That seems to have been working ever since I created

that extension Saturday morning. Could call and text both ways with Linphone.

To my surprise tonight when I took a look at my gmail account, there were four messages from the

pi telling me that I had some voice mail recordings to listen to. For this feature, I thought it was not

enabled until I entered somewhere in the pbx admin pages the smtp and pop mail settings. Going

to have to take a look at that feature and see how that could be used to send messages to a Jnos

system that I plan to have hooked up once I get things more advanced. I know it can be done, just

been a while since I have done it.

I don't think I will be taking this out for FD this year for each station to talk to each other. Not mature

enough to not have to worry about yet.

I now have two SPA1001's and two SPA2102's coming to tinker with. Now to figure out how to have

an old android phone be able to talk to a hsmm node directly. Can that be done?

James W8ISS

WIFI IP address is currently auto set as 10.n.n.n. where n.n.n is the last 3 octets of the WIFI MAC address converted from hexadecimal to decimal.

How are IP addresses determined by mesh nodes? My Ubiquiti based nodes come up with an IP, but I'm setting up a PI based node and it want's me to select a address. How can I select an address that will most likely not conflict?

Thanks
Bernie

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.

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.

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

A couple of items come to mind here:

1) The amplifier -- it is very possible the amplifier itself is decreasing the quality of the signal being transmitted.  WIFI requires very linear amplification. It has been seen that many amplifiers actually distort the signal (especially when the power from the router is more than 2-3dbm ) so while you may have an LQ of 100% in ine direction it could be 0% in the other direction.

2) The Omni -- while omni's may have a place they can pick up noise from all directions,  add this to the noise from the amplifier and you may be far enough out that thr node just can't hear you due to local noise.

3) Bullets are single chain devices, having multiple chains (Rocket or Nanostation) has proven to be a better receiver than just a bullet. (Signals while bouncing can change the plane they are in)

4) Distance Paramater -- Ensure this is set do the distance required on both nodes.

There is no timeout in units trying to mesh, it will happen continuously.  You may want to look at the OLSR Status page and see how the routes look and if you have an NLQ value for the node in question and what the % is and what the RTX cost on the route is .  If you have 100% one way but 0% the other than you don't have a connection that would be useable.

The PC attached plays no part in meshing only in accessing the services on the mesh. 

at a remote location with mobile wrt54, a power amp and tp link omni at a distance of 9.84 miles from my home ubiquity i get 90 to 100 % link quality over a 15 minute period; but can not mesh--from a closer location with only link quality of 50-60% using just the wrt54 i can mesh--my computer times out when i try to mesh from the distant point---can i increase the time allowed for attempted mesh?

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