On Jan 24, 2011, at 7:31 PM, Berkay Celik wrote:
If there is a syn bit set seen from an endpoint, this is the source.
Presumably you mean "if there is a SYN bit, *and no ACK bit*, seen from an endpoint, this is a packet coming from the machine trying to start the TCP connection" (i.e., that by "source" you mean the machine that's trying to start the connection, and that this applies only to the initial SYN, not the the SYN+ACK you get back from the machine to which you're trying to connect). I am curious about if wireshark defines in some other ways
Does Wireshark even define the "source" and "destination" of a TCP connection? A packet trace might not have the three-way handshake, so it might not be possible to determine, at the TCP layer, what the source and destination of a connection are.
Wireshark *does* identify the source and destination of a packet at various layers, including the IP layer, but those are defined fairly straightforwardly by the protocol. or only the syn bit is enough to identify the source and destination?
*If* you see either the initial SYN or the SYN+ACK, that's sufficient to identify the "source" and "destination" of a TCP connection, where "source" is "the endpoint that tried to connect" and "destination" is "the endpoint to which the connection was attempted". For other transport layers, there might be other definitions, or there might not be any definition of "source" and "destination" at the transport layer (consider UDP, for example). Secondly,
if my traces has are partial conversations, not any syn bit is seen, which one is the source and destination? port numbers can be used to determine them but what if both port numbers makes sense.
If both port numbers make sense as the "server" port number, then there is absolutely no way to determine, at the transport layer, which endpoint is the "source" ("client") and which endpoint is the "destination" ("server"). That would have to be determined at a higher layer, for example at the layer of the protocol running *atop* TCP - a request packet is presumably going from "source"/"client" to "destination"/"server", and a response packet is presumably going the other way.
Of course, if a protocol is peer-to-peer, so that *either* side can send a request or reply to a request, even that won't work.
|