Greg Helps wrote:
> Screen redraws, mouse movements and keystrokes are all high priority
> activities compared to something like printing. Therefore, the first two
> bytes of the tcp data are not encrypted
Note that there's no guarantee that the first two bytes of a Citrix ICA
packet are the first two bytes of a TCP segment - TCP's a byte-stream
protocol, so a higher-level packet can be fragmented across TCP
segments, and a TCP segment can contain more than one ICA packet. As
such, matching on a particular byte after a TCP header isn't guaranteed
to match anything.
> I'd like to filter by the first two bits of the second byte of the tcp
> payload data. I am currently trying variations of the following display
> filter :
> (tcp[21] & 0xc0) == 0
>
> This filter is rejected as invalid.
Capture filter, or display filter?
It is, confusingly enough, not a valid capture filter. A valid capture
filter would be
(tcp[21] & 0xc0) = 0
with "=", rather than "==", as the comparison operator. I'm tempted to
change that in libpcap, so that either "=" or "==" can be used.
As for display filters, there are two issues:
The first of which is that the constant operand of "&" must be a byte
string, i.e. a sequence of hex values separated by colons, so you have
to say "c0" rather than "0xc0" for a one-byte value.
The second of which is that, at least as I read the man page, that you
can't do something such as
(tcp[21] & c0) == 0
but you can do
!(tcp[21] & c0)
(Note also that those display and capture filters assume the TCP segment
has no TCP options.)
_______________________________________________
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users
