RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1860216 - tcpdump can not parse mptcp options [NEEDINFO]
Summary: tcpdump can not parse mptcp options
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: tcpdump
Version: 8.3
Hardware: Unspecified
OS: Unspecified
high
low
Target Milestone: rc
: 8.0
Assignee: Michal Ruprich
QA Contact: Ondrej Mejzlik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-24 02:30 UTC by xmu
Modified: 2021-11-10 00:30 UTC (History)
4 users (show)

Fixed In Version: tcpdump-4.9.3-2.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-11-09 18:38:26 UTC
Type: Bug
Target Upstream Version:
Embargoed:
jorton: needinfo?

Attachments (Terms of Use)
Patch (5.57 KB, patch)
2020-10-02 12:26 UTC, Michal Ruprich 		no flags Details | Diff
Sample mptcp v1 capture file (22.06 KB, application/vnd.tcpdump.pcap)
2020-10-02 12:27 UTC, Michal Ruprich 		no flags Details
sample capture for MPC, MPJ, ADD_ADDR v1 (1.56 KB, application/vnd.tcpdump.pcap)
2021-03-08 11:29 UTC, Paolo Abeni 		no flags Details
Patch v2 (13.41 KB, patch)
2021-03-18 13:31 UTC, Michal Ruprich 		no flags Details | Diff
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:4236 0 None None None 2021-11-09 18:38:29 UTC

Description xmu 2020-07-24 02:30:33 UTC 
Description of problem:
setup mptcp connetion,  tcpdump shows "mptcp capable[bad opt]"


Version-Release number of selected component (if applicable):
tcpdump-4.9.3-1.el8.x86_64

How reproducible:
always

Steps to Reproduce:
1.install `kernel-debuginfo`, `kernel-debuginfo-common`, `systemtap`, `systemtap-devel`, `kernel-devel`, `nmap-ncat` packages 
2.on client and server: sysctl -q net.mptcp.enabled=1
3.  Create the `mptcp.stap` file with the following content:

#! /usr/bin/env stap

%{
#include <linux/in.h>
#include <linux/ip.h>
%}

/* according to [1], RSI contains 'type' and RDX
 * contains 'protocol'.
 * [1] https://github.com/torvalds/linux/blob/master/arch/x86/entry/entry_64.S#L79
 */

function mptcpify () %{
    if (CONTEXT->kregs->si == SOCK_STREAM &&
        (CONTEXT->kregs->dx == IPPROTO_TCP ||
         CONTEXT->kregs->dx == 0)) {
                CONTEXT->kregs->dx = IPPROTO_MPTCP;
                STAP_RETVALUE = 1;
    } else {
           STAP_RETVALUE = 0;
    }
%}

probe kernel.function("__sys_socket") {
        if (mptcpify() == 1) {
                printf("command %16s mptcpified\n", execname());
        }
}
4. on client and server:  stap -vg mptcp.stap
5. on any host: tcpdump -i any port 4321
6. on server: ncat -4 -l 4321 
7. on client: 
ncat -4 192.0.2.1 4321
Hello world 1
Hello world 2
Hello world 3
Hello world 4
Hello world 5
<ctrl+d>


Actual results:
dhcp-12-174.nay.redhat.com.rwhois: Flags [S], seq 3595648, win 29200, options [mss 1460,sackOK,TS val 393061247 ecr 0,nop,wscale 7,mptcp capable[bad opt]>
10:49:30.695082 IP dhcp-12-174.nay.redhat.com.rwhois > dhcp-12-246.nay.redhat.com.35380: Flags [S.], seq 937153818, ack 3595649, win 28960, options [mss 1460,sackOK,TS val 3100882841 ecr 393061247,nop,wscale 7,mptcp capable Unknown Version (1)], length 0
10:49:30.695149 IP dhcp-12-246.nay.redhat.com.35380 > dhcp-12-174.nay.redhat.com.rwhois: Flags [.], ack 1, win 229, options [nop,nop,TS val 393061248 ecr 3100882841,mptcp capable Unknown Version (1)], length 0
10:49:41.661588 IP dhcp-12-246.nay.redhat.com.35380 > dhcp-12-174.nay.redhat.com.rwhois: Flags [P.], seq 1:7, ack 1, win 229, options [nop,nop,TS val 393072215 ecr 3100882841,mptcp capable[bad opt]>
10:49:41.662004 IP dhcp-12-174.nay.redhat.com.rwhois > dhcp-12-246.nay.redhat.com.35380: Flags [.], ack 7, win 227, options [nop,nop,TS val 3100893809 ecr 393072215,mptcp dss ack 18002013714408992926], length 0
10:56:12.993987 IP dhcp-12-174.nay.redhat.com.rwhois > 


Expected results:
client Out IP 192.0.2.2.60802 > 192.0.2.1.4321: Flags [S], seq 3420255622, win 29200, options [mss 1460,sackOK,TS val 411 4539945 ecr 0,nop,wscale 7,mptcp capable v1], length 0       
client In  IP 192.0.2.1.4321 > 192.0.2.2.60802: Flags [S.], seq 2619315374, ack 3420255623, win 28960, options [mss 1460 sackOK,TS val 3241564233 ecr 4114539945,nop,wscale 7,mptcp capable v1 {0xb6f8dc721aee7f64}], length 0                    
client Out IP 192.0.2.2.60802 > 192.0.2.1.4321: Flags [.], ack 1, win 229, options [nop,nop,TS val 4114539945 ecr 3241564 233,mptcp capable v1 {0xcc58d5d632a32d13,0xb6f8dc721aee7f64}], length 0
client Out IP 192.0.2.2.60802 > 192.0.2.1.4321: Flags [P.], seq 1:17, ack 1, win 229, options [nop,nop,TS val 4114539945 ecr 3241564233,mptcp capable v1 {0xcc58d5d632a32d13,0xb6f8dc721aee7f64},nop,nop], length 16
client In  IP 192.0.2.1.4321 > 192.0.2.2.60802: Flags [.], ack 17, win 227, options [nop,nop,TS val 3241564233 ecr 411459945,mptcp dss ack 1105509586894558345], length 0
client Out IP 192.0.2.2.60802 > 192.0.2.1.4321: Flags [P.], seq 17:33, ack 1, win 229, options [nop,nop,TS val 4114540939 ecr 3241564233,mptcp dss ack 13265586846326199424 seq 105509586894558345 subseq 17 len 16,nop,nop], length 16


Additional info:
Comment 1 Michal Ruprich 2020-08-21 06:25:32 UTC 
Hi Xiumei,

is there a customer that needs this? This would help evaluate whether this is worth fixing. After looking at the changes, this is not a simple fix. The new capabilities are fixed in 2 commits from upsteam:

https://github.com/the-tcpdump-group/tcpdump/commit/4738c1fa73227fcc0fc4de757572807cadec2b01
https://github.com/the-tcpdump-group/tcpdump/commit/fdd065fb0f505ca6d0396b144878581d56983018

But in the meantime, a lot has changed elsewhere, for instance the ND_PRINT usage has changed, that would require both of these commits to be rewritten in the old way. It would also require to change all the commits for all tests for mptcp due to this commit:

https://github.com/the-tcpdump-group/tcpdump/commit/018b2b8c96259348efccbcf14d2480f07892353f

This would be better fixed when a new version comes out that includes these changes and we could rebase the package. So if you have a customer case that requires this, please attach it here.

Thanks and regards,
Michal
Comment 2 xmu 2020-08-21 14:24:41 UTC 
(In reply to Michal Ruprich 🐧 from comment #1)
> Hi Xiumei,
> 
> is there a customer that needs this? This would help evaluate whether this
> is worth fixing. After looking at the changes, this is not a simple fix. The
> new capabilities are fixed in 2 commits from upsteam:
> 
> https://github.com/the-tcpdump-group/tcpdump/commit/
> 4738c1fa73227fcc0fc4de757572807cadec2b01
> https://github.com/the-tcpdump-group/tcpdump/commit/
> fdd065fb0f505ca6d0396b144878581d56983018
> 
> But in the meantime, a lot has changed elsewhere, for instance the ND_PRINT
> usage has changed, that would require both of these commits to be rewritten
> in the old way. It would also require to change all the commits for all
> tests for mptcp due to this commit:
> 
> https://github.com/the-tcpdump-group/tcpdump/commit/
> 018b2b8c96259348efccbcf14d2480f07892353f
> 
> This would be better fixed when a new version comes out that includes these
> changes and we could rebase the package. So if you have a customer case that
> requires this, please attach it here.
> 
> Thanks and regards,
> Michal

I agree with you. It's from qe, not the requirement of customer.
Comment 5 Michal Ruprich 2020-10-02 12:26:52 UTC 
Created attachment 1718438 [details]
Patch
Comment 6 Michal Ruprich 2020-10-02 12:27:50 UTC 
Created attachment 1718440 [details]
Sample mptcp v1 capture file
Comment 10 Paolo Abeni 2021-03-08 11:29:35 UTC 
Created attachment 1761569 [details]
sample capture for MPC, MPJ, ADD_ADDR v1

this sample comprises hopefully all the v1-related MPTCP packets:

- MPC handshake v1, pkts 1-4
- ADD_ADDR pkt 5
- ADD_ADDR echo pkt 7
- MPJ handshake, pkts 6,8,9,10
Comment 11 Michal Ruprich 2021-03-18 13:28:09 UTC 
Hi Paolo,

I've built a test package of tcpdump with the all important mptcp commits from upstream(hopefully I did not miss some), but even from the samples, I am not sure it is complete. Do you have a change to try it out?

https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=35536879

I don't see any info about ADD_ADDR but I might be reading it wrong. Please, let me know if the output is ok like this.

Michal
Comment 12 Michal Ruprich 2021-03-18 13:31:01 UTC 
Created attachment 1764395 [details]
Patch v2
Comment 13 Michal Ruprich 2021-03-19 13:48:52 UTC 
Paolo noticed one field from the options of mptcp missing in the output of the upstream version. I created a PR with a fix. Hopefully the upstream will take a look soon:
https://github.com/the-tcpdump-group/tcpdump/pull/914
Comment 14 Michal Ruprich 2021-03-22 13:48:25 UTC 
Cancelling the needinfo, question discussed on IRC.
Comment 15 Michal Ruprich 2021-04-12 08:30:21 UTC 
PR from comment #13 merged by upstream. Paolo, my merged PR conflicts with your PR: https://github.com/the-tcpdump-group/tcpdump/pull/915/commits/0a43a97cb3d2310bbeb39b17f5867b98122365da - the added Length value needs to be added to your commit. Can you please take a look at it and rebase it to the latest master? This will speed things up.

Thanks.

Michal
Comment 16 Paolo Abeni 2021-04-12 14:04:47 UTC 
(In reply to Michal Ruprich from comment #15)
> PR from comment #13 merged by upstream. Paolo, my merged PR conflicts with
> your PR:
> https://github.com/the-tcpdump-group/tcpdump/pull/915/commits/
> 0a43a97cb3d2310bbeb39b17f5867b98122365da - the added Length value needs to
> be added to your commit. Can you please take a look at it and rebase it to
> the latest master? This will speed things up.

I just updated PR#915. Let's see how things will go.

Thanks!

Paolo
Comment 35 errata-xmlrpc 2021-11-09 18:38:26 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: tcpdump security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:4236
Note You need to log in before you can comment on or make changes to this bug.