Aye Aye!! Just as what I fear. I was testing a mobile protocol using ping. When I switched networks, there are at least 6-7 packets loss. I wanted to reduce this loss and if possible, eliminate it. Buffering comes to my mind but I need to know which packet to send. My idea is to collect this in a backlog buffer at the point where the packets failed and resend these packets again. ICMP is the portion which I thought would have an indication of whether the transmission is successful or not. The packets are to be cleared from the buffer without any regard to whether they actually reached their destinations, because we can never know this at the IP level. If it fails, the packets will be queued again. I can make use of a simple tracking table to discard the packet after n number of tries. I have another question, how can I detect link carrier loss in 2.4 kernel? I tried the thingy for carrier but it doesn't seem to work, at least for eepro100 driver. regards, jonathan > -----Original Message----- > From: kernelnewbies-bounce@nl.linux.org > [mailto:kernelnewbies-bounce@nl.linux.org] On Behalf Of Seth Arnold > Sent: Thursday, June 13, 2002 3:19 AM > To: kernelnewbies@nl.linux.org > Subject: Re: detecting undelivered packets? > > > On Wed, Jun 12, 2002 at 11:35:39PM +0900, Jonathan Khoo wrote: > > Pardon me if this has been asked before, but how can I > detect packets > > that failed to reach their destination (eg. loss of wireless > > coverage)? > > > > Host-A Host-B > > | > > +-------> X > > > > I tried the DEST_UNREACH for icmp, but it doesn't seem to > be the right > > place. > > This is a difficult problem. > > I'm going to assume you are talking about IPv4 as it is > really the only protocol suite I know with any familiarity; > IPv6, IPX, Netatalk, Xerox, X.25, whatever else you might be > trying to deal with, you'll have to go elsewhere. :) > > The only _real_ way to know if a specific packet X did not > reach its destination B is if B knew the packet was coming, > and eventually sends a packet to A saying that the expected > packet X hasn't yet arrived. This packet might get lost. :) > > IP does not provide this. The UDP protocol layered above IP > does not provide this. The TCP protocol layered about IP does > not provide this, but it does give some heuristic information > that in practice seems to work pretty well. Assume A sends > packets X, Y and Z to B, in that order. Also assume that the > tcp session has been established. > > If Y arrives before X, B will send to A the last known good > sequence number. A is supposed to take that as a hint that > packet X has not yet arrived. Similar happens if X and Z > arrive fine, but Y does not. There is no indication sent back > if X and Y arrive fine and Z does not; B will send nothing > back, unless TCP keepalive is being used or the protocol > being used on top of TCP notices something funny going on and > sending back requests for more packets. Similar happens if > none of X, Y, Z arrive at B. > > I don't think there is any error-recovery on ICMP packets. > > In short -- I'm not sure if what you are trying to do is > possible. But I'd be willing to entertain conversation about > what you are trying to accomplish. :) > > -- > http://immunix.org/ > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
