SYN-bit's profile - activity

Oh, and after re-reading your question, you only want to see the SYN/ACK packets, so you can filter with tcp.completenes

Oh, and after re-reading your question, you only want to see the SYN/ACK packets, so you can filter with tcp.completenes

Apart from the (very flexible) Lua solution, you could also use the TCP completeness filter to achieve (kind of) the sam

You are correct in that it needs to be 1052 (so my 1024 above was not correct, although it could not hurt for the test).

A quick analysis shows that there is a huge amount of packet-loss. It does not seem to be MTU related, as the advertised

Thanks for adding the link to the pcapng file!

Could you please share the file in PCAP or PCAPNG format instead of text output, we love using Wireshark for a reason ;-

Have you seen the "Conversaton Coloring" functionality (FKA Temporary Coloring)? It let's you colorize TCP/UDP/IP/Eth co

On top of that, a scaling factor of -2 means the SYN and SYN/ACK were indeed seen, but no WS option was seen in the SYN

@johnthacker In this case the behavior is inconsistent. While I do agree on all other types of multiple IP layers, in th

@johntacker In this case the behavior is inconsistent. While I do agree on all other types of multiple IP layers, in thi

As the IP addresses are not overwritten by the inner included IP header, I can see benefit in not overwriting/filling th

That is the output of the file creation, tshark does not log file deletion to stdout, so most probably if you look on di

While the new column features are really great, they won't help in this case, as each packet will only have one IV, so t

Perfect, thanks!

Thank you for providing a capture file that shows the issue. I can confirm that I see the same behavior. I did a quick c

And a pcap file instead of a screenshot helps us help you even (a lot!) better :-)

And a pcap file instead of a screenshot helps us help you even (a lot!) better :-)

Having trouble saving Office files to the network, works but is slow I ran a wireshark capture, this is the output. I am

Are yu by any chance using a VPN? That would make the ping traffic encapsulated (and encrypted) so you would not be able

I'm sorry you got this feedback, as it is not a proper analysis and they are sending you in the wrong direction. I'm n

@hugo.vanderkooij Good to know about Citrix sending small segments, did not know that... As for the window size not dro

I seems both the telecom operator as well as the Palo Alto administrator are right, the problem does not lie in those do

Often when people analyze TCP traffic, a capture is made near/on the client and another one near/on the server. So I ass

In your provided captures there is not a real problem. One TCP segment did not get an ACK in time, so the 200ms RTO time

There is a TCP option called "Timestamps" which are indeed extra bytes in the TCP header. These are generated by the end

Glad my answer helped you in solving your issue. I reopened the question and selected my answer as the one that answere

The TCP dissector usually works just fine without the payload, as long as you have the complete TCP header, which you sh

Easiest way I think is to extract the epoch timestamps from the first capture and then use them with editcap to extract

There are quite a view elements involved in the name resolution process. Maybe my Sharkfest 2021 US virtual presentation

Are the rtpevent packets shown as UDP in the info column, or maybe as some other protocol. In my case they were show as

I'm not sure if this will work for the way your protocol adds the multiple messages to the tree, but if it does, the lay

Or use the --enable-heuristic option like this tshark -r rtpevent.pcap --enable-heuristic rtp_udp

You can also look at the port numbers with tshark -r rtpevent.pcap -qz conv,udp and then use decode as to decode the spe

Another solution is to save the SDP packets in the new file too, as they contain the mapping of the dynamic payload type

TCP conversation completeness is a bitwise field where the occurance of certain flags over the conversation is recorded

There is no timestamp field in the ICMP header, so the time comes from the ICMP data part. Some ping implementations ad