Hi all,
I just setup a new mesh node (see: http://www.aredn.org/content/and-running-san-fernando-valley ).
I'm having trouble establishing a tunnel connection with Don Hill. I think the issue might be the same as this post: http://www.aredn.org/content/client-cant-connect-established-servers
I can see traffic going between my node and Don's node, but his side just returns an "ERR" after my side sends the 'CHAL'.
# vtund -n -f ./vtund.conf KF6NMZ-106-93-246-172-31-148-48 68.5.89.32 vtund[1921]: VTun client ver 3.X 02/26/2017 started vtund[1921]: Connecting to 68.5.89.32 vtund[1921]: Connection denied by 68.5.89.32 vtund[1921]: Exit # telnet 68.5.89.32 5525 VTUN server ver 3.X 05/11/2016
My node has a public address, the only firewall is the one running on the mesh node itself.
Something is up with the authentication. Is the "session string" part of the authentication? One of the examples I've seen online has the client named, in my example, "KF6NMZ-106-93-246". This is the string that appears on the 'node status' page. But when I setup vtun, it creates the client strings as "KF6NMZ-106-93-246-172-31-148-48". It appends the subnet to the node name. Is that correct? I manually changed the string to see if it mattered, but it still didn't work.
I copied the vtun config over to another host and ran it with a strace. Here is the output (I changed the CHAL strings):
socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getpid() = 21551 writev(2, [{iov_base="KF6NMZ-106-93-246-172-31-148-48 connecting to 68.5.89.32[21551]: Connecting to 68.5.89.32", iov_len=89}, {iov_base="\n", iov_len=1}], 2) = 90 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4 connect(4, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = 0 sendto(4, "<30>May 2 10:07:07 KF6NMZ-106-93-246-172-31-148-48 connecting to 68.5.89.32[21551]: Connecting to 68.5.89.32", 109, MSG_NOSIGNAL, NULL, 0) = 109 close(4) = 0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) fcntl(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(5525), sin_addr=inet_addr("68.5.89.32")}, 16) = -1 EINPROGRESS (Operation now in progress) select(4, NULL, [3], NULL, {tv_sec=30, tv_usec=0}) = 1 (out [3], left {tv_sec=29, tv_usec=926649}) getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 fcntl(3, F_SETFL, O_RDWR) = 0 select(4, [3], NULL, NULL, {tv_sec=60, tv_usec=0}) = 1 (in [3], left {tv_sec=59, tv_usec=923933}) read(3, "VTUN server ver 3.X 05/11/2016\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 50) = 50 write(3, "HOST: KF6NMZ-106-93-246-172-31-148-48\n\0\0\0\0\0\0\0\0\0\0\0\0", 50) = 50 select(4, [3], NULL, NULL, {tv_sec=60, tv_usec=0}) = 1 (in [3], left {tv_sec=59, tv_usec=918059}) read(3, "OK CHAL: <xxxxxxxxxxxxxx>\n\0\0\0\0\0\0", 50) = 50 write(3, "CHAL: <xxxxxxxxxxxxxxxxxx>\n\0\0\0\0\0\0\0\0\0", 50) = 50 select(4, [3], NULL, NULL, {tv_sec=60, tv_usec=0}) = 1 (in [3], left {tv_sec=59, tv_usec=922561}) read(3, "ERR\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 50) = 50 getpid() = 21551 writev(2, [{iov_base="KF6NMZ-106-93-246-172-31-148-48 connecting to 68.5.89.32[21551]: Connection denied by 68.5.89.32", iov_len=96}, {iov_base="\n", iov_len=1}], 2) = 97 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4 connect(4, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = 0 sendto(4, "<30>May 2 10:07:08 KF6NMZ-106-93-246-172-31-148-48 connecting to 68.5.89.32[21551]: Connection denied by 68.5.89.32", 116, MSG_NOSIGNAL, NULL, 0) = 116 close(4) = 0 close(3) = 0 getpid() = 21551 writev(2, [{iov_base="KF6NMZ-106-93-246-172-31-148-48 connecting to 68.5.89.32[21551]: Exit", iov_len=69}, {iov_base="\n", iov_len=1}], 2) = 70 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3 connect(3, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = 0 sendto(3, "<30>May 2 10:07:08 KF6NMZ-106-93-246-172-31-148-48 connecting to 68.5.89.32[21551]: Exit", 89, MSG_NOSIGNAL, NULL, 0) = 89 close(3) = 0 exit_group(0) = ?
"it creates the client strings as "KF6NMZ-106-93-246-172-31-148-48". It appends the subnet to the node name. Is that correct? "
As I recall yes that is intended. and by design.
I'll also try to see if I can figure out the exact size limit. It would be good to have it documented.
The system should handle these limits, requiring a user to change a node name for tunnels to work would be a flaw.
I'm not aware of any ticket addressing that single issue so if you have a confirmed test case I would suggest filing it as it's own bug (don't try and mix it in with an enhancement request or display changes)
Something along the lines of "Tunnels fail to connect when node name is greater than NN characters" (replace NN with what that count might be)
I'm up and running now. Don decided to move the tunnel endpoint to a different location/device. Once he did that, things started working.
Now on to the real work.... getting more RF nodes in the Valley so I don't need a tunnel.
It seems that the maximum number of characters allowed for a tunnel node with the current firmware is 42 (we're running 3.17.1.0RC1). However, the tunnel client software appends the tunnel client IP address to the node name using dashes which can take up to 16 of those allowed characters. So, the "safe" limit on a tunnel node name is only 26 characters... far from the 63 characters allowed for a node name as described in the AREDN HELP FILE 3.16.1.0 fournd here:
http://www.aredn.org/content/aredn-help-file-31610
This naming convention obviously does not apply to tunnel nodes and I haven't found this documented any where else on the AREDN website except for this post.
I think this limitation should be at least documented in the Help Files or How To files for those who wish to create tunnels on their networks. Ideally, the software should be updated so a tunnel node is not an "exception" and can also have 63 characters in the node name.
73,
Ron N4RT
Bromley, AL
You can open a ticket in the Issue Tracker to request this enhancement/bugfix.
[edit Apr 2, 2020 update link to current]
http://github.com/aredn/aredn_ar71xx/issues
Thanks
https://www.arednmesh.org/content/long-node-names-tunnel-clients-and-ser...
See also:
https://sites.google.com/site/orangecountymeshorganization/internet-tunn...
and
https://sites.google.com/site/orangecountymeshorganization/internet-tunn...