Running a central tunnel service is a different subject than just running a few tunnels on a node.

if your going to do it make sure your a good networking guy as that's critical. Having skills in SaaS industry would be an advantage as it's the same concept.

I've looked in to it and had it on my plate but I've been pulled towards the core BBHN project and haven't had time to work on it more than the proof of concept phase because of my responsibilities to core.

Services can be placed anywhere that's why we have the services advertisement features, IP addressing is a networking low level item and doesn't affect where services are, as long as the routing is good.

Node IP addressing is already standardized by an auto generation routine. VPN tunnels have a standardized address space recommendation  as well.

Has there been any talk of standardizing of IP Address allotment? So that there is a standard between NODES, so that if they are connected be it localy, or tunnel, addressing is easily determined. for such things as servers, and voip? 

thank you,

Works for me.

You will need to use NAT mode as only 10.x addresses are permitted on the mesh.

This means the host IP's will not be directly reachable on the mesh and you will have to use port forwards for any services you wish to host.

Regarding ease of changing nodes...

I could make the UI "suggest" the IP by default, but, allow the user to change it if they want.  This way the server "admin" can decide to change nodes at will.  They just need to override the network numbers 172.31.x.x on the new server node. 

No client changes would be required with this approach.

D.

Hi,

I am trying to change the LAN IP adresse and subnet from 10.x.y.z to another range on a linksys router.

I have modified all the files containing this address without success. I am assuming this address is computed on the flight by the router.

What do I need to modify to change it?

73 Remi F6CNB or W5/F6CNB

Again, won't tell you what to go with as the following statements are equally true for version 1.0.0 as they are for 3.0.0b02  so it it wouldn't matter what version you chose.

I can say as the guy doing most the coding a this time, the Linksys isn't the stable code base... its got issues in it, and unlike the Ubiquiti base there is zero chance for them to be fixed by BBHN in some cases (Flaws inside the onboard switch module for one, and flaws in the WIFI driver which is closed source for another as example)

As noted, the issues your seeing in 1.0.0-1.1.2 are around 60% Linksys only issues (never affected Ubiquiti) and 40% affect both equally (making it 80% Linksys unstable, 20% Ubiquiti)  -- Doesn't really go well for calling "Linksys" stable and the Ubiquit code "unstable" when you look at it from a known flaws standpoint.

Again, choose the version your area is most comfortable with. In the end its each area that has to deploy the devices so they need to be happy with what they are running  and I do not intend to force my view on that into whats a local decision.

Ah ok, that makes a bit more sense now.

Only downside I see is that if you change the central node you have to reconfigure all the clients.

We have a potential IP conflict issue but that is overall going to be very minor I think in this case. and should work.

I wonder If we want to consider the following:

1) Switch from TUN to TAP interfaces (its no longer a PtP its a Broadcastable link which means we don't need to put a 'broadcast' address in olsrd config, only the interface name

--- This does have a downside of a bit more traffic may be generated over the link, but should be minimal.

2) Run a DHCP server on the server node, and use a DHCP Client on the client node to obtain ip address -- This lets us get around IP address changes when the main node gets replaced.

I've done this once in the past to make client side easier, than all they would need to know is the user/password combo.  it adds a fair bit more complexity however to the server side. 

Its a judgment call, is the extra use of resources worth the ease of configuration for users. I welcome input on that subject. I'm not pushing one way or the other, now that I understand the IP is based off server side it makes more sense to me what you are suggesting and it is certainly viable.

As for IP addresses:  OLSRD advertises any link it runs over in its packets, so the whole mesh knows about the PtP link IP address and puts it in its routing tables. If two nodes share the same IP in a mesh the program will think that  they are the same node and you can end up with a split brain routing problem if I recall correctly.

Jim: May be time to pull this under Developers forum as its really evolved into a development discussion.

This is just my opinion, but frankly none of the BBHN code is production code or even release candidate level.  That doesn't mean it won't be someday, but it's not today.  Having a major change in the development team and consecutive releases of fairly buggy code does not instill user confidence in new releases.  You may say those days are behind and even if true, it's still not field ready today.

I'm not trying to be a snot, I'm just offering why I'm not anxious to jump on 3.x.x.  Mesh is not my passion, so I have no interest in beta testing or playing musical software versions every few weeks.  My perspective is specifically as an end user.  As such I won't sit on the forum and throw rocks either.  I'll just wait and see what comes along and when I see something that looks promising, I'll jump in.  For today, 1.0.0 works perfectly for what myself and others in my area are doing with it.  As far as advocacy, it's a tough sell to describe how a beta version should work someday in front of a group of prospective users.  You cannot show something they can't reproduce with success themselves. In terms of deployment, it's unrealistic to expect users to "upgrade" field units in established networks every few weeks, reconfigure, and rediscover what works and what doesn't.  Having disparate hardware platforms and incompatible software versions is only serving to delay reaching the critical mass of nodes required for mesh to see any useful level of adoption.  1.0.0 was polished enough to attract my attention but the follow through hasn't happened yet.  

I understand, and agree that Ubiquiti is a better radio and hardware platform.  But because the Ubiquiti code is not solid yet, I see little value to spend money, time and effort to replace a working solution with an unknown one.  BBHN is just a little too "green" for me to make a sizeable hardware investment in right now.  For all I know, the the current line of Ubiquiti models that run BBHN today may not be the same models or even the same brand BBHN supports a year from now.  

I see a day when the Linksys platform will not be developed further.  I lament losing the low cost and ease of deployment they offer.  Conversely, should the Ubiquiti (or another) platform succeed, then it's not much of a loss to repurpose the Linksys boxes with OpenWRT (or other) and move ahead.  But, as a user, not until I see BBHN become stable.  To me, that's a shift from revisions for just getting it to run to revisions that offer improvements and optimization.


Mark K5LXP
Albuquerque, NM

and wow.  looks like I may need to start a new thread for the Virtual Tunnel UI work...  this one is getting long!

yes.  Octet 5 and 6 are what I intended.

I'm totally open to discussion on how best implement this...

Also, the vtun server is where the network assignment calculations are done.  The client will simply enter their assigned number on their end.  The network numbers would always be based on the serving node's MAC address and order of entry of how many clients are defined to connect.

on the client, we can calculate the required addresses based on the "network number" assigned by the server.  (server ip, client ip, broadcast address, and network numbers).

I'm envisioning the interaction would flow as follows:

client12 asks to connect to server53

server53 creates a "client" entry for client12, assigns a pwd, and gets a "generated" network number based on server53's mac and how many clients he has already defined. (MAC + every 4)

server53 then sends client12 that information via email, phone, CW, winlink, packet, Dstar slow-data, etc... ;-)

client12 creates a "server" entry on his node and specifies the host, port, pwd, and network number.

Another question regarding OLSRD and routing... aren't the vtun addresses "172.31.x.x" simply point to point?  Ie. they shouldn't be visible from other nodes on the mesh, right?

D.

MAC: 11:22:33:44:55:66

Octet 3 would only change when vendors change (100% of Ubiquiti share the octet already) would think you would want to use octet 6 for ip octet 3 and octet 5 (rotated and flipped) for ip octet 4 base.

Another problem: how do you intend to get the CLIENT mac address to the server for setting up easily (would need to use client side as server side will be less unique as it will host several tunnels) ? Post it on the UI and tell the user to give this to the other end? Would this be considered burdensome by users to do? Is it less burdensome than the alternatives ? 

This methoud would mean a client could only connect to one tunnel master (no redundancy in tunnels) because the client IP needs to be UNIQUE across the mesh.

While I like the idea of making things easier, and I like the thought of reusing what we already doing, I wonder if tunnels (something that is suppose to have user interaction to setup as apposed to dtdlink which is suppose to work out of the box) is the right place to automate or if we should leave IP assignment to the tunnel master admin.... Though that brings it's own issues. 

I don't think I can give a flat out answer on it at this moment as to what I would suggest without the deeper thought to the rest of the setup. The method prescribed is not without potential just needs some gaps filled in to better understand I think. 

So, In order to make this simple for the user...

I propose the following algorithm to determine the network number...

first octet is always 172
second octet is always 31

third and fourth octets are derived:

Take the MAC address 3rd octet and rotate right 2 times,
then flip the bit order (ie. 00000001 becomes 10000000)

Then take the MAC address 4th octet (which is "most unique")

third octet of the vtun becomes MAC 4th octet
forth octet of the vtun becomes the MAC (rotated and flipped) 3rd octet.

This should mean that we always have the last two bits cleared due to the rotate right x2 and to be used for the 2 host entries plus broadcast address.
Then, each vtun client entry, gets the "next 4" group of addresses.

Make sense?

zip text file attached

Attachments
 nanostationm5unsupported.zip [0 KB] ::

Many versions of the hardware exist, you may have a revision that is not yet had a board.info file provided.

If you can provide a board.info file we can work on moving your version into the list.

http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-37-ubnt-firmware/topic-759-help-us-gather-info-on-ubnt-devices.html

This is known and at the moment isn't high on the list to be enabled due to lack of good limits notice and a previous issue in 2011 where we know some hardware out there and avaliable may have flaws untill we learn for sure these are not current issues

https://forum.openwrt.org/viewtopic.php?id=23442

You can try the procedure here AT YOUR OWN RISK

http://wiki.openwrt.org/toh/ubiquiti/nanostationm5#poe.passtrough

Ubiquiti gives very little info about this port, from what they do give it's meant to run a CAMERA not a full 2nd node so keep that in mind.  I've read posts of these ports being fried by users in the field.  Make sure if you do use it your using 24v 1amp supply to be sure current through the port is at a minimal and reduce risk of frying the port.