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.
