Re: What does "error handling packet: bad outbound TCP options" mean?

138 views
Skip to first unread message

Neal Cardwell

unread,
Oct 16, 2015, 8:37:03 AM10/16/15
to Dennis Li, packetdrill
On Thu, Oct 15, 2015 at 10:50 PM, Dennis Li <denni...@gmail.com> wrote:
> Hi all,
>
> I just tried to install packetdrill in CentOS 7, which kernel version is
> 3.10.0-229.14.1.el7.x86_64.
> After successfully compling the tool, I picked up
> <packetdrill>/tests/linux/connect/http-get-nonblocking-ts.pkt as my first
> try.
> I setup a server on one host by "./packetdrill --wire_server", then
> switch to another machine to execute "./packetdrill --wire_client
> --wire_server_ip=<server_ip>
> ./tests/linux/connect/http-get-nonblocking-ts.pkt".
> Then I got this error on both client and server side:
> ./tests/linux/connect/http-get-nonblocking-ts.pkt:11: error handling
> packet: bad outbound TCP options
> script packet: 0.100000 S 0:0(0) <mss 1460,sackOK,TS val 100 ecr
> 0,nop,wscale 6>
> actual packet: 0.100429 S 0:0(0) win 14600 <mss 1460,sackOK,TS val 100
> ecr 0,nop,wscale 7>
>
> What does that mean? Why actual packet is different with script packet?
> Does script continues executing to the end? Does the error represent this
> test fail?

That means that the script expected the TCP options on the output
packet to look like the "script packet" line, and the actual TCP
options the network stack sent looked like the "actual packet" line.
So the test failed, and stopped at that line.

In this case the only difference I see is that the script expected
"wscale 6", but the actual option was "wscale 7".

In Linux the value of wscale tends to be a function of the max value
from the net.ipv4.tcp_rmem sysctl. So different systems will see
different behavior, depending on their configuration (and also
depending on the kernel version). So you may want to adjust the test
for your system.

Hope that helps,
neal

Dennis Li

unread,
Oct 19, 2015, 2:07:01 AM10/19/15
to packetdrill, denni...@gmail.com
Hi Neal,

    Thanks for your information, and thanks for the great tool.
    I tried to modify the script, replace wscale's value from 6 to 7, and case works great.
    I'll try to modify the wscale's value in system later.

regards,
Dennis


Neal Cardwell於 2015年10月16日星期五 UTC+8下午8時37分03秒寫道:

Dennis Li

unread,
Oct 19, 2015, 3:54:28 AM10/19/15
to packetdrill, denni...@gmail.com
Hi Neal,

    I have a problem and I think it might be related to environment like this case.

    In fast_retransmit case, the script writes 4000 bytes by write system call at line 25, and line 26 expects 4000 bytes data would be push out from TCP stack.
    In my environment, the script shows such error:    
    ./tests/linux/fast_retransmit/fr-4pkt-sack-linux.pkt:25: error handling packet: live packet field ipv4_total_length: expected: 4040 (0xfc8) vs actual: 1040 (0x410)
    script packet:  0.201223 P. 1001:5001(4000) ack 1
    actual packet:  0.201104 . 1001:2001(1000) ack 1 win 115

    I guess you have a NIC can do TCP offload work for you, is that correct? Or do I miss something?
    
    
regards,
Dennis
 
Dennis Li於 2015年10月19日星期一 UTC+8下午2時07分01秒寫道:

Neal Cardwell

unread,
Oct 19, 2015, 8:25:16 AM10/19/15
to Dennis Li, packetdrill
On Mon, Oct 19, 2015 at 3:54 AM, Dennis Li <denni...@gmail.com> wrote:
Hi Neal,

    I have a problem and I think it might be related to environment like this case.

    In fast_retransmit case, the script writes 4000 bytes by write system call at line 25, and line 26 expects 4000 bytes data would be push out from TCP stack.
    In my environment, the script shows such error:    
    ./tests/linux/fast_retransmit/fr-4pkt-sack-linux.pkt:25: error handling packet: live packet field ipv4_total_length: expected: 4040 (0xfc8) vs actual: 1040 (0x410)
    script packet:  0.201223 P. 1001:5001(4000) ack 1
    actual packet:  0.201104 . 1001:2001(1000) ack 1 win 115

    I guess you have a NIC can do TCP offload work for you, is that correct? Or do I miss something?

Yes, this test case is assuming the network device is performing GSO or TSO segmentation offload.

neal

Reply all
Reply to author
Forward
0 new messages