Re: ICS with XP host, ME client not quite working

Tech-Archive recommends: Fix windows errors by optimizing your registry

On 5 Aug 2005 16:25:58 -0700, "Dazed" <kemps@xxxxxxxxxxxxx> wrote:

>Thanks . . . I feel like I'm getting closer but not quite there.
>
>The second link was most instructive, and allowed me to determine the
>maximum client MTU to be 1472. However, when I navigated through the
>registry to
>"HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ Class\ Net\"
>I was unable to find a key where the DriverDesc showed TCP/IP. (Two
>had "F5D5000 . . . ", the third had "Internet Connection Sharing".)
>Since I'm not much for experimenting with the registry, I didn't insert
>a MaxMTU key anywhere.
>
>Is the lack of a "TCP/IP" key unusual?
>
>I've also been speculating on why just now does this MTU problem crop
>up - I'm guessing it stems from the fact that when I first set up this
>network the original release of XP was on the host. Now that the host
>has been converted to SP1 perhaps system behavior got worse here, not
>better.
>
>Thanks -

Last question first. From what I've read, an MTU problem could happen to
anyone, at any time. It's a combination of four factors:
1) You are accessing a server that doesn't accept fragmented packets.
2) The route from your computer to that server somewhere involves a segment
that encapsulates your packets (causing an overhead of header bytes).
3) The overhead generated by encapsulating your packets causes them to be too
large for some router between you and the server in question, so your packets
then have to be fragmented (ie, one packet must be split into two).
4) Your MTU is set to the maximum value, to make your packets efficient for you
(and allowing for no overhead between you and any servers that you wish to
access).

You can control #4. You can control #1, by not accessing certain servers. You
cannot control #2 or #3.

One of the more common occurrence of the MTU setting problem starts with someone
having PPPoE DSL service, or accessing problem servers from an ICS client.
Since you're mentioning "client" and "host", I'm guessing that you have ICS in
there somewhere.

As far as changing the MTU value, I'm going to recommend that you use DrTCP.
Why do it by hand when you can use a free tool? See the updated copy of my
article:
<http://nitecruzr.blogspot.com/2005/06/internet-connectivity-problems-caused.html>

--
Cheers,
Chuck, MS-MVP [Windows - Networking]
http://nitecruzr.blogspot.com/
Paranoia is not a problem, when it's a normal response from experience.
My email is AT DOT
actual address pchuck mvps org.
.

Relevant Pages

  • Re: SBS 2003 Setup recommendation
    ... Your suggestion about MTU looks very interesting. ... We want something lige the following setup: http://pings.dk/sbssetup.gif ... agaist SBS2003 server. ... IPSec adds a small overhead the size of a packet which would make packets ...
    (microsoft.public.windows.server.sbs)
  • Re: Problem of blocking ICMP packet while calculating Path MTU
    ... > I am in process of implementing Path MTU detection technique. ... > process the received ICMP ECHO reply packets. ... > there is no need to write server code at all. ...
    (comp.os.linux.networking)
  • PROBLEM: Oops, nfsd, networking
    ... NFSD crash at large MTU and odd wsize/rsize. ... over NFS to a Linux NFS server. ... Our product is essentially a high end media server that takes in up to ... null getattr setattr root lookup readlink ...
    (Linux-Kernel)
  • Re: 64K limit for socket send
    ... 150 MTU, isn't it better for the server to send 1500 size packets ... arrive at the receiver for the datagram to be reassembled. ...
    (comp.os.vms)
  • Understanding path MTU discovery
    ... As far as I can tell from my reading, if a computer on the internet accesses our web server, but the reply from the server is too big (for example, the client computer is using a PPPoE link with an MTU of 1492), the client's ISP's gateway router will send an ICMP package back to our router. ... I understand that I could mark incoming packets from clients so that replies are sent out through the same interface they came in, but I would prefer to balance the output packets. ...
    (comp.os.linux.networking)