Re: [PATCH mptcp-next 2/2] selftests: mptcp: convert iptables to nftables for mptcp_join.sh

[Matthieu Baerts <matttbe@kernel.org>]

Hi Hangbin,

On 07/09/2026 03:02, Hangbin Liu wrote:
> 
> Hi Matthieu,
> On Fri, Sep 04, 2026 at 06:40:02PM +0200, Matthieu Baerts wrote:
>>>
>>> Yes, if not in purpose, I feel flush the whole table is dangerous.
>>> Some rules may still in using in later testing.
>>
>> Indeed. But in our case, each subtest uses a dedicated netns. Plus only
>> some tests add Netfilter rules. At the end, it is clearer to delete a
>> specific rule, but I think that makes sense only if the nft_handle var
>> is set locally, and used a few lines below.
>>
>> If a global nft_handle var is used, that doesn't seem clear, and I think
>> it would be clearer/easier to:
>>
>> - either delete a specific rule (but I don't think that's supported)
>>
>> - get the handle from the test and use it to delete the rule
>>
>> - or flush the table.
>>
>> So up to you, but probably best to avoid using nft_handle as global var.
> 
> Thanks, endpoint_tests is the only test that could delete iptables rules.
> I use the nft_handle mainly because the iptables also delete rules with
> specific match (iptables -D OUTPUT -s .. -p tcp -j REJECT) other than flush
> the table directly.
> 
> endpoint_tests
>   - reset_with_tcp_filter
>     - iptables -D
>     - iptables -I
>     - iptables -D
>   - reset_with_events
>     - iptables -I
>     - iptables -D
>   - reset_with_tcp_filter
>     - iptables -D
> 
> While from the logic it should be safe to flush the tables. I can avoid the
> nft_handle in v4 (after v3 review).

Just to be sure it is clear: nft_handle can be used, just better to
avoid using it globally I think. An alternative could be to pass a local
nft_handle to reset_with_tcp_filter and set it there, but in bash,
that's not very clear either.

> Just one question, why we use
> iptables -I here? Is there any intend? If not I will use "add" instead of
> "insert" in nft rules.

I don't remember. I would say probably best not to change the behaviour
during the transition. We could add a commit switching back to "add",
but if that doesn't change anything, probably easier for the reviewers
to keep "insert" (or add an explicit message in the commit message
explaining why it is better to change).

>>> However, I cannot perform a reset on the b4 branch, and git rebase also failed.
>>> These steps have blocked me a little. I have to manually recreate the b4 branch,
>>> or perhaps avoid using b4 when working on mptcp changes.
>>
>> You need to use `|git rebase --onto` instead, e.g.
>>
>>   git fetch origin  # adapt here and below if needed
> 
> For export branch, I think git fetch is not enough? I have to reset
> to latest net/net-next merge commit and pull on that.

I'm not sure to understand. 'git fetch' with the right remote should get
the latest <remote>/export branch ...

>>   git rebase --onto origin/export "$(b4 prep --show-info base-commit)"

... then this command will use this new ref. Why do you need to reset
net/net-next merge commit?

> Yes, it works! New git usage learned :)
> 
>>
>> Can you check if it works for you, please? (so I can update the wiki
>> page if needed)
>>
>> The alternative is to use `for-review`, with a continuous history, see:
>>
>>   https://github.com/multipath-tcp/mptcp_net-next/wiki/Git-Branches
> 
> I will try this tree next time

Up to you, but "export" is good as well, and required when using "git
blame".

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.