Re: Brower Fix Issue
- From: "John Tolmachoff \(Lists\)" <johnlist@xxxxxxxxxxxxxxxxxxx>
- To: "'[ISAserver.org Discussion List]'" <isalist@xxxxxxxxxxxxx>
- Date: Mon, 15 Sep 2003 13:22:28 -0700
> 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
Other related posts:
