On 7/9/26 6:51 AM, Cosmin Ratiu wrote:

So the test relies on TCP retransmissions to catch the encrypted echo
from the responder on the UDP socket. The timeline seems to be:
1. data_send_off disables PSP on its end.
2. data_send_off opens a UDP socket and binds it to port 1000.
3. data_send_off sends "data echo" to psp_responder on the control
connection.
4. psp_responder send "echo" on the now sabotaged PSP connection.
5. psp_responder acks the "echo request" on the control connection.
6. data_send_off receives the ack.
7. data_send_off tries to receive "echo" on the PSP connection but
expect_fail==True so stops after 100 ms.
8. data_send_off reenables PSP on its end.
9. data_send_off waits for "echo" to be received now that connectivity
is back for up to 350 ms.
10. data_send_off asserts that something is in the UDP socket queue.

So UDP packets could be enqueued if PSP packets are received between
steps 4-8.

It seems disabling PSP steering rules isn't as atomic as we thought,
and sometimes the first echo is discarded by steering. The default TCP
retransmission timeout is 200 ms so there are no retransmissions in the
~150-170 ms between steps 4-8.

With a slightly modified test that directly requests data echoes, the
test becomes more reliable. Additionally, you need the UDP_NO_CHECK6_RX
(102) socket options for the ipv6 version, otherwise zero-checksum UDP
packets are discarded by the stack. I vaguely remember doing this
change for this test in Jakub's repo a few years ago.

Anyway, here's the diff that makes both tests reliably pass:

Thanks for taking a look. I suppose the timing and 0 udp checksum 
explain why I wasn't seeing any packets. I was concerned that we may 
have entered a state where we were losing some udp packets permanently, 
as opposed to just some transient drops at the time the device is 
reconfigured, but it sounds like that isn't the case. So, I think this 
works ok then.