[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1213985826.9245.169.camel@localhost.localdomain>
Date: Fri, 20 Jun 2008 13:17:06 -0500
From: Travis Stratman <tstratman@...cinc.com>
To: Evgeniy Polyakov <johnpol@....mipt.ru>
Cc: netdev@...r.kernel.org
Subject: Re: data received but not detected
On Fri, 2008-06-20 at 21:54 +0400, Evgeniy Polyakov wrote:
> >
> > I see the packets being sent in tcpdump from the sending application,
> > but they don't show up in the receiving side until something else comes
> > in behind them. For example if you look at the client and server trace
> > that I sent yesterday side by side you will see how the timings line up.
> > The same packets are shown in each trace. Data needs to be received by
> > the board to unlock it, sending does not seem to have any effect.
>
> So, packets are actually received by the host, since you see them in the
> receiving host tcpdump, but they do not reach socket queue. Please check
> UDP_MIB_INERRORS mib. You can do that via netstat -s.
Let me clarify this again... I see the packet being sent at the expected
time from the sender on the tcpdump. The packet does not show up in
tcpdump or in the application on the receive side. When some other data
is received by the receiver (i.e. ARP), the missing packet shows up in
the tcpdump and in the application at the same time. So the delay shows
up in the tcpdump as well. It seems to me that everything is pointing to
the packet being in the DMA buffer but the controller driver not knowing
anything about it.
netstat -s shows 0 UDP errors on both systems.
Thanks,
Travis
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists