Hi Sake,
Thanks for the reply. The program in question is the OneCare download
manager or stub (small 1.4MB file that does the actual download). It
can be found at
http://onecare.live.com/standard/en-us/install/install.htm.
> You might be a bit too paranoid here, but could you
> send in the tracefile showing this behavior, as I...
The trace is a bit large and mostly irrelevant - I've attached the the
minimum which demonstrates. Packet in question is 36. (My apologies if
anyone is on dialup and suffers through the 56 KB file).
The data in the packet in question (36 in the attached dump) is as
follows. Does anything jump out at you? I have not pulled out a
SSL/TLS reference to begin trying to interpret:
0000 82 31 8e c9 f6 bf 71 12
Thanks in advance,
Jeff
On 6/2/09, Sake Blok <sake@xxxxxxxxxx> wrote:
> On Tue, Jun 02, 2009 at 03:43:25PM -0400, Jeffrey Walton wrote:
> > Second Socket (TLS v1):
> > * TCP Three way handshake
> > * Client Hello
> >
> > After the client hello, Wireshark is claiming '[TCP Previous segment
> > lost] [TCP segment of a reassembled PDU]'. I then observe a data
> > exchange, but Wireshark reports 'Ignored unknown data'. No information
> > regarding the server hello, and no 'vanilla' TCP data transfer.
> >
> > I suspect that this *might* be an anti-debug/trace trick (am I being
> > too paranoid?). It is definitely reproducible. Has anyone encountered
> > similar?
>
>
> You might be a bit too paranoid here, but could you send in the
> tracefile showing this behavior, as I...
>
>
> > The server in question is instinfo.onecare-live.com.nsatc.net.
>
>
> ... can't seem to reproduce it here. The site just gives me a normal SSL
> handshake in the proper order.
>
> I think you just receive the frames out-of-order, or your capturing
> device might miss a packet here and there...
>
> Cheers,
>
> Sake
>
Attachment:
OneCare.0-100.pcap
Description: Binary data