https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16156
Peter Wu <pe...@lekensteyn.nl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |pe...@lekensteyn.nl
Status|UNCONFIRMED |CONFIRMED
--- Comment #2 from Peter Wu <pe...@lekensteyn.nl> ---
This is not a GLib bug, but a Wireshark bug in the handling of string values.
See Bug 15716.
The fact that the pattern \x01-\xff works is pure luck. If you use the \x5c
pattern for example, it would result in an error:
$ dftest 'frame matches "[\x5c]"'
Filter: "frame matches "[\x5c]""
dftest: Error while compiling regular expression [\] at char 3: missing
terminating ] for character class
Why? Because 5c is the hexadecimal value for the backslash character.
Wireshark's display filter parser currently converts escape character before
storing it as string. Due to internally handling strings as a NUL-terminated
buffer, it will not always have the expected effect.
The pattern "com\x00" will therefore be treated as pattern "com". To workaround
this issue, use this pattern instead:
frame contains "com[\\x00]"
Notice the escaped backslash, and the character class around it. If you do not
need a regex, you could follow Chris' example to represent bytes.
In summary:
- Escape rules should be better documented, tracked by Bug 15716.
- \x00 should not truncate strings. We should probably find a way to properly
handle patterns such as 'frame contains "A\x00B"'. It should not be treated as
'frame contains "A"'. Let's track that here.
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
