Guy, thanks for the info
yes, P is < than M, and this was a tcpdump (on Linux) captured into a
file, and read through Ethereal then I assume that 3. doesn't count.
So my problem is 1.
Regards
>
> On Wednesday, September 3, 2003, at 12:08 PM, Distribution Lists wrote:
>
>> I'm seeing a fair amount of short frame during some LDAP binds/search.
>> What are short frames
>
> The consequence of either
>
> 1) when capturing, specifying a "snapshot length" not large enough to
> capture the entire packet;
>
> 2) possibly not enabling LDAP-over-TCP reassembly (although those
> should show up as something other than a "Short Frame", e.g. "Malformed
> Packet" or "Unreassembled Packet");
>
> 3) some weird interaction between some VPN/etc. drivers on Windows and
> WinPcap, that causes an effect similar to 1);
>
> 4) some bug in Ethereal.
>
> At the beginning of the detailed view of each packet it should say
> something such as
>
> Frame N (M bytes on wire, P bytes captured)
>
> If P is less than M, it's either 1) or 3).
>
> If it's neither 1) nor 3), then select "Preferences" from the Edit
> menu, open up the "Protocols" list in the Preferences dialog box,
> select "LDAP", and make sure that "Desegment all LDAP messages spanning
> multiple TCP segments" is turned on. If it's not, turn it on, and
> click "OK".
>
> If that makes the problem go away, it's 2). If it doesn't make the
> problem go away, it's 4).
>
>> and are they hindering performance ?
>
> They don't represent any real behavior on the wire, they represent an
> artifact of the way the packets are being captured or dissected by
> Ethereal.
>
>> I can send the trace in text...but its verbose
>
> A binary version of the trace would be better. If the problem is 4)
> rather than 1), 2), or 3), send us that.
>
>
--
http://www.seekitzone.com
http://www.e-securenetworks.net
http://www.shopper-holic.com
http://www.planet247.net
http://www.auction-holic.com