|
Broadband-Hamnet™ Forum |
|
|
|
|
|
|
Subject :Re:Backward compatability?..
2014-09-24- 17:17:11
|
|
|
KG6JEI |
|
Member |
 |
Joined: 2013-12-02- 19:52:05
Posts: 516
Location: |
|
|
|
Forum :
Firmware
Topic :
Backward compatability?
Well let me address the quick part of this first. Upgrading nodes, I'll admit is currently not the easiest of process and not the most feasible remotely (it is actually doable though via various methods since it comes up in a AP mode still) You will want to keep an eye on BBHN->ticket:54 for this. Your not alone on that issue, its been voiced by the beta team as well (whom each has probably done more upgrades than any other group around) that it is something we need to add. It is also an issue that affects me as one of my nodes is in limited access with a second also planned. The ticket hasn't had much progress due to several other priority tickets in recent months but it is on the list of things we want to be seen done. Hopefully it will be possible in the nearer future to get those nodes upgrades without any direct interaction. Compatibility, now that is a deep subject. You are right that it creates its own issues jumping versions, and it is not taken lightly. Networks take time to upgrade and planning to do, The choice to go to V2 was done based on needs seen and as many of those needs that would need to jump a version were put in at the time of the build (compile enough changes to justify the version jump.) Some of those needs might not stick out at first, but as we plan ahead for networks to be bigger we have to be ahead of the curve.
Version 3 was in no way on the roadmap for this soon (read as: I had zero items on my personal roadmap that could justify being the cause of a version jump.) Without being binding (life changes as we move along) that probably meant I hope at least another 12+ months before the subject even would arise. Version 3 is ultimately a patch set, we found issues in the 1.1.x build that we think are going to take a couple months to fix, and it just happens it was in one of the parts that was added as a feature (but wasn't the only protocol changing feature added so we can't just roll back to V1) It was a difficult choice to come out with V3, but was made based on the general appearance that not many networks had fully adopted V2 yet, and that the issues were so severe we needed to provide a new working version. The goal was to fix the problem and get a release out without a version jump, that didn't pan out and the decisions tree basically got to where we had to make the decisions to pull a set of code that appeared to be a large part of the issues, and get a more stable release out. I can attest that a large number of man hours were put in by the beta team members to find the root cause of why we are having the issues we are having. I wish I could say from the dev side that we were already able to solve all the problems based on their feedback but we havent. They have given us significant amounts of detail on the matter and worked with us to make sure we collected all the information we believe could get us to fix the issue and it puts us where we just have to dig through and find the lines of code that cause issue. So in closing, you have a perfectly valid point, and it is absolutely fair to be commented on, especially from the forward thinking mindset you appear to have on the subject. |
IP Logged
|
Note: Most posts submitted from iPhone |
|
|
|
|
|
Subject :Re:Mesh/Asterisk/PSTN..
2014-09-24- 16:32:04
|
|
|
W5LMM |
|
Member |
 |
Joined: 2012-02-13- 18:18:04
Posts: 126
Location: Albuquerque, NM |
|
|
|
Forum :
VoIP
Topic :
Mesh/Asterisk/PSTN
I'll give it a try, but I can't imagine how that would work, how the LAN that the phone system is on would be able to assign the DHCP address for the phone system, while a mesh node is sitting between it and the Asterisk box.
Even so, how would a VOIP phone reach it, since it's outside the mesh?
To add insult to injury, the LAN happens to be a 10.x.x. subnet, which unfortunately is what was chosen (the entire 10.x range! ugh)by the developers of BBHN. |
IP Logged
|
|
|
|
|
|
Subject :Re:Backward compatability?..
2014-09-24- 15:23:37
|
|
|
N1AHH |
|
Member |
 |
Joined: 2013-12-29- 09:04:08
Posts: 11
Location: |
|
|
|
Forum :
Firmware
Topic :
Backward compatability?
I think loss of interoperability is a big blow to the future of mesh networking. I can't imagine that all the nets in the world will continually upgrade to the next version. So for travelers, like many of us, it will be a big issue. I intended to run a node as I drove from Maine to AZ this fall. I won't be in any one place long enough to re-flash my routers every time I change networks.
I have run a number of repeaters in places like Maine, where access is a sometimes thing. Many of the sites are a hard trip by snow machine or helicopter. Get a ride up when the commercial guy has a problem. Not something that will happen for a software change. We are in the process of building a link which will use a hardened military site as one part of the hop. Not an easy place to access when you are trying to keep a low profile.
And what happens with VPN attached systems? I assume they would need the same version to work together. I have been considering hosting a VPN server at QuartzFest15 (or perhaps QF16--17?) with a link (via firewall) to the outside world. You could leave your home network running and VPN to it through our server. For those that might not know, QuartzFest is a week long hamfest in the desert just south of Quartzsite AZ in late January. Last year I think some 600+ hams attended.
Other networks could VPN to us during QFnn and attend virtually. In time I envision one of those "Personna Robots" wandering about QF19, attending the seminars, run by a ham in Idaho..or Brazil...
Obviously the version changes are considered a necessity. Nobody would go to that much trouble, rewriting the software unless it was necessary. I just wanted to voice some issues that hopefully will hide in your mind as you continue developing software for what I consider to be the next big thing in amateur radio.
Ron, N1AHH.
PS. We will be running a mesh network at QuartzFest 15 this January. Hopefully with a slew of nodes and many services. It will be a great opportunity for us to learn about dense networking, solar operation and general messing about with networks. Interoperability is already an issue. |
IP Logged
|
|
|
|
|
|
Subject :Re:Version 3.0.0 who is using it?..
2014-09-24- 05:51:00
|
|
|
|
|
|
|
Subject :Re:NTP Server..
2014-09-24- 04:55:53
|
|
|
KG6JEI |
|
Member |
 |
Joined: 2013-12-02- 19:52:05
Posts: 516
Location: |
|
|
|
Forum :
Applications
Topic :
NTP Server
Ok, as long as you understanding (and anyone reading this in the future) understand the limits of the suggestion that is all I wanted to make clear. BTW: Patches are welcomed (GPLv3) for adding features that fit a need such as picking up the time from a different node that is advertised, sorting through them to find a valid one, etc) Some features make it in quicker when someone whom personally really needs it and is vested in its outcome is working on it (Ubiquiti in my case.)
|
IP Logged
|
Note: Most posts submitted from iPhone |
|
|
|
|
|
Subject :Re:NTP Server..
2014-09-24- 04:36:29
|
|
|
AD7QF |
|
Member |
 |
Joined: 2012-04-16- 05:51:12
Posts: 23
Location: |
|
|
|
Forum :
Applications
Topic :
NTP Server
As you said, " Manually updating the ntpclient settings on each node is the hard part."
This may not be a solution for everybody, it was never meant to be. But it is eloquent and simple once it is put together. Part of that is that it does not require any modification of other nodes. It is also a boon to those that would be daunted in going in on the command line of a BBHN node to make modifications from there.
As I said before.
A great appliance in the correct situations. |
IP Logged
|
Last Edited On: 2014-09-24- 04:39:32 By AD7QF for the Reason
|
|
|
|
|
|
Subject :Re:NTP Server..
2014-09-24- 04:16:06
|
|
|
AD7QF |
|
Member |
 |
Joined: 2012-04-16- 05:51:12
Posts: 23
Location: |
|
|
|
Forum :
Applications
Topic :
NTP Server
I have not completely codified the processes yet, as some more experimentation is to be done to satisfy my curiosity. Such as, working with additional GPS devices. Currently this is dependent on a single vendor. At such time as I do, then step by step instructions can be written. Also, by then I will have read all the critiques posted here and evaluated their worth.
As you see in my previous posting, this appliance has it's greatest worth when no other connection is available. A very real and frequent situation. If a current Internet connection becomes lost, then would be the time to plug this appliance into a WAN port. As currently coded, the BBHN node software is not set up for alternatives. Until that is changed, this is the most eloquent and simple solution. I have seen in the wish list items addressing the need for better time controls. |
IP Logged
|
Last Edited On: 2014-09-24- 04:23:14 By AD7QF for the Reason
|
|
|
|
|
|
Subject :Re:NTP Server..
2014-09-24- 03:47:42
|
|
|
AD7QF |
|
Member |
 |
Joined: 2012-04-16- 05:51:12
Posts: 23
Location: |
|
|
|
Forum :
Applications
Topic :
NTP Server
In this geo area no one has made a gateway, as of yet, to the Internet, and are not likely to. We do mostly ad hoc field setups for event support, field day, etc. The purpose and assumption is that there is no Internet gateway. In addition, both the node and DHCP server offer up Google name server addresses for failed resolutions. Nothing unusual about that.
Again I repeat, if an Internet gateway exists then there is no need for this device. My experience is that mesh are being set up without a gateway to the outside Internet. And you will agree that random times are seen across such a mesh from each node. Such chaos can not be tolerated on the Internet. There is some software that will choke with inconsistent timings.
Having an actual Internet connection is a luxury, and may not be possible. Having the correct time "can" become a technical need. We ordinarily do not see the need with the simple services currently being used. But as we become more sophisticated in our use of BBHN mesh then what you call a luxury will become a critical technical need.
With this understanding, I put forth this as one possible solution. Part of it's elegance is that the operators of the other nodes need not understand or configure their devices to take advantage of this service. That is until the BBHN software is modified to allow better control of the time settings, such an appliance it useful. |
IP Logged
|
Last Edited On: 2014-09-24- 04:21:18 By AD7QF for the Reason
|
|
|
|
|
|
Subject :Version 3.0.0 who is using it?..
2014-09-24- 03:29:02
|
|
|
AE5CA |
|
Member |
 |
Joined: 2012-05-19- 21:52:33
Posts: 81
Location: |
|
|
|
Forum :
General
Topic :
Version 3.0.0 who is using it?
In the downloads folder for both Linksys and UBNT, there is an experimental software link that includes version 3.0.0 Beta. I have put it on my mesh network here in Waco with good results. It appears to fix or mask the errors in 1.1.2. I have over 20 nodes up and running and they are maintaining connections. The OLSR crashes are minimized and the watchdog is bringing it back up when it does crash.
Who else is using it and what have been your results? Clint, AE5CA
|
IP Logged
|
|
|
|
|
|
Subject :Re:Thank you MOD GODs for your blessings of our own board!..
2014-09-23- 11:52:14
|
|
|
|
|
|
|
Subject :WRT54g v2 & v3 ver 1.1.2 missing full 'status' web page code..
2014-09-23- 11:19:36
|
|
|
K5TCS |
|
Member |
 |
Joined: 2014-08-31- 07:23:23
Posts: 2
Location: |
|
|
|
Forum :
Firmware
Topic :
WRT54g v2 & v3 ver 1.1.2 missing full 'status' web page code
All, I have both a Linksys WRT54g v-2 and a Linksys WRT54g v-3 routers initially loaded with and running version 1.1.2 but on both of those routers the full html page for the 'status' (initial load page) is incomplete. When I locally connect to the MESH using the proper IP/port I get the normal redirecting link then the Status page for the router starts to load but then spins on until it times out. It displays the nodes name and shows the command buttons but when I view the html source behind it the code is incomplete. I used a good version 1.1.2 Linksys WRT54g v-2 MESH node router to compare the html and on the two mentioned the code stops midway down the listing. If I select the WiFi Scan button it works properly but none of the others work at all. I have tried to use the update .trx file to reload things but it results in the same condition after I reconfigure the nodes. I think that the update file does not restore the files in the /www/cgi-bin folder when it is used and I can not reload the initial 1.1.2 .bin file using the Update tool on the Administrator page. Any help to get these running again locally would be a great help. BTW, I can access and modify the node Setup pages remotely from another node with connected PC and this is true for both the routers I am having this local issue with. Thanks,
|
IP Logged
|
|
|
|
|
|
Subject :Re:Need help connecting Foscam IP camera..
2014-09-23- 11:15:13
|
|
|
AE6XE |
|
Member |
 |
Joined: 2013-11-05- 00:09:51
Posts: 116
Location: |
|
|
|
Forum :
General
Topic :
Need help connecting Foscam IP camera
Camera (voip device, etc.) on DHCP--which should be default on most devices--it will obtain a 10.x.x.x address on the LAN port of the node. This address is fully known to all nodes in the mesh--the LAN 'subnet' is automatically shared to all nodes in the mesh and all the route tables automatically set. This is the beauty of a mesh and the smarts of what the 'olsr' program is doing. |
IP Logged
|
|
|
|
|
|
Subject :Re:Need help connecting Foscam IP camera..
2014-09-23- 10:51:11
|
|
|
W4PHS |
|
Member |
 |
Joined: 2014-09-14- 15:35:23
Posts: 6
Location: Brentwood, TN |
|
|
|
Forum :
General
Topic :
Need help connecting Foscam IP camera
Joe,
Thanks for the info. This is helpful.
Should the camera be set to a static IP or to use DHCP to pull an address? Doesn't the camera's IP need to be in the 10.x.x.x block? Does it need to be within the subnet mask range of the IP addresses of the node it's connected to?
Phil
W4PHS |
IP Logged
|
|
|
|
|
|
Subject :Re:NTP Server..
2014-09-23- 10:49:05
|
|
|
AE5CA |
|
Member |
 |
Joined: 2012-05-19- 21:52:33
Posts: 81
Location: |
|
|
|
Forum :
Applications
Topic :
NTP Server
I have found several articles on building a time server on the internet and I will probably build one in the near future. In the mean time, I have a Linux computer attached to my QTH node. Since this node has internet access, the computer has access to the internet through the node. I do not check mesh gateway because I do not want to provide internet to my entire mesh. By setting up the computer to serve out the time it receives from the pool servers, I have a time server on my LAN. This computer hosts a number of sevices including web, email, asterisk and a file server. All I have to do is reserve an ip for the computer in the setup section of the web interface. On a remote node editing the ntsclient file to point to my server on the mesh provides the time to those nodes. Any NTP traffic is on the mesh and my server already had the time. I could plug an dedicated NTP server into my nodes LAN and advertise it to the mesh. Manually updating the ntpclient settings on each node is the hard part. I would not want my time server to be visible from the internet. I don't want it on the WAN interface. Clint, AE5CA |
IP Logged
|
|
|
|
|
|
Subject :Re:NTP Server..
2014-09-23- 10:19:32
|
|
|
AE6XE |
|
Member |
 |
Joined: 2013-11-05- 00:09:51
Posts: 116
Location: |
|
|
|
Forum :
Applications
Topic :
NTP Server
AD7QF, I'm trying to figure out when I'll have time to build one of these. Is there a section on the website you would be willing to post the config files, scripts, instructions for others to build?
If I understand your design correctly, other nodes that use this NTP-gps node as the default gateway (because it is lowest link cost to access) would then not have access to the internet should other gateways exist on the mesh. This issue only becomes significant in the scenario where it is desirable to connect off/on to the internet and be self sufficient with ntp clock. For example in normal mode our mesh in orange county is connected to the internet. But if we went into 'incident' mode, we may likely disconnect from the internet, reboot nodes, etc. So how to make this off-the-grid ntp server independent of the internet-gateway connection? (as an additional option, not a replacement?)
Would we turn off the Pi DHCP server and become a DHCP client, connect the Pi to the LAN port of a node, then advertise this as a service to the mesh. The admins of the mesh could edit ntpclient on each node with a search path of the Pi mesh 10.x.x.x address, then fail over to internet ntp IP address? maybe we need a mesh ntp finder script for a node. |
IP Logged
|
Last Edited On: 2014-09-23- 10:27:11 By AE6XE for the Reason
|
|
|
|
|
|
Subject :Re:Ubiquity bullet firmware flash..
2014-09-23- 10:16:11
|
|
|
KG6JEI |
|
Member |
 |
Joined: 2013-12-02- 19:52:05
Posts: 516
Location: |
|
|
|
Forum :
Northeast OH
Topic :
Ubiquity bullet firmware flash
See: http://ubnt.hsmm-mesh.org/products/BBHN/wiki/HowTo/FlashUbiquiti Most common error I've seen is using the config import box instead of the firmware import box. The error text would go a long way rather than everyone guessing. |
IP Logged
|
Note: Most posts submitted from iPhone |
|
|
|
|
|
Subject :Re:Ubiquity bullet firmware flash..
2014-09-23- 10:13:04
|
|
|
N8LXY |
|
Member |
 |
Joined: 2014-07-17- 13:59:00
Posts: 4
Location: |
|
|
|
Forum :
Northeast OH
Topic :
Ubiquity bullet firmware flash
This is a Bullet M2HP unit purchased in the last 4 weeks. I am using the "factory" bin file. |
IP Logged
|
|
|
|
|
|
Subject :Re:NTP Server..
2014-09-23- 09:51:08
|
|
|
KG6JEI |
|
Member |
 |
Joined: 2013-12-02- 19:52:05
Posts: 516
Location: |
|
|
|
Forum :
Applications
Topic :
NTP Server
Note: this critique written assuming all hams of the mesh have not met and agreed that a meshgw node will never be used , if that agreement is in place the below only partially relevant (extra traffic and delays)
As a network engineer I see this as a gross abuse of the meshgw feature and can cause numerous problems in the long run. One example is now your increasing delay times possibly on DNS, your putting a lot of random traffic on the mesh that will just be denied several hops down stream ( wasting bandwidth)!etc. Throwing dns queries out that will get no useable results etc. And once a mesh node with real gateway access comes along you will be corrupting that gateways ability to serve. Please make sure you understand just exactly what you have done to the mesh if you use this feature This especially true since time on a node is more a luxury than an actual technical need. |
IP Logged
|
Last Edited On: 2014-09-23- 09:52:51 By KG6JEI for the Reason
|
Note: Most posts submitted from iPhone |
|
|
|
|
|
Subject :Re:Need help connecting Foscam IP camera..
2014-09-23- 09:46:15
|
|
|
AE6XE |
|
Member |
 |
Joined: 2013-11-05- 00:09:51
Posts: 116
Location: |
|
|
|
Forum :
General
Topic :
Need help connecting Foscam IP camera
Lan port. If only 1 device to plug into the Bullet, then simply plug in (device is on lan port). go into setup in "reserve address" and "advertise services" and add this camera. From another node and your laptop in "mesh status" you'll find the service adverstised, click on it and access the camera.
If you are looking to connect more devices, including gateway to home network, internet, or use a cable to tie 2 nodes together (Device to Device - DtD), then you'll need a switch with Vlan capability on ubiquiti devices, e.g. netgear GS105E (and the 'E' is significant). There are other posts on the forum going over this. A linksys can also be used as a low cost switch--but read other posts about doing this if going this route. I recommend a dedicated switch for robustness and scalability. |
IP Logged
|
|
|
|
|
|
Subject :Re:Need help to get started with VoIP..
2014-09-23- 09:31:07
|
|
|
AE6XE |
|
Member |
 |
Joined: 2013-11-05- 00:09:51
Posts: 116
Location: |
|
|
|
Forum :
VoIP
Topic :
Need help to get started with VoIP
I've demoed voip a few times. Connect the phones to the LAN port of the nodes. Assumption is default Lan-direct mode (not lan-nat, but this also can work) and that a voip phone will use dhcp by default to obtain on IP address. Go into setup for "reserved addresses". reserve the IP address to the phone and record it's IP address. This is an IP address known on the mesh by all nodes and hosts to correctly route. Setup memory IP dial on each phone and call away. Optionally, on the same setup screen, add the "advertised service" that you have a Voip phone. Other mesh'ers will know what IP address they can call you with.
Others may be able to comment on this specific voip phone. Also Don, KE6BXT, posted a video on this website showing the set up of other voip devices to take a look at as well.
Great pic! Joe AE6XE PPSEL IFR |
IP Logged
|
Last Edited On: 2014-09-23- 09:33:52 By AE6XE for the Reason formatted
|
|
|
|
|