On Thu, Nov 07, 2002 at 09:17:26AM -0500, Joshua Wright wrote:
> + From looking through the -users archives, I've seen a few older
> posts asking if it's possible to match strings in payload data. The
> Ethereal "data" macro would make me think this is possible, but when I
> try to apply a filter with 'data[4:4] eq "All "', I get an error message
> stating '"All " is not a valid byte string'. Is there a way to match
> strings in the data payload of a packet when I can specify an offset and
> length value?
Well, converting the characters of the string to hex, e.g.
data[4:4] eq 41:6c:6c:20
might work. I'm not sure if there's a reason why we *couldn't* allow
text strings as byte strings - Gilbert?
Note that the above isn't the sort of matching some people have asked
for - they want to match a string *anywhere* in the packet (or part of
the packet), but we don't have a string-matcher in Ethereal (we'd want
something faster than the naive "scan through the packet, doing compares
starting at the first byte and advancing a byte at a time until we get a
match or run out of data" algorithm, I suspect).
> + The 802.11 decoder has been very helpful to me, saving me in many
> occasions from the painful byte-counting analysis I was doing with
> tcpdump. I am interested in using the wlan_mgt.tag.interpretation macro
> to match non-ascii characters. I am successful with this filter when
> trying to match ascii characters, e.q. 'wlan_mgt.tag.interpretation eq
> "myessid"', but I am having trouble matching with
> 'wlan_mgt.tag.interpretation eq 0x6D796573736964'. I'm trying to match
> SSIDs with non-printable characters - is there a way to accomplish this?
Well, I tried using the same byte-string technique listed above in a
capture I had, but that doesn't work. If that's done deliberately,
rather than being a bug, perhaps we should also allow byte strings as
text strings.
