netdev
[Top] [All Lists]

Re: select says I can read, but recvfrom hangs

To: hugh@xxxxxxxxxx, Marco Berizzi <pupilla@xxxxxxxxxxx>
Subject: Re: select says I can read, but recvfrom hangs
From: Michael Richardson <mcr@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 21 Jun 2001 09:17:50 -0400
Cc: netdev@xxxxxxxxxxx
In-reply-to: Your message of "Wed, 20 Jun 2001 22:57:59 EDT." <Pine.LNX.4.33.0106202214500.8383-100000@redshift.mimosa.com>
Sender: owner-netdev@xxxxxxxxxxx
-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "D" == D Hugh Redelmeier <hugh@xxxxxxxxxx> writes:
    D> - the scenario that provokes the problem for the user goes as follows:

    D>   + Pluto is running on a security gateway, with a Windows NT box
    D>     behind it

  This should be immaterial.

    D>   + he connects a second windows box, running PGPnet (an IPSEC
    D>     implementation), through the internet, to the public interface
    D>     of the security gateway.  This box negotiates a tunnel with
    D>     the security gateway.
  
  okay.

    D>   + he disconnects the second windows box, and reconnects the same way
    D>     but with a different IP address (the IP address is dynamically
    D>     assigned whenever he connects this box to the internet).

    D>   + the second box starts and completes IKE negotiation.

  okay, and completes.
  Was there actually data transmitted from the second box? I.e. were all
messages sent by the PGPnet actually received by Pluto?

    D>   + Pluto is tricked into hanging on a recvfrom.

    D> Is there any way to tell from the system whether the select is wrong
    D> (i.e. there is no message) or the recvfrom is wrong (i.e. there is a
    D> message, but it still hangs reading it)?

marajade-[~] mcr 1001 %netstat -f inet -n
Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        State
tcp        0      0  127.0.0.1.53           *.*                    LISTEN
udp        0      0  127.0.0.1.500          *.*                   
udp        0      0  172.16.212.1.500       *.*                   
udp        0      0  127.0.0.1.65522        127.0.0.1.65523       
udp        0      0  127.0.0.1.65523        127.0.0.1.65522       
udp        0      0  127.0.0.1.53           *.*                   

  (-f is BSD-ism. I think that there is -u for UDP on Linux, but plain
netstat would work as well.)

  That should tell you if the system thinks that there is in fact any data
queued on the socket.  Perhaps throw in a:
  system("netstat") in after the second select to help debug.

  If not, then this sounds like a race condition in the kernel with delivery
of multiple data available messages. I admit to have not read those pieces of 
2.2.

]     Internet Security. Have encryption, will travel           |1 Fish/2 Fish [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F [
] mcr@xxxxxxxxxxxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/ |strong crypto [
]                                                                for everyone  [

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface

iQCVAwUBOzHz+oqHRg3pndX9AQFf9QP/RvIhI/CK6sC2Tt/txIH6p2QtYe9VZYs1
SBgmHoKPxAu1bPKGQiTzTD94KwdheT1lnDjFzvO3pgWKvSjqa7ypsYM/lZSeYU9f
mmVj8QFQk6MTJWCeE8iihTx+rqlyS1vuEs0moIQlqtzt0N3EnSNBzF7INmb1S1zS
htBr0ta3n20=
=cvSw
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>