NetX packet pool broken when using RNDIS

[SDS-GaelB]

During intensive data streaming with RNDIS device class, our system crashes after a while.
A post mortem analysis shows that the list in the NetX packet pool is broken:

• according to nx_packet_pool_available field of the pool (NX_PACKET_POOL) there is only one packet allocated,
• according to the list, only one packet is available in the pool (the nx_packet_queue_next field is NULL in the first packet descriptor).

It seems that it is due to _ux_device_class_rndis_write which populate a FIFO of packets to by treated by _ux_device_class_rndis_bulkin_thread.
The FIFO management is protected by a mutex but just after adding a packet in that FIFO, _ux_device_class_rndis_write reset nx_packet_queue_next field of the packet (set to NULL).

It is possible that just after _ux_device_class_rndis_write released the mutex _ux_device_class_rndis_bulkin_thread processes the packet and releases it, then _ux_device_class_rndis_write continue its process and reset the nx_packet_queue_next field braking the list of the packet pool.

In our system _ux_device_class_rndis_bulkin_thread thread priority is greater (10) than the thread calling _ux_device_class_rndis_write (25).

Fix:
protect the reset of nx_packet_queue_next field with the mutex.

[fdesbiens]

Hi @SDS-GaelB.

Thank you for raising this issue. I will ask a member of the team to review the information you provided and to get back to you.

[yuxinzhou5]

I may be missing something here, but nx_packet_pool_available indicates the number of available packets in the pool. It looks like it is consistent with your observation that there is one packet in the pool.

[SDS-GaelB]

Hi @yuxinzhou5,

my description may be confusing, sorry.
nx_packet_pool_available indicates that almost all buffers are available (31/32 in our case) but the list contains only one buffer.

[LennSar]

I was facing the same problem but the issue is not in the packet pool list. At least not in my case. The issue is that the TCP sequence number gets lost due to a race condition. The sequence number is then updated which causes the TCP Header size to be subtracted from the prepend_ptr twice. This will then later cause an assertion to hit because prepend_ptr < start_ptr. This in our case caused the Thread to sleep and with that at least the communication part crashed.
PullRequest is allready out. I hope this fixes your problem too