• 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: Quinn <email@hidden>
  • Date: Thu, 31 Jan 2008 11:05:54 +0000

At 10:53 +1300 31/1/08, Glenn Anderson wrote:
Sometimes when this happens, accept() returns an address_len of 0. I see this on both Mac OS X 10.4 and 10.5. On Mac OS X 10.5 setsockopt(x, SOL_SOCKET, SO_NOSIGPIPE, ...) also fails with EINVAL in this case. Depending on the timing of the RST, I have also seen a correct address_len from accept() but the subsequent setsockopt() fails.

Is accept() returning an address_len of 0 and setsockopt() failing with EINVAL intended behavior? If it is intended, is it documented anywhere? The man pages for these calls definitely don't mention this behavior.

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.

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 (-:

While debugging this, I couldn't help wondering if there any way to check the state of a socket to see if the connection has shut down, like OTGetEndpointState under OS 9?

I expect that your best bet is <x-man-page://2/getpeername>. This is traditionally used by sockets code to test whether a connection is in place. For example, when doing non-blocking connects, you typically use getpeername to determine whether the connect succeeded or failed.


S+E
--
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
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


  • Follow-Ups:
    • Re: accept() and setsockopt() and port scans
      • From: Glenn Anderson <email@hidden>
References: 
 >accept() and setsockopt() and port scans (From: Glenn Anderson <email@hidden>)

  • Prev by Date: Re: Porting Winsock DHCP Server; is OS/X ignoring Broadcast UDP in recvall()?
  • Next by Date: Re: Porting Winsock DHCP Server; is OS/X ignoring Broadcast UDP in recvall()?
  • Previous by thread: accept() and setsockopt() and port scans
  • Next by thread: Re: accept() and setsockopt() and port scans
  • Index(es):
    • Date
    • Thread