netdev - Re: data received but not detected

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1213743506.5771.220.camel@localhost.localdomain>
Date:	Tue, 17 Jun 2008 17:58:26 -0500
From:	Travis Stratman <tstratman@...cinc.com>
To:	Ben Greear <greearb@...delatech.com>
Cc:	netdev@...r.kernel.org
Subject: Re: data received but not detected

On Tue, 2008-06-17 at 15:31 -0700, Ben Greear wrote:
> Travis Stratman wrote:
> > I am working on an application that uses a fairly simple UDP protocol to
> > send data between two embedded devices. I'm noticing an issue with an
> > initial test that was written where datagrams are received but not seen
> > by the recvfrom() call until more data arrives after it. As of right now
> > the test case does not implement any type of lost packet protection or
> > other flow control, which is what makes the issue so noticeable.
> 
> UDP packets can be lost anywhere..including in the receive buffer
> after it has been received by the NIC.
> 
> You probably just need to write your code smarter to use non-blocking
> IO and deal with packet loss.

Thanks Ben.

I understand that there is no guarantee of anything with UDP, but it
seems to me that if there is a packet in the buffer (it shows up after
another packet comes in behind it) the system should know about it,
right?

The code will eventually deal with packet loss / retransmission (it is
actually a customer's application, not my own). Development was only
stopped at this point because this behavior was discovered. However, if
the final application behaves in the same way that things are going now,
the application would need to timeout on read, request retransmission,
receive the original packet (that was just stuck in the buffer
somewhere) and the retransmitted packet and decide which to toss every
couple of seconds. This is a whole lot more retransmissions than I would
expect to see on a cross-over cable, especially from receiving and
processing only two small packets at one pass.

If this is what's required I will relay that to the customer or
implement some type of workaround to force a poll or flush. However, if
there is possibly a bug or race condition that is not getting handled
properly it would be better to try and find it.

Thanks,
Travis

> 
> Thanks,
> Ben
> 

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