Re: How source and destination is identified in Wireshark?

[Guy Harris <guy () alum mit edu>]

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.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe