Re: [tipc-discussion] Link level packet loss

[Ying X. <yin...@wi...>]

Erik Hugne wrote:
> I think i'm closing in on the problem.
> During retransmission of fragments, if we have not yet allocated a 
> buffer (that's only done when FIRST_FRAGMENT is received), and receive 
> a fragment that is not FIRST_FRAGMENT.
> We will fall through the tipc_link_recv_fragment function, free the 
> fragment buffer and return zero.
> http://lxr.free-electrons.com/source/net/tipc/link.c#L2506
>

Sorry, actually i possibly don't understand your descried issue.
 From my understanding, the sequence number of FIRST_FRAGMENT packet is 
always less than FRAGMENT packet. If FRAGMENT packets are incoming 
earlier than the FIRST_FRAGMENT packet, we have to put them into 
deferred queue. So in this case, i cannot understand why 
tipc_link_recv_fragment() will be called, and fragment buffer will be freed.

Please give some details.

Thanks,
Ying

> tipc_recv_msg (in the link layer) will then continue, believing that 
> the fragment have been put in a reassembly queue, and the (now lost) 
> message will be acked.
>
> What i have yet to discover is _why_ this occurs, packets should 
> always be put on the deferred queue if they are not 'next_in_no', and 
> the deferred packets should only be replayed back on the receive loop 
> when we have all previous packets..
>
> //E
>
>