Bug#92757: apt-get fails to connect through a socks server

[Michel Casabona <michel.casabona@free.fr>]

Subject: apt-get fails to connect through a socks server
Package: apt
Version: 0.5.3
Severity: normal


-- System Information
Debian Release: testing/unstable
Kernel Version: Linux agenor 2.2.18 #1 Mon Jan 8 17:41:03 CET 2001 i586 unknown

Versions of the packages apt depends on:
ii  libc6          2.2.2-1        GNU C Library: Shared libraries and Timezone
ii  libstdc++2.10- 2.95.3-6       The GNU stdc++ library

Since I've migrated from 0.3.x to 0.5.3 (in testing), apt-get fails to connect
through a socks server. I'm using dante-client:

agenor:/etc/apt# socksify apt-get update
Err ftp://ftp.uk.debian.org woody/main Packages     
  Unable to determine the local name - getsockname (105 No buffer space
available)
 ...

Of course there is plenty of buffer space available.
The source code for dante Rgetsockname function gives a hint:

michel@agenor:dante-1.1.8$ head -83 lib/Rgetsockname.c | tail -16
                case SOCKS_CONNECT:
                        if (socksfd->state.inprogress) {
                                if (socksfd->state.err != 0) /* connect failed.
*/
                                        errno = socksfd->state.err;
                                else
                                        /* 
                                         * XXX
                                         * this is bad but we don't know what
address the socksserver
                                         * will use on our behalf yet.  Lets
hope the client
                                         * will retry on this error.
                                         * Another option might be to wait here
until the 
                                         * socksnegotiation has completed, but
applications probably
                                         * don't expect getsockname(2) to block.
                                        */
                                        errno = ENOBUFS;
                                return -1;

So it might be a timing problem. Indeed, moving back getsockname for the local
name from FTPConn:Open() to FTPConn:CreateDataFd() cures the problem. 
Here is the patch:

michel@agenor:apt$ diff -u methods/ftp.cc-org methods/ftp.cc
--- methods/ftp.cc-org  Thu Mar  8 03:20:43 2001
+++ methods/ftp.cc      Mon Mar 26 18:51:27 2001
@@ -160,9 +160,9 @@
       return _error->Errno("getpeername","Unable to determine the peer name");
    
    // Get the local machine's address
-   ServerAddrLen = sizeof(ServerAddr);
+/*   ServerAddrLen = sizeof(ServerAddr);
    if (getsockname(ServerFd,(sockaddr *)&ServerAddr,&ServerAddrLen) != 0)
-      return _error->Errno("getsockname","Unable to determine the local name");
+      return _error->Errno("getsockname","Unable to determine the local name");
*/
    
    Owner->Status("Logging in");
    return Login();
@@ -731,6 +731,11 @@
       return _error->Errno("listen","Could not listen on the socket");
    SetNonBlock(DataListenFd,true);
    
+   // Get the local machine's address
+   ServerAddrLen = sizeof(ServerAddr);
+   if (getsockname(ServerFd,(sockaddr *)&ServerAddr,&ServerAddrLen) != 0)
+      return _error->Errno("getsockname","Unable to determine the local name");
+
    // Determine the name to send to the remote
    struct sockaddr_storage Addr;
    socklen_t AddrLen = sizeof(Addr);

The patch only restores the old apt 0.3.x behaviour. I've no idea if it's the
right fix, but it demonstrates the timing problem. 

Thanks,

Michel Casabona