Re: ADAM handshaking very slow in a DMZ




The missing packets are LLC checks and other unrelated packets. Those all
appear to be normal. I just didn't want to clutter the post with those.

There's a second web application (on the same box) which queries SQL and
returns data to the user. This forms authentication piece just directs them
to that secondary web application once authentication is good.

What is confusing to me is the SSLv2 request and then the TLSv1 response.

From the point of sequest 631 and 651 ... between those two are just some
LLC checks... no TCP.

Yes, the 10.128.2.38 is the internal ADAM instance.

What's throwing me, and what I don't understand, is the 3 ports opened to
ADAM from the web server. Is this a result of the TCP DUP?

Ted

"Lee Flight" wrote:

Hi

so looking at the problem trace you pick up (20.04s,19.93s,19.93s,19.75s)
so say 20s at each of the 4 points below. It also looks from your trace
sequence numbers (the first number on each line?) that there are ~128
packets not shown during each of those intervals what was happening there?
Noted also that the problem trace has 4 Client Hellos whereas "normal" trace
has 3.

Also your traces from the WWW server in both cases only show packets
with 10.128.2.38 (the intranet ADAM instance?) as destination.

Thanks
Lee Flight

"Ted Wagner" <TedWagner@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A7E4EE55-7641-4500-AF4E-A7E52C023ECB@xxxxxxxxxxxxxxxx

"506","52.862277","172.16.0.36","10.128.2.38","TCP","cognex-insight >
ldaps
[ACK] Seq=40 Ack=4997 Win=65535 Len=0"
"634","72.906563","172.16.0.36","10.128.2.38","TLSv1","Certificate, Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"

"651","72.934195","172.16.0.36","10.128.2.38","TCP","cardax > ldaps [ACK]
Seq=40 Ack=4997 Win=65535 Len=0"
"785","92.859324","172.16.0.36","10.128.2.38","TLSv1","Certificate, Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"


"869","92.914686","172.16.0.36","10.128.2.38","TCP","rdrmshc > ldaps [ACK]
Seq=40 Ack=4997 Win=65535 Len=0"
"997","112.843447","172.16.0.36","10.128.2.38","TLSv1","Certificate,
Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"

"1028","113.122915","172.16.0.36","10.128.2.38","TCP","cardax > ldaps
[ACK]
Seq=1816 Ack=65639 Win=64742 Len=0"
"1157","132.874402","172.16.0.36","10.128.2.38","TLSv1","Certificate,
Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"



.



Relevant Pages

  • Re: ADAM handshaking very slow in a DMZ
    ... It also looks from your trace ... Key Exchange, Change Cipher Spec, Encrypted Handshake Message" ...
    (microsoft.public.windows.server.active_directory)
  • Re: TCP stack bug related to F-RTO?
    ... On the wrong tcp checksum, that's because of hardware checksum offload. ... As for the seq/ack number, because the trace is long, I deliberately removed those irrelevant packets between after the three-way handshake and when the problem happens. ... The client opens up a big window, ...
    (Linux-Kernel)
  • RE: how to trace what is accessing the nic ?
    ... how to trace what is accessing the nic? ... > There is happening something very strange on one of our Linux ... > packets to always the same private address. ... This e-mail message is private, is intended for the recipient named in it and may contain material which is confidential and privileged. ...
    (Security-Basics)
  • Re: TCP stack bug related to F-RTO?
    ... in the trace), but all of them are dropped due to some ... Server is still in slow start mode, ... time retransmission timer expiring before retransmit the lost packets. ...
    (Linux-Kernel)
  • Re: ADAM handshaking very slow in a DMZ
    ... It also looks from your trace ... Key Exchange, Change Cipher Spec, Encrypted Handshake Message" ...
    (microsoft.public.windows.server.active_directory)