Hi,
Check out the Users Guide for details.
There you'll find that [ ] is a substring operator. That means take the protocol field and get out the defined substring length. In this case you compare them to a hex string.
Note that here you base your filter on frame, that is the raw frame data taken from the wire. It uses nothing of the dissection capabilities to work its way through Ethernet, IP and UDP.
If any of these protocols have extensions (like vlan tag for Ethernet, IP options) your offset into the raw frame becomes invalid.
Even worse, your network may carry traffic that is not BOOTP/DHCP at all but still has this substring at that offset in the frame. I bet an RTP packet could match as well.
Oke, assuming your frame indeed carries DHCP and the offsets are correct you're looking at the first DHCP option present. This option is a TLV (Tag, Length, Value), a common pattern in transmitting unpredictable length units of data. In this case you're filtering for (Tag) DHCP option 0x35 = 53 = DHCP Message type, (Length) 0x01 = 1 byte, (Value) 0x06 = 6 = DHCPNAK and (Value) 0x02 = 2 = DHCPOFFER.
Yes, Wireshark could do with an improved filter language to be able to filter TLVs like these using the dissector. Unfortunately not enough developer brain cycles are available for that now.
Thanks,
Jaap.
On Wed, 15 Dec 2010 15:04:50 +0100, Jürgen Dietl <juergen.dietl@xxxxxxxxxxxxxx> wrote:
Hello,
today I made a trace and I wanted to see all the DHCPNAK.
For this I found a filter:
frame[282:3] == 35:01:06
It works perfect. But my question is how is this filter defined.
For example frame[282:3] == 35:01:02 would be DHCPOFFER.
So {282:3] must be then DHCP. But how is that defined? Is that an offset? some bit? just a fix list?
and what is 35:01:06.
Any help would be greatly appreciated.
thanx a lot and have a nice day,
cheers,
Juergen