Cookie madness 1

[MrRetro]

Hello all
I have a problem driving me up the wall with 2 machines on a remote site. When they attempt to log into a webpage with an ID and password the page never comes up (takes a long time resolving it) and they get a page cannot be displayed error. I can take my computer in the very next room on the same site and log into that web page fine. My machine is identical to the other 2 having the problem (same OS, same IE, same service packs).
I can terminal into a remote machine on the other side of the country (different OS, same IE) and access the same webpage no problem as well.
I think it is a cookie problem, as I have a cookie from the webpage in my cookies folder and the 2 suspect machines dont.
I have tried logging in as admin, adding the site as trusted in IE, overriding the cookie settings within IE all to no avail. This is an important website needed for these guys to do business so it is crucial they get this access.

Thanks in advance for any help offered.

 

[bcastner]

http://support.microsoft.com/default.aspx?scid=kb;en-us;821814

http://www.microsoft.com/downloads/...familyid=6F7244DF-3BD7-48B3-A19E-3DCADF913045

The number one cause of secure site authentication failures is that the date and time settings are wrong on the computer.

Additional troubleshooting of secure sites:

http://www.helpwithwindows.com/WindowsXP/troub-10.html

Finally, if using broadband, be certain the MTU settings for the router and all clients is set correctly. For ADSL 1492 rather than the default of 1500 is the correct MTU size in most cases. (Dial-up it should get correctly).

 

[MrRetro]

Thanks for the reply

The site is located on the east coast falling under the Atlantic time zone, that is what the machines timezone are configured as...My machine (the one that connects fine) is set to central time...the webserver we are trying to hit is in the same Atlantic timezone so there should be no problem with the connetion.
We are all going out the same router to make this connection so I would think that would eliminate the mtu settings being an issue.
I have never had to request a hotfix from MS before and am not sure I want to if I have to pay for it.

 

[bcastner]

The router MTU setting affects or shapes the size of your outbound packets. You need to configure MTU on each client to shape inbound packets, a possible source of the problem.

DrTCP, freeware, makes it easy enough to do:

http://www.dslreports.com/drtcp

 

[MrRetro]

Thanks for the tip Bill, much appreciated.

I changed the clients MTU settings and all is well with the website...again thank you very much.

 

[bcastner]

You have made my day, sir.

I have for two plus years made the frequent suggestion that MTU size is important if using broadband, and usually get the response back: "No, that cannot be the issue. Give me some other fix."

The elusive factor is that MTU does not consistely appear to cause problems. Security concerns have heightened in the browser, OS and on web sites themselves with hotfixes and tougher standards; you have to make sure every element is right anymore (for secure sites in particular). It is such a painless thing to set MTU correctly, that I have always been surprised at the resistence I have seen to the suggestion that it be checked and set appropriately.

I should note above that this statement is a simplification of the truth: "The router MTU setting affects or shapes the size of your outbound packets. You need to configure MTU on each client to shape inbound packets, a possible source of the problem." There is a whole lot more involved in the actual process, but this is close enough to explaining how routers discover the MSS size of the packets to exchange.