faq

sock protocol ,it is useful!

@(#)$Id: FAQ,v 1.24 2000/01/05 11:08:29 michaels Exp $

Submit your question with an answer to [e-mail].

1. Reporting bugs in Dante
1.1. Why was I told to read this in response to my outstanding bug report?
1.2. Why is "it does not work" not a good bug report?
1.3. How can I provide you with the information you need?

2. Technical Problems
2.1. Why doesn't the socksify program work with glibc-2?
2.2. Why doesn't the socksify program work with cvs?

1. Reporting bugs in Dante
1.1. Why was I told to read this in response to my superb bug report?
Because you were unable to provide a usable bug report.  Since
there are so many of you, we prefer to refer you to this FAQ rather
than repeating ourselves over and over.

1.2. Why is "it does not work" not a good bug report?
It's a common misconception among users who have never done any
programming that by stating something along the lines of "it does
not work", or "I get a segmentation fault" (these are real examples,
believe it or not), the programmers at Inferno Nettverk will without
a shred of doubt be able to pin-point that one line, that one line
among the thousands of other lines, responsible for it "not working"
or "segmentation faulting".

The fact is, any one of the tens of thousands of lines could be
the "bad" line, we don't have time to re-read them all each time
we get a "it does not work" message.

1.3. How can I provide you with the information you need?
First of all, look in the config file you are using.
If you are using the Dante client, it's /etc/socks.conf.
If you are using the Dante server, it's /etc/sockd.conf.
Both files contain by default the lines "logoutput:".  Set "logoutput:"
to some file that Dante can log output to.

If the problem is with the client, also uncomment the line containing
"debug".
If the problem is with the server, also add "-dl" to whatever
arguments you usually start the server with.

Repeat whatever you did to produce the error and look at the
log messages.  Do they provide any hints?  Could this be
a user error on your part rather than a bug?  (of course not.)

If it looks like a user error, you configured something wrong, etc.
you can try sending a mail to [e-mail], a public mailing
list where someone might be kind enough to help you if you formulate
your question in a understandable way.
And remember, unless you are a customer of Inferno Nettverk, no one
owes you any support or help, you are the one asking someone to
spend their time to help you, not the other way around.

If it looks like a bug, first perform the following step:
 a) Make sure that you are using the latest
    version of Dante, even if the latest version is a "prerelease"
    and you are using official release.  Always check
    ftp.inet.no:/pub/socks/ to see if there's a later version before
    sending a bugreport.

Next, depending on whether the suspected bug is in the client
or sever, do one of the following:

 If it's a bug in the client:
  1) Compile the program you are trying to socksify with the compiler
     option "-g".
  2) Compile Dante with "-g" (--enable-debugging option to configure).
  3) Set debug and logoutput as described above.
  4) cp /dev/null <logoutput file> (to make sure it's empty.)
  5) ktrace/truss/strace/<whatever> socksify <bad program>.  Save the
     output to a file.  If you have a program that can trace
     library calls too (late version of Solaris truss and redhat
     linux apparently do), please include information about that too.

  6) If a coredump was generated do 
       $ gdb <bad program> <coredump>
       (gdb) backtrace 50
     Save the output to a file.
 
 If it's a bug in the server:
  1) Compile Dante with "-g" (--enable-debugging option to configure).
  2) Set debug and logoutput as described above.
  3) cp /dev/null <logoutput file> (to make sure it's empty.)
  4) If the server crashed/exited due to the bug, a coredump should
     be generated.
     If you do not find a coredump in the directory you started
     the Dante server from you need to find out why.
     Some possible reasons are:
      a) your shell has disabled coredumps (check what ulimit(1)) says.
      b) some systems by default disable coredumps on processes that
	 are either setuid, or that are run by root.

     When you have found the coredump do 
	$ gdb <Dante server> <coredump>
        (gdb) backtrace 50
     Save the output to a file.

Then:
  b) In addition to the server/client specific files mentioned below,
    include the output from configure and the file "include/autoconf.h".

  c) Collect the output from configure and the file include/autoconf.h,
     the <logoutput file>, gdb/ktrace/truss/strace/whatever output
     in a orderly fashion so it's easy to read and understand, and
     send it to us.  Make sure you include information about what
     all the ipaddresses in the logfiles are (10.0.0.1 is "client
     using lynx", 10.0.0.2 is "remote webserver", etc.).

     The address to use for Dante bugs is [e-mail].  See
     the BUGS file coming with Dante.

  d) If you have the possibility to create a temporary account for
     one of the Dante developers in the case we are unable to
     reproduce the error on our own systems, please mention that
     in the bugreport (but don't create the account until we ask
     for it, we rarely need it).


2. Technical Problems
2.1. Why doesn't the socksify program work with glibc-2?
If glibc is not correctly installed (old header files are still
installed) socksify won't work if logging is enabled. The server will
also crash when it exits. Upgrade the header files (/usr/include) and
compile again.

2.2. Why doesn't the socksify program work with cvs?
It does work.  A problem however is that cvs usually ends up calling
a setuid program (rsh, ssh, whatever) which will ignore what
"socksify" sets up.
Solution: strip off the suid bit if possible or recompile the (rsh,
ssh, whatever) binary with explicit socks support (adding "-ldsocks"
to the linkoptions is usually enough.)