Thanks to both bishop and Michael for their comments.

By the way, I omitted mentioning this in the original post, but I'm
working with vtun 2.6-1. I doubt that submitting a patch for debugging
for 2.6 would do much good.

Shortly after I posted the message, I decided that I was too impatient
to wait, and started throwing vtun_syslog() calls into auth.c and
recompiling. I narrowed the problem down to the second phase of the
challenge - the client isn't returning the response that the server expects.

Both ends have, for the connection configuration:
tapbridge {
  passwd MyPasswordHere ;    # Password
  type  ether;          # Ethernet tunnel
  proto udp;            # UDP protocol
  compress  no;         # no compression
  encrypt  no;          # no encryption
  stat  no;             # turn off connection statistics
  keepalive yes;        # Keep connection alive
  multi yes;            # multiple connections allowed
}
I've confirmed that that portion of the config is identical at both
sides (I omitted the up{} and down{} blocks.

Unfortunately, the clients are Soekris net4501 and net4801 boxes.
They're running an image that was developed by a previous employee quite
a few years ago. The binaries on the client are statically linked, and I
have no knowledge of how they were compiled, or even whether they've
been patched from the official release.

At this point, since I've narrowed it down to the server receiving an
"incorrect" challenge, I'm going to try recompiling without SSL.

Thanks,
Jason Antman


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Vtun-Users mailing list
Vtun-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vtun-users

Reply via email to