I'm trying to capture from a pcap file connections that starts correctly (with 3-way protocol: syn,syn-ack,ack) and ends correctly.
To capture connections that starts correctly I use the following filter:
(tcp.flags.syn == 1) || (tcp.flags.syn==1 && tcp.flags.ack==1)
I don't filter just by ack's because it will filter every single package that contains an ack and isn't useful to me. So I use: SYN or SYN-ACK flags to filter.That's only for starting connections so, how I should filter packages to get also ending packages?
I'm using something like this: (tcp.flags.fin==1) || (tcp.flags.fin==1 && tcp.flags.ack==1)
I don't feel that's correct because I don't know exactly how every connection ends, that depends on implementation? or is always the same?
it is always the same for TCP connection, save for abnormal situations when a peer reset the connection (RST flag). Also, in wireshark you have convenient option: if you right-click a packet a choose "follow TCP stream" it will display only packets belonging to that connection, so you can see how it starts and ends...
Related
I am working on a tool that takes a pcap file (from wireshark in this case), and attempts to parse out data from the TCP packets.
Now in this case, I only care about the data in one direction. So my logic was to sort out each wireshark captured packet into a list by the protocol-destIP-sourceIP-destPort-sorcePort.
So from this point, I now have a list of only packets for one direction on a particular port.
From there I just want to be able to walk through the bodies of the TCP payloads in order. is it as simple as then going in order by Sequence numbers?
I would simply take the first sequence number captured, add the payload size to it and expect that to be the next TCP packet sent? Is there more to this that I am missing?
I was noticing when sorting the interfaces this way, eventually I would come up to a sequence that dosent make sense. I guess I could just assume that is the start of the next stream? I know it becomes more difficult if I have to consider traffic going back and forth... but in this case I only want to watch packets in one direction.
Wireshark captures the packet on the wire. It might happen that the packets don't arrive in sequential order, that packets are corrupt (bad checksum), that there are duplicate packets ... - and this is ignoring possible attacks designed to confuse the analysis. The TCP stack will take care of all these problems so that the application gets the right packets, but Wireshark works outside the TCP stack. Thus, while in most cases your simple procedure will likely work (assuming that you at least check TCP flags for start and end of connection), it might fail in some cases.
I am designing a simple protocol on top of UDP and now I've realized that someone else can send a packet to the port I'm listening on. Such packet will obviusly be incorrect for my application (I'm not concerned about security now)
Is there the way of filtering these invalid messages? I was thinking about adding some fixed magic number at the beginning of each packet, but how large should it be? Is 16 bits enough?
I believe the typical solution is to require a handshake (that could include a "long enough" magic number) in the beginning of the session. Of course the "session" is something your protocol needs to keep track of, UDP does not have the concept. Keeping a list ip, port and last packet receive time for all current sessions should do it: then you can drop all packets from a peers that have not done the handshake beforehand. This not only prevents random unknown app traffic from breaking your application but will also prevent multiple legitimate peers from screwing up each others traffic.
Additionally you could add either a session id or an increasing packet sequence number (with allowances for missing packets) to packets if you need to ensure that the peer agrees with you on which session this is.
Probably. Java uses 32 for .class files (0xcafebabe). But you only have 534 bytes in practical UDP so you might need to save a couple.
I'm working on a tool to test a tcp proxy and I see the following:
Client sends a SYN to the server with timestamps option (TSval=12345, TSecr=0).
Server sends a SYN-ACK and omits the timestamps option.
The problem is that I'm not sure if a TCP is supposed to interpret that to mean that the timestamps option should not be used.
I've been poring over rfc 1323 for a while now, and this is all I could find on the subject:
A TCP may send the Timestamps option
(TSopt) in an initial segment
(i.e., segment containing a SYN bit
and no ACK bit), and may send a TSopt
in other segments only if it received a TSopt in the initial
segment for the connection.
I infer from this that the fact that the SYN-ACK is missing the timestamps option doesn't mean anything about whether or not it's valid later in the session. However, doing so requires me to assume a bit more than I'd like. Does anyone have an authoritative source on the subject or personal experience with how different TCP stacks behave in this situation?
The peer TCP is indicating that it does not support (or wish to use) the option. You should not send any further Timestamp options on that session.
This is fairly standard practice for TCP options.
When transferring data in TCP, and given all the incoming and outcoming packets, how will one know if the packet received is the last of the data?
TCP packets are fragmented into smaller parts. I'm transferring over the HTTP protocol.
When the FIN flag is set by one end of the connection, it indicates that that end will not be sending anymore data.
If the connection is not being closed after the last of the data, then there must be an application-layer method of determining it. For HTTP, the rules are reasonably complicated.
You might use PSH flag of TCP protocol. It should be set to 1 in last packet.
To confirm this just start tracing, make HTTP GET and filter session. You will find that last packet for each response on your HTTP GET is marked by this flag.
I'm assuming you're using some sort of socket library. You can tell a TCP connection is finished because a read() on the socket will return 0. This will happen when the other side closes the connection (which it never has to do).
Is there any field/option/anything that I can put in a TCP packet (be it a syn or an ack or just plain data) that I can be sure will be returned by the other end intact?
For eg. I want to "tag" a particular connection (src, srcport, dst, dstport) with a number that I can always read from a packet belonging to that connection. That means I can identify the connection without using the 4-tuple (as given above).
Yes: it is called a Client protocol encapsulated in the TCP server protocol.
In other words: define the Client protocol to meet your needs. Don't try to "shove" extra bits in the TCP overhead.
There are of course the 'options' overhead in TCP but I doubt you'll find an easy way to access these... and in any case, you shouldn't.
You could possibly abuse the TCP Timestamp option for this. It does not seem like a great idea, though.
You can have a lookup table in your application where you associate your tag with the socket.
No, there isn't any facility for what you describe.
Typically what you would do if you're writing a socket application with multiple connections to other systems, is keep track of the socket handle that belongs to each remote system. When receiving data, you are using the socket handle (in some form, don't know which OS or language you're using) so you can take appropriate action based on whichever socket handle that is.
I've never seen a server application that keeps track of connections based on the 4-tuple of address/ports. That seems like way too much work.
On rereading your question, it seems like you may be asking this from the point of view of the TCP driver level. What sort of software are you writing here?
In UDP, destination IP and destination port number are used to demultiplex the packets, but in TCP destination IP, source IP, destination port number and source port numbers (4-tuple) all needed to distinguish between the connections why reasoning for this usage.