Charles,
This got me excited enough to just code something up.
Here is my current output:
*| *-9112490598188246883 * | *120782885 * | *191 * | *NS|ECE (ECN
capable)|URG|ACK|PSH|RST|SYN * |*
*| *3418479551590665689 * | *120782885 * | *191 * | *NS|ECE (ECN
capable)|URG|ACK|PSH|RST|SYN * |*
*| *9404749046357206 * | *120782885 * | *191 * | *NS|ECE (ECN
capable)|URG|ACK|PSH|RST|SYN * |*
*| *7971558575805030122 * | *120782885 * | *191 * | *NS|ECE (ECN
capable)|URG|ACK|PSH|RST|SYN * |*
*| *-4666599101156419893 * | *120782885 * | *191 * | *NS|ECE (ECN
capable)|URG|ACK|PSH|RST|SYN * |*
*| *-672627876006511342 * | *-1846673370 * | *49 * | *ECE
(Congestion experienced)|URG|SYN * |*
*| *6346604732028469374 * | *1611798224 * | *106 * | *CWR|ECE (ECN
capable)|ACK|RST * |*
*| *-9031405983396365775 * | *1611798224 * | *201 * | *NS|CWR|ACK|SYN
* |*
*| *7738739733723725373 * | *1611798224 * | *219 * | *
NS|CWR|URG|ACK|RST|SYN * |*
*| *6346604732028469374 * | *1611798224 * | *106 * | *CWR|ECE (ECN
capable)|ACK|RST * |*
*| *-9031405983396365775 * | *1611798224 * | *201 * | *NS|CWR|ACK|SYN
* |*
*| *7738739733723725373 * | *1611798224 * | *219 * | *
NS|CWR|URG|ACK|RST|SYN * |*
I am not confident of the ack number being correct and will check against
your reference. What is new here is the decoded flags column. It might be
reasonable to have specific columns for the most important flags "ACK, RST,
SYN" since all access is lazy anyway.
What do you think?
Can some or all of the pcap file you included be distributed as a unit test?
On Mon, Jan 1, 2018 at 12:31 PM, Charles Givre <[email protected]> wrote:
> Hello all,
> I was playing with the PCAP functionality in Drill and I wanted to add the
> TCP flags to the data that Drill is returning. I was also interested in
> adding the TCP Sequence and Ack numbers as well. I noticed that the code
> as written currently has a function in Packet.java which returns the TCP
> Sequence number, however this was never added to the schema, so I added
> that and rebuilt Drill, however, it doesn’t seem to be returning the
> correct result. The file I was querying is attached to this email, and
> should in all cases return a sequence number of zero.
>
> Questions:
> 1. Could someone please take a look at the code for the tcp_sequence and
> see if I did something wrong, or if the offset is not being calculated
> correctly
> 2. I’m trying to figure out the offsets for the various TCP flags. I
> would think that the offset should be PacketConstants.ETHER_HEADER_LENGTH
> + getIPHeaderLength() +13 to get the word that has the flags and then from
> there, access the individual bits. However, this doesn’t seem to work.
> What am I missing?
> Thanks and Happy New Year!
> - C
