2012/10/11 Mike Morrin
> On 11/10/2012 06:26, Pascal Quantin wrote:
>
>> Le 11/10/2012 05:10, mman...@netscape.net a écrit :
>>
>>> Pascal,
>>> Did you settle on the value, value+1? I think I have the exact same
>>> problem in bug 7728
>>> (https://bugs.wireshark.org/**bugzilla/show_bug.cgi?id=7
On 10/11/2012 1:27 AM, Guy Harris wrote:
Actually, this one:
for(sid_number = 1; sid_number <= number_of_sids; sid_number++) {
proto_tree_add_item(parameter_tree, hf_stream_reset_sid, parameter_tvb,
sid_offset, SID_LENGTH, ENC_BIG_ENDIAN);
sid_offset += SID_LENGTH;
}
co
On 11/10/2012 06:26, Pascal Quantin wrote:
Le 11/10/2012 05:10, mman...@netscape.net a écrit :
Pascal,
Did you settle on the value, value+1? I think I have the exact same
problem in bug 7728
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7768)
Hi,
right now I'm displaying the value like
On Oct 10, 2012, at 8:55 PM, wme...@wireshark.org wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=45462
>
> User: wmeier
> Date: 2012/10/10 08:55 PM
>
> Log:
> Change 'for (i=1; i<=n;...' to 'for (i=0; i
> Done on general principles altho none of the cases
> changed w
Le 11/10/2012 05:10, mman...@netscape.net a écrit :
> Pascal,
>
> Did you settle on the value, value+1? I think I have the exact same
> problem in bug 7728
> (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7768)
Hi,
right now I'm displaying the value like what we would do with a
value_stri
Pascal,
Did you settle on the value, value+1? I think I have the exact same problem in
bug 7728 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7768)
-Original Message-
From: Pascal Quantin
To: Developer support list for Wireshark
Sent: Wed, Oct 3, 2012 8:18 am
Subject: Re: [
On Wed, Oct 10, 2012 at 5:32 PM, Maynard, Chris
wrote:
> Hi Evan,
> I finally got around to applying/testing your patch on Windows XP SP3 32-bit.
> As expected, Wireshark continues to capture just fine.
>
> The relevant code in gui_utils and tshark are very similar indeed, but there
> are some
You would be correct, it's a loop over a tapping point. Logged bug 7845 and
CCed the original author just because the specs aren't free. Probably a
trivial fix though.
-Original Message-
From: Jaap Keuter
To: Developer support list for Wireshark
Sent: Wed, Oct 10, 2012 5:30 pm
Sub
Hi Evan,
I finally got around to applying/testing your patch on Windows XP SP3 32-bit.
As expected, Wireshark continues to capture just fine.
The relevant code in gui_utils and tshark are very similar indeed, but there
are some differences, so I'm not sure if they could be combined or not.
But
On Wed, Oct 10, 2012 at 9:41 PM, Jaap Keuter wrote:
> On 10/10/2012 03:48 PM, mman...@netscape.net wrote:
>
>> I ran some fuzztesting overnight (on a 32-bit WinXP VM, off of trunk),
>> and when
>> I checked on it this morning, I had "WARNING **: Too many taps queued" so
>> many
>> times, it scrol
On 10/10/2012 03:48 PM, mman...@netscape.net wrote:
I ran some fuzztesting overnight (on a 32-bit WinXP VM, off of trunk), and when
I checked on it this morning, I had "WARNING **: Too many taps queued" so many
times, it scrolled beyond the top of my window.
I've never seen this before. Could it
Hi,
I don't know of anyone who has done validation of Wireshark in this regard. Even
if they did I will be thrown out, because it's the capture engine that
timestamps the frames, not Wireshark. Please study the design of Wireshark[1]
and WinPcap[2] a little closer to understand the difference.
Sent that last one too fast...
On Wed, Oct 10, 2012 at 3:19 PM, Evan Huus wrote:
> On Wed, Oct 10, 2012 at 3:18 PM, Jakub Zawadzki
> wrote:
>> On Wed, Oct 10, 2012 at 12:19:42PM -0400, Evan Huus wrote:
>>> At this point I want to just revert the whole recent set of emem
>>> changes *and* the ref
On Wed, Oct 10, 2012 at 3:18 PM, Jakub Zawadzki
wrote:
> On Wed, Oct 10, 2012 at 12:19:42PM -0400, Evan Huus wrote:
>> At this point I want to just revert the whole recent set of emem
>> changes *and* the ref-counting. (...)
>> I don't have access to a commit-capable machine again until tomorrow
>
On Wed, Oct 10, 2012 at 12:19:42PM -0400, Evan Huus wrote:
> At this point I want to just revert the whole recent set of emem
> changes *and* the ref-counting. (...)
> I don't have access to a commit-capable machine again until tomorrow
> evening, so if somebody else wants to take care of it that w
mman...@netscape.net wrote:
I ran some fuzztesting overnight (on a 32-bit WinXP VM, off of trunk),
and when I checked on it this morning, I had "WARNING **: Too many taps
queued" so many times, it scrolled beyond the top of my window.
I've never seen this before. Could it be a result of the f
On Wed, Oct 10, 2012 at 10:51 AM, Martin Mathieson
wrote:
> I have discovered one problem since the change, but it may have been a bug
> all along.
>
> In tcp_graph.c, it was referencing the tap (struct tcpheader) after the tap
> had run. The struct is allocated in packet-tcp.c using ep_alloc(),
I have discovered one problem since the change, but it may have been a bug
all along.
In tcp_graph.c, it was referencing the tap (struct tcpheader) after the tap
had run. The struct is allocated in packet-tcp.c using ep_alloc(), but now
it wasn't valid to access that memory (immediately after tap
On Wed, Oct 10, 2012 at 10:10:08AM -0400, Evan Huus wrote:
> > I still think that
> > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5284#c26
> > would also fix the problem, and we just unnecessary overcomplicate
> > allocator.
>
> Is that not the same idea Guy and Jeff discussed that earli
All,
I would like to develop a application protocol dissector based on IEEE 802.11.
My application protocol is a payload of IEEE 802.11. I also use TCP/IP and
UDP/IP.
I would like to use IEEE 802.11 dissector (already in Wireshark) for my
application dissector.
How do I use it in my application
Dear Jaap
thanks for your answer.
I'd like to add some information to explain better.
My accuracy can be in ms (I don't need ns) because my requirements are
Delta time <= 150 ms
Delta time <= 100 ms
Delta time <= 50 ms
My problem is only to convince other people that Wireshark is a right tool t
If NTP and the OS are not good enough, we use capture cards from Napatech to
obtain better time stamps than our host servers can manage. They sync with a
PTP grand master.
They provide a custom libpcap that works with their card (and wire/tshark).
d
--
David Arnold
Mantara
Office: +1 646
On Wed, Oct 10, 2012 at 9:50 AM, Jakub Zawadzki
wrote:
> On Wed, Oct 10, 2012 at 09:32:07AM -0400, Evan Huus wrote:
>> The fix is needed regardless of what else happens - even with the old
>> old allocator this was still a bug
>> (in the sl_ allocator, if not the ep_ one)
>
> Nah, sl_ allocator do
On Wed, Oct 10, 2012 at 09:32:07AM -0400, Evan Huus wrote:
> The fix is needed regardless of what else happens - even with the old
> old allocator this was still a bug
> (in the sl_ allocator, if not the ep_ one)
Nah, sl_ allocator don't have this bug.
1. Right now sl_free_all() is never used
2.
I ran some fuzztesting overnight (on a 32-bit WinXP VM, off of trunk), and when
I checked on it this morning, I had "WARNING **: Too many taps queued" so many
times, it scrolled beyond the top of my window.
I've never seen this before. Could it be a result of the files I was testing?
New bug
On Wed, Oct 10, 2012 at 8:53 AM, Jakub Zawadzki
wrote:
> On Wed, Oct 10, 2012 at 08:32:00AM -0400, Evan Huus wrote:
>> On Wed, Oct 10, 2012 at 8:24 AM, wrote:
>> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=45445
>> >
>> > User: darkjames
>> > Date: 2012/10/10 05:24 AM
>> >
On Wed, Oct 10, 2012 at 08:32:00AM -0400, Evan Huus wrote:
> On Wed, Oct 10, 2012 at 8:24 AM, wrote:
> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=45445
> >
> > User: darkjames
> > Date: 2012/10/10 05:24 AM
> >
> > Log:
> > Fix bug #7814
> >
> > We need to pass original p
On Wed, Oct 10, 2012 at 8:32 AM, Evan Huus wrote:
> On Wed, Oct 10, 2012 at 8:24 AM, wrote:
>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=45445
>>
>> User: darkjames
>> Date: 2012/10/10 05:24 AM
>>
>> Log:
>> Fix bug #7814
>>
>> We need to pass original pointer and length
On Wed, Oct 10, 2012 at 8:24 AM, wrote:
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=45445
>
> User: darkjames
> Date: 2012/10/10 05:24 AM
>
> Log:
> Fix bug #7814
>
> We need to pass original pointer and length to munmap().
>
> Directory: /trunk/epan/
> ChangesPath
On Wed, Oct 10, 2012 at 12:47:16AM +0200, Jakub Zawadzki wrote:
> On Mon, Oct 08, 2012 at 06:29:33PM -0400, Evan Huus wrote:
> > It doesn't crash, yes, but it leaks again. I've added
> > emem_destroy_chunk() for now in revision 45412,
>
> I forgot to note that emem_destroy_chunk() works only with
On Wed, Oct 10, 2012 at 7:13 AM, Martin Mathieson
wrote:
>
>
> On Wed, Oct 10, 2012 at 5:19 AM, Jakub Zawadzki
> wrote:
>>
>> On Tue, Oct 09, 2012 at 10:53:41PM -0400, Martin Mathieson wrote:
>> > I am getting the same assertion, for every file that I try
>> > reload/refilter.
>>
>> Can you get e
On Wed, Oct 10, 2012 at 5:19 AM, Jakub Zawadzki
wrote:
> On Tue, Oct 09, 2012 at 10:53:41PM -0400, Martin Mathieson wrote:
> > I am getting the same assertion, for every file that I try
> reload/refilter.
>
> Can you get errno number for me?
>
>
12 (Cannot Allocate Memory?)
> > Is there a fix in
On Tue, Oct 09, 2012 at 10:53:41PM -0400, Martin Mathieson wrote:
> I am getting the same assertion, for every file that I try reload/refilter.
Can you get errno number for me?
> Is there a fix in the works?
Nope, but I submitted alternative patch in
[Bug 7775] Wireshark leaks memory when selec
33 matches
Mail list logo
