capture snaplen parameter -s not working

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

kuldip
1 ●1 ●2 ●2

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

cmaynard

11115 ●11 ●317 ●165 https://www.igt.com/

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 ( 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...

Chuckc ( 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 ( 2019-10-04 17:21:29 +0000 )edit

Thanks Graham. Missed the old date.

Chuckc ( 2019-10-04 21:26:26 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

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

Guy Harris
19890 ●3 ●659 ●207

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.