| 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
| ||
|
Date: Tue, 17 Jun 2008 16:45:49 -0700 From: Ben Greear <greearb@...delatech.com> To: Travis Stratman <tstratman@...cinc.com> CC: netdev@...r.kernel.org Subject: Re: data received but not detected Travis Stratman wrote: > 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? Ahh, I see what you mean. I'm afraid I don't know anything about your NIC driver, and it would seem to be implicated. Thanks, Ben -- Ben Greear <greearb@...delatech.com> Candela Technologies Inc http://www.candelatech.com -- 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