Ref: Burton M. Strauss III <[EMAIL PROTECTED]>'s
message dated 18 September 2002, 18:29 hours.
> It's called a binary search ... see TAOCP by Donald Knuth...
>
> However, gang, I really thing that the MTU issue is a false flag. Unless
> some router in the path is refusing to fragment, all that a MTU mismatch
> would cause is lag and processing time. Besides, when you're making a
> tcp/ip connection ... that's a tiny packet ... the three way handshake is
> just headers (<100 bytes) and the http request is just a few browser headers
> and an http get command. Besides, if the fragmentation was causing lost of
> connection, she'd see timeouts, not an RST (Reset).
>
> However, let me clue you all into how fragmentation works:
>
> Say Irene's path has an MTU of 1500, except for one wanky router that's at
> 600.
>
> OK, so she sends a 1500 byte packet. It goes through the routers until it
> gets to the wanky one (that's a technical term, BTW). That router breaks
> her packet into 3 fragments...
>
> 0..600 601..1200 1201..1500
>
> And they travel the rest of the way that way (as separate fragments) until
> they're reassembled at a gateway or the destination. Fragments can be
> refragmented, but usually aren't reassembled (unless they hit a gateway). Or
> the ultimate destination. But it's entirely done under the covers by the
> underlying IP protocol. At the tcp/ip session level, it's invisible.
>
>
> If there were something with her browser settings, cookies, headers, etc.
> that was causing it, she would be able to see the opening http response
> through WebBug. Since WebBug was bounced, it can't be related to the
> browser.
>
>
> I remain convinced that the mit bbs is specifically blocking Irene or her IP
> block or her ISP, or she's failing reverse dns lookup or something. And the
> only place that's going to be able to address this is the bbs sysop.
>
>
> -----Burton
>
>
>
> -----Original Message-----
> From: Dave (by way of Dave <[EMAIL PROTECTED]>)
> [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 17, 2002 2:55 AM
> To: [EMAIL PROTECTED]
> Subject: Re: help with network problem
>
>
> Hi Irene,
> Although it seems unlikely that any public system would have a weird MTU
> - there is something to do to save time.
>
> Never just sequence when trying to find a fixed limit (unless there are very
> few possibilities.)
> If it is the maximum size that you are trying to find, try using 100 as a
> first test to make sure that that will work. If it doesn't very unlikely MTU
> is the problem, but you can try values under 100.
>
>
> If MTU 100 does work jump to 1464, then down to 700 up to 1150, up
> to 1300, etc
>
> You can follow the pattern ... roughly half the difference between known
> good
> value and known bad value for each jump.
>
> If you have some idea that it is going to be over 1400 try that value early
> in the sequence.
>
> This is fairly standard procedure for finding any unknown limit. (Or it is
> by
> me :) )
>
> /Dave
>
> > From: "Irene Xie" <[EMAIL PROTECTED]>
> > To: "ticker" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Sent: Monday, September 16, 2002 23:24
> > Subject: RE: help with network problem
> >
> > > Hi, Ticker,
> > >
> > > Thank you for your email and attention. I did take a look at the MTU
> >
> > stuff,
> >
> > > since it is a new stuff for me, and it requires to change the register
> >
> > file,
> >
> > > I hesitate to change it now and I will need more time to read the
> > > material before I do the changes. I was too busy to do that part. Seems
> > > that is the only part that I didn't get a chance to try yet. I will do
> > > that maybe late today or tomorrow since the machine is at my home.
> > >
> > > Since you did that before, I would like to ask you some special
> questions
> > > about the MTU. What is the range of the XXXX number that you use to
> ping,
> > > 1464 and lower? Does that mean 1464 to 1? Should I try 1464 then 1463
> and
> > > ....to 1 or there is some trick that I can follow?
> > >
> > > Thank you again and have a nice day!
> > >
> > >
> > > Irene
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: ticker [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, September 16, 2002 9:12 AM
> > > To: Irene; [EMAIL PROTECTED]
> > > Subject: Re: help with network problem
> > >
> > >
> > > Hi Irene...
> > > Someone mentioned earlier that your MTU might be too big, did you
> > > try to change it ? I had same kind of problems earlier and by changing
> > > the MTU to a smaller value, I was able to fix this problem.
> > >
> > > You can determine the MTU by doing:
> > >
> > > ping -f -l xxxx IP/name of the webserver that you are trying to access.
> > > For xxxx, start with 1464 and lower the number until you get a reply.
> > > Then add 28 to the highest number at which you get a reply.
> > > The result is the MTU that you should change to.
> > >
> > > /Jani
>
>
I have left all the posts to this thread on purpose because they are all
interesting in their own right.
The MTU, MSS et al settings depend on several issues, but, in basic terms
can be put this way:
#1 - On a LAN or not.
#2 - Using a modem or what
#3 - What OS the machine is running.
For a Win 9x series box, I would suggest a visit to www.hms.com and
download *iSpeed v 2.7.3* which is freeware and using that software set
your tcp/ip connection values, writing them to your Registry.
There is one entry that for reasons unknown must be changed manually,
namely:
HKLMachine\System\CurrentControlSet\Services\VxD\MSTCP\Parameters: set
the values to what your *iSpeed* settings are.
Here is a sample for a Windows 98 (OEM) box using a US Robotics 56K
modem:
MTU=576
MSS=536 (always 40 less than MTU)
RWIN=4288
TTL=128
MTU Auto Discover (yes, put a tick here)
MTU Black Hole Detection (yes, put a tick here)
NDI Cache Size=64
There are several interesting pages available (hms.com is one) where you
can read up on all the different types of web connections.
Hope this helps to the general idea. :-)
--
Richard H. Cotterell <mailto:[EMAIL PROTECTED]>
Son, when you grow up you will know who I really am. I am just
a child like you who has been forced to act responsibly.
-Rod Byrnes
