You are here

New node tunnel issue

13 posts / 0 new
Last post
KF6NMZ
New node tunnel issue

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)                           = ?



 

KG6JEI
Sounds like something doesn't

Sounds like something doesn't match between the two sides, either the server node doesn't have your nodename correct, or when they passed you the details to enter on the client screen those were passed over incorrectly.

"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.

KF6NMZ
Yeah, it seems like that

Yeah, it seems like that would be the issue. I figured it would be my side since Don has setup tunnels for other people. I'll have him send a screenshot from his side, maybe another set of eyes on the setup screen will resolve things. 

K5DLQ
K5DLQ's picture
one thing to try is shorten

one thing to try is shorten your node name (on the Basic setup page).  There is a limit on the number of characters for the "tunnel name", but, I don't recall the exact number at the moment.
 

KF6NMZ
Seems plausible. I've renamed

Seems plausible. I've renamed the node to be "KF6NMZ-1". Once Don changes his side I'll post an update. 

I'll also try to see if I can figure out the exact size limit. It would be good to have it documented.

k1ky
k1ky's picture
Tunnel Node Name size limit

I believe I have had success with up to 25 characters., 30 max. A good rule of thumb is usually "If it fits in the display window" it's usually good to go - but I have found that the shorter the name the better. I believe the display window has been expanded with the latest upgrades, Anything longer than 28 or 30 seems to cause problems - or at least they used to. I've also experienced problems with rapidly changing the name and expecting it to connect.  Moving to another tunnel server node or position in the list (new server ad-hoc network addy)  usually fixes it.  I have submitted a request for this limit to be determined and documented as well. 

KG6JEI
If this is indeed an issue we

If this is indeed an issue we need to tag that as a bug in itself.

The system should handle these limits, requiring a user to change a node name for tunnels to work would be a flaw.

k1ky
k1ky's picture
Agreed

Absolutely - this has been a known issue and has been identified and reported.  I don't know if there is a specific ticket other than the one(s) where I have outlined the "Display length" issues, some of which I believe have been improved in 3.17.  Darryl can probably shed more light on this.

KG6JEI
I don't run tunnels so I can

I don't run tunnels so I can't check on it.

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) 

KF6NMZ
Hi all!

Hi all!
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.

N4RT
N4RT's picture
Tunnel Name Limit

This "bug" is, indeed, real as we ran into it today and spent many hours trying to figure out why one tunnel node on our mesh would not connect!

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
 

K5DLQ
K5DLQ's picture
You can open a ticket in the

You can open a ticket in the Issue Tracker to request this enhancement/bugfix.
http://bloodhound.aredn.org/products/AREDN/dashboard

 

K6CCC
K6CCC's picture
I know this is a two year old

I know this is a two year old thread, but I ran into this problem today.  Tried to set up a tunnel from a connected radio at work (client) with a really long name to home (server).  Everything looked great as far as packets flowing at both ends, but could not connect.  While searching around the forum for a solution, came across this thread.  Shortened the name of the node at work and almost immediately the tunnel established.  This is using a Rocket M5 with 3.19.3.0 on both ends.

Thanks
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer