Some have sentence-long node names, DHCP reservation names, and Service names. It makes for a wide mesh status screen, resulting in horizontal scrolling on some small displays.
Would it be possible to truncate those, with column width adjustable in Advanced Settings... perhaps with a default of 25 characters or so?
Something like:
Node Name:
XXXXX-NanoStation-M2-off N-Fairfield-Rd-in-Beavercreek-Ohio.local.mesh
XXXXX-NanoStation-M2-off N-Fairfield-Rd...
Service Name:
Join our weekly MeshChat conference every Wednesday at 800 PM
Join our weekly MeshChat conference ever...
You are here
Maximum Column Widths
Thu, 01/03/2019 - 10:18
#1
Maximum Column Widths
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
In the interest of addressing duplicates (across the mesh) in DHCP Address Reservations, how about adding a single text line above "DHCP Address Reservations" in the /cgi-bin/ports page which might read something like this: " * Note: should be unique name within mesh". That would get a bit more info in front of those making the choice of (new/updated) DHCP names.
Just a thought, Thanks,
- Don - AA7AU
Guess I need to do more research before posting suggestions here. Turns out duplicate DHCP hostnames have already been addressed in the nightly builds:
https://github.com/aredn/aredn_ar71xx/issues/216
- Don - AA7AU
It makes no sense (and it's annoying sometimes) to see hostnames like: pbx.local.mesh, mail.local.mesh ... I can understand that it could be a general host name generated by a pre-built Pi image ... but if two people on the network do the same, it's a mess.
If the software can force appending "AL0Y-" to the beginning of the hostname and convert it to al0y-pbx.local.mesh for example, it will be great and will solve a lot of problems.
I understand the frustration with the lack of discipline and/or consideration for others that evidences itself in these types of non-unique service names across whatever mesh one might be connected to (another one of the reasons on my Idhao Mesh Island we won't use tunnels to other meshes). However I fear that the approach to solving it with heavy-handed firmware "legislation" may very will end up with lots of unintended consequences. I hope this gets thought out *completely* before rushing to try to "solve stupid".
As far as my little Mesh Island up in Idaho, a mandated renaming (or extnded naming) of mesh services would really screw up some stuff already in place. We don't worry about bozos advertising pbx.local.mesh because the users themselves are already disciplined and self-policing. I would likely hold back and not implement whatever firmware release it is that attempts to enforce this, at least until I had the time and energy to thoroughly go thru all the other stuff which tries to use these mesh services. I really hope there is a better solution found, or a way to control those outliers. Maybe a dup-check before DNS accepts the offered service ... or whatever. We're Hams, we're not Part 15 operators, we shouldn't have these problems.
Personally, I would love to see s "whitelist"/ "blacklist" ability to control which nodes/IP#s connect to my node but that is likely a major task.
Good luck with this hot potato,
- Don - AA7AU
Don, giving those of us with small mobile and portable screens relief from wide pages is NOT "heavy-handed firmware "legislation." If the column width is adjustable, those in your Idaho island can set them as wide as you like.
Sorry, I guess I mis-communicated. I was NOT referring to column width issues whatsoever.
I am all for light-weight manageable/usable output and would love to eventually see some sort of custom CSS type approach being available for the various mesh screens to give even finer control to the end user.
I was (speaking for myself and not for all of Idaho) referring to the possible suggestion to mandate longer compound service names, implemented in the firmware, to include callsigns or whatever on all advertised services. Due to service naming "abuse" (which is caused by ignorance and/or lack of consideration) this topic quickly becomes a contentious issue. I would advocate for education over the other approach.
Sorry for the confusion,
- Don - AA7AU (an island dweller)
To the extent that using "bad" service names reflects lack of understanding of the issues involved, perhaps a "How to best setup services" write-up here someplace on this site might help (I have looked and not found anything like that). One could even send a link to URL for such a write-up to folks who are using less-than-optimumly named services as a useable "hint".
I have wondered why there is apparently no Wiki type of setup for AREDN as having one place to find the latest/most-current info by topic/device/usage would be far better than trying to drag thru all the several years of posts here in the forums.
Just a thought - definitely NOT a complaint - thanks for all that the team does,
- Don - AA7AU
https://arednmesh.readthedocs.io/en/latest/
https://github.com/aredn/documentation/issues
Darryl/Joe: thanks for the quick follow-up to my post. This is *terrific*. No, I had not noticed it before. Well done and nicely packaged, in a form that would seem to be easy to keep current. I feel sorta bad for not noticing it.
What a treat to start the new year going forward for 2019! I haven't looked for a section on naming services yet, but now I know where to direct my feedback.
Thank you so much for all that you do,
- Don - AA7AU
edited 7-Jan to add: Thank you, Steve Lewis, KC0EUW - well done!
Thank Steve Lewis, KC0EUW. This is largely started and produced by him. He's made a fantastic contribution to AREDN.