DSL SSL3.0 issue

[chrisayres]

Hi,

I have a pretty strange problem.

I have a 6015 which is connected to 828's. (GSHDSL)

Users on this system have reported "Page cannot be Displayed" errors when trying to login to their Hotmail accounts.

I have put a sniifer on various places in the network and what I have found is that 1 packet from

loginnet.passport.com is getting as far as the 6015 but is not getting to the 828's. loginnet.passport.com resends this packet 4 times then resets the TCP session (the TCP reset packet is recieved OK).

It is always the same packet that is not recieved but everything else is transmitted OK

This only happens when the users connect using SSL 3.0, if they change their browser to use SSL 2.0 it works fine.

I don't think this is an MTU issue as I can see larger packets going to the users OK.

Is anyone aware of issues similar to this

[michael.groves]

Hi

I have the same problem, although by changing to SSL 2.0 does not work for me.

If you find the answer could you post it on the forum, similarily If I find it first I will let you know.

Lets hope someone out there knows the answer!

Regards

Michael

[tcrellin]

Is this packet part of the existing TCP session or something else? What are the distinguishing features that allow you to identify it as the same packet each time?

[chrisayres]

Tom,

The session between the user (U) and server (S) which is login.passport.com goes something like this.

The user enters their Hotmail username and password and click login, then the packets go like this

U -> S 70bytes S flag

S -> U 70bytes AS flag

U -> S 64bytes A flag

U -> S 136bytes AP flag

S -> U 64bytes A flag

and this is where it goes wrong the next packet is the one which fails to arrive

S -> U 1061bytes AP flag

on a non cisco dsl network the session continues OK, on cisco the

S -> U 1061byte AP flag packet is resent 4 times, each time the resend time is doubled. (3secs, 6secs, 12secs, 24secs)

Then

S -> U 64byte RST flag, resetting the TCP session.

This packet is receieved OK everytime.

Analysis of the seq's and ack's show that this is all part of the same TCP session

[michael.groves]

I managed to fix my .Net Passport problem by reducing the Maximum Segmant Size (MSS) on Ethernet0

ip tcp adjust-mss 1412

If this does not work, try 1360

Take a look at the following link which gives a good explanation

http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a0080093bc7.shtml

Let me know if it solves your problem.

Regards

Michael