On Tue, May 17, 2022 at 01:19:38PM +0800, Geliang Tang wrote:
> Martin KaFai Lau <kafai@xxxxxx> 于2022年5月17日周二 09:32写道：
> >
> > On Fri, May 13, 2022 at 03:48:25PM -0700, Mat Martineau wrote:
> > [ ... ]
> >
> > > +/*
> > > + * Parse the token from the output of 'ip mptcp monitor':
> > > + *
> > > + * [ CREATED] token=3ca933d3 remid=0 locid=0 saddr4=127.0.0.1 ...
> > > + * [ CREATED] token=2ab57040 remid=0 locid=0 saddr4=127.0.0.1 ...
> > How stable is the string format ?
> >
> > If it happens to have some unrelated mptcp connection going on, will the test
> > break ?
>
> Hi Martin,
>
> Yes, it will break in that case. How can I fix this? Should I run the
> test in a special net namespace?
>
> 'ip mptcp monitor' can easily run in a special net namespace:
>
> ip -net ns1 mptcp monitor
>
> But I don't know how to run start_server() and connect_to_fd() in a
> special namespace. Could you please give me some suggestions about
> this?
You can take a look at the open_netns() usages under prog_tests/.
For example, tc_redirect.c.
I would also avoid string matching from "ip mptcp monitor" if possible
considering the command may not have support (test skip) and the
string format may change also.
One option, you can consider to directly trace some of the mptcp
functions by using bpf fentry/fexit prog to obtain the token and
save it in a global bpf variable.
Search 'SEC("fentry' or 'SEC("fexit' for some examples. Then
the iproute2 support testing and the test skip logic can go away.
Suggesting them here because the test will have better chance
to catch issue if the test is not skipped or failed because
of string format not match. I won't insist on not using
"ip mptcp monitor" though.
