Re: EAGAIN mystery on accept()

From: Sony Antony (sonyantony_at_hotmail.com)
Date: 08/28/04 

Date: Sat, 28 Aug 2004 00:06:22 -0400

Thanks a real lot Michael for reading my mail. My comments below

> > fd=31 ev=POLLRDNORM|POLLRDBAND rev=0
> > fd=32 ev=POLLRDNORM|POLLRDBAND rev=0
> > accept(17, 0xFCD01970, 0xFCD0198C, 1) Err#11 EAGAIN
>
> Has there been a fork()?

No.

 Could another copy of the process be
> accepting the connection so there are no pending connections by the
> time this process calls accept()?

No, lsof showed this to be the only process with a socket on this port
number.

 I was able to duplicate this
> error by setting up such a scenario.

Thank you very much again, for spending time on this. I know this must have
taken considerable time.

>
> Is it possible that file descriptor 17 isn't a listening socket at
> all, but rather a connected socket that has data ready for reading?

I dont think so. I could not reproduce the problem. And I started truss ing
the process only when the problem was reported. So I m not sure of the
"history" of the process.

> Is it possible that the code should be calling recv() or one of its
> friends instead of accept()?
>
> In an earlier post you said that tcpdump showed no incoming packets.
> What tcpdump options and arguments are you using?
I used "port 32778". I also used -i hme and -i 2_nd_interface
You were right. This machine had 2 interfaces. I did tcpdump on both of them

 Are you sure
> you're sniffing the right port?

I did a pfiles on the process in order to get the port number associated
with file descriptor 17. I used this port on tcpdump.

Could packets be arriving on an
> interface that you're not sniffing, in particular the loopback
> interface?

As some more background : The above poll()/accept() combination was
happening in a fast loop.
And the product involved was iona's Orbix2000.
What is most surprising is that the exact same trouble happened on 4 of our
orbix installation exactly at the same time.
I think something happened, that triggered an iona bug.
But from an OS point of view I could not define the nature of the bug, as
there is no reason for the accept() to give EAGAIN when the poll() has
reported RDNORM

Thanks again, for thinking about my problem

--sony

Relevant Pages

  • Re: FreeBSD Firewall/Router/Gateway questions.
    ... Ive been reading every single web page that I can find on PF and have ... Far too much reading ... ... Here i have a private network 192.168.1.0/24 on a second interface ... rdr pass inet proto tcp from any to 134.157.10.41 port = http -> ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Dropping syn+fin replies, but not really?
    ... tcpdump command on firewall: ... where <interface> was the publicly facing interface on the firewall. ... Results for port 80: ... This can be seen from the tcpdump output only showing the 'S' flag. ...
    (FreeBSD-Security)
  • Re: tcpdump
    ... tcpdump -i port 80 ... Also man tcpdump will help you further with your refining your snoop. ... I am connected to a box through command line interface, ...
    (Fedora)
  • Problem with Nat (port forwarding)
    ... PPPoE Configuration for DSL ... nat# cat /etc/ppp/ppp.conf ... In addition rule number 00301 triggers appropriately when a packet destined for port 5000 is inbound. ... TCPDUMP from destination machine ...
    (freebsd-questions)
  • Re: tcpdump
    ... Subject: tcpdump ... If I say tcpdump port 80 ... tcpdump dst port 22 and dst host 10.10.20.20 ... The loop is executed fine. ...
    (Fedora)