How exactly does the BuildBot fuzztesting work? Do the BuildBots take all of
the mined capture files for fuzztesting and if a fuzz-generated capture file
generates a fatal error, that generated file is automatically posted as a bug?
So in tracking down the error, the supplied capture file in
On Oct 28, 2011, at 10:45 AM, Stig Bjørlykke wrote:
> The checks will introduce more conversions from string to integer, but
> that may not be an issue?
Unless somebody has a Wireshark extension or script running TShark or something
of that sort that attempts to compile millions of filters per
This patch causes "debug" output on the console when launching
Wireshark:
looking for dissectors in /usr/local/src/wireshark/epan/wspython/wspy_dissectors
looking for dissectors in /home/sfisher/.wireshark/plugins
registered protocols []
Can these be removed?
On Mon, Oct 24, 2011 at 04:33:02PM
On Fri, Oct 28, 2011 at 7:06 PM, Stephen Fisher
wrote:
> On Fri, Oct 28, 2011 at 09:00:59AM +0200, Stig Bjørlykke wrote:
>> The previously attached patch does check for signed/unsigned issues,
>> and will mark the filter as bad/red. I think it would be nice to check
>> all values if they are valid
On Fri, Oct 28, 2011 at 09:00:59AM +0200, Stig Bjørlykke wrote:
> On Thu, Oct 27, 2011 at 9:12 PM, Stephen Fisher
> wrote:
> > Is there a problem with accepting -1 in that filter?
>
> It's not a problem, but it's a bug in the logic because the filter
> does not do what it's supposed to.
I under
On 10/20/2011 07:29 PM, Guy Harris wrote:
On Oct 20, 2011, at 8:30 AM, Stephen Fisher wrote:
I don't know how the debian things work in the Wireshark source, but I
assume that this minimum GTK requirement will need to be bumped every time
it is bumped in configure.in. Should we put a comment
>> Right now I analyze the first 2 bytes to check if it's equal to 0x0002
> That's somewhat of a weak check
Indeed, and moreover, it's a wrong check since I discovered a packet
starting with 0x0001 for the first time after a hundred packets ^^
In fact, there is an udp broadcast from enddevices in w
On Thu, Oct 27, 2011 at 9:12 PM, Stephen Fisher
wrote:
> Is there a problem with accepting -1 in that filter?
It's not a problem, but it's a bug in the logic because the filter
does not do what it's supposed to.
> If so, should the
> filter be checked against possible values of the value, i.e. t
