On Mon, Nov 05, 2001 at 10:24:34PM +0100, Philipp Schulte wrote:
>Thats not true. nmap shows "open" ports which means that something is
>listening on them. If I connect from localhost:1024 to
>www.debian.org:80 that does not mean that my port 1024 is open. It
>doesn't accept connections.
>I actually think that the explanation from Moritz was correct. I have
>not seen this kind of behaviour with recent versions of nmap.
Yes, that's true. I would say it was a problem with previous versions of
libc / kernel / don't know what rather than nmap.
I wrote a simple program which endlessly tries to connect to port 60000
(of course nothing is listening on that port).
here it follows :
---
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <arpa/inet.h>
#include <errno.h>
#include <netdb.h>
#include <string.h>
int main()
{
int sock;
struct sockaddr_in server_addr;
struct hostent* host;
int retval;
int ile = 0;
do {
sock = socket (AF_INET, SOCK_STREAM, 0);
host = gethostbyname ("localhost");
memset (&server_addr, 0, sizeof(struct sockaddr_in));
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons (60000);
memcpy (&server_addr.sin_addr, host->h_addr_list[0],
sizeof(server_addr.sin_addr));
ile++;
retval = connect (sock, (struct sockaddr*)&server_addr,
sizeof (struct sockaddr_in));
printf ("[%d] trying to connect -> %d\n",ile,retval);
close (sock);
/* sleep (1); */
} while (retval == -1);
printf ("[%d] trying to connect -> %d\n",ile,retval);
return 0;
}
---
nothing special, isn't it ?
when run in my last potato installation (2.2.x kernel) it ends with :
...
[6123] trying to connect -> -1
[6124] trying to connect -> -1
[6125] trying to connect -> 0
The numbers are rather random, but near couple of thousands.
If I put 'sleep(1);' (or some delay, let's say bigger than 1/100sec)
at the end of each loop, it will run perfectly
normal. It also works normal on kernels 2.4.x with libc 6.1, for example
on my current debian distribution.
I would suspect that what it really does is connecting to _itself_.
Imagine that in the 6125-th run of the loop kernel assigns 60000 as the
source port to 'connect' call - why not ?
Or it assigns it a little bit earlier, and this port stays binded,
because kernel has no time to free it ?
Or maybe I am missing something, then show me please errors in the
program above :)
best regards,
--
Marcin Bieńkowski
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
