Guy, thanks for the answer but i'm not satisfied. When you get the
conversation list using the tshark, even if there are partial
conversations (no Syn or 3-way handshake is not observed) commonly
tshark gives the correct results, i need more detail or reference to
delve into this topic which i will use for packet analysis in my
program...
thanks.
On 1/24/2011 10:55 PM, Guy Harris wrote:
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@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
|
