You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For packet captures, the capture length is currently set to a size that cuts off almost all TCP header options. When analyzing traces it is very useful to be able to see SACK blocks. In older traces at least the first SACK block was still captured, however since many connections now have timestamps enabled SACKs are pushed further out in the header, and they are no longer captured at all.
It would be very beneficial to use a mechanism that does not truncate header options. I am aware that header length is dynamic, so maybe there is a way to sanitize traces after capturing while extending capture length to make sure that headers are always completely captured?
The text was updated successfully, but these errors were encountered:
For packet captures, the capture length is currently set to a size that cuts off almost all TCP header options. When analyzing traces it is very useful to be able to see SACK blocks. In older traces at least the first SACK block was still captured, however since many connections now have timestamps enabled SACKs are pushed further out in the header, and they are no longer captured at all.
It would be very beneficial to use a mechanism that does not truncate header options. I am aware that header length is dynamic, so maybe there is a way to sanitize traces after capturing while extending capture length to make sure that headers are always completely captured?
The text was updated successfully, but these errors were encountered: