TCPDump: display MP_TCPRST info

[matttbe]

Description

For the moment, tcpdump displays unknown when there is an MP_TCPRST:

Flags [R.], seq 1, ack 1339, win 34710, options [nop,nop,TS val 1101661606 ecr 2665685440,mptcp unknown], length 0

Solution

Could be good to display the reason as mentioned in the RFC

The "T" flag is used by the sender to indicate whether the error condition that is reported is Transient ("T" bit set to 1) or Permanent ("T" bit set to 0). If the error condition is considered to be Transient by the sender of the RST segment, the recipient of this segment MAY try to re-establish a subflow for this connection over the failed path. The time at which a receiver may try to re‑establish this subflow is implementation specific but SHOULD take into account the properties of the failure as defined by the provided reason code. If the error condition is considered to be Permanent, the receiver of the RST segment SHOULD NOT try to re‑establish a subflow for this connection over this path. The "U", "V", and "W" flags are not defined by this specification and are reserved for future use. An implementation of this specification MUST set these flags to 0, and a receiver MUST ignore them.

"Reason" is an 8-bit field that indicates the reason code for the termination of the subflow. The following codes are defined in this document:

• Unspecified error (code 0x00). This is the default error; it implies that the subflow is no longer available. The presence of this option shows that the RST was generated by an MPTCP-aware device.
• MPTCP-specific error (code 0x01). An error has been detected in the processing of MPTCP options. This is the usual reason code to return in the cases where a RST is being sent to close a subflow because of an invalid response.
• Lack of resources (code 0x02). This code indicates that the sending host does not have enough resources to support the terminated subflow.
• Administratively prohibited (code 0x03). This code indicates that the requested subflow is prohibited by the policies of the sending host.
• Too much outstanding data (code 0x04). This code indicates that there is an excessive amount of data that needs to be transmitted over the terminated subflow while having already been acknowledged over one or more other subflows. This may occur if a path has been unavailable for a short period and it is more efficient to reset and start again than it is to retransmit the queued data.
• Unacceptable performance (code 0x05). This code indicates that the performance of this subflow was too low compared to the other subflows of this Multipath TCP connection.
• Middlebox interference (code 0x06). Middlebox interference has been detected over this subflow, making MPTCP signaling invalid. For example, this may be sent if the checksum does not validate.

Considered alternatives

Note that Wireshark and ptcpdump displays the info correctly.

Additional context

No response

[dcaratti]

hi @matttbe, I can pick this up! _ BTW, I remember support for MP_RST reason though was present, bundled in the commit for #189 _ but maybe I can check this easily with scapy (hoping that scapy has support for injecting MPTCP options :) )

[matttbe]

Hi @dcaratti

Thank you for your reply! I forgot about what you did almost 4 years ago.

I just checked: the commit you sent is in master, but not in any stable release... See the last one: https://github.com/the-tcpdump-group/tcpdump/blob/tcpdump-4.99.5/print-mptcp.c → MPTCP_SUB_TCPRST is not declared!

So when we execute the packet trace from the test with the latest version, we get:

16:27:19.175792 IP 192.0.2.1.55739 > 192.168.76.28.8080: Flags [R.], seq 1, ack 2176696966, win 256, options [mptcp 4 unknown], length 0
16:27:19.175964 IP 192.0.2.1.55739 > 192.168.76.28.8080: Flags [R.], seq 0, ack 1, win 256, options [mptcp 4 unknown], length 0

but maybe I can check this easily with scapy (hoping that scapy has support for injecting MPTCP options :) )

Or simply use packetdrill with run_all.py -c <path>, e.g.

$ run_all.py -lv -c . mptcp/mp_join/mp_join_server_bad_token.pkt
$ editcap -r mptcp/mp_join/mp_join_server_bad_token_ipv4.pcap mptcp/mp_join/mp_join_server_bad_token_ipv4_extract_rst.pcap 3

mp_join_server_bad_token_ipv4.pcap.gz
mp_join_server_bad_token_ipv4_extract_rst.pcap.gz

Should we close this ticket, or first check with the TCPDump team if it is possible to backport that to stable (if they don't plan to do a major release anytime soon)?

[matttbe]

(and it looks like scapy still doesn't support MPTCP despite this initial work that had been done a few years ago: secdev/scapy#3334)