Record direction and missed SYN

[Rafael Barbosa]

Hi Carter,

I think I wasn't clear on the explanation. But the ACK is the *only* packet
missing, the record contains 10 packets, from the SYN-ACK to the TCP
connection tear-down.

Best regards,
Rafael Barbosa
http://www.ewi.utwente.nl/~barbosarr/



On Wed, Sep 12, 2012 at 2:28 AM, Carter Bullard <carter at qosient.com> wrote:

> Hey Rafael,
> The SYN_ACK won't be used as definitive for the direction, unless there is
> additional traffic to indicate that its a real connection.  Single SYN_ACK
> can be a scan strategy, so we don't want to reverse he flow direction in
> his case.  If this isn't  the correct behavor, then we've got a bug.
>
> Thanks for the packet file, I'll check it out tonight !!!
>
> Carter
>
>
> On Sep 11, 2012, at 11:46 AM, Rafael Barbosa <rrbarbosa at gmail.com> wrote:
>
> Hi,
>
> I am running into another problem with the reversed record directions. Now
> I have a flow with a single record were the SYN packet is missing (i.e.,
> the first captured packet is a SYN-ACK).
>
> After creating the argus dump and reading it with ra, I get the following:
> $> argus -r bug.pcap -w bug.argus
> $> ra -r bug.argus
>    09:43:42.524434  e           tcp       X.X.X.X.10502     ->
> Y.Y.Y.Y.43539        10       3312   FIN
>
> So argus is using the source of the SYN-ACK packet as 'client' and the
> destination as 'server', while the opposite would be the correct.
>
> I uploaded the bug.pcap to the server.
>
> Best regards,
> Rafael Barbosa
> http://www.ewi.utwente.nl/~barbosarr/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120912/b544faa5/attachment.html>