Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] using offset to check any byte in the whole ether-frame

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 21 Nov 2013 11:07:58 -0800
On Nov 21, 2013, at 7:02 AM, Julio Talaverano <delaflota@xxxxxxxxx> wrote:

> as far as I saw up to now offsets can only be used on specific fields like ip, tcp, eth.src and such.

Offsets can be used in:

	"fields" that are actually protocols;

	fields that are byte arrays;

	fields that are MAC addresses;

and there might be some other fields.  So, for example, they can be used on dns.

> I'd like to do something like:
> etherframe[1410:2] == 20:f1 for example.
> 
> What I wanted to check for is the hostname a dns request asked for

Then, at least with Wireshark 1.10.0 or later (and possibly earlier), just check dns.qry.name by comparing it against a string corresponding to the name.

> and the related icmp port unreachable error messages which also include the hostname in their load behind the icmp header.

Try doing the same there.

> Or even the ip identification field in both, the ip packet and in the load of the icmp error message, as above.

Try comparing ip.id against the value you're looking for.

> This way I'd like to know how long our proxies keep asking the same name server
> for the resolution of the same hostname after reception of the port unreachable error message. 
> 
> Any hint?

Yes.

Instead of trying to look at raw bytes in the packet, use named fields corresponding to what you're actually interested in.

If no named field corresponds to what you're looking for, then

	1) file an enhancement request at http://bugs.wireshark.org, as, ideally, all fields in packets should be named if possible;

	2) use offsets within the protocol you're looking at (assuming the field in question is at a specific offset; that's why named fields are superior to looking at raw bytes - they handle fields *not* at specific offsets within the protocol).