[Winpcap-users] What do the expressions guarantee to me?

[David Barnish]

The filter will only identify the packet type you ask for. It looks at
values in the various headers, going down through the encapsulation as
far as it needs to. Other than that, it doesn't do any other processing
on the packet itself. If the header says that it is a TCP packet, but
the TCP data is corrupted, it will still get returned by the filter as a
TCP packet. It is up to the code that is receiving the packets to
perform any additional tests or processing on the packet itself.

In the filter string you show, you are guaranteed to get a frame
containing an Ethernet packet whose data type field is set to "IP"
encapsulating an IP packet whose protocol field is set to either "UDP"
or "TCP".

Hope this helps.


Thank you,
David Barnish
 
Senior Software Engineer R&D
Spanlink Communications

-----Original Message-----
From: winpcap-users-bounces at winpcap.org
[mailto:winpcap-users-bounces at winpcap.org] On Behalf Of Ramiro Polla
Sent: Wednesday, March 15, 2006 11:45 AM
To: winpcap-users at winpcap.org
Subject: [Winpcap-users] What do the expressions guarantee to me?

Hello,

By compiling the expression "ip and (tcp or udp)", what I am guaranteed
to 
have?
Such as in checksum calculation of ip header, tcp/udp header, and
tcp/udp 
data.

Does it do any checksum at all, or just tells me that the ethernet data
(or 
whatever), has IP set as the protocol, and inside the ip header (or the 
bytes that would correspond to an ip header) TCP or UDP are set as the 
protocol?

Thanks,
Bye,
Ramiro Polla

>From: "Jacob Gnarly" <jacob.gnarly at gmail.com>
>Reply-To: winpcap-users at winpcap.org
>To: winpcap-users at winpcap.org
>Subject: Re: [Winpcap-users] TCP stack resets connections established 
>byWinPCap on XP SP2
>Date: Wed, 15 Mar 2006 09:11:14 -0700
>
>Thanks for the quick response. I'll check it out and post the result
back 
>to
>this thread.
>
>Jacob
>
>On 3/14/06, Guy Harris <guy at alum.mit.edu> wrote:
> >
> > Jacob Gnarly wrote:
> > > I hope someone has already seen strange behavior like this and can

>point
> > > me in the right direction. I "inherited" an application which
creates 
>a
> > > TCP connection with a remote host, sends a small number of
packets, 
>and
> > > terminates the connection. The odd behavior that I am finding is
that 
>on
> > > some XP SP2 systems the TCP session works just like you would
expect
> > > while other systems have the connection terminated prematurely by
the
> > > originator's TCP stack.  Instead of the expected SYN/SYN_ACK/ACK
> > > handshake the originator's TCP stack generates a RST packet as
soon as
> > > it receives the SYN_ACK packet back from the remote system and
then 
>the
> > > WinPCap program responds with an ACK packet as follows:
> > > SYN/SYN_ACK/RST/ACK.
> >
> > Capture a network trace, look at RFC 793, and see whether the sender
of
> > the SYN+ACK packet is violating the TCP spec in some fashion
(including
> > "the ACK of the SYN was already sent).
> > _______________________________________________
> > Winpcap-users mailing list
> > Winpcap-users at winpcap.org
> > https://www.winpcap.org/mailman/listinfo/winpcap-users
> >


>_______________________________________________
>Winpcap-users mailing list
>Winpcap-users at winpcap.org
>https://www.winpcap.org/mailman/listinfo/winpcap-users


_______________________________________________
Winpcap-users mailing list
Winpcap-users at winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users