Re: Brower Fix Issue
- From: "Jeff Sloan" <jsloan@xxxxxxxxxxxx>
- To: "ISALists" <isalist@xxxxxxxxxxxxx>
- Date: Mon, 15 Sep 2003 15:50:25 -0500
You seem to be light years ahead on IP than I am.
I know how to set the IP address.
I don't have a clue about subnet masks and the like.
I get paid for telling the client to 'try re-booting your machine',
Can you see it now? Good.
Jeff Sloan
Network Administrator
Cross Oil Refining & Marketing, Inc.
484 E. 6th St.
Smackover, AR 71762
-----Original Message-----
From: John Tolmachoff (Lists) [mailto:johnlist@xxxxxxxxxxxxxxxxxxx]
Sent: Monday, September 15, 2003 3:22 PM
To: ISALists
Subject: [isalist] Re: Brower Fix Issue
http://www.ISAserver.org
> But,
> I do have issues with any solution that requires making MTU changes at
> the client. At least manually.
> MS, or who ever, should fix the problem through a supported fix, not a
> set of instructions for editing the registry.
> I know some things are inevitable, but I would hate to have to edit
> several hundred registries.
> I guess some kind of script would do it for you, but that is hard to
> track on who has applied it and who has not.
I agree Jeff. Up to now, I was under the impression that the root of the
cause were routers on the Internet disrupting the MTU path/size
negotiation and new security "features" on those websites experiencing
the problem.
What I would love to see is a packet trace on a computer that is having
problems connecting before and after applying the patch. I am not a
betting man, but I would not be surprised if the patch does end up
altering or allowing the MTU size to be altered.
Normally, the session initiator (client computer) and the session
receiver (website on a web server) negotiate the MTU size if the default
can not be accommodated. This is done through ACK and response packets.
However, sometimes other things get in the way and cause problems. PPPoE
is a good one for causing problems. So are blackhole routers. Many
times, the firewall or router at the client will see these problems, and
take matters into its own hands and fragment the packets to a smaller
size and send them on their way. This is perfectly fine and allowed.
However, problems occur when there are routers or security
configurations in the way that either do not allow the maximum MTU size
to be found, or drop fragmented packets. Normally, the session initiator
will sense a problem by receiving an ACK from the router or firewall and
retry.
But in the cases that are coming up with secure sites, it appears that
no packets are sent back to the session initiator after the initial
setups, instead they are being silently dropped. What is left is the
client in a waiting state until timeout occurs.
Now, I am not technically an expert in TCP/IP, but this is what I have
been able to gather and understand over the last several months.
John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com
------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Other Internet Software Marketing Sites:
Leading Network Software Directory: http://www.serverfiles.com No.1
Exchange Server Resource Site: http://www.msexchange.org Windows
Security Resource Site: http://www.windowsecurity.com/ Network Security
Library: http://www.secinf.net/ Windows 2000/NT Fax Solutions:
http://www.ntfaxfaq.com
------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion List as:
jsloan@xxxxxxxxxxxx To unsubscribe send a blank email to
$subst('Email.Unsub')
Other related posts: