On Fri, May 09, 2003 at 12:02:56PM +0200, David Fay (LMI) wrote:
> I have no MAPI traffic.
There is both a bug in the MAPI dissector and a bug, or, at least, a
strong deficiency in the DCE RPC dissector; the MAPI dissector thinks
some field is a string length when it's not, and the DCE RPC dissector
doesn't check string lengths carefully enough.
I've checked in a fix to the DCE RPC dissector problem - it should now
report the appropriate error if the length of the string is larger than
the available packet data, before trying to allocate a buffer of that
length.
I've also checked in a change to the MAPI dissector - the MAPI dissector
is being constructed by reverse engineering from looking at MAPI
captures (NOTE: I'm *not* one of the main reverse engineers here), and I
suspect somebody saw 6 bytes between two strings in one capture and
tentatively put in code to dissect 6 bytes between those strings; they
put in a comment suggesting that there might be padding, and it looks as
if, of the 6 bytes they saw, 2 were padding and 4 were a 4-byte
quantity, with the padding putting it on a 4-byte boundary. Dissecting
it as a 4-byte DCE RPC number fixes up the dissection of the strings in
question.
> Also another question on my laptop I have a certain amount of RAM and
> Swap space. When this space is full up will Ethereal automatically
> crash
It'll probably crash - Ethereal uses "g_malloc()" for most memory
allocation, and it crashes if it fails. (It also uses a number of GLib
routines that *themselves* use "g_malloc()", so even if Ethereal itself
stopped using "g_malloc()" directly, it'd still be using it.)
> or should it slow down and wait for memory to become available?
...or should it just give up and stop reading the capture? Most
applications on, I suspect, most desktop platforms don't retry memory
allocations if they fail; it might be nice to do so, but it'd be a fair
bit of work to make them do so, in many cases.
