[LTP] network/stress/ltp_net_stress_ipsec_tcp: problems with IP Payload Compression (comp) transform protocol on VTI

[LTP] network/stress/ltp_net_stress_ipsec_tcp: problems with IP Payload Compression (comp) transform protocol on VTI

[Petr Vorel]

Hi Alexey,

I'm trying to debug problems with IP Payload Compression (comp) transform protocol on VTI.
I.e. tcp4_ipsec_vti03 and tcp6_ipsec_vti03 tests:
tcp4_ipsec_vti03 tcp_ipsec_vti.sh -p comp -m tunnel -s "100 1000 65535"
tcp6_ipsec_vti03 tcp_ipsec_vti.sh -6 -p comp -m tunnel -s "100 1000 65535"

netstress server gets killed after calling accept():

write(2, "netstress.c:659: \33[1;34mINFO: \33["..., 106) = 106
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 6
setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
write(2, "netstress.c:579: \33[1;34mINFO: \33["..., 75) = 75
bind(6, {sa_family=AF_INET6, sin6_port=htons(27102), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0
listen(6, 100)                    = 0
write(2, "netstress.c:595: \33[1;34mINFO: \33["..., 73) = 73
getpid()                          = 2127
accept(6,  <unfinished ...>
<... wait4 resumed> <unfinished ...>) = ?
+++ killed by SIGKILL +++
<... accept resumed> <unfinished ...>) = ?
+++ killed by SIGKILL +++

Any idea what can cause it? Tests tcp{4,6}_ipsec_vti02 running with esp protocol on VTI
work well.


Kind regards,
Petr

[LTP] network/stress/ltp_net_stress_ipsec_tcp: problems with IP Payload Compression (comp) transform protocol on VTI

[Petr Vorel]

> Hi Alexey,

> I'm trying to debug problems with IP Payload Compression (comp) transform protocol on VTI.
> I.e. tcp4_ipsec_vti03 and tcp6_ipsec_vti03 tests:
> tcp4_ipsec_vti03 tcp_ipsec_vti.sh -p comp -m tunnel -s "100 1000 65535"
> tcp6_ipsec_vti03 tcp_ipsec_vti.sh -6 -p comp -m tunnel -s "100 1000 65535"
Using netns, running on various distros (behaving the same).

Kind regards,
Petr

[LTP] network/stress/ltp_net_stress_ipsec_tcp: problems with IP Payload Compression (comp) transform protocol on VTI

[Alexey Kodanev]

On 11/10/2017 01:50 AM, Petr Vorel wrote:
> Hi Alexey,
>
> I'm trying to debug problems with IP Payload Compression (comp) transform protocol on VTI.
> I.e. tcp4_ipsec_vti03 and tcp6_ipsec_vti03 tests:
> tcp4_ipsec_vti03 tcp_ipsec_vti.sh -p comp -m tunnel -s "100 1000 65535"
> tcp6_ipsec_vti03 tcp_ipsec_vti.sh -6 -p comp -m tunnel -s "100 1000 65535"
>
> netstress server gets killed after calling accept():
>
> write(2, "netstress.c:659: \33[1;34mINFO: \33["..., 106) = 106
> socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 6
> setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> write(2, "netstress.c:579: \33[1;34mINFO: \33["..., 75) = 75
> bind(6, {sa_family=AF_INET6, sin6_port=htons(27102), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0
> listen(6, 100)                    = 0
> write(2, "netstress.c:595: \33[1;34mINFO: \33["..., 73) = 73
> getpid()                          = 2127
> accept(6,  <unfinished ...>
> <... wait4 resumed> <unfinished ...>) = ?
> +++ killed by SIGKILL +++
> <... accept resumed> <unfinished ...>) = ?
> +++ killed by SIGKILL +++
>
> Any idea what can cause it? Tests tcp{4,6}_ipsec_vti02 running with esp protocol on VTI
> work well.

Server killed by LTP timeout in this case, looks like there
is no incoming connections... I'll take a look.

Thanks,
Alexey

[LTP] network/stress/ltp_net_stress_ipsec_tcp: problems with IP Payload Compression (comp) transform protocol on VTI

[Petr Vorel]

Hi Alexey,

> > Any idea what can cause it? Tests tcp{4,6}_ipsec_vti02 running with esp protocol on VTI
> > work well.

> Server killed by LTP timeout in this case, looks like there
> is no incoming connections... I'll take a look.
If it helps you I can send you strace logs from both client and server.

Client cannot connect and it also fails with timeout:
safe_net.c:216: BROK: netstress.c:272: connect(5, 10.23.1.2:7108, 16) failed: ETIMEDOUT

I have no clue what prevents it connecting.

Kind regards,
Petr

[LTP] network/stress/ltp_net_stress_ipsec_tcp: problems with IP Payload Compression (comp) transform protocol on VTI

[Alexey Kodanev]

On 11/10/2017 10:31 PM, Petr Vorel wrote:
> Hi Alexey,
>
>>> Any idea what can cause it? Tests tcp{4,6}_ipsec_vti02 running with esp protocol on VTI
>>> work well.
>> Server killed by LTP timeout in this case, looks like there
>> is no incoming connections... I'll take a look.
> If it helps you I can send you strace logs from both client and server.
>
> Client cannot connect and it also fails with timeout:
> safe_net.c:216: BROK: netstress.c:272: connect(5, 10.23.1.2:7108, 16) failed: ETIMEDOUT

ipcomp actually works with vti, what doesn't work is the packets that
are not compressed/transformed (small packets skipped onthreshold)
and sent as is... and vti doesn't register any hooksfor handling them
(only ah, esp, comp) + xfrm stats XfrmInNoPols increased.

As a workaround we could add to ipcomp setup:
ROD sysctl net.ipv4.conf.$(tst_iface).disable_policy=1

Though I think the packet should be handled by vti device and the
proper hook registered... I'll try to prepare the patch for netdev
and we can continue discussion there about this problem.

Also we could change/add the test-case with a more real-life scenario
where the packet compressed, then encrypted.

Thanks,
Alexey

[LTP] network/stress/ltp_net_stress_ipsec_tcp: problems with IP Payload Compression (comp) transform protocol on VTI

[Petr Vorel]

Hi Alexey,

thanks for investigation!

> ipcomp actually works with vti, what doesn't work is the packets that
> are not compressed/transformed (small packets skipped onthreshold)
> and sent as is... and vti doesn't register any hooksfor handling them
> (only ah, esp, comp) + xfrm stats XfrmInNoPols increased.

> As a workaround we could add to ipcomp setup:
> ROD sysctl net.ipv4.conf.$(tst_iface).disable_policy=1

> Though I think the packet should be handled by vti device and the
> proper hook registered... I'll try to prepare the patch for netdev
> and we can continue discussion there about this problem.
Please, CC me.

> Also we could change/add the test-case with a more real-life scenario
> where the packet compressed, then encrypted.
Good idea! Are you planning to do it yourself?


Kind regards,
Petr