Many of the references linked no longer go to the intended page.

In addition almost no one uses Windows 98 or the old style Mac OS
so don't bother including this in an FAQ.

Approved by:	bcr
This commit is contained in:
Eitan Adler 2012-08-09 15:16:34 +00:00
parent 029f1d38b8
commit e7138387cb
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=39342

View file

@ -9340,78 +9340,6 @@ ATDT1234567</programlisting>
</answer>
</qandaentry>
<qandaentry id=PPPoEwithNAT>
<question id="macos-win98-pppoe-freeze">
<para>Why do &macos; and &windows;&nbsp;98 connections freeze
when running PPPoE on the gateway?</para>
</question>
<answer>
<para>Thanks to Michael Wozniak
<email>mwozniak@netcom.ca</email> for figuring this out and
Dan Flemming <email>danflemming@mac.com</email> for the Mac
solution:</para>
<para>This is due to what is called a <quote>Black
Hole</quote> router. &macos; and &windows;&nbsp;98 (and maybe
other &microsoft; OSs) send TCP packets with a requested
segment size too big to fit into a PPPoE frame (MTU is
<literal>1500</literal> by default for Ethernet)
<emphasis>and</emphasis> have the <quote>do not
fragment</quote> bit set (default of TCP) and the Telco
router is not sending ICMP <quote>must fragment</quote> back
to the WWW site you are trying to load. (Alternatively, the
router is sending the ICMP packet correctly, but the
firewall at the WWW site is dropping it.) When the www
server is sending you frames that do not fit into the PPPoE
pipe the Telco router drops them on the floor and your page
does not load (some pages/graphics do as they are smaller
than a MSS). This seems to be the default of most Telco
PPPoE configurations.</para>
<para>One fix is to use <application>regedit</application> on
your 95/98 system to add the following registry entry:</para>
<programlisting>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU</programlisting>
<para>It should be a string with a value
<literal>1436</literal>, as some ADSL routers are reported
to be unable to deal with packets larger than this. This
registry key has been changed to
<literal>Tcpip\Parameters\Interfaces\<replaceable>ID for
adapter</replaceable>\MTU</literal> in &windows;&nbsp;2000
and becomes a <literal>DWORD</literal>.</para>
<para>Refer to the Microsoft Knowledge Base documents <ulink
url="http://support.microsoft.com/support/kb/articles/Q158/4/74.asp">Q158474 - Windows TCPIP Registry Entries</ulink>
and <ulink
url="http://support.microsoft.com/support/kb/articles/Q120/6/42.asp">Q120642 - TCPIP & NBT Configuration Parameters for &windowsnt;</ulink>
for more information on changing &windows; MTU to work with
a NAT router.</para>
<para>Another regedit possibility under &windows;&nbsp;2000 to
set the <literal>Tcpip\Parameters\Interfaces\<replaceable>ID
for adapter</replaceable>\EnablePMTUBHDetect</literal>
<literal>DWORD</literal> to <literal>1</literal> as
mentioned in the Microsoft document 120642 mentioned
above.</para>
<para>Unfortunately, &macos; does not provide an interface for
changing TCP/IP settings. However, there are several commercial
programs available that will allow users to customize TCP/IP
settings. &macos; NAT users should search for their MTU
settings and enter <literal>1450</literal> instead of
<literal>1500</literal>.</para>
<para>The &man.ppp.8; has an <command>enable
tcpmssfixup</command> command that will automatically adjust
the MSS to an appropriate value. This facility is enabled
by default. If you are stuck with an older version of
&man.ppp.8;, you may want to look at the <filename
role="package">net/tcpmssd</filename> port.</para>
</answer>
</qandaentry>
<qandaentry>
<question id="desperation">
<para>None of this helps &mdash; I am desperate! What can I