On 26 June 2013 18:19, Jakub Zawadzki darkjames...@darkjames.pl wrote:
(Wow, someone was using it! awesome)
Cheers,
Jakub.
Hey, I use it too.I really like it option to modify and save that to file.
It can be used to check another protocol value while writing new dissector.
Bug 8858 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8858) reminded me
of something I noticed when trying to apply the new filterable expert info API
- there isn't a consistency among dissectors to note a good or bad checksum.
I've seen
1. Checksum field (no verification)
2. Checksum
On 06/26/13 13:58, Christopher Maynard wrote:
Christopher Maynard Christopher.Maynard@... writes:
Jeff Morriss jeff.morriss.ws at ... writes:
Yes, unfortunately that's expected.
OK, yum update qt-devel it is then.
Of course, that should have read, yum install qt-devel.
I have another
mmann78@... writes:
The ones that really seem excessive are 5 6 - do we really need this
duplication? dissector.bad_checksum = TRUE equals
dissector.good_checksum = FALSE. Could we consolidate all (that have
checksum verification) to
Checksum field + good boolean field filter (of the form
Jeff Morriss jeff.morriss.ws@... writes:
Does your compile server have GTK, etc.?
The RPM stuff is currently set up to assume that it does and then
generate 2 packages: one without the GUI (wireshark) and one with the
GUI (wireshark-gnome, I hope to soon add wireshark-qt as another
While I thought dissector.good_checksum = FALSE and dissector.bad_checksum
= TRUE, was duplicative, you provided a valid case for having it.
Perhaps all checksum validations could be an enumeration of
-1 (or 2?) - unknown/disabled
0 - good
1 - bad
If we're already going to take a hit with
Basically the problem is that XMPP needs to be registered to work with SSL.
See bug 8625 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8625) and
revs 49152 (http://anonsvn.wireshark.org/viewvc?view=revisionrevision=49152)
and 49183
On Thu, Jun 27, 2013 at 3:17 PM, darkja...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=50197
User: darkjames
Date: 2013/06/27 12:17 PM
Log:
cleanup [u]int fill proto with value_string function
Create generic int/uint fill functions from
mmann78@... writes:
Perhaps all checksum validations could be an enumeration of
-1 (or 2?) - unknown/disabled
0 - good
1 - bad
The TCP dissector does something similar for the window scaling factor. If
the 3-way handshake isn't captured, then the scaling factor is unknown and
set to -1.
So I guess you use vi as an editor ... but maybe not this time? :)
I've done that from time to time as well when switching from vi to some other
editor.
- Chris
-Original Message-
From: wireshark-commits-boun...@wireshark.org
[mailto:wireshark-commits-boun...@wireshark.org] On Behalf
Christopher Maynard Christopher.Maynard@... writes:
Removing the bad_checksums does have at least 1 drawback though, and that's
that several of them are used in default coloring rules, so if they're
removed, users will likely end up with several warnings of the form:
Warn Could not compile
I (proudly) still use vi... for quick edits and commit messages... :)
On Thu, Jun 27, 2013 at 2:40 PM, Maynard, Chris
christopher.mayn...@gtech.com wrote:
So I guess you use vi as an editor ... but maybe not this time? :)
I've done that from time to time as well when switching from vi to
On Thu, Jun 27, 2013 at 03:28:00PM -0400, Evan Huus wrote:
On Thu, Jun 27, 2013 at 3:17 PM, darkja...@wireshark.org wrote:
XXX: to be honest I don't get it why if dev picked up BASE_DEC_HEX and has
value string we're truncating it to BASE_DEC...
Nesting parentheses? If I recall
I logged something into Bugzilla for now
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8859) if anyone has any
other thoughts. I have too many other half-completed ideas resulting in too
many changed files to tackle this now in one swoop.
As for the coloring rule, thanks for the
On Jun 27, 2013, at 12:40 PM, Maynard, Chris christopher.mayn...@gtech.com
wrote:
So I guess you use vi as an editor ... but maybe not this time? :)
I've done that from time to time as well when switching from vi to some other
editor.
Hi Michael,
2013/6/25 Bálint Réczey bal...@balintreczey.hu:
Hi Michael,
2013/6/24 Michael Tuexen michael.tue...@lurchi.franken.de:
...
The current process puts responsibility on the core developer who
commits a change. Personally, I don't think it is bad if this breaks
the build on some
On Thu, Jun 27, 2013 at 01:15:06PM -0700, Guy Harris wrote:
On Jun 27, 2013, at 12:40 PM, Maynard, Chris
christopher.mayn...@gtech.com wrote:
So I guess you use vi as an editor ... but maybe not this time? :)
I've done that from time to time as well when switching from vi to some
Sorry, it appears my comment may have been misinterpreted. It wasn't at all
meant as any sort of critique of any editor. I merely noticed the extra :wq
and had a laugh because when I wrote, I've done that ..., the *that* was that
I too had typed :wq while either still in vi edit mode or when
[Taking discussion out of the bug since it's not specifically related to
that bug.]
On 06/18/13 18:20, bugzilla-dae...@wireshark.org wrote:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8674#c8
However, those
protocols currently use glib memory and therefore leak on shutdown,
Isn't
19 matches
Mail list logo
