Ask Your Question
0

capture snaplen parameter -s not working

asked 2018-02-19 10:07:12 +0000

kuldip gravatar image

updated 2018-10-26 14:17:29 +0000

cmaynard gravatar image

Using 2.0.13 version and upon trigerring opentionl ike below

"tshark -s 80"

expected behavior is that WS will capture only 80 bytes of any given packet if it exceeds to it. But its not working. it shows "Packet size limited during capture" but doesnt reduce it. May i know the behviour or this feature

1> will it reduce only when it goes to file and doesnt show on capture?

 43   0.999316   10.129.1.0 -> 10.129.1.0   TCP 154 rimsl > 61107 [PSH, ACK] Seq=91 Ack=1404 Win=24582 Len=88 TSval=208099 TSecr=207213
44   0.999501   10.129.1.0 -> 10.129.1.0   TCP 154 rimsl > 61107 [PSH, ACK] Seq=179 Ack=1404 Win=24582 Len=88 TSval=208099 TSecr=207213
 45   0.999672   10.129.1.0 -> 10.129.1.0   TCP 154 rimsl > 61107 [PSH, ACK] Seq=267 Ack=1404 Win=24582 Len=88 TSval=208099 TSecr=207213
 46   0.999842   10.129.1.0 -> 10.129.1.0   TCP 154 rimsl > 61107 [PSH, ACK] Seq=355 Ack=1404 Win=24582 Len=88 TSval=208099 TSecr=207213
 47   1.000058   10.129.1.0 -> 10.129.1.0   TCP 66 61107 > rimsl [ACK] Seq=1404 Ack=443 Win=24583 Len=0 TSval=208100 TSecr=208099
 48   1.046312   10.129.1.0 -> 10.129.1.0   TCP 261 61721 > submitserver [PSH, ACK] Seq=1 Ack=1 Win=16519 Len=195 TSval=208146 TSecr=203152[Packet size limited during capture]
 49   1.046368   10.129.1.0 -> 10.129.1.0   TCP 66 submitserver > 61721 [ACK] Seq=1 Ack=196 Win=19855 Len=0 TSval=208146 TSecr=208146
 50   1.139877   10.129.1.0 -> 10.129.1.0   TCP 66 submitserver > 63491 [ACK] Seq=1 Ack=1 Win=19721 Len=0 TSval=208240 TSecr=203232
edit retag flag offensive close merge delete

Comments

Hello all,

I am also facing same issue. Has any one any idea on this issue?

T1000 gravatar imageT1000 ( 2018-12-25 12:26:15 +0000 )edit

Can you add output of tshark -v to the question?

Reports of libpcap causing issues with snaplen:

https://superuser.com/questions/71373...

bubbasnmp gravatar imagebubbasnmp ( 2019-10-04 15:04:46 +0000 )edit

Note that this is an old question, resurrected for some reason, the OP has long gone.

grahamb gravatar imagegrahamb ( 2019-10-04 17:21:29 +0000 )edit

Thanks Graham. Missed the old date.

bubbasnmp gravatar imagebubbasnmp ( 2019-10-04 21:26:26 +0000 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2019-10-04 16:54:27 +0000

Guy Harris gravatar image

Why do you think it's not reducing the captured length?

On Ethernet, the link-layer header is 14 bytes. The default IPv4 header, with no options, is 20 bytes, and the default TCP header, with no options, is 20 bytes. That's a total of 54 bytes, which is less than 80 bytes, so if you set the snapshot length to 80, you will see the entire TCP header unless there are a lot of options in either the IPv4 or TCP headers.

And the "Len=" in the output is coming from the on the wire length of the packets, not the captured length, so you can see "Len=" values bigger than the snapshot length.

edit flag offensive delete link more
0

answered 2019-10-04 14:19:29 +0000

updated 2019-10-04 14:37:09 +0000

Hi,

Is it only when capturing IKE?

I tested this using Version 3.0.5 (v3.0.5-0-g752a55954770) with the following command:

tshark -i 6 -ns 80 -w c:\users\xxxx\documents\test.pcap

and length was limited to 80 ok.

below are some examples:

Frame 9: 179 bytes on wire (1432 bits), 80 bytes captured (640 bits) on interface 0

Frame 13: 179 bytes on wire (1432 bits), 80 bytes captured (640 bits) on interface 0

Frame 20: 775 bytes on wire (6200 bits), 80 bytes captured (640 bits) on interface 0

Hope this is helpful,

John

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2018-02-19 10:07:12 +0000

Seen: 111 times

Last updated: Oct 04