• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: accept() and setsockopt() and port scans
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: accept() and setsockopt() and port scans


  • Subject: Re: accept() and setsockopt() and port scans
  • From: Glenn Anderson <email@hidden>
  • Date: Fri, 1 Feb 2008 13:47:45 +1300

At 11:05 am +0000 31/1/2008, Quinn wrote:
There are two cases here.

A. accept returns a valid address and setsockopt fails afterwards -- This seems like reasonable behaviour on behalf of the kernel. It gave you back a valid socket but the socket shut down before you called setsockopt. The standard specifically states that EINVAL can be caused by:

    The specified option is invalid at the specified socket level
    or the socket has been shut down.
    <http://www.opengroup.org/onlinepubs/009695399/functions/setsockopt.html>

I suspect that the UNIX '03 conformance changes are the reason why you're seeing different behaviour on 10.4 vs 10.5.

Thanks for the info. It is a bit frustrating that they have decided that the same error code is to be returned for two quite different things, but at least I know now that error code likely to continue to mean one of those two things.


I filed a bug report on this yesterday, ID 5716640. I have amended it with a link to that page and a request that the OS X man page be updated.

B. accept returns a null address -- This smells like a bug to me. Definitely Radar-worthy IMHO.

<http://developer.apple.com/bugreporter/>

Please send me the bug number. Also, if you can include code that reproduces the problem, that will definitely improve the chances of it getting fixed (-:

Filed, ID 5718597, with sample code. I have also included it below in case anyone else is interested, but as far as I am aware it is a pretty basic example of listening on a TCP socket. If you run it and scan it with nmap the problem will show up (eg: nmap 127.0.0.1 -p T:1234). It may need scanned a few times, the RST has to arrive at just the right time to trip up accept(). Hopefully I can find some time to do a test and see if doing poll() or select() followed by a delay followed by accept() will show the problem.


Glenn.

#include <stdio.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <errno.h>
#include <unistd.h>
#include <sys/types.h>

int main (int argc, char * const argv[])
{
	int listenerSocket;
	int connectionSocket;
	sockaddr_in tempAddr;
	socklen_t address_len;

listenerSocket = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
if (listenerSocket == -1)
printf("socket error %d\n", errno);
else {
tempAddr.sin_len = 8;
tempAddr.sin_family = AF_INET;
tempAddr.sin_port = htons(1234);
tempAddr.sin_addr.s_addr = htonl(INADDR_ANY);
if (bind(listenerSocket, (sockaddr*)&tempAddr, sizeof(tempAddr)) == -1)
printf("bind error %d\n", errno);
else {
if (listen(listenerSocket, 10) == -1)
printf("listen error %d\n", errno);
else {
printf("listening\n");
do {
address_len = sizeof(tempAddr);
connectionSocket = accept(listenerSocket, (sockaddr*)&tempAddr, &address_len);
if (connectionSocket < 0) {
printf("accept error %d\n", errno);
break;
}
printf("address_len is %d\n", address_len);
close(connectionSocket);
} while (true);
}
}
close(listenerSocket);
}
return(0);
}
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
References: 
 >accept() and setsockopt() and port scans (From: Glenn Anderson <email@hidden>)
 >Re: accept() and setsockopt() and port scans (From: Quinn <email@hidden>)

  • Prev by Date: Client Side Certificates + CFNetwork
  • Previous by thread: Re: accept() and setsockopt() and port scans
  • Next by thread: Client Side Certificates + CFNetwork
  • Index(es):
    • Date
    • Thread