I thought I read somewhere that part of the reason for including the call sign as part of the node name was to meet FCC station identification requirements. If that is the case, then I would assume you would need to use the recriprical call as you would on any other band/transmission.
This idea relates to an earlier post on saving data between firmware upgrades. We are using a modified version of the WiFi scan that implements ae6xe's mod to display mesh member nodes individually, and a related mod to provide a small table of MAC Address to name/IP Address resolution for known node stations. This helps resolve the "(hidden)" stations that show up in the scan output.
So, it would be nice to have a standard location where files like our lookup table could be safely stored. Similar data might include images, sounds, etc. (Dealing with modified versions of standard release code, like the modified wscan, would be outside the scope of this request.)
A "0001" would work, the primary criteria is "uniqueness" to avoid conflict. However, it is not very descriptive.
One identifier, that would be better to use flows from the default hostname in the initial setup "nocall-111-222-252". The numbers are derived from the MAC address and used to create unique IP addresses for the device. This is a decent randon # to avoid IP conflicts and thus reasonalbe method to also derive names. Maybe truncate in some cases. Examples:
AE6XE-NSM2-135 <- AE6XE's node, it is a NanoStation 2.4Ghz M2. 135 is unique (to distinguish my multiple NSM2s and for us network types is part of it's IP address to help identify)
KE6BXT-W6HRO-M2B-OMNI-164-228-117 <- bear with me here, KE6BXT has donated a node on top of W6HRO store, it is a Bullet M2 2.4Ghz using an Omni antenna, and the IP address is 10.164.228.117. (Don needs a way to remember where and what his inventory is across the county :) ).
Q. Does AREDEN restrict itself to a B network in the 10 range, or are the node IP spread out over the entire 10 range?
Q. Is if possible for the end user to move to network 44 to avoid conflicts?
Background: The N2MO local network is on 10.x.x.x, and is being linked via fiber to our academic partner who are currently using a wide swath of 10.x.x.x.
Yes. on inspection of any node, here is an example:
MAC wifi interface: DC:9F:DB:54:26:A4
Wifi IP address: 10.84.38.164
A4 (hex) = 164 (decimal)
26 (hex) = 38 (decimal)
54 (hex) = 84 (decimal)
The dtdlink interface (eth0.2 - vlan 2) IP address increments the 84 + 1 = 85 (10.85.38.164)
The assignments are somewhere in the perl code under /www. There will be a section of code to change this assignment algorythm, and validation code, if any. This is the same code in all images from beginning of hsmm, patched from release to release to keep working (trying to keep up with the expanding needs). Others will have more in depth knowledge of this code than I. We have a lot of work to do to move this from a 'protype' implmentation to 'production'--it's a re-write.
You might also edit the config files in /etc/config (/etc/config.mesh) with these addresses hardcoded, but would likely need to test how much of the setup UI functionality can work before clobbering the hand edits or crash.
Note, the Mesh route tables with OLSRD is done on an IP by IP address basis and very small 10.x.x.x LAN subnets (13 or less addresses in this "HNA" subnets). You might go ahead and just connect the networks--the default route will get out to the larger environment. If/when you find an IP collision, then go into setup of the node in question and change the IP address to resolve. Might be manageable unless you start getting a very large mesh network.
"The dtdlink interface (eth0.2 - vlan 2) IP address increments the 84 + 1 = 85 (10.85.38.165)"
Not strictly the case, it actually takes the MAC address of the ethernet interface and soes the same computation to it as it does to the WIFI/Mesh. For the moment all the hardware I have seen has been one up, but that may not always be the case.
Part of this comes from the basis as well that these nodes have been designed to function independently of any other network, plugging them in as part of a larger network is a minor sub feature. If absolutely having issues they could always be put behind a NAT router at a site that uses 10.x address to give it a 192.168.x.x address.
Strictly speaking (though never announced by BBHN) the 10.x and the 172.16.x private ranges (currently only the vpn tunnels publish operation in the 172.16.31.x range but nat mode also uses a range in here as well) should be considered 'reserved for mesh node usage' to avoid issues now or in the future.
As noted by joe though the default gateway on the 10.x network should still work, as the system by default checks the MESH routing table first and gives it priority for all mesh based traffic, especially when mesh GW isn't checked all mesh to mesh traffic never even sees the internet port as an option.
Using the 44.x AmperNet subnet range for default IP's on AREDN really does not fit well with the design of AREDN.
It is intended to be an easy to configure, requiring minimal knowledge, and immediate setup.
Since 44.x addresses are assigned by local authorities this negates the ability for all 3 of the above goals as every time a user would want a new node they have to obtain a new IP address and work from there.
In addition I strongly advise against using directly publicly reachable IP space. It is not very hard for an attacker (some one you angered over the years, etc) to create a packet that is compliant with all part 15 laws, that gets repeated by a node that has a direct IP address that gets repeated across the mesh causing the users of those internet reachable mesh nodes to have to answer for part 15 (or local jurisdiction) license violations.
The 44.x net was a great idea when the internet was clean, no one ever heard of the idea of spam, but today with regular attacks...not so much.
Our local network is already using 10.x.x.x. There are currently 42 hosts in the class C we are using. We interface with a school district with several thousand hosts scattered through 10.x.x.x.
The original plan was to simply route the IP interface on the M5 to an external interface on the firewall, and into the network.
Obviously we are going to end up with IP conflicts if the AREDN hosts are scattered all over the place in 10.x.x.x. NAT might work, if you knew what was already in use on the outside.
I'm the first to admit I might be missing something here....
Brain storming here... You may be able to go to the IT folks and obtain allocation of some 10.x.x.x address space from the school district. Then whenever a node is setup-initialized, manually type in the IP address this node should use in the allocated address space--in existing setup. I suspect, and Conrad can confirm, but there is still an issue with dtdlink/lan interface IP addresses which may still be derived and fall out of bounds. This might be 3 address spaces of allocations (should be small in the big picture) for your use in the school district if we game the current setup logic in the node of any derived addresses.
(The school district is going to enable you to connect this foreign network to theirs? )
Perhaps we should jump this out of the Standards thread and move into another discussion for a while.
I think we need to take a step back discuss what you want to do and evaluate from there as to how best accomplish it and what concerns may exist with each method and see what is the best solution.
Take your pick, new thread in General should work probably as it seems to have a bit of mixing and matching to it, or Deployment thread could work as well.
Just its own thread, and if you could start the description of the deployment (how its thought to implement, what the nodes need to provide, or why they need access. etc) so we have an idea to work against.
Just a note this should not be confused with protocol standards which are discussed under
Forum - Development - Protocol Specification
Always prefix your reserved names with your callsign and a hyphen.
You may not have the only host named raspbx, or asterisk, but, I would have the only K5DLQ-raspbx.
K5DLQ - Darryl
What about reciprocal callsign?
I use W5-F6CNB-xxxxxxxxx> Is it the recommended one ?
73
W5/F6CNB Remi Frelsburg, Tx, USA
or
F6CNB Remi Bures-sur-Yvette, France
I thought I read somewhere that part of the reason for including the call sign as part of the node name was to meet FCC station identification requirements. If that is the case, then I would assume you would need to use the recriprical call as you would on any other band/transmission.
I think that makes sense. As long as the prefix identifies you, and the suffix identifies your resource.
If you can answer this question with NO, you're good:
Would anyone else in the world also name THEIR resource with this name?
My $0.02 worth
K5DLQ - Darryl
This idea relates to an earlier post on saving data between firmware upgrades. We are using a modified version of the WiFi scan that implements ae6xe's mod to display mesh member nodes individually, and a related mod to provide a small table of MAC Address to name/IP Address resolution for known node stations. This helps resolve the "(hidden)" stations that show up in the scan output.
So, it would be nice to have a standard location where files like our lookup table could be safely stored. Similar data might include images, sounds, etc. (Dealing with modified versions of standard release code, like the modified wscan, would be outside the scope of this request.)
Top
So where does an Institutional or Club Call running multiple nodes fit into the naming convention? would W1AW-0001 meet the intent?
A "0001" would work, the primary criteria is "uniqueness" to avoid conflict. However, it is not very descriptive.
One identifier, that would be better to use flows from the default hostname in the initial setup "nocall-111-222-252". The numbers are derived from the MAC address and used to create unique IP addresses for the device. This is a decent randon # to avoid IP conflicts and thus reasonalbe method to also derive names. Maybe truncate in some cases. Examples:
AE6XE-NSM2-135 <- AE6XE's node, it is a NanoStation 2.4Ghz M2. 135 is unique (to distinguish my multiple NSM2s and for us network types is part of it's IP address to help identify)
KE6BXT-W6HRO-M2B-OMNI-164-228-117 <- bear with me here, KE6BXT has donated a node on top of W6HRO store, it is a Bullet M2 2.4Ghz using an Omni antenna, and the IP address is 10.164.228.117. (Don needs a way to remember where and what his inventory is across the county :) ).
Joe AE6XE
Joe,
Appreciate the help so far. I understand that the node name determines the IP. Unique is good, a text string for humans is preferred
Next question: Is is safe to assume that the software generates addresses only in network 10?
Martin W2RWJ
absolutely, yes. All node address in mesh mode are in the 10.x.x.x network. (tunnel addresses are in the 172.31.x.x network)
Q. Does AREDEN restrict itself to a B network in the 10 range, or are the node IP spread out over the entire 10 range?
Q. Is if possible for the end user to move to network 44 to avoid conflicts?
Background: The N2MO local network is on 10.x.x.x, and is being linked via fiber to our academic partner who are currently using a wide swath of 10.x.x.x.
Martin
W2RWJ
AREDN uses the entire class-A block in the 10 address space.
Can you give some background on what are you trying to do?
Yes. on inspection of any node, here is an example:
MAC wifi interface: DC:9F:DB:54:26:A4
Wifi IP address: 10.84.38.164
A4 (hex) = 164 (decimal)
26 (hex) = 38 (decimal)
54 (hex) = 84 (decimal)
The dtdlink interface (eth0.2 - vlan 2) IP address increments the 84 + 1 = 85 (10.85.38.164)
The assignments are somewhere in the perl code under /www. There will be a section of code to change this assignment algorythm, and validation code, if any. This is the same code in all images from beginning of hsmm, patched from release to release to keep working (trying to keep up with the expanding needs). Others will have more in depth knowledge of this code than I. We have a lot of work to do to move this from a 'protype' implmentation to 'production'--it's a re-write.
You might also edit the config files in /etc/config (/etc/config.mesh) with these addresses hardcoded, but would likely need to test how much of the setup UI functionality can work before clobbering the hand edits or crash.
Note, the Mesh route tables with OLSRD is done on an IP by IP address basis and very small 10.x.x.x LAN subnets (13 or less addresses in this "HNA" subnets). You might go ahead and just connect the networks--the default route will get out to the larger environment. If/when you find an IP collision, then go into setup of the node in question and change the IP address to resolve. Might be manageable unless you start getting a very large mesh network.
Joe AE6XE
"The dtdlink interface (eth0.2 - vlan 2) IP address increments the 84 + 1 = 85 (10.85.38.165)"
Not strictly the case, it actually takes the MAC address of the ethernet interface and soes the same computation to it as it does to the WIFI/Mesh. For the moment all the hardware I have seen has been one up, but that may not always be the case.
Part of this comes from the basis as well that these nodes have been designed to function independently of any other network, plugging them in as part of a larger network is a minor sub feature. If absolutely having issues they could always be put behind a NAT router at a site that uses 10.x address to give it a 192.168.x.x address.
Strictly speaking (though never announced by BBHN) the 10.x and the 172.16.x private ranges (currently only the vpn tunnels publish operation in the 172.16.31.x range but nat mode also uses a range in here as well) should be considered 'reserved for mesh node usage' to avoid issues now or in the future.
As noted by joe though the default gateway on the 10.x network should still work, as the system by default checks the MESH routing table first and gives it priority for all mesh based traffic, especially when mesh GW isn't checked all mesh to mesh traffic never even sees the internet port as an option.
So I dug in the code and here are the specifics (literally the math) for those interested in how IP addresses are determined in the Perl UI Setup:
http://bloodhound.aredn.org/products/AREDN/wiki/TechRef/GUI/admin/PerlUI...
Using the 44.x AmperNet subnet range for default IP's on AREDN really does not fit well with the design of AREDN.
It is intended to be an easy to configure, requiring minimal knowledge, and immediate setup.
Since 44.x addresses are assigned by local authorities this negates the ability for all 3 of the above goals as every time a user would want a new node they have to obtain a new IP address and work from there.
In addition I strongly advise against using directly publicly reachable IP space. It is not very hard for an attacker (some one you angered over the years, etc) to create a packet that is compliant with all part 15 laws, that gets repeated by a node that has a direct IP address that gets repeated across the mesh causing the users of those internet reachable mesh nodes to have to answer for part 15 (or local jurisdiction) license violations.
The 44.x net was a great idea when the internet was clean, no one ever heard of the idea of spam, but today with regular attacks...not so much.
Our local network is already using 10.x.x.x. There are currently 42 hosts in the class C we are using. We interface with a school district with several thousand hosts scattered through 10.x.x.x.
The original plan was to simply route the IP interface on the M5 to an external interface on the firewall, and into the network.
Obviously we are going to end up with IP conflicts if the AREDN hosts are scattered all over the place in 10.x.x.x. NAT might work, if you knew what was already in use on the outside.
I'm the first to admit I might be missing something here....
Martin W2RWJ
Martin,
Brain storming here... You may be able to go to the IT folks and obtain allocation of some 10.x.x.x address space from the school district. Then whenever a node is setup-initialized, manually type in the IP address this node should use in the allocated address space--in existing setup. I suspect, and Conrad can confirm, but there is still an issue with dtdlink/lan interface IP addresses which may still be derived and fall out of bounds. This might be 3 address spaces of allocations (should be small in the big picture) for your use in the school district if we game the current setup logic in the node of any derived addresses.
(The school district is going to enable you to connect this foreign network to theirs? )
Joe AE6XE
Perhaps we should jump this out of the Standards thread and move into another discussion for a while.
I think we need to take a step back discuss what you want to do and evaluate from there as to how best accomplish it and what concerns may exist with each method and see what is the best solution.
Will do - let me know where
Take your pick, new thread in General should work probably as it seems to have a bit of mixing and matching to it, or Deployment thread could work as well.
Just its own thread, and if you could start the description of the deployment (how its thought to implement, what the nodes need to provide, or why they need access. etc) so we have an idea to work against.
Typo alert: M3 should read M5
you should be able to edit your own posts. If not let us know. (I went ahead and changed it on your behalf for now). ;-)
73, K5DLQ - Darryl