readme98.htm

学习书籍

    there will be no icon for it in the system tray. To
    disconnect the connection, double-click the <strong>Connection
    through </strong><em><strong>Adapter Name</strong></em> icon
    that was placed on the desktop to bring up the connection
    status and click the <strong>Disconnect</strong> button there.</p>
    <p><strong>Background:</strong> The installer places an entry
    under the <strong>RunOnce</strong> registry key to run itself
    after the reboot. When starting, <strong>Windows</strong>
    runs all entries under this key and waits for each one to
    finish <strong>before</strong> starting the shell. Thus, the
    connection will be established before the task bar is
    created, making it impossible for <strong>Dial-Up Networking</strong>
    to add a connection icon to the system tray.</p>
    <h4><a name="KnownIssue2"><u>7.2</u></a><u> Dial-Up Server
    does not recognize the dial-up devices exposed by the
    protocol until the machine is rebooted</u></h4>
    <p>If the installer starts the protocol dynamically without a
    reboot, it is possible to make <strong>outgoing</strong>
    connections with it, but the <strong>Dial-Up Server</strong>
    will not recognize the dial-up devices exposed by the
    protocol. The user must <strong>reboot</strong> the machine
    to make <strong>Dial-Up Server</strong> recognize the
    protocol's dial-up devices.</p>
    <p><strong>Background:</strong> The cause of this issue is
    undetermined.</p>
    <h4><a name="KnownIssue3"><u>7.3</u></a><u> When acting as a
    PPPoE Access Concentrator, Windows 98/98SE/ME machines cannot
    connect</u></h4>
    <p>When you configure a <strong>Windows 98/98SE/ME</strong>
    machine to act as a PPPoE <strong>Access Concentrator</strong>
    (server) and try to connect from another <strong>Windows 98/98SE/ME</strong>
    machine, the connection will hang during negotiation and
    cannot be successfully established. There is currently no
    workaround for this problem other than using a different
    operating system on the client or server machine. Connections
    with <strong>Windows 2000/XP/2002</strong> at either end work
    fine.</p>
    <p><strong>Background:</strong> <strong>Windows 98/98SE/ME</strong>
    negotiates the PPP options <strong>Address Field Compression</strong>
    and <strong>Protocol Field Compression</strong>, despite the
    protocol indicating that these options are <strong>not</strong>
    supported, since <strong>RFC 2516</strong> explicitly <strong>forbids</strong>
    these options for PPP over Ethernet connections. When there
    are <strong>Windows 98/98SE/ME</strong> machines at both
    ends, these options are successfully negotiated, but the
    machines can no longer communicate as soon as they are used.
    When there is a <strong>Windows 2000/XP/2002</strong> machine
    at either end, it will <strong>reject</strong> any of these
    options and the connection can be successfully established.</p>
</blockquote>

<hr>

<h3><a name="Section8"><u>8.</u></a><u> Revision History</u></h3>

<ul type="square">
    <li><h4>Version 0.96, May 29th, 2001</h4>
    </li>
</ul>

<blockquote>
    <ul type="disc">
        <li>First release with <strong>Intel Itanium 64-bit CPU
            support</strong>! The <strong>IA64</strong> version
            is distributed in a <strong>separate</strong> archive
            for now.</li>
        <li><strong>Fixed:</strong> Some code paths in the <strong>ProtocolReceivePacket()</strong>
            handler returned a non-zero value, which would not
            return the received packet to the network adapter
            driver, eventually causing it to run out of packets,
            making unable to operate. Fixed this by ensuring all
            code paths return zero.</li>
        <li><strong>Changed:</strong> The <strong>watchdog timer</strong>
            that checks <strong>every ten seconds</strong>
            whether any packets have been received will now send <strong>up
            to three LCP Echo-Requests</strong> before
            terminating the connection. Thus, a connection loss
            will now be detected <strong>within 40 to 50 seconds</strong>.
            This should cure the disconnection problems a number
            of users have been suffering from due to the watchdog
            timer being a bit too sensitive for some service
            providers.</li>
        <li><strong>Changed:</strong> When connecting to the <strong>unnamed
            default service</strong>, the protocol will now
            connect to the <strong>first offered</strong>
            service, even if it is not unnamed. This enhances
            compatibility with service providers who are not
            fully <strong>RFC 2516</strong> compliant.</li>
    </ul>
</blockquote>

<ul type="square">
    <li><h4>Version 0.95, December 29th, 2000</h4>
    </li>
</ul>

<blockquote>
    <ul type="disc">
        <li><strong>Added:</strong> <strong>A no-reboot installer</strong>
            (<font color="#FF0000"><strong>fully licensed version
            only</strong></font>) that <strong>installs</strong>,
            <strong>repairs</strong> or <strong>upgrades</strong>
            the protocol from a single, self-extracting
            executable, typically <strong>without</strong>
            requiring a reboot on <strong>any</strong> of the
            supported platforms. Additionally, it creates a dial-up
            connection and then prompts the user to connect to
            allow an <strong>&quot;instant success&quot;</strong>
            experience. The protocol will be added to the list of
            installed programs in <strong>Add/Remove Programs</strong>
            in <strong>Control Panel</strong> for convenient and <strong>complete</strong>
            uninstallation. Optional command-line switches allow <strong>silent</strong>
            installation, upgrade and removal for licensees who
            wish to provide their own installer front-end.</li>
        <li><strong>Added:</strong> <strong>Server capability</strong>.
            If one of the dial-up devices exposed by the protocol
            is configured to accept incoming connections, the
            protocol will offer the <strong>unnamed default
            service</strong> on the corresponding adapter and use
            the <strong>computer name</strong> set in the
            networking configuration as the <strong>Access
            Concentrator name</strong>. If the connection is
            accepted, the protocol will do a left-to-right (big-endian)
            comparison of the adapter's <strong>MAC address</strong>
            with the one of the connecting host, and generate an <strong>even</strong>
            (LSB 0) <strong>session identifier</strong> is the
            adapter's <strong>MAC address</strong> is <strong>lower</strong>,
            or an <strong>odd</strong> (LSB 1) one if it is <strong>higher</strong>,
            to ensure that two machines connecting to each other
            simultaneously do not generate <strong>identical</strong>
            session identifiers. The server is <strong>not
            industry-strength</strong>. There is <strong>no</strong>
            limit on the connections per <strong>MAC address</strong>,
            nor is any encryption being used in the <strong>Access
            Concentrator Cookies</strong> generated by the
            protocol, so a malicious user <strong>on the same
            Ethernet segment</strong> could <strong>occupy all
            incoming lines</strong> with a <strong>denial-of-service</strong>
            attack, but do no harm beyond that. Great care has
            been taken to <strong>minimize the load</strong> on
            the system if such an attack is made.</li>
        <li><strong>Added:</strong> <strong>Timers</strong>. The
            protocol now times out connection requests and
            resends requests two times, once after <strong>one
            second</strong>, then after <strong>two seconds</strong>,
            and <strong>three seconds</strong> after that
            indicates <strong>no answer</strong>. <strong>Incoming</strong>
            connections are offered for <strong>five seconds</strong>
            before being rejected. When a connection is
            established, a <strong>watchdog timer</strong> checks
            <strong>every ten seconds</strong> whether any
            packets been received, and generates and sends an <strong>LCP
            Echo-Request</strong> to the peer if no packet has
            been received since the last check. If at the next
            check still no packet has been received, the
            connection is terminated with <strong>no answer</strong>.
            Thus, a connection that was dropped by the other end <strong>without
            proper termination</strong> will be detected as lost <strong>within
            20 to 30 seconds</strong>.</li>
        <li><strong>Added: </strong>In <strong>Windows 98/98SE/ME</strong>,
            <strong>RASPPPOE.EXE</strong> now checks whether <strong>Dial-up
            Networking</strong> is installed and gives an error
            message if it is not. Additionally, it checks if <strong>NDIS.VXD</strong>
            version <strong>4.10.2222</strong> is installed, and
            warns the user to install fix <strong>Q243199</strong>
            if it is.</li>
        <li><strong>Added:</strong> In <strong>Windows 98/98SE/ME</strong>,
            <strong>WINPPPOE.DLL</strong> now adds a new value to
            the <strong>Packet Size</strong> setting of the <strong>Dial-Up
            Adapter</strong> called <strong>PPP over Ethernet</strong>,
            which sets the packet size to either the default (<strong>1492</strong>)
            or the <strong>overridden MTU</strong>.</li>
        <li><strong>Fixed:</strong> <strong>RASPPPOE.EXE</strong>
            would show <strong>erroneous</strong> query results
            if <strong>more than one</strong> <strong>Access
            Concentrator</strong> offered services, because the
            driver was returning an incorrect query result length.
            Fixed this by correcting the length calculation in
            the driver.</li>
        <li><strong>Fixed:</strong> In <strong>Windows 98/98SE/ME</strong>,
            <strong>RASPPPOE.EXE</strong> was unable to properly
            retrieve the names of network adapters which were 58
            characters or more long, which led to it displaying a
            <strong>blank</strong> adapter name and being unable
            to create a dial-up connection for the adapter. Fixed
            this by increasing the size of the retrieval buffer
            and limiting the size of the passed name.</li>
        <li><strong>Fixed:</strong> <strong>Windows 98/98SE/ME</strong>
            was unable to tell apart the dial-up devices exposed
            for two network adapters of the same name. Fixed this
            by appending a <strong>&quot;#X&quot;</strong> suffix
            to the dial-up device name if the protocol is already
            bound to a network adapter of the same name.</li>
        <li><strong>Fixed:</strong> In <strong>Windows 98SE/ME</strong>,
            <strong>NDIS.VXD</strong> versions <strong>4.10.2224</strong>
            (from fix <strong>Q243199</strong> for <strong>Windows
            98SE</strong>) and <strong>4.90.3000</strong> (included
            in <strong>Windows ME</strong>) randomly <strong>dropped</strong>
            packets received from the <strong>NE2000</strong> or
            the <strong>Realtek RTL8029(AS)</strong> driver
            without indicating them to the protocol for an
            unknown reason. Worked around this problem by adding <strong>NDIS_PACKET_TYPE_ALL_LOCAL</strong>
            to the packet filter if <strong>Windows 98/98SE/ME</strong>
            and one of these two drivers is detected, which makes
            <strong>NDIS.VXD</strong> work reliable again.</li>
        <li><strong>Fixed:</strong> If <strong>TAPI</strong>
            requested to <strong>drop</strong> a call, the
            protocol would not transition to the <strong>idle</strong>
            call state, because I had misunderstood a paragraph
            in the DDK documentation. This might also have been
            the cause of <strong>TAPISRV.EXE</strong> causing
            crashes in <strong>RPCRT4.DLL</strong> in <strong>Windows
            ME</strong>. Fixed this by reviewing all <strong>TAPI</strong>
            call state transitions and making sure the behavior
            is compliant with the DDK documentation.</li>
        <li><strong>Fixed:</strong> When running a <strong>repair</strong>
            or <strong>upgrade install</strong> on <strong>Windows
            2000</strong>, the protocol could <strong>crash</strong>
            the operating system with a blue screen indicating
            that <strong>RASPPPOE.SYS</strong> was unloaded
            without canceling pending operations. Investigation
            revealed that <strong>Windows 2000</strong> was
            trying to call the protocol's <strong>ProtocolPnPEventHandler()</strong>
            function after it had been unloaded, because the
            protocol had not been deregistered. Further
            investigation revealed that the <strong>ProtocolUnload()</strong>
            handler is never called in <strong>Windows 2000</strong>,
            which is <strong>not documented</strong> in the <strong>Windows
            2000 DDK</strong> documentation. Fixed this by
            providing a <strong>DriverUnload()</strong> handler
            again to deregister the protocol, and by putting the
            pointer to this function directly into the driver
            object in <strong>DriverEntry()</strong> to omit the <strong>NdisMRegisterUnloadHandler()</strong>
            call, which is not available in <strong>Windows 98</strong>.
            The <strong>ProtocolUnload()</strong> handler is
            still provided for <strong>Windows 98/98SE/ME</strong>.</li>
        <li><strong>Changed:</strong> <strong>RASPPPOE.EXE</strong>
            now displays a <strong>different</strong> error
            message if the user tried to query available services
            through an adapter which line is already in use by an
            active PPPoE session, explaining that the user needs
            to disconnect that session to be able to query
            services.</li>
        <li><strong>Changed: </strong>If more than one <strong>WAN
            Endpoint</strong> is configured for a network
            adapter, <strong>&quot;Line X&quot;</strong> suffixes