- tor-commits - lists.torproject.org

[torsocks/osx] Update Changelog for v1.1 release
by hoganrobert＠torproject.org 24 Oct '11

24 Oct '11

commit fda06ecbfe4894a07a3d202748803b313da35d6a Author: Robert Hogan <robert(a)roberthogan.net> Date: Sat Dec 11 16:28:08 2010 +0000 Update Changelog for v1.1 release --- ChangeLog | 176 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 176 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 15d1b17..7000880 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,179 @@ +Torsocks 1.1 +2010-12-12 Robert Hogan <robert(a)roberthogan.net> + o Handle wildcard addresses in getaddrinfo calls. Reported by Mike Perry. + + o Move the address inspection to the end of sendmsg() and sendto() + so that we can exit early if the socket is not SOCK_STREAM (i.e. + tcp). + + o Exit if Tor DNS is disabled. + Exit with an error code if Tor DNS is disabled in the configuration + or if we cannot reserve the deadpool address space for .onion + addresses. + + o Always print error messages. + + o Allow error logging by default. + + o Style cleanup: + No brackets for single-statement conditionals + Whitespace fixes in tsocks.c + Remove torsocks.kdevelop + Remove non-free RFC and replace with link. + o Remove USE_TOR_DNS compile guard + This is a leftover from the tsocks days. We always want this option + enabled. + + o Only enable debug output for debug builds + Debug output was printing on release builds and getting suppressed + on debug builds - which is the wrong way round! + + o Make a global variable less generic + Exporting a global variable called 'progname' is not a good + idea if you are a library. Exporting global variables at all + is probably a bad idea. + For now, make the name less generic - it was causing crashes + when torsocks was used with dig. + Part of the fix for: + http://code.google.com/p/torsocks/issues/detail?id=15 + + o Use socket rather than address to determine connection type + In sendmsg() and sendto() we were inspecting the sock_addr_t + structure to determine if the connection was Internet or not. + Since msg->msg_name is an optional value in sendmsg() and + sendto() this could result in crashes because we weren't ensuring + it was non-null. + Since it's optional we should have been inspecting the SO_DOMAIN + of the connection's socket anyway - it will always be there. + Part of the fix for: + http://code.google.com/p/torsocks/issues/detail?id=15 + + o Major refactor of symbol hooking + Patch by alex(a)ohmantics.net + Make torsocks fully compatible with Snow Leopard OSX. + Slim down the symbol hooking code considerably. + Alex's notes: + "http://developer.apple.com/mac/library/releasenotes/Darwin/SymbolVariantsRe…. + don't have the $UNIX2003 variants. For working 10.6 support, we'll need to + conditionalize the UNIX2003 variants off when compiling for 64-bit." + + o Improve compile-time detection of the res* family of system calls + Some platforms need to explicitly include resolv.h so cater for + that. + Thanks to SwissTorExit for reporting and debugging assistance. + + o Do our best to ensure tsocks_init is called only once. + + o Build fix for BSD. + Support presence of res_query in libc rather than libresolve. + +Torsocks 1.0-epsilon +2009-11-01 Robert Hogan <robert(a)roberthogan.net> + + o Manpage syntax fixes from Patrick Matthäi <pmatthaei(a)debian.org> + + o Clarify use of the configuration file. + + Amend the default behaviour to work as summarized below and updated the + manual pages to make the default behaviour obvious to users. + + "By default, torsocks will assume that it should connect to the SOCKS proxy + running at 127.0.0.1 on port 9050. This is the default address and port for + Tor's socks server on most installations. + + In order to use a configuration file, you must set the environment variable + TORSOCKS_CONF_FILE with the location of the file. + + If TORSOCKS_CONF_FILE is not set, torsocks will attempt to read the configuration + file at @CONFDIR@/torsocks.conf. If that file cannot be read, torsocks will + use sensible defaults for most Tor installations, i.e. it will assume that + you want to use a SOCKS proxy running at 127.0.0.1 (localhost) on port 9050." + + o Fix compilation in 64-bit OSX. + + o Mac OSX compatibility in tsocks.c + Original Patch from Alex Rosenberg <alex(a)ohmantics.com> + + 1. Hook OSX-specific syscalls + ----------------------------- + Mac OXS has a number of variants of each syscall. This patch adds + hooks for the following OSX variants: + + select() : select_unix2003() + select_nocancel() + select_darwinextsn_nocancel() + select_darwinextsn() + + poll(), connect(), sendmsg(), sendto(), close(): *_unix2003(), + *_nocancel() + getpeername(): *_unix2003() + + 2. Add Hooking Macros + -------------------- + Move the symbol loading and checking out to macros of the form + [syscall]_PATCH: + + PATCH_SELECT, PATCH_CONNECT, PATCH_CLOSE, PATCH_POLL, + PATCH_GETPEERNAME, PATCH_SENDTO, PATCH_SENDMSG + + Rename the syshooks to functions of the form *_guts(). + + 3. Miscellaneous + ---------------- + Add NONSTD_SOURCE define for Mac OSX.Defining _NONSTD_SOURCE + causes library and kernel calls to behave as closely + to Mac OS X 10.3's library and kernel calls as possible. + + Use socklen_t instead of int. + + Move get_environment() and get_config() to tsocks_init(), + rather than calling adhoc in the syscalls. + + Differentiate between EISCONN and EINPROGRESS errors in + connect(). + + Original Patch from Alex Rosenberg <alex(a)ohmantics.com> + http://code.google.com/p/torsocks/issues/detail?id=2#c11 + + o Patch torsocks.in for Mac OSX + Patch from alexr(a)ohmantics.com + Mac OSX uses the DYLD_INSERT_LIBRARIES and DYLD_FORCE_FLAT_NAMESPACE + environment variables to enable/perform syscall-hooking. Also, on + Mac OSX dynamically linked libraries use the '*.dylib' extension + rather than '*.so'. Alex's patches for torsocks.in and configure.in + ensure that we use the appropriate values for Max OSX. Ideally, we + wouldn't export DYLD_FORCE_FLAT_NAMESPACE on non-Mac OSX platforms + but it is harmless to do so. We'll leave that for another day. + The patch also fixes up the sed reg-exp to interpret the 'echo + DYLD_INSERT_LIBRARIES' output as well as that from LD_PRELOAD. + + o Whitespace cleanup in parser.c + + o Add linker checks for Mac OSX. Patch from alexr(a)ohmantics.com + + o Move MAP_ANONYMOUS to common.h + + o LD_PRELOAD is ignored for binaries where setuid/gid is used. As used, + torsocks doesn't detect this, which means that it provides a false sense + of security when running these types of executables. + Added logic that detects setuid/setgid programs and fails early with an + error message. + Further reorganized the file to simplify flow and improve command line + argument handling. + Patch by Marcus Griep <marcus(a)griep.us> + + o remove aclocal.m4 + + o BSD build patch from grarpamp. See http://code.google.com/p/torsocks/issues/detail?id=4. + + o Replace TSOCKS_* environment variables with TORSOCKS_* equivalents as per man page. + + o Remove superfluous include. + + o Fix compilcation on Mac OSX. See http://code.google.com/p/torsocks/issues/detail?id=2 + + o Expand reject message for UDP and ICMP requests + Torsocks 1.0-delta 2009-02-XX Robert Hogan <robert(a)roberthogan.net> o Fix segfault when address supplied for getaddrinfo is null. Reported by Mike Perry.

1 0

[torsocks/osx] Exit if Tor DNS is disabled
by hoganrobert＠torproject.org 24 Oct '11

24 Oct '11

commit 965ae344734bd97c26d657719e72d99fc86bfa01 Author: Robert Hogan <robert(a)roberthogan.net> Date: Mon Sep 20 20:44:46 2010 +0100 Exit if Tor DNS is disabled Exit with an error code if Tor DNS is disabled in the configuration or if we cannot reserve the deadpool address space for .onion addresses. --- src/tsocks.c | 44 ++++++++++++++++++++++++++------------------ 1 files changed, 26 insertions(+), 18 deletions(-) diff --git a/src/tsocks.c b/src/tsocks.c index 80f7b9c..40b7e11 100644 --- a/src/tsocks.c +++ b/src/tsocks.c @@ -180,7 +180,6 @@ void tsocks_init(void) (error)?error:"not found"); \ dlerror(); \ } - pthread_mutex_lock(&tsocks_init_mutex); /* We only need to be called once */ @@ -245,7 +244,11 @@ void tsocks_init(void) #endif /* Unfortunately, we can't do this lazily because otherwise our mmap'd area won't be shared across fork()s. */ - deadpool_init(); + if (!deadpool_init()) { + show_msg(MSGERR, "Fatal error: exiting\n"); + exit(1); + } + tsocks_init_complete=1; pthread_mutex_unlock(&tsocks_init_mutex); @@ -1608,23 +1611,28 @@ int EXPAND_GUTS_NAME(res_send)(RES_SEND_SIGNATURE, int (*original_res_send)(RES_ static int deadpool_init(void) { - if(!pool) { - get_environment(); - get_config(); - if(config.tordns_enabled) { - pool = init_pool( - config.tordns_cache_size, - config.tordns_deadpool_range->localip, - config.tordns_deadpool_range->localnet, - config.defaultserver.address, - config.defaultserver.port - ); - if(!pool) { - show_msg(MSGERR, "failed to initialize deadpool: tordns disabled\n"); - } - } + if (pool) + return 1; + + if (!config.tordns_enabled) { + show_msg(MSGERR, "Tor DNS is disabled. Check your configuration.\n"); + return 0; + } + + get_environment(); + get_config(); + pool = init_pool(config.tordns_cache_size, + config.tordns_deadpool_range->localip, + config.tordns_deadpool_range->localnet, + config.defaultserver.address, + config.defaultserver.port); + + if (!pool) { + show_msg(MSGERR, "Could not initialize reserved addresses for " + ".onion addresses. Torsocks will not work properly.\n"); + return 0; } - return 0; + return 1; } struct hostent *tsocks_gethostbyname_guts(GETHOSTBYNAME_SIGNATURE, struct hostent *(*original_gethostbyname)(GETHOSTBYNAME_SIGNATURE))

1 0

[torsocks/osx] Partially revert commit c8c6c60b.
by hoganrobert＠torproject.org 24 Oct '11

24 Oct '11

commit 1e4e20b1bbed7d2e3b8b4d60420a746a0615f1af Author: Robert Hogan <robert(a)roberthogan.net> Date: Mon Sep 20 22:38:58 2010 +0100 Partially revert commit c8c6c60b. The SO_DOMAIN socket() option is Linux only. So revert to inspecting the sock_addr_t in sendmsg() and sendto() but ensure it is non-null before doing so. Move the address inspection to the end of sendmsg() and sendto() so that we can exit early if the socket is not SOCK_STREAM (i.e. tcp). --- src/tsocks.c | 55 +++++++++++++++++++++++-------------------------------- 1 files changed, 23 insertions(+), 32 deletions(-) diff --git a/src/tsocks.c b/src/tsocks.c index 40b7e11..02e21fc 100644 --- a/src/tsocks.c +++ b/src/tsocks.c @@ -1667,14 +1667,13 @@ ssize_t tsocks_sendto_guts(SENDTO_SIGNATURE, ssize_t (*original_sendto)(SENDTO_S { int sock_type = -1; unsigned int sock_type_len = sizeof(sock_type); - int sock_domain = -1; - unsigned int sock_domain_len = sizeof(sock_domain); + struct sockaddr_in *connaddr; /* See comment in close() */ if (!tsocks_init_complete) tsocks_init(); - /* If the real connect doesn't exist, we're stuffed */ + /* If the real sendto doesn't exist, we're stuffed */ if (original_sendto == NULL) { show_msg(MSGERR, "Unresolved symbol: sendto\n"); return(-1); @@ -1682,17 +1681,6 @@ ssize_t tsocks_sendto_guts(SENDTO_SIGNATURE, ssize_t (*original_sendto)(SENDTO_S show_msg(MSGDEBUG, "Got sendto request\n"); - /* Get the domain of the socket */ - getsockopt(s, SOL_SOCKET, SO_DOMAIN, - (void *) &sock_domain, &sock_domain_len); - - /* If this isn't an INET socket we can't handle it, just call the real - connect now */ - if ((sock_domain != PF_INET)) { - show_msg(MSGDEBUG, "Connection isn't an Internet socket ignoring\n"); - return (ssize_t) original_sendto(s, buf, len, flags, to, tolen); - } - /* Get the type of the socket */ getsockopt(s, SOL_SOCKET, SO_TYPE, (void *) &sock_type, &sock_type_len); @@ -1707,22 +1695,29 @@ ssize_t tsocks_sendto_guts(SENDTO_SIGNATURE, ssize_t (*original_sendto)(SENDTO_S return -1; } - return (ssize_t) original_sendto(s, buf, len, flags, to, tolen); + connaddr = (struct sockaddr_in *) to; + + /* If there is no address in 'to', sendto will only work if we + already allowed the socket to connect(), so we let it through. + Likewise if the socket is not an Internet connection. */ + if (connaddr && (connaddr->sin_family != AF_INET)) { + show_msg(MSGDEBUG, "Connection isn't an Internet socket ignoring\n"); + } + return (ssize_t) original_sendto(s, buf, len, flags, to, tolen); } ssize_t tsocks_sendmsg_guts(SENDMSG_SIGNATURE, ssize_t (*original_sendmsg)(SENDMSG_SIGNATURE)) { int sock_type = -1; unsigned int sock_type_len = sizeof(sock_type); - int sock_domain = -1; - unsigned int sock_domain_len = sizeof(sock_domain); + struct sockaddr_in *connaddr; /* See comment in close() */ if (!tsocks_init_complete) tsocks_init(); - /* If the real connect doesn't exist, we're stuffed */ + /* If the real sendmsg doesn't exist, we're stuffed */ if (original_sendmsg == NULL) { show_msg(MSGERR, "Unresolved symbol: sendmsg\n"); return(-1); @@ -1730,31 +1725,27 @@ ssize_t tsocks_sendmsg_guts(SENDMSG_SIGNATURE, ssize_t (*original_sendmsg)(SENDM show_msg(MSGDEBUG, "Got sendmsg request\n"); - /* Get the domain of the socket */ - getsockopt(s, SOL_SOCKET, SO_DOMAIN, - (void *) &sock_domain, &sock_domain_len); - - /* If this isn't an INET socket we can't handle it, just call the real - connect now */ - if ((sock_domain != PF_INET)) { - show_msg(MSGDEBUG, "Connection isn't an Internet socket ignoring\n"); - return (ssize_t) original_sendmsg(s, msg, flags); - } - /* Get the type of the socket */ getsockopt(s, SOL_SOCKET, SO_TYPE, (void *) &sock_type, &sock_type_len); show_msg(MSGDEBUG, "sockopt: %i\n", sock_type); - /* If this a UDP socket then we refuse it, since it is probably a DNS - request */ if ((sock_type != SOCK_STREAM)) { show_msg(MSGERR, "sendmsg: Connection is a UDP or ICMP stream, may be a " - "DNS request or other form of leak: rejecting.\n"); + "DNS request or other form of leak: rejecting.\n"); return -1; } + connaddr = (struct sockaddr_in *) msg->msg_name; + + /* If there is no address in msg_name, sendmsg will only work if we + already allowed the socket to connect(), so we let it through. + Likewise if the socket is not an Internet connection. */ + if (connaddr && (connaddr->sin_family != AF_INET)) { + show_msg(MSGDEBUG, "Connection isn't an Internet socket\n"); + } + return (ssize_t) original_sendmsg(s, msg, flags); }

1 0

[torsocks/osx] Use @libdir@ instead of @prefix@ in src/Makefile.am
by hoganrobert＠torproject.org 24 Oct '11

24 Oct '11

commit 917fc9b824e665aaa10ce0d4b986ff41b666e151 Author: Robert Hogan <robert(a)roberthogan.net> Date: Sun Dec 12 14:18:56 2010 +0000 Use @libdir@ instead of @prefix@ in src/Makefile.am Patch from Hicham Haouari. Fixes build for Fedora 64-bit. --- src/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index d5d1239..f0ae121 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1,7 +1,7 @@ # Makefile used by configure to create real Makefile LIBS = -ldl -lc -lresolv -libdir = @prefix@/lib/torsocks +libdir = @libdir@/torsocks # Install helper programs #bin_PROGRAMS = validateconf inspectsocks saveme

1 0

[torsocks/osx] Always print error messages.
by hoganrobert＠torproject.org 24 Oct '11

24 Oct '11

commit dfaf9e799092d1b901270b7492ab727739d60898 Author: Robert Hogan <robert(a)roberthogan.net> Date: Mon Sep 20 20:19:46 2010 +0100 Always print error messages. Allow error logging by default. --- configure.in | 4 ---- src/tsocks.c | 7 +------ 2 files changed, 1 insertions(+), 10 deletions(-) diff --git a/configure.in b/configure.in index 9d8a1e2..9a41cf1 100644 --- a/configure.in +++ b/configure.in @@ -189,10 +189,6 @@ if test "${enable_oldmethod}" = "yes"; then oldmethod="yes" fi -if test "x${enable_debug}" != "x"; then - AC_DEFINE([ALLOW_MSG_OUTPUT],[],[Description]) -fi - AC_DEFINE([HOSTNAMES],[0],[Description]) if test "x${enable_hostnames}" = "xyes"; then diff --git a/src/tsocks.c b/src/tsocks.c index 3773bb0..80f7b9c 100644 --- a/src/tsocks.c +++ b/src/tsocks.c @@ -255,24 +255,19 @@ void tsocks_init(void) static int get_environment() { static int done = 0; -#ifdef ALLOW_MSG_OUTPUT int loglevel = MSGERR; char *logfile = NULL; char *env; -#endif + if (done) return(0); /* Determine the logging level */ -#ifndef ALLOW_MSG_OUTPUT - set_log_options(-1, (char *)stderr, 0); -#else if ((env = getenv("TORSOCKS_DEBUG"))) loglevel = atoi(env); if (((env = getenv("TORSOCKS_DEBUG_FILE"))) && !suid) logfile = env; set_log_options(loglevel, logfile, 1); -#endif done = 1;

1 0

[torsocks/osx] Remove non-free RFC and replace with link.
by hoganrobert＠torproject.org 24 Oct '11

24 Oct '11

commit 54f25db9d54c63052e789ec429d8a4296520e9d8 Author: mwenge <robert(a)roberthogan.net> Date: Sat Nov 28 10:24:01 2009 +0000 Remove non-free RFC and replace with link. --- doc/SOCKS5 | 2 + doc/SOCKS5-rfc1928.txt | 507 ------------------------------------------------ 2 files changed, 2 insertions(+), 507 deletions(-) diff --git a/doc/SOCKS5 b/doc/SOCKS5 new file mode 100644 index 0000000..40dfcbd --- /dev/null +++ b/doc/SOCKS5 @@ -0,0 +1,2 @@ +http://www.ietf.org/rfc/rfc1928.txt + diff --git a/doc/SOCKS5-rfc1928.txt b/doc/SOCKS5-rfc1928.txt deleted file mode 100644 index 46bf46e..0000000 --- a/doc/SOCKS5-rfc1928.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -Network Working Group M. Leech -Request for Comments: 1928 Bell-Northern Research Ltd -Category: Standards Track M. Ganis - International Business Machines - Y. Lee - NEC Systems Laboratory - R. Kuris - Unify Corporation - D. Koblas - Independent Consultant - L. Jones - Hewlett-Packard Company - March 1996 - - - SOCKS Protocol Version 5 - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Acknowledgments - - This memo describes a protocol that is an evolution of the previous - version of the protocol, version 4 [1]. This new protocol stems from - active discussions and prototype implementations. The key - contributors are: Marcus Leech: Bell-Northern Research, David Koblas: - Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont - Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt - Ganis: International Business Machines. - -1. Introduction - - The use of network firewalls, systems that effectively isolate an - organizations internal network structure from an exterior network, - such as the INTERNET is becoming increasingly popular. These - firewall systems typically act as application-layer gateways between - networks, usually offering controlled TELNET, FTP, and SMTP access. - With the emergence of more sophisticated application layer protocols - designed to facilitate global information discovery, there exists a - need to provide a general framework for these protocols to - transparently and securely traverse a firewall. - - - - - -Leech, et al Standards Track [Page 1] - -RFC 1928 SOCKS Protocol Version 5 March 1996 - - - There exists, also, a need for strong authentication of such - traversal in as fine-grained a manner as is practical. This - requirement stems from the realization that client-server - relationships emerge between the networks of various organizations, - and that such relationships need to be controlled and often strongly - authenticated. - - The protocol described here is designed to provide a framework for - client-server applications in both the TCP and UDP domains to - conveniently and securely use the services of a network firewall. - The protocol is conceptually a "shim-layer" between the application - layer and the transport layer, and as such does not provide network- - layer gateway services, such as forwarding of ICMP messages. - -2. Existing practice - - There currently exists a protocol, SOCKS Version 4, that provides for - unsecured firewall traversal for TCP-based client-server - applications, including TELNET, FTP and the popular information- - discovery protocols such as HTTP, WAIS and GOPHER. - - This new protocol extends the SOCKS Version 4 model to include UDP, - and extends the framework to include provisions for generalized - strong authentication schemes, and extends the addressing scheme to - encompass domain-name and V6 IP addresses. - - The implementation of the SOCKS protocol typically involves the - recompilation or relinking of TCP-based client applications to use - the appropriate encapsulation routines in the SOCKS library. - -Note: - - Unless otherwise noted, the decimal numbers appearing in packet- - format diagrams represent the length of the corresponding field, in - octets. Where a given octet must take on a specific value, the - syntax X'hh' is used to denote the value of the single octet in that - field. When the word 'Variable' is used, it indicates that the - corresponding field has a variable length defined either by an - associated (one or two octet) length field, or by a data type field. - -3. Procedure for TCP-based clients - - When a TCP-based client wishes to establish a connection to an object - that is reachable only via a firewall (such determination is left up - to the implementation), it must open a TCP connection to the - appropriate SOCKS port on the SOCKS server system. The SOCKS service - is conventionally located on TCP port 1080. If the connection - request succeeds, the client enters a negotiation for the - - - -Leech, et al Standards Track [Page 2] - -RFC 1928 SOCKS Protocol Version 5 March 1996 - - - authentication method to be used, authenticates with the chosen - method, then sends a relay request. The SOCKS server evaluates the - request, and either establishes the appropriate connection or denies - it. - - Unless otherwise noted, the decimal numbers appearing in packet- - format diagrams represent the length of the corresponding field, in - octets. Where a given octet must take on a specific value, the - syntax X'hh' is used to denote the value of the single octet in that - field. When the word 'Variable' is used, it indicates that the - corresponding field has a variable length defined either by an - associated (one or two octet) length field, or by a data type field. - - The client connects to the server, and sends a version - identifier/method selection message: - - +----+----------+----------+ - |VER | NMETHODS | METHODS | - +----+----------+----------+ - | 1 | 1 | 1 to 255 | - +----+----------+----------+ - - The VER field is set to X'05' for this version of the protocol. The - NMETHODS field contains the number of method identifier octets that - appear in the METHODS field. - - The server selects from one of the methods given in METHODS, and - sends a METHOD selection message: - - +----+--------+ - |VER | METHOD | - +----+--------+ - | 1 | 1 | - +----+--------+ - - If the selected METHOD is X'FF', none of the methods listed by the - client are acceptable, and the client MUST close the connection. - - The values currently defined for METHOD are: - - o X'00' NO AUTHENTICATION REQUIRED - o X'01' GSSAPI - o X'02' USERNAME/PASSWORD - o X'03' to X'7F' IANA ASSIGNED - o X'80' to X'FE' RESERVED FOR PRIVATE METHODS - o X'FF' NO ACCEPTABLE METHODS - - The client and server then enter a method-specific sub-negotiation. - - - -Leech, et al Standards Track [Page 3] - -RFC 1928 SOCKS Protocol Version 5 March 1996 - - - Descriptions of the method-dependent sub-negotiations appear in - separate memos. - - Developers of new METHOD support for this protocol should contact - IANA for a METHOD number. The ASSIGNED NUMBERS document should be - referred to for a current list of METHOD numbers and their - corresponding protocols. - - Compliant implementations MUST support GSSAPI and SHOULD support - USERNAME/PASSWORD authentication methods. - -4. Requests - - Once the method-dependent subnegotiation has completed, the client - sends the request details. If the negotiated method includes - encapsulation for purposes of integrity checking and/or - confidentiality, these requests MUST be encapsulated in the method- - dependent encapsulation. - - The SOCKS request is formed as follows: - - +----+-----+-------+------+----------+----------+ - |VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT | - +----+-----+-------+------+----------+----------+ - | 1 | 1 | X'00' | 1 | Variable | 2 | - +----+-----+-------+------+----------+----------+ - - Where: - - o VER protocol version: X'05' - o CMD - o CONNECT X'01' - o BIND X'02' - o UDP ASSOCIATE X'03' - o RSV RESERVED - o ATYP address type of following address - o IP V4 address: X'01' - o DOMAINNAME: X'03' - o IP V6 address: X'04' - o DST.ADDR desired destination address - o DST.PORT desired destination port in network octet - order - - The SOCKS server will typically evaluate the request based on source - and destination addresses, and return one or more reply messages, as - appropriate for the request type. - - - - - -Leech, et al Standards Track [Page 4] - -RFC 1928 SOCKS Protocol Version 5 March 1996 - - -5. Addressing - - In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies - the type of address contained within the field: - - o X'01' - - the address is a version-4 IP address, with a length of 4 octets - - o X'03' - - the address field contains a fully-qualified domain name. The first - octet of the address field contains the number of octets of name that - follow, there is no terminating NUL octet. - - o X'04' - - the address is a version-6 IP address, with a length of 16 octets. - -6. Replies - - The SOCKS request information is sent by the client as soon as it has - established a connection to the SOCKS server, and completed the - authentication negotiations. The server evaluates the request, and - returns a reply formed as follows: - - +----+-----+-------+------+----------+----------+ - |VER | REP | RSV | ATYP | BND.ADDR | BND.PORT | - +----+-----+-------+------+----------+----------+ - | 1 | 1 | X'00' | 1 | Variable | 2 | - +----+-----+-------+------+----------+----------+ - - Where: - - o VER protocol version: X'05' - o REP Reply field: - o X'00' succeeded - o X'01' general SOCKS server failure - o X'02' connection not allowed by ruleset - o X'03' Network unreachable - o X'04' Host unreachable - o X'05' Connection refused - o X'06' TTL expired - o X'07' Command not supported - o X'08' Address type not supported - o X'09' to X'FF' unassigned - o RSV RESERVED - o ATYP address type of following address - - - -Leech, et al Standards Track [Page 5] - -RFC 1928 SOCKS Protocol Version 5 March 1996 - - - o IP V4 address: X'01' - o DOMAINNAME: X'03' - o IP V6 address: X'04' - o BND.ADDR server bound address - o BND.PORT server bound port in network octet order - - Fields marked RESERVED (RSV) must be set to X'00'. - - If the chosen method includes encapsulation for purposes of - authentication, integrity and/or confidentiality, the replies are - encapsulated in the method-dependent encapsulation. - -CONNECT - - In the reply to a CONNECT, BND.PORT contains the port number that the - server assigned to connect to the target host, while BND.ADDR - contains the associated IP address. The supplied BND.ADDR is often - different from the IP address that the client uses to reach the SOCKS - server, since such servers are often multi-homed. It is expected - that the SOCKS server will use DST.ADDR and DST.PORT, and the - client-side source address and port in evaluating the CONNECT - request. - -BIND - - The BIND request is used in protocols which require the client to - accept connections from the server. FTP is a well-known example, - which uses the primary client-to-server connection for commands and - status reports, but may use a server-to-client connection for - transferring data on demand (e.g. LS, GET, PUT). - - It is expected that the client side of an application protocol will - use the BIND request only to establish secondary connections after a - primary connection is established using CONNECT. In is expected that - a SOCKS server will use DST.ADDR and DST.PORT in evaluating the BIND - request. - - Two replies are sent from the SOCKS server to the client during a - BIND operation. The first is sent after the server creates and binds - a new socket. The BND.PORT field contains the port number that the - SOCKS server assigned to listen for an incoming connection. The - BND.ADDR field contains the associated IP address. The client will - typically use these pieces of information to notify (via the primary - or control connection) the application server of the rendezvous - address. The second reply occurs only after the anticipated incoming - connection succeeds or fails. - - - - - -Leech, et al Standards Track [Page 6] - -RFC 1928 SOCKS Protocol Version 5 March 1996 - - - In the second reply, the BND.PORT and BND.ADDR fields contain the - address and port number of the connecting host. - -UDP ASSOCIATE - - The UDP ASSOCIATE request is used to establish an association within - the UDP relay process to handle UDP datagrams. The DST.ADDR and - DST.PORT fields contain the address and port that the client expects - to use to send UDP datagrams on for the association. The server MAY - use this information to limit access to the association. If the - client is not in possesion of the information at the time of the UDP - ASSOCIATE, the client MUST use a port number and address of all - zeros. - - A UDP association terminates when the TCP connection that the UDP - ASSOCIATE request arrived on terminates. - - In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR - fields indicate the port number/address where the client MUST send - UDP request messages to be relayed. - -Reply Processing - - When a reply (REP value other than X'00') indicates a failure, the - SOCKS server MUST terminate the TCP connection shortly after sending - the reply. This must be no more than 10 seconds after detecting the - condition that caused a failure. - - If the reply code (REP value of X'00') indicates a success, and the - request was either a BIND or a CONNECT, the client may now start - passing data. If the selected authentication method supports - encapsulation for the purposes of integrity, authentication and/or - confidentiality, the data are encapsulated using the method-dependent - encapsulation. Similarly, when data arrives at the SOCKS server for - the client, the server MUST encapsulate the data as appropriate for - the authentication method in use. - -7. Procedure for UDP-based clients - - A UDP-based client MUST send its datagrams to the UDP relay server at - the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE - request. If the selected authentication method provides - encapsulation for the purposes of authenticity, integrity, and/or - confidentiality, the datagram MUST be encapsulated using the - appropriate encapsulation. Each UDP datagram carries a UDP request - header with it: - - - - - -Leech, et al Standards Track [Page 7] - -RFC 1928 SOCKS Protocol Version 5 March 1996 - - - +----+------+------+----------+----------+----------+ - |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | - +----+------+------+----------+----------+----------+ - | 2 | 1 | 1 | Variable | 2 | Variable | - +----+------+------+----------+----------+----------+ - - The fields in the UDP request header are: - - o RSV Reserved X'0000' - o FRAG Current fragment number - o ATYP address type of following addresses: - o IP V4 address: X'01' - o DOMAINNAME: X'03' - o IP V6 address: X'04' - o DST.ADDR desired destination address - o DST.PORT desired destination port - o DATA user data - - When a UDP relay server decides to relay a UDP datagram, it does so - silently, without any notification to the requesting client. - Similarly, it will drop datagrams it cannot or will not relay. When - a UDP relay server receives a reply datagram from a remote host, it - MUST encapsulate that datagram using the above UDP request header, - and any authentication-method-dependent encapsulation. - - The UDP relay server MUST acquire from the SOCKS server the expected - IP address of the client that will send datagrams to the BND.PORT - given in the reply to UDP ASSOCIATE. It MUST drop any datagrams - arriving from any source IP address other than the one recorded for - the particular association. - - The FRAG field indicates whether or not this datagram is one of a - number of fragments. If implemented, the high-order bit indicates - end-of-fragment sequence, while a value of X'00' indicates that this - datagram is standalone. Values between 1 and 127 indicate the - fragment position within a fragment sequence. Each receiver will - have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these - fragments. The reassembly queue must be reinitialized and the - associated fragments abandoned whenever the REASSEMBLY TIMER expires, - or a new datagram arrives carrying a FRAG field whose value is less - than the highest FRAG value processed for this fragment sequence. - The reassembly timer MUST be no less than 5 seconds. It is - recommended that fragmentation be avoided by applications wherever - possible. - - Implementation of fragmentation is optional; an implementation that - does not support fragmentation MUST drop any datagram whose FRAG - field is other than X'00'. - - - -Leech, et al Standards Track [Page 8] - -RFC 1928 SOCKS Protocol Version 5 March 1996 - - - The programming interface for a SOCKS-aware UDP MUST report an - available buffer space for UDP datagrams that is smaller than the - actual space provided by the operating system: - - o if ATYP is X'01' - 10+method_dependent octets smaller - o if ATYP is X'03' - 262+method_dependent octets smaller - o if ATYP is X'04' - 20+method_dependent octets smaller - -8. Security Considerations - - This document describes a protocol for the application-layer - traversal of IP network firewalls. The security of such traversal is - highly dependent on the particular authentication and encapsulation - methods provided in a particular implementation, and selected during - negotiation between SOCKS client and SOCKS server. - - Careful consideration should be given by the administrator to the - selection of authentication methods. - -9. References - - [1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium. - -Author's Address - - Marcus Leech - Bell-Northern Research Ltd - P.O. Box 3511, Stn. C, - Ottawa, ON - CANADA K1Y 4H7 - - Phone: (613) 763-9145 - EMail: mleech(a)bnr.ca - - - - - - - - - - - - - - - - - - -Leech, et al Standards Track [Page 9] -

1 0

[torsocks/osx] Manpage syntax fixes from Patrick Matthäi <pmatthaei@debian.org>
by hoganrobert＠torproject.org 24 Oct '11

24 Oct '11

commit 2b42c80f106aae039d85458aa3c6624a6459febb Author: mwenge <robert(a)roberthogan.net> Date: Sun Nov 8 12:35:11 2009 +0000 Manpage syntax fixes from Patrick Matthäi <pmatthaei(a)debian.org> --- src/torsocks.conf.5.in | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/torsocks.conf.5.in b/src/torsocks.conf.5.in index b8ab870..7cd22d8 100644 --- a/src/torsocks.conf.5.in +++ b/src/torsocks.conf.5.in @@ -53,7 +53,7 @@ Obviously if a connection is not to a locally accessible network it will need to be proxied over a SOCKS server. However, many installations have several different SOCKS servers to be used to access different internal (and external) networks. For this reason the configuration file allows the definition of -'paths' as well as a default SOCKS server. +`paths' as well as a default SOCKS server. Paths are declared as blocks in the configuration file. That is, they begin with a 'path {' line in the configuration file and end with a '}' line. Inside @@ -97,7 +97,7 @@ The following directives are used in the torsocks configuration file: .I server The IP address of the SOCKS server (e.g "server = 10.1.4.253"). Only one server may be specified per path block, or one outside a path -block (to define the default server). Unless --disable-hostnames was +block (to define the default server). Unless \-\-disable-hostnames was specified to configure at compile time the server can be specified as a hostname (e.g "server = socks.nec.com") @@ -149,7 +149,7 @@ local, otherwise torsocks would need a SOCKS server to reach SOCKS servers. .TP .I reaches This directive is only valid inside a path block. Its parameter is formed -as IP[:startport[-endport]]/Subnet and it specifies a network (and a range +as IP[:startport[\-endport]]/Subnet and it specifies a network (and a range of ports on that network) that can be accessed by the SOCKS server specified in this path block. For example, in a path block "reaches = 150.0.0.0:80-1024/255.0.0.0" indicates to torsocks that the SOCKS server @@ -161,7 +161,7 @@ range 150.0.0.0 to 150.255.255.255 when the connection request is for ports .I tordns_enable This enables the use of the 'tordns' feature in torsocks, which overrides the standard C library name resolution calls to use SOCKS. The default value is -'true'. +`true'. .TP .I tordns_deadpool_range

1 0

[torsocks/osx] Remove kdevelop project file
by hoganrobert＠torproject.org 24 Oct '11

24 Oct '11

commit aacc9731963484958ac7b6daf165b36056e42345 Author: mwenge <robert(a)roberthogan.net> Date: Sat Sep 26 09:43:00 2009 +0100 Remove kdevelop project file --- torsocks.kdevelop | 266 ----------------------------------------------------- 1 files changed, 0 insertions(+), 266 deletions(-) diff --git a/torsocks.kdevelop b/torsocks.kdevelop deleted file mode 100644 index f3322c6..0000000 --- a/torsocks.kdevelop +++ /dev/null @@ -1,266 +0,0 @@ -<?xml version = '1.0'?> -<kdevelop> - <general> - <author>Robert Hogan</author> - <email>robert(a)roberthogan.net</email> - <version>0.1</version> - <projectmanagement>KDevAutoProject</projectmanagement> - <primarylanguage>C</primarylanguage> - <keywords> - <keyword>C</keyword> - <keyword>Code</keyword> - </keywords> - <ignoreparts/> - <projectname>torsocks</projectname> - <projectdirectory>.</projectdirectory> - <absoluteprojectpath>false</absoluteprojectpath> - <description/> - <defaultencoding/> - <versioncontrol>kdevcvsservice</versioncontrol> - </general> - <kdevautoproject> - <general> - <activetarget>src/torsocks</activetarget> - <useconfiguration>debug</useconfiguration> - </general> - <run> - <mainprogram>/home/robert/Development/torsocks-svn/torsocks/debug/</mainprogram> - <terminal>true</terminal> - <programargs>ping google.com</programargs> - <globaldebugarguments>ping www.google.com</globaldebugarguments> - <globalcwd>/home/robert/Development/torsocks-svn/torsocks/</globalcwd> - <useglobalprogram>true</useglobalprogram> - <autocompile>false</autocompile> - <autoinstall>false</autoinstall> - <autokdesu>false</autokdesu> - <envvars> - <envvar value="debug/src/.libs/libtorsocks.so" name="LD_PRELOAD" /> - <envvar value="2" name="TSOCKS_DEBUG" /> - </envvars> - </run> - <configurations> - <optimized> - <builddir>optimized</builddir> - <ccompiler>kdevgccoptions</ccompiler> - <cxxcompiler>kdevgppoptions</cxxcompiler> - <f77compiler>kdevg77options</f77compiler> - <cflags>-O2 -g0 </cflags> - </optimized> - <debug> - <configargs>--enable-debug=full --enable-gcc-warnings</configargs> - <builddir>debug</builddir> - <ccompiler>kdevgccoptions</ccompiler> - <cxxcompiler>kdevgppoptions</cxxcompiler> - <f77compiler>kdevg77options</f77compiler> - <cflags>-O0 -g3 </cflags> - <envvars/> - <topsourcedir/> - <cppflags/> - <ldflags/> - <ccompilerbinary/> - <cxxcompilerbinary/> - <f77compilerbinary/> - <cxxflags/> - <f77flags/> - </debug> - <default> - <envvars/> - <configargs>--enable-gcc-warnings</configargs> - <builddir/> - <topsourcedir/> - <cppflags/> - <ldflags/> - <ccompiler>kdevgccoptions</ccompiler> - <cxxcompiler>kdevgppoptions</cxxcompiler> - <f77compiler>kdevpgf77options</f77compiler> - <ccompilerbinary/> - <cxxcompilerbinary/> - <f77compilerbinary/> - <cflags/> - <cxxflags/> - <f77flags/> - </default> - </configurations> - <make> - <envvars> - <envvar value="1" name="WANT_AUTOCONF_2_5" /> - <envvar value="1" name="WANT_AUTOMAKE_1_6" /> - </envvars> - <abortonerror>true</abortonerror> - <runmultiplejobs>true</runmultiplejobs> - <numberofjobs>3</numberofjobs> - <dontact>false</dontact> - <makebin/> - <prio>0</prio> - </make> - </kdevautoproject> - <kdevdoctreeview> - <ignoretocs> - <toc>ada</toc> - <toc>ada_bugs_gcc</toc> - <toc>bash</toc> - <toc>bash_bugs</toc> - <toc>clanlib</toc> - <toc>w3c-dom-level2-html</toc> - <toc>fortran_bugs_gcc</toc> - <toc>gnome1</toc> - <toc>gnustep</toc> - <toc>gtk</toc> - <toc>gtk_bugs</toc> - <toc>haskell</toc> - <toc>haskell_bugs_ghc</toc> - <toc>java_bugs_gcc</toc> - <toc>java_bugs_sun</toc> - <toc>kde2book</toc> - <toc>libstdc++</toc> - <toc>opengl</toc> - <toc>pascal_bugs_fp</toc> - <toc>php</toc> - <toc>php_bugs</toc> - <toc>perl</toc> - <toc>perl_bugs</toc> - <toc>python</toc> - <toc>python_bugs</toc> - <toc>qt-kdev3</toc> - <toc>ruby</toc> - <toc>ruby_bugs</toc> - <toc>sdl</toc> - <toc>stl</toc> - <toc>w3c-svg</toc> - <toc>sw</toc> - <toc>w3c-uaag10</toc> - <toc>wxwidgets_bugs</toc> - </ignoretocs> - <ignoreqt_xml> - <toc>Guide to the Qt Translation Tools</toc> - <toc>Qt Assistant Manual</toc> - <toc>Qt Designer Manual</toc> - <toc>Qt Reference Documentation</toc> - <toc>qmake User Guide</toc> - </ignoreqt_xml> - <ignoredoxygen> - <toc>KDE Libraries (Doxygen)</toc> - </ignoredoxygen> - </kdevdoctreeview> - <kdevfilecreate> - <useglobaltypes> - <type ext="c" /> - <type ext="h" /> - </useglobaltypes> - </kdevfilecreate> - <kdevfileview> - <groups> - <group pattern="*.h" name="Header files" /> - <group pattern="*.c" name="Source files" /> - <hidenonprojectfiles>false</hidenonprojectfiles> - <hidenonlocation>false</hidenonlocation> - </groups> - <tree> - <hidepatterns>*.o,*.lo,CVS</hidepatterns> - <hidenonprojectfiles>false</hidenonprojectfiles> - <showvcsfields>false</showvcsfields> - </tree> - </kdevfileview> - <kdevdocumentation> - <projectdoc> - <docsystem>Doxygen Documentation Collection</docsystem> - <docurl>torsocks.tag</docurl> - </projectdoc> - </kdevdocumentation> - <substmap> - <APPNAME>torsocks</APPNAME> - <APPNAMELC>torsocks</APPNAMELC> - <APPNAMESC>Torsocks</APPNAMESC> - <APPNAMEUC>TORSOCKS</APPNAMEUC> - <AUTHOR>Robert Hogan</AUTHOR> - <CFLAGS/> - <EMAIL>robert(a)roberthogan.net</EMAIL> - <LICENSE>GPL</LICENSE> - <LICENSEFILE>COPYING</LICENSEFILE> - <OPT_INCS>-I/usr/include</OPT_INCS> - <OPT_LIBS>-lm</OPT_LIBS> - <VERSION>0.1</VERSION> - <YEAR>2008</YEAR> - <dest>/home/robert/Development/torsocks</dest> - </substmap> - <kdevcppsupport> - <qt> - <used>false</used> - <version>3</version> - <includestyle>3</includestyle> - <root>/usr/share/qt3</root> - <designerintegration>EmbeddedKDevDesigner</designerintegration> - <qmake>/usr/bin/qmake-qt3</qmake> - <designer>/usr/bin/designer-qt3</designer> - <designerpluginpaths/> - </qt> - <codecompletion> - <automaticCodeCompletion>false</automaticCodeCompletion> - <automaticArgumentsHint>true</automaticArgumentsHint> - <automaticHeaderCompletion>true</automaticHeaderCompletion> - <codeCompletionDelay>250</codeCompletionDelay> - <argumentsHintDelay>400</argumentsHintDelay> - <headerCompletionDelay>250</headerCompletionDelay> - <showOnlyAccessibleItems>false</showOnlyAccessibleItems> - <completionBoxItemOrder>0</completionBoxItemOrder> - <howEvaluationContextMenu>true</howEvaluationContextMenu> - <showCommentWithArgumentHint>true</showCommentWithArgumentHint> - <statusBarTypeEvaluation>false</statusBarTypeEvaluation> - <namespaceAliases>std=_GLIBCXX_STD;__gnu_cxx=std</namespaceAliases> - <processPrimaryTypes>true</processPrimaryTypes> - <processFunctionArguments>false</processFunctionArguments> - <preProcessAllHeaders>false</preProcessAllHeaders> - <parseMissingHeadersExperimental>false</parseMissingHeadersExperimental> - <resolveIncludePathsUsingMakeExperimental>false</resolveIncludePathsUsingMakeExperimental> - <alwaysParseInBackground>true</alwaysParseInBackground> - <usePermanentCaching>true</usePermanentCaching> - <alwaysIncludeNamespaces>false</alwaysIncludeNamespaces> - <includePaths>.;</includePaths> - </codecompletion> - <creategettersetter> - <prefixGet/> - <prefixSet>set</prefixSet> - <prefixVariable>m_,_</prefixVariable> - <parameterName>theValue</parameterName> - <inlineGet>true</inlineGet> - <inlineSet>true</inlineSet> - </creategettersetter> - <splitheadersource> - <enabled>false</enabled> - <synchronize>true</synchronize> - <orientation>Vertical</orientation> - </splitheadersource> - <references/> - </kdevcppsupport> - <cppsupportpart> - <filetemplates> - <interfacesuffix>.h</interfacesuffix> - <implementationsuffix>.cpp</implementationsuffix> - </filetemplates> - </cppsupportpart> - <kdevdebugger> - <general> - <gdbpath/> - <dbgshell>libtool</dbgshell> - <configGdbScript/> - <runShellScript/> - <runGdbScript/> - <breakonloadinglibs>true</breakonloadinglibs> - <separatetty>false</separatetty> - <floatingtoolbar>false</floatingtoolbar> - <raiseGDBOnStart>false</raiseGDBOnStart> - </general> - <display> - <staticmembers>false</staticmembers> - <demanglenames>true</demanglenames> - <outputradix>10</outputradix> - </display> - </kdevdebugger> - <kdevcvsservice> - <recursivewhenupdate>true</recursivewhenupdate> - <prunedirswhenupdate>true</prunedirswhenupdate> - <createdirswhenupdate>true</createdirswhenupdate> - <recursivewhencommitremove>true</recursivewhencommitremove> - <revertoptions>-C</revertoptions> - </kdevcvsservice> -</kdevelop>

1 0

[torsocks/osx] Build fix for BSD.
by hoganrobert＠torproject.org 24 Oct '11

24 Oct '11

commit 17839f73a638d562c726ec5a808842256d0cdc14 Author: mwenge <robert(a)roberthogan.net> Date: Mon Dec 14 22:04:07 2009 +0000 Build fix for BSD. Support presence of res_query in libc rather than libresolve. --- configure.in | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/configure.in b/configure.in index 390d08e..f7b1af9 100644 --- a/configure.in +++ b/configure.in @@ -129,11 +129,14 @@ if test "$tempdso" = "no"; then "Check your system for libc.so and/or libdl.so.")) fi -AC_CHECK_LIB(resolv, res_query, [ tempres="no" ],tempres="yes") +AC_CHECK_LIB(resolv, res_query, [ tempres="yes" ],tempres="no") if test "$tempres" = "no"; then - AC_DEFINE([SUPPORT_RES_API],[],[Support the res_query family of calls]) + AC_CHECK_LIB(c, res_query,,AC_MSG_ERROR("res_query() not found in libc or libresolve." \ + "Check your system for libc.so and/or libresolve.so.")) fi +AC_DEFINE([SUPPORT_RES_API],[],[Support the res_query family of calls]) + dnl If we're using gcc here define _GNU_SOURCE AC_MSG_CHECKING(for RTLD_NEXT from dlfcn.h) AC_EGREP_CPP(yes,

1 0

[torsocks/osx] Improve compile-time detection of the res* family of system calls
by hoganrobert＠torproject.org 24 Oct '11

24 Oct '11

commit a4d3828cfd09e16d5933e6cb763bc76cd3259035 Author: Robert Hogan <robert(a)webkit.org> Date: Tue Jul 6 21:50:29 2010 +0100 Improve compile-time detection of the res* family of system calls Some platforms need to explicitly include resolv.h so cater for that. Thanks to SwissTorExit for reporting and debugging assistance. --- configure.in | 19 ++++++++++++++----- 1 files changed, 14 insertions(+), 5 deletions(-) diff --git a/configure.in b/configure.in index b447fe3..04703e4 100644 --- a/configure.in +++ b/configure.in @@ -129,11 +129,20 @@ if test "$tempdso" = "no"; then "Check your system for libc.so and/or libdl.so.")) fi -AC_CHECK_LIB(resolv, res_query, [ tempres="yes" ],tempres="no") -if test "$tempres" = "no"; then - AC_CHECK_LIB(c, res_query,,AC_MSG_ERROR("res_query() not found in libc or libresolve." \ - "Check your system for libc.so and/or libresolve.so.")) -fi +AC_CHECK_FUNC(res_query, , + [AC_CHECK_LIB(resolv, res_query, [], + [ save_libs="$LIBS" + LIBS="-lresolv $LIBS" + AC_MSG_CHECKING([for res_query in -lresolv (alternate version)]) + AC_LINK_IFELSE( + [AC_LANG_PROGRAM([[#include <resolv.h>]], [[res_query(0,0,0,0,0)]])], + [ AC_MSG_RESULT(yes) ], + [ AC_MSG_RESULT(no) + LIBS="$save_libs" + AC_CHECK_LIB(resolv, res_query, + [], [ AC_MSG_ERROR(res_query not found in libc or libresolve. Check your system for libc.so and/or libresolve.so.) ] ) ] ) ] ) + ] +) AC_DEFINE([SUPPORT_RES_API],[],[Support the res_query family of calls])

1 0