Possible packet loss in vTaskRouter for some interfaces (csp_if_can especially)

When vTaskRouter accepts a new connection it calls csp_read in a loop
untill a timeout of 10 ticks happen. This could be done more elegantly, but
basically works as it should. 

The problem arises when the timeout occurs. vTaskRouter sends a call to
csp_conn_close in order to free the connection structure and continue to
the next frame. Which is fine under normal circumstances. When the next
packet arrives at the router, a new connection will just be allocated. The
problem exists when only a partial frame has been received and the router
calls csp_conn_close! This will drop all received data and reject the rest
of the fragmented parts of a packet. (This is only the case with Layer 2
drivers that use fragmentation like the csp_if_can)

Some drivers are unaffected such as the I2C, RS232 and spacelink where
whole messages are put directly into one csp_buffer in full before being
enqued to the router. In these situations there might however be a small
race condition in the router.

If a connection has JUST timed out, and the packet occurs before
csp_conn_close is called, the packet will be enqueued to the router, but
the router will drop the packet upon calling csp_conn_close. A debug
warning is inserted into csp_conn_close to catch this very situation, and
so far the condition has not been caught. However in principle this is an
issue.

Original issue reported on code.google.com by johan.de...@gmail.com on 1 May 2010 at 12:13

New380 / cubesat-space-protocol

Possible packet loss in vTaskRouter for some interfaces (csp_if_can especially) #8