Possible problem in fcntl

Possible problem in fcntl

[Filipe Cabecinhas]

Hi,

We have written a little webserver for our CS course. But we have a
problem with fcntl.
We are using non-blocking sockets and per fcntl man page:
       On Linux, the new socket returned by accept () does  not  inherit  file
       status  flags such as O_NONBLOCK and O_ASYNC from the listening socket.
       This behaviour differs from the canonical BSD  sockets  implementation.
       Portable  programs should not rely on inheritance or non-inheritance of
       file status flags and always explicitly set all required flags  on  the
       socket returned from accept().

We call fcntl after calling bind and listen. Then we also call fcntl
for each accept'ed connection to set O_NONBLOCK:
				flags = fcntl(e, F_GETFL);
				fcntl(e, F_SETFL, flags | O_NONBLOCK);

$ uname -a
Linux lab9p2 2.6.11.12 #3 Sat Sep 3 20:09:17 WEST 2005 i686 Intel(R)
Pentium(R) 4 CPU 2.26GHz GenuineIntel GNU/Linux
$

The code is at http://mega.ist.utl.pt/~facab/proj/
(files httpd.n.[ch] have the line numbers)
The line that's causing the trouble is line 377 in httpd.c. Commenting
that line fixes the problem (although we think that shouldn't be
necessary).

However, in my laptop (with a different kernel version) it works. So,
does this kernel version (2.6.11.12) has a bug with fcntl or are we
doing something wrong?


Thanks in advance,
Filipe Cabecinhas

P.S: Please CC me, because I'm not subscribed to this list.

Re: Possible problem in fcntl

[linux-os (Dick Johnson)]

On Tue, 13 Dec 2005, Filipe Cabecinhas wrote:

> Hi,
>
> We have written a little webserver for our CS course. But we have a
> problem with fcntl.
> We are using non-blocking sockets and per fcntl man page:
>       On Linux, the new socket returned by accept () does  not  inherit  file
>       status  flags such as O_NONBLOCK and O_ASYNC from the listening socket.
>       This behaviour differs from the canonical BSD  sockets  implementation.
>       Portable  programs should not rely on inheritance or non-inheritance of
>       file status flags and always explicitly set all required flags  on  the
>       socket returned from accept().
>

Okay already. What is it that it doesn't do that you expect it to do?

> We call fcntl after calling bind and listen. Then we also call fcntl
> for each accept'ed connection to set O_NONBLOCK:
> 				flags = fcntl(e, F_GETFL);
> 				fcntl(e, F_SETFL, flags | O_NONBLOCK);
>
> $ uname -a
> Linux lab9p2 2.6.11.12 #3 Sat Sep 3 20:09:17 WEST 2005 i686 Intel(R)
> Pentium(R) 4 CPU 2.26GHz GenuineIntel GNU/Linux
> $
>
> The code is at http://mega.ist.utl.pt/~facab/proj/
> (files httpd.n.[ch] have the line numbers)
> The line that's causing the trouble is line 377 in httpd.c. Commenting
> that line fixes the problem (although we think that shouldn't be
> necessary).
>

So what is it that the socket doesn't do, that you expect it
should do?

> However, in my laptop (with a different kernel version) it works. So,
> does this kernel version (2.6.11.12) has a bug with fcntl or are we
> doing something wrong?
>

What is it that you expect it to do? Networking exists at several
levels. You may have to use setsockopt() to set some socket parameters
for some kinds of sockets. The 'fact' that something worked in
some previous code does not mean that the code was correct.

> Thanks in advance,
> Filipe Cabecinhas
>
> P.S: Please CC me, because I'm not subscribed to this list.
> -

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.56 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Possible problem in fcntl

[Filipe Cabecinhas]

On 12/13/05, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:

> So what is it that the socket doesn't do, that you expect it
> should do?
>

When we call recv on that socket, it returns 0 and sets the string to
"" (as if the the client had done an orderly shutdown (which is not
true, since wget says connection refused).

We were expecting it to return -1 and set errno to EAGAIN (or to
return the number of bytes written and set the string to what it
received).

It works as expected if we don't have that (second) fcntl call. But,
as the accept manpage tells us, in linux the socket returned by accept
() does  not  inherit  file status  flags such as O_NONBLOCK, so we
think we should call it (to be sure it has that flag). And, even if it
isn't necessary, we can't tell why it's breaking (because it would
just be setting a flag (that is already set )).

Thanks in advance,
Filipe Cabecinhas

Re: Possible problem in fcntl

[linux-os (Dick Johnson)]

On Tue, 13 Dec 2005, Filipe Cabecinhas wrote:

> On 12/13/05, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
>
>> So what is it that the socket doesn't do, that you expect it
>> should do?
>>
>
> When we call recv on that socket, it returns 0 and sets the string to
> "" (as if the the client had done an orderly shutdown (which is not
> true, since wget says connection refused).
>

How do you know what wget did after the connection was refused?
Didn't it close its socket when returning to the shell?

> We were expecting it to return -1 and set errno to EAGAIN (or to
> return the number of bytes written and set the string to what it
> received).
>

But you said the connection was refused. Wget wouldn't have sent
anything.

> It works as expected if we don't have that (second) fcntl call. But,
> as the accept manpage tells us, in linux the socket returned by accept
> () does  not  inherit  file status  flags such as O_NONBLOCK, so we
> think we should call it (to be sure it has that flag). And, even if it
> isn't necessary, we can't tell why it's breaking (because it would
> just be setting a flag (that is already set )).
>

You can always display the results of fcntl(s, F_GETFL) after
changing it to see if it "works".

Did you use setsockopt() to set the socket to SO_BSDCOMPAT if you
are porting or copying BSD code?

> Thanks in advance,
> Filipe Cabecinhas
>

Also, since probably 90% of the Web-Pages accessed on the Internet
are served by Linux servers, it is highly unlikely that Linux is
doing something wrong in its socket code. FYI, there is a seperate
networking list........

Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.56 BogoMips).
Warning : 98.36% of all statistics are fiction.
.

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Possible problem in fcntl

[Filipe Cabecinhas]

> How do you know what wget did after the connection was refused?
> Didn't it close its socket when returning to the shell?

If we have the call to fcntl, the following happens:
Telnet: SYN
Server: SYN, ACK
T: ACK
S: FIN, ACK
T: FIN, ACK
S: ACK

There was no data exchanged. It just accepted the connection, and then
finished it.

Without the call to fcntl everything goes normally:
T: SYN
S: SYN, ACK
T: ACK
T: PSH, ACK (HTTP request)
S: ACK
S: PSH, ACK (HTTP header)
T: ACK
S: PSH, ACK (data)
T: ACK
S: FIN, ACK
T: ACK
T: FIN, ACK
S: ACK

Thanks in advance,

Filipe Cabecinhas