The OS X builder (an aging Power Mac G4) went down early this morning
and now refuses to boot. I haven't had time to look at the problem in
detail, but we may be without fuzz testing for a while.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
On Apr 16, 2007, at 3:16 PM, Mike Duigou wrote:
> packet-dtls.c: In function 'dissect_dtls':
> packet-dtls.c:433: warning: cast to pointer from integer of
> different size
That call happens to do something that's probably safe on platforms
where
1) "int" has no more bits than a poin
I been fighting for quite a while, TRYing to figure out a way to have
both exception handling mechanisms that are used in windows.
First and mostly we use our macros based on kazlib's exception code
(which build arround ANSI's setjmp and longjmp).
Then for catching "exceptional exceptions" (actu
packet-dtls.c: In function 'dissect_dtls':
packet-dtls.c:433: warning: cast to pointer from integer of different size
I hope that with the recent emphasis on fixing warnings that all
conversions between pointers and integers are now flagged as errors. For
software like Wireshark which doesn't di
Tuomas Maattanen wrote:
> TS Info field should be three bytes long, not two.
> Suspension Interval field is missing altogether, shifting all other
> fields by four bytes.
> Maximum Burst Size, Minimum PHY Rate, Peak Data Rate and Delay Bound are
> in wrong order.
>
> I have attached a patch that f
Hi,
the current SVN (rev 21448) 802.11 WMM TSPEC dissector seems to have
some bugs.
TS Info field should be three bytes long, not two.
Suspension Interval field is missing altogether, shifting all other
fields by four bytes.
Maximum Burst Size, Minimum PHY Rate, Peak Data Rate and Delay Bou
This patch implements parameter dissection
for about 1/2 to 2/3 of the messages in IS-801.
Built and tested against the latest source
as of Friday April 13th 2007.
Build environment was:
Windows XP Pro
Microsoft Visual Studio 6.0
Thanks
--
Michael Lum Principal Software Engi
Michael Roth wrote:
> I wanted to propose a programming API, e.g. a DLL version of tshark
> which you could load once and then call on a per frame basis to get data
> decoded into memory buffered PDML or something like that.
My response on wireshark-users was:
There's already an API from libwire
A small fix to prevent freezing on a loop. Sorry for this.
Anyway, as I said, it is not yet finished, but I like to get some
response to the code (to prevent myself from useless coding ;) ).
--- packet-gdsdb.c
+++ packet-gdsdb.c
@@ -723,7 +723,7 @@
proto_tree_add_item(tree, hf_gdsd
Hi,
in the wireshark-users mailing list I was told to input new proposals to
this mailing list:
I wanted to propose a programming API, e.g. a DLL version of tshark
which you could load once and then call on a per frame basis to get data
decoded into memory buffered PDML or something like that.
A
I ran it on a 64 bit version of Red Hat Enterprise 4. I was doing a live
capture on a busy tap to get an idea about the protocols being used and
byte counts. I did not roll past 2^32 frames. Looks like 100 million was
the most I saw. Since I was updating the byte counter I just updated the
frame co
Jeff Morriss wrote:
> Bug 1511 replaced a g_assert() by a DISSECTOR_ASSERT() to avoid exiting
> on a bad packet, but that will show up as a "dissector bug" when really
> the problem is in the packet.
You're correct - neither g_assert() nor DISSECTOR_ASSERT() are
appropriate for problems with p
Jeff Morriss wrote:
> Hi list,
>
> Bug 1511 replaced a g_assert() by a DISSECTOR_ASSERT() to avoid exiting
> on a bad packet, but that will show up as a "dissector bug" when really
> the problem is in the packet.
>
Well:
You should never use g_assert() or exit() or something like that in any
Hi list,
What do you think--how should we go about this?
-J
Glattfelder Christoph (glc) wrote:
> Hello Jeff
>
> Unfortunately, a frame must be searched for the trailer to recognize it as
> PRP frame. But I see no problem to have it disabled by default.
>
>
> Best regards
>
> Christoph Gla
RayFred Pip wrote:
> Wireshark development team:
>I want to be a developer of *wireshark* project. But I got problems
> mainly on how to get involved into it quickly.
>I have a wish for wireshark that I want to implement. That is to add
> a "content playback" functionality(playback the
Jeff Morriss wrote:
>
>
> Victor Fajardo wrote:
>> To wireshark-maintainers,
>>
>> Attached is a patch file for the PANA protocol dissector. The changes
>> updates the packet-pana.c dissector to support
>> draft-ietf-pana-pana-15a.txt.
>
> Checked (rev 21447), thanks!
I had to change the g_
Hi list,
Bug 1511 replaced a g_assert() by a DISSECTOR_ASSERT() to avoid exiting
on a bad packet, but that will show up as a "dissector bug" when really
the problem is in the packet.
Any objections to, say, DISSECTOR_ASSERT_MALFORMED_PACKET which would
throw a BoundsError for use in this kind
Victor Fajardo wrote:
> To wireshark-maintainers,
>
> Attached is a patch file for the PANA protocol dissector. The changes
> updates the packet-pana.c dissector to support
> draft-ietf-pana-pana-15a.txt.
Checked (rev 21447), thanks!
___
Wireshark-
Meier Sven (msv) wrote:
> This is a dissector for the Parallel Redundancy Protocol (PRP) defined
> in chapter 6 of the IEC 62439.
>
> PRP uses two independent networks in parallel and allows redundancy
> without switchovers.
>
> The protocol is sending Mac multicast messages with Ethertype 0x
On Mon, Apr 16, 2007 at 07:48:00AM +0200, Kukosa, Tomas wrote:
>
> I think your solution is not workaround but quite standard solution in
> Wireshark.
> As it is not guaranteed that you have captured whole SSL session it is
> better to have good heuristic than to relay upon state information.
OK,
20 matches
Mail list logo
