Re: [Wireshark-dev] [PATCH] Fix false malformed SSL handshakemessages (Was: Catch 22 in SSL dissector?)
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, that makes sense too! Although my personality would like to see everything analysed with 100% certaintly, the real world is not always perfect, and tracesfiles might not always be either... Let's stick to the currently committed heuristic solution, the chances of a false malformed packet are deminished by a large factor. Cheers, Sake ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Parallel Redundancy Protocol (PRP) dissector
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 0x88fb. In > addition to that it adds to every Ethernet frame a 4 byte trailer before > the FCS. The trailer is detected by checking a size field and an > identifier which are part of the trailer. Therefore, if the last 4 bytes > of a frame match a correct trailer they get interpreted as a trailer, > although it was probably not a real one. Is there some way to know if the trailer is going to be there without searching for it? As it is, registered as a postdissector (didn't even know those existed until now), this dissector will get called for every frame--which seems a bit excessive to me. If there's no way to know ahead of time, maybe this dissector should be disabled by default, though I'm not sure how to best go about doing that. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patches to update PANA Protocol dissector
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-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] assertion for malformed packets?
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 of situations? (No, it's not really a bounds error but the effect is the desired one: the user gets shown "malformed packet".) I have, in the past, also wanted a simple assertion like that when a dissector finds illogical stuff in the packet. -J ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Patches to update PANA Protocol dissector
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_assert() back to DISSECTOR_ASSERT() to avoid Wireshark crashing on bad packets (see bug 1511). Also, could you provide an updated sample capture on the Wiki? The one there currently is for the older draft. http://wiki.wireshark.org/SampleCaptures ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Newbie to wireshark development,help !
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 captured bits as its > original format so that human can read and understand them) for wireshark. Hmm, usually Wireshark is used to interpret the bits to make them human-readable but I'm not sure what you mean by "playback." >It is now easy job though.And I even don't know how to get into it as > quickly as possible beginning from scratch. > I have read the web pages on the official site and the Developer's Guide > from which I got information of how wireshark works and how to set up a > development environment for it ,BUT until now wireshark has become a big > project and software that has too many C codes .Should I begin with > reading codes and understand all the APIs and what anything else ...? >Any good suggestions please ? When I started Wireshark coding all I read was doc/README.developer--it was enough to get started writing dissectors. You "should" only need to go digging into Wireshark's code and header files if you're doing bleeding-edge not-quite-documented-yet or not-done-before stuff. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Parallel Redundancy Protocol (PRP) dissector
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 Glattfelder > > Zürcher Hochschule Winterthur > Institute of Embedded Systems - InES > > Technikumstrasse 9 > Postfach 805 > CH-8401 Winterthur > Tel. +41(0)52 260 69 74 > > [EMAIL PROTECTED] > > > -Ursprüngliche Nachricht- > Von: Jeff Morriss [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 16. April 2007 10:26 > An: Developer support list for Wireshark; Glattfelder Christoph (glc) > Betreff: Re: [Wireshark-dev] Parallel Redundancy Protocol (PRP) dissector > > > > 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 0x88fb. In >> addition to that it adds to every Ethernet frame a 4 byte trailer before >> the FCS. The trailer is detected by checking a size field and an >> identifier which are part of the trailer. Therefore, if the last 4 bytes >> of a frame match a correct trailer they get interpreted as a trailer, >> although it was probably not a real one. > > Is there some way to know if the trailer is going to be there without > searching for it? As it is, registered as a postdissector (didn't even > know those existed until now), this dissector will get called for every > frame--which seems a bit excessive to me. > > If there's no way to know ahead of time, maybe this dissector should be > disabled by default, though I'm not sure how to best go about doing that. > > ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] assertion for malformed packets?
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 dissector code. You should never call DISSECTOR_ASSERT() for bad packet data. DISSECTOR_ASSERT() should only be used to detect bad dissector code (e.g. causing an endless recursion). Please read the description for ANSI-C assert() call to get an idea why :-) > Any objections to, say, DISSECTOR_ASSERT_MALFORMED_PACKET which would > throw a BoundsError for use in this kind of situations? (No, it's not > really a bounds error but the effect is the desired one: the user gets > shown "malformed packet".) I have, in the past, also wanted a simple > assertion like that when a dissector finds illogical stuff in the packet. > Yes, I think something like this would be useful. In the past I've did a workaround for stuff like that, using tvb to get 100 bytes or so which are really not in the packet, and therefore I get a BoundsError. But that's actually a workaround. However, I don't think that DISSECTOR_ASSERT_MALFORMED_PACKET is a good name for it. That translates to: "be sure that the packet is malformed" - sounds strange to me. Ideas for a better name: - DISSECTOR_VERIFY_PACKET_DATA - DISSECTOR_VERIFY_DATA (I prefer this name, as it's shorter and still makes it clear what it does) Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] assertion for malformed packets?
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 packet data. An assert is something that
should be used to test something that should *always* be true - i.e.,
there's an error in the code if it's not true. That applies to
assert(), g_assert(), and DISSECTOR_ASSERT() - and to any
DISSECTOR_ASSERT_... macro.
> Any objections to, say, DISSECTOR_ASSERT_MALFORMED_PACKET which would
> throw a BoundsError for use in this kind of situations? (No, it's not
> really a bounds error
Then it shouldn't be BoundsError.
> but the effect is the desired one: the user gets
> shown "malformed packet".) I have, in the past, also wanted a simple
> assertion like that when a dissector finds illogical stuff in the packet.
In that particular case, dissection shouldn't necessarily be aborted if
an AVP has a bogus length - a bad AVP within a Grouped AVP should
terminate dissection of the grouped AVP, but the dissector should be
able to dissect the next AVP.
If there are problems at a low level in a packet that should truly abort
the dissection of that entire packet, not just a sub-item in the packet,
we should probably add a new exception for that purpose; we're already
abusing ReportedBoundsError for that in some places. If the problem is
associated with a particular item in the packet, the exception
shouldn't add its own item to the protocol tree, as happens with
ReportedBoundsError - the item in the packet should be displayed with an
error indication, and then the exception should be thrown. That
exception should be caught in the same places that ReportedBoundsError
is caught, so that if a given lower-level packet has data from more than
one higher-level packet, an error in the higher-level packet doesn't
abort dissection of the lower-level packet.
This raises several questions:
1) I seem to remember noticing that, at some point, generic
TVL/AVP/{whatever the particular protocol spec calls them} dissection
code was added for use by dissectors, although I can't remember where it
was. Am I misremembering? If not, where's that code, and could we
convert more dissectors to use it? Presumably if it can dissect
TVL's/AVP's/whatever's when the length is the total length of the item,
rather than the length of the value, it checks for a length that's
shorter than the length of the type field + the length of the length
field, and somehow reports an error.
2) Perhaps some mechanism for flagging a packet as being somehow "bad"
would be useful, so a display filter could check for "bad" packets, and
various types of problems, including but not limited to actual
ReportedBoundsErrors?
Would the expert mechanism be appropriate for that? We can already
mark a packet as having an error with an expert severity of PI_ERROR;
should we support display filters to check for particular expert severities?
3) Speaking of the expert mechanism, why are the PI_ values defined in
proto.h rather than expert.h?
4) In a number of dissectors, length checking when dissecting sub-items
within an item is done by creating a tvbuff for the item; that means
that if the item is too short, a ReportedBoundsError exception is thrown
if the item is too short, so dissection of the entire packet is aborted
even if items past the too-short item can be dissected.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] Protocol statistics
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 counter as well just in case. So doing a live capture long enough I could probably roll the frame counter as well. I use the stats part often to help characterize the traffic and volume. Thanks, Todd On Mon, 2007-04-16 at 13:15 +0800, Jeff Morriss wrote: > > Todd Vollmer wrote: > > Sorry for the repost. The wiki doesn't mention putting PATCH in the > > subject line and I am new here. > > > > I have attached a patch for the protocol hierarchy statistics (-z io, > > phs). It's a simple update from a 32 bit unsigned integer to a 64 bit > > version. I am a little uncertain about the portability of the new > > include but I tied to follow how it was done else where in the code. > > It should be portable enough since Wireshark now requires 64-bit types. > And I'm all about 64-bit counters (32-bits is so, like, 1990's), but: > > - Did you actually have a capture with more than 2^32 frames? On what > OS and with how much RAM? I didn't think Wireshark could read files > that big and I certainly thought it would run out of memory before it > got that far. Just curious, really... > > - If Wireshark/tshark are going to support more than 2^32 frames, > there's more changes that should happen too: the frame numbers are > currently guint32, for example. Rollover there will mess up the > statistics the taps are gathering. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] How to propose a new feature?
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 simpler alternative would be to allow tshark to read from stdin or to use pipes, so it could be used like an on-the-fly filter for PCAP to PDML. Maybe this would not even cause problems with GPL/LGPL. Thanks! Michael ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] Firebird/Interbase dissector, request for comments
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_gdsdb_receive_messages, tvb,
offset, 4, FALSE);
offset += 4;
- while(tvb_bytes_exist(tvb, 0, 12)) {
+ while(tvb_bytes_exist(tvb, offset, 12)) {
proto_tree_add_item(tree, hf_gdsdb_receive_direction,
tvb, offset, 4, FALSE);
offset += 4;
--
Mvg
Môshe van der Sterre
http://www.moshe.nl/
http://www.coecu.nl/
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] How to propose a new feature?
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 libwiretap, which both Wireshark and TShark use to dissect packets - but it's currently not guaranteed to remain unchanged from release to release. If the API stabilizes, there's a good chance that it won't stabilize as the current API. It dissects packets to yield a protocol tree. Joerg Mayer further noted: Also, be aware that the code is under GPL, not LGPL, i.e. if you use the dll in a product, that product must be under a GPL compliant license. > A simpler alternative would be to allow tshark to read from stdin or to use > pipes, The main difficulty there is that to determine the file type, TShark might have to try to read the file, as not all file types *Shark support have magic numbers. Currently, that's done by, for each file type, seeking back to the beginning of the file and calling the "open this file type" routine. A different buffering scheme could let that be done on pipes (i.e., support seeking within a buffer, even on pipes). ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] IS-801 enhancement patch
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 Engineer 4600 Jacombs Road +1.604.276.0055 Richmond, B.C. Canada V6V 3B1 UTStarcom Canada, Inc. CDMA Division packet-ansi_801.c.patch.gz Description: packet-ansi_801.c.patch.gz ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] [PATCH] Fix for 802.11 WMM TSPEC dissector
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 Bound are in wrong order. I have attached a patch that fixes these. The changes were tested OS X. 802_11_wmm_tspec_fix.diff.gz Description: GNU Zip compressed data // Tuomas ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] [PATCH] Fix for 802.11 WMM TSPEC dissector
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 fixes these. The changes were tested OS X. Checked in in r21450. Thanks! ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Compile broken on 64-bit Linux -- packet-dtls.c
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 directly touch hardware or depend up on the internal representation format of pointers any conversion between a pointer type and a non-pointer type should always be highly suspect. Expressions who's result is a ptrdiff_t or involve addition or subtraction of a ptrdiff_t are certainly fine of course... Mike ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] Problems with Exception Handling on Windows.
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" (actual bugs in the code)
we use window's own __try {} __finally {} and __except {} mechanism.
One problem is that longjmp forces the execution of the __finally
block. so when THROW is called execyution jumps to the ENDTRY and not
necessarily to the CATCH
Removing these __finaly blocks I added to the TRY ENDTRY macros on the
other hand would cause ENDTRY's code not to be evaluated when a
windows exception is thrown and thus leaving kazlib's stack in an
inconsistent state possibly causing errors when handling THROW()
triggered exceptions.
In any case I'll back up the changes to the exception mechanism I made
that are actually causing more problems than those they solved.
But then, at this point we have various choices:
a) Rewrite the TRY THROW CATCH and ENDTRY macros on windows so that we
only use win32's SEH and not kazlib to avoid the unpredictable effects
of mixing both exception mechanisms. We need to add another macro at
the end of the try block and other than the above listed macros
there's CLEANUP_PUSH userers that need being refactored to use
ep_allocs instead.
b) Dump the "exceptional exception" mechanism used in windows to catch
bugs in the code as they were exceptions (i.e. crash instead of trying
to go ahead when such a problem happens)
c) Live with the problems caused when an "exceptional exception"
leaves the kazlib's stack in an inconsistent state. (It still handles
most would be crashes without misbehaving.)
Ideas or suggestions.
Notes:
Users of TRY ... ENDTRY
[id-est:~/src/ws/trunk] lego% grep ENDTRY `find . -name '*.c'` | wc
64 1422504
Users of CLEANUP_PUSH
[id-est:~/src/ws/trunk] lego% grep CLEANUP_PUSH `find . -name '*.c'`
./asn1/h245/packet-h245-template.c:
CLEANUP_PUSH(reset_h245_pi, NULL);
./epan/dissectors/packet-dcerpc-spoolss.c: CLEANUP_PUSH(g_free, key_name);
./epan/dissectors/packet-giop.c: CLEANUP_PUSH(g_free, tmpbuf);
./epan/dissectors/packet-giop.c: CLEANUP_PUSH(g_free, objkey);
./epan/dissectors/packet-giop.c: CLEANUP_PUSH(g_free, operation);
./epan/dissectors/packet-giop.c: CLEANUP_PUSH(g_free, operation);
./epan/dissectors/packet-giop.c: CLEANUP_PUSH(g_free, repobuf);
./epan/dissectors/packet-h245.c:
CLEANUP_PUSH(reset_h245_pi, NULL);
./epan/dissectors/packet-multipart.c: /*
CLEANUP_PUSH(cleanup_multipart_info, m_info); */
./epan/dissectors/packet-radius.c:CLEANUP_PUSH(g_free, eap_buffer);
./epan/dissectors/packet-socks.c:
CLEANUP_PUSH(clear_in_socks_dissector_flag, NULL);
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Compile broken on 64-bit Linux -- packet-dtls.c
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 pointer and 2) converting from int to pointer doesn't mangle the bits which is true of all the platforms we currently support. However, it's still a good idea to fix it. There is no code in Wireshark that actually *uses* the DTLS tap, so we could just get rid of the tap. It seems a bit odd that the data passed to the tap is the proto_dtls value - that doesn't seem like very interesting information to pass to a tap, as it doesn't change from call to call. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
[Wireshark-dev] OS X builder down
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 http://www.wireshark.org/mailman/listinfo/wireshark-dev
