From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 754C0A04FD; Tue, 27 Dec 2022 15:26:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 16576410FC; Tue, 27 Dec 2022 15:26:28 +0100 (CET) Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by mails.dpdk.org (Postfix) with ESMTP id 7B69C40FDF for ; Tue, 27 Dec 2022 15:26:26 +0100 (CET) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-46d4840b51fso126057017b3.12 for ; Tue, 27 Dec 2022 06:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=iJfC5XjafK2X8McngFG3thIy3EMPxCDubu/SEEZkgXg=; b=gvYrBfMSMUrnwdzN6NSvB1geJBB6rjZKpqXMlfrwmHBV3/bFzMjopLkWiXWPEdN1W2 qbXg0TIy39y073i1EwErWKZ1YTrzkkHV55WOlTqJyTi0/bEupO880hyUIYXLvXtwl0w1 H+JmnqGjHLigtt8/KEfa09+OkAp/ff+JFbOX157z0hR5OALZ8R/OLk9yOT4UxzLbVh/g G3nZb37A+dlAumslAVoWWsq1Mz6pKoFfXmNlZaEIjdInK6AJ/18ZVp+Vn3nF39r2tj7E HsR+9UasMoyjJKJGz7sZHKXdvFP5zc9xFC2zFV8DMX716ofuU8+jSE0I5e6W3PLCACr+ G09g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=iJfC5XjafK2X8McngFG3thIy3EMPxCDubu/SEEZkgXg=; b=C+K5IgMRssasBvRDVj7PKDsC43wPruaJYj8z298+0E2w0WsJuDLLxjlgho4Le6ajlp JKJ0fuoxW5U4M5xZrIfoncEz4L4t9wIOTFOqWxlm9IerDc52B+WtLYzihteCwYaOJptT 00R49Z3a3c1HUVvD/7S0YnvBztpHEukqi+4ilA7vFOjnX7wUZwEyIou0BNNDw/k/g5I4 clZtm63M8Yr8JDhCq7Mb1Dpz7oFr/gNG8ILlAzP4N6FkbFufOsL3JLupK2/D4zZZvu9H JGz6rqqXCMePmtAKF3DeHy1l6hiWjs1BtFxCsvJIGMgtB7OjDwuUl/O+ZTQL7dQnVb9p 6rmg== X-Gm-Message-State: AFqh2kq4YHnVJpZO5bofBsnzqU1o3kf79PMPCYNzU1vSidGuXNxxpaTP Gq0zRLIK3sLyW9yPmnhZG7CIn6e/CdjQAUbIVjW6T5RouC0= X-Google-Smtp-Source: AMrXdXs4bP1CjV1y3TWB02HdAfzQpyyXkzI4aLGMTFJtV4M6huyobhjeRwizgjBTOshCYDx8/YR5tMVQNChXd8wcCVY= X-Received: by 2002:a0d:c385:0:b0:3df:21db:24f3 with SMTP id f127-20020a0dc385000000b003df21db24f3mr1939999ywd.25.1672151185605; Tue, 27 Dec 2022 06:26:25 -0800 (PST) MIME-Version: 1.0 From: Ben Magistro Date: Tue, 27 Dec 2022 09:26:14 -0500 Message-ID: Subject: dumpcap, interfaces, and promiscuous mode To: dev@dpdk.org, "Kaur, Arshdeep" , Stephen Hemminger Cc: ben.magistro@trinitycyber.com Content-Type: multipart/alternative; boundary="0000000000006dc6f705f0d009d2" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000006dc6f705f0d009d2 Content-Type: text/plain; charset="UTF-8" I'd like to start out by saying what I believed to be a simple change (a8dde09 ("app/dumpcap: allow help/version without primary process")) seems to have had more ripples than I anticipated. I'd like to just get a conversation going here before developing/submitting a patch. I think this will likely need to be at least two patches just to keep scope in check. With regard to interface selection, the most recent patch (7f3623a ("app/dumpcap: fix select interface")) breaks capturing on multiple interfaces. You can still specify the `-i` option as many times as you would like but only the last entry is used in the capture selection as each entry just overwrites the previous entry. I believe this needs to be flipped to an array or similar structure that can have entries appended to it as the arguments are processed. Selecting all interfaces with the asterisk seems to be unaffected but could also result in capturing traffic on unnecessary interfaces. With regard to promiscuous mode, there are two areas of concern here. The first is this flag is global and not per interface. I can envision a scenario where you might want to capture on one interface in promiscuous mode and on a second not in promiscuous mode. My first thought is to make this option follow the interface parameter then when parsing arguments so that it can be associated with a specific interface. The second is that if I run a capture in promiscuous mode and then stop the capture, it will also disable promiscuous mode. Generally I think I would agree with this behavior as it follows how a typical call to tcpdump should behave. The concern here though is that that the main process may have been started/running with promiscuous mode and stopping a capture would change that mode for the main process. My first thought here is to query the initial state and check that when quitting to know if it should disable promiscuous mode or not. This brings me to another aspect here and I don't think changing the behaviour of the `-p` flag is appropriate, but can see maybe adding an option to inherit the main process's promiscuous state(s) when starting. Happy to try and work on some of these changes but want to talk through the issues first so we can try to address all of them. Cheers, Ben Magistro --0000000000006dc6f705f0d009d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to start out by saying what I believed to be = a simple change (a8dde09 ("app/dumpcap: allow help/version without pri= mary process")) seems to have had more ripples than I anticipated.=C2= =A0 I'd like to just get a conversation going here before developing/su= bmitting a patch.=C2=A0 I think this will likely=C2=A0need to be at least t= wo patches just to keep scope in check.

With regard to i= nterface selection, the most recent patch (7f3623a ("app/dumpcap: fix = select interface")) breaks capturing on multiple=C2=A0interfaces.=C2= =A0 You can still specify the `-i` option as many times as you would like b= ut only the last entry is used in the capture selection as each entry just = overwrites the previous entry.=C2=A0 I believe this needs to be flipped to = an array or similar structure that can have entries appended=C2=A0to it as = the arguments are processed.=C2=A0 Selecting all interfaces with the asteri= sk seems to be unaffected but could also result in capturing traffic on unn= ecessary interfaces.

With regard to promiscuous mo= de, there are two areas of concern here.=C2=A0 The first is this flag is gl= obal and not per interface.=C2=A0 I can envision a scenario where you might= want to capture on one interface in promiscuous mode and on a second not i= n promiscuous mode.=C2=A0 My first thought is to make this option follow th= e interface parameter then when parsing arguments so that it can be associa= ted with a specific interface.=C2=A0 The second is that if I run a capture = in promiscuous mode and then stop the capture, it will also disable promisc= uous mode.=C2=A0 Generally I think I would agree with this behavior as it f= ollows how a typical call to tcpdump should behave.=C2=A0 The concern here = though is that that the main process may have been started/running with pro= miscuous mode and stopping a capture would change that mode for the main pr= ocess.=C2=A0 My first thought here is to query the initial state and check = that when quitting to know if it should disable promiscuous mode or not.=C2= =A0 This brings me to another aspect here and I don't think changing th= e behaviour of the `-p` flag is appropriate, but can see maybe adding an op= tion to inherit the main process's promiscuous state(s) when starting.<= /div>

Happy to try and work on some of these changes but= want to talk through the issues first so we can try to address all of them= .

Cheers,

Ben Magistro
--0000000000006dc6f705f0d009d2--