Wireshark · Wireshark-users: Re: [Wireshark-users] Strange SSL record sizes?

[Martin Visser <martinvisser99@xxxxxxxxx>]

Prabhat,

It is fairly hard to tell what is going on from what you have sent.

The first thing to do would be the decode the SSL using wireshark, at least then you might have an insight into the underlying application protocol.

It is important to get also look at the packet timing, and whether there are things occuring such as ACKnowledgement (at an application level) of your incoming traffic in a timely fashion. Often delays occur when authentication or name resolution is poor, resulting in fall back mechanisms that have a fixed timeout.

Regards, Martin

Regards, Martin

MartinVisser99@xxxxxxxxx

On 27 December 2014 at 07:37, Prabhat Puroshottam <prabhat.puroshottam@xxxxxxxxxxx> wrote:

Hi,

We have a software where Client is used to copy a file to and from
 a server. The communication happens over SSL layer. I am analyzing an
issue where file copying is "very" slow using our client-server software
 when compared with some other tools.

What I have observed is that, the packets captured follow a pattern.
First there will be a packet with a payload data of 16384 bytes
(reassembled from 12 assembled TCP segments) and the next one will
be a packet with payload data of 71 bytes only. And this pattern repeats
itself. I am worried about the packet with 71 bytes, is it causing some
delay?

For example,

Following is excerpt from first type (reassembled, 16384 bytes) of
packet's wireshark output:

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[12 Reassembled TCP Segments (16421 bytes): #76576(1460), #76577(1460), #76578(1460), #76579(1460), #76580(1460), #76581(1460), #76582(1460), #76583(1460), #76584(1460), #76585(1460), #76586(1460), #76587(361)]
    [Frame: 76576, payload: 0-1459 (1460 bytes)]
    [Frame: 76577, payload: 1460-2919 (1460 bytes)]
    [Frame: 76578, payload: 2920-4379 (1460 bytes)]
    [Frame: 76579, payload: 4380-5839 (1460 bytes)]
    [Frame: 76580, payload: 5840-7299 (1460 bytes)]
    [Frame: 76581, payload: 7300-8759 (1460 bytes)]
    [Frame: 76582, payload: 8760-10219 (1460 bytes)]
    [Frame: 76583, payload: 10220-11679 (1460 bytes)]
    [Frame: 76584, payload: 11680-13139 (1460 bytes)]
    [Frame: 76585, payload: 13140-14599 (1460 bytes)]
    [Frame: 76586, payload: 14600-16059 (1460 bytes)]
    [Frame: 76587, payload: 16060-16420 (361 bytes)]
    [Segment count: 12]
    [Reassembled TCP length: 16421]
    [Reassembled TCP Data: 1703014020248070ffbaa440b4f2edc9aed51827627e3ef2...]
Secure Sockets Layer
    TLSv1 Record Layer: Application Data Protocol: data
        Content Type: Application Data (23)
        Version: TLS 1.0 (0x0301)
        Length: 16416
        Encrypted Application Data: 248070ffbaa440b4f2edc9aed51827627e3ef2831e473708...
Data (16384 bytes)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


And following is from the very next packet (71 bytes):

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Secure Sockets Layer
    TLSv1 Record Layer: Application Data Protocol: data
        Content Type: Application Data (23)
        Version: TLS 1.0 (0x0301)
        Length: 96
        Encrypted Application Data: 0f92c19d11ffd0cc38e854549738eb7a0b5ca1979020ef24...
Data (71 bytes)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


This pattern of 16384 byte SSL record(?) followed by a 71 byte SSL
record(?)
keeps on repeating itself till the whole file is uploaded.
Could this be
 slowing down the file transfer? Moreover, why could
this thing be
happening? Any pointers?

Sorry if this is something very simple that I can't understand, I am
very
new to this thing. Thanks for taking time to go through this
rather lengthymessage.

-Prabhat


___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe