Multipath connections removed after succesful probe

[sanjaybhat2004]

Hello,

Currently I am building an application which uses the multipath feature of the library. Similar to the example shown in picoquicdemo.c, I use the function picoquic_probe_new_path_ex to add a new path via passing the struct sockaddr of the IP address of the alternative interface, which works fine (i.e, provides a return value of 0). I also print out the value of the variable client_cnx -> nb_paths and the value of this variable is increased as well, as expected.

However, after the program ends, when I try to print out the data for each path (again, similar to picoquicdemo.c), I find the the variable client_cnx -> nb_paths has taken on the value of 1, and the client application does not use the multipath functionalities, and sends and receives everything on only the main path, path 0.

What is the reason causing this issue?

[huitema]

Please collect a log -- qlog would be nice. It is difficult to debug otherwise.

[sanjaybhat2004]

Thank you for this suggestion. I collected the log, and here are a few of my observations about client side:

• initially client sends the "path_new_connection" frames (over path 0) which seems to be informing about there existing more than 1 one path, which seems to be as expected.

• After this, it apparently sent a path challenge over path id 1. I use the word apparently here, because I had monitored the interface of path id 1 using wireshark, and it did not seem to have sent any QUIC/UDP packet to the server IP. (Also observing the server qlog file, this challenge packet does not seem to be have been received. )

• After many retries of the above, it decides to abandon the path, shown by following screenshot, which I guess explains why client_cnx -> nb_paths variable is decreased.
  

All this while, it seems like server did not send any packet over path with id 1, which I guess makes sense since the challenge itself did not reach it and it did not register the second path.

I have attached the client and server qlog files for reference in the below link:
https://drive.google.com/drive/folders/1DjLHjd7wy7gSeVYQHRIZnOg939ns7li5?usp=sharing

[huitema]

Diagnostic is simple: the packets sent on path 1 do not arrive to destination. In fact, they are not even sent. The most likely explanation is that port number value in the source address is wrong.

The socket loop tries to match the source port number in the source sockaddr to an outgoing socket, with a simple algorithm:

1. If the value is zero, it selects the default socket, unless the flag "use_extra_socket" is set, in which case it selects the last socket.

2. If the value is not zero, it looks for a socket bound to exactly the same port as the port number in the source address.

3. if the value is not zero and there is no matching socket, the packet is dropped.

Note that all port numbers in sockaddr structure are expected to be expressed in network order. For example, 443 will be expressed as "htons(443)".

[sanjaybhat2004]

Thank you very much for your assistance. Actually it was not exactly due to wrong port number in source address, but it was a similar thing, as I was passing server address itself as a pointer to struct *sockaddr_storage, rather than itself. It sneakily avoided being detected as an compile time type mismatch error due to the fact that they needed to type casted to struct * sockaddr to be passed to the function. Multipath now works as intended.
Thank you for your time again.