packetdrill %{ print tcpi_reordering }%

[Wang Jian]

Hi,

I want to use packetdrill to observe how TCP reodering works, so I write below packetdrill script, but I get this error.

If I remove %{ print tcpi_reordering }% , everything works fine.

Any ideas how to fix it?

 

$ sudo ./packetdrill -v ./reord1.pkt

socket syscall: 1527677512.902764

setsockopt syscall: 1527677512.902817

setsockopt syscall: 1527677512.902824

bind syscall: 1527677512.902833

listen syscall: 1527677512.902841

inbound injected packet:  0.000107 S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>

outbound sniffed packet:  0.000176 S. 529793165:529793165(0) ack 1 win 14600 <mss 1460,nop,nop,sackOK,nop,wscale 7>

inbound injected packet:  0.100356 . 1:1(0) ack 529793166 win 32792

accept syscall: 1527677513.003199

write syscall: 1527677513.003240

inbound injected packet:  0.200593 . 1:1(0) ack 529794166 win 32792

write syscall: 1527677513.103549

./reord1.pkt:17: expected getsockopt(SOL_TCP, 11) output of at least 192 bytes; got 104 bytes

Script is below:

0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3

+0  setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0

+0  setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0

+0  bind(3, ..., ...) = 0

+0  listen(3, 1) = 0

+0  < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>

+0  > S. 0:0(0) ack 1 <...>

+.1 < . 1:1(0) ack 1 win 32792

+0  accept(3, ..., ...) = 4

+0  write(4, ..., 1000) = 1000

+.1 < . 1:1(0) ack 1001 win 32792

+0  write(4, ..., 10000) = 10000

+.0 %{ print tcpi_reordering }%

+.1 < . 1:1(0) ack 1001 win 257 <sack 6001:7001,nop,nop>

+.0 < . 1:1(0) ack 1001 win 257 <sack 2001:3001 9001:10001,nop,nop>

+.0 %{ print tcpi_reordering }%

+5 < . 1:1(0) ack 10001 win 257

+.0 %{ print tcpi_reordering }%

 

[Wang Jian]

Seems related to my OS. I changed to a ubuntu 4.17 to run script and have no problem.

But if run it with a CentOS 7(3.10), then it will fail.

Don't know why..

[Neal Cardwell]

On Wed, May 30, 2018 at 10:07 AM Wang Jian <jianjia...@gmail.com> wrote:

> Seems related to my OS. I changed to a ubuntu 4.17 to run script and have
no problem.
> But if run it with a CentOS 7(3.10), then it will fail.
> Don't know why..

Thanks for the report!

Do you mind if I credit your name and email address in a Reported-by tag in
the commit description for the patch that fixes this? See:


https://www.kernel.org/doc/html/v4.16/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes

The clue as to the cause is in this error message:

./reord1.pkt:17: expected getsockopt(SOL_TCP, 11) output of at least 192
bytes; got 104 bytes

This is from get_data() in code.c:

https://github.com/google/packetdrill/blob/master/gtests/net/packetdrill/code.c

We recently pushed an update to packetdrill that knows about more recent
fields of tcp_info (192 bytes worth of fields). But some distributions have
kernels that are older. Here the OS only exports 104 bytes, which met
packetdrill's previous expectations, but does not meet the expectations of
the more recent packetdrill release.

In general, there is no easy way for packetdrill to tell how old the kernel
is in order to validate the amount of data returned by tcp_info. So my
proposed fix (attached) would be to just remove this size check from the
packetdrill tool. This will mean that fields not exported by the kernel
under test will be zero (get_data() in code.c uses calloc()).

I suppose we could make the packetdrill code fancier, and only define
python variables for the fields that were actually exported by the kernel.
We could teach packetdrill about tcp_info in terms of a table with {name,
offset, size, type}, or something like that. Then packetdrill could decide
to only emit Python definitions for fields where offset+size <
len_of_returned_tcp_info. But that seems like more work than is warranted
at this point. :-)

Let me know if anyone has any other suggestions.

thanks,
neal

[Wang Jian]

>> Do you mind if I credit your name and email address in a Reported-by tag in
>> the commit description for the patch that fixes this? See:

No, please go ahead.

Thanks for the quick fix!

[Neal Cardwell]

On Wed, May 30, 2018 at 8:39 PM Wang Jian <jianjia...@gmail.com> wrote:

>> Do you mind if I credit your name and email address in a Reported-by tag in
>> the commit description for the patch that fixes this? See:
No,  please go ahead.

Thanks for the quick fix!

Great! Thanks. I've merged the fix into the github repo:

  https://github.com/google/packetdrill/commit/fd03fda63c7ecbabfa04ec1b149b35ce1d2e9130

cheers,

neal