Re: nmap ...

[Marcin Bieńkowski <young@i.pl>]

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