RASPPPOE ReadMe for Windows 2000/XP/2002 Users
RASPPPOE
PPP over Ethernet Protocol
for Windows 2000/XP/2002
(If you are using Windows
98/98SE/ME, please click here)
written by Robert Schlabbach
Version 0.96, May 29th, 2001
Contents
1. Introduction
Welcome to RASPPPOE, a PPP over Ethernet
(short: PPPoE) implementation for Windows
98/98SE/ME/2000/XP/2002. PPPoE as a method for establishing PPP
connections through Ethernet adapters is described in RFC 2516
and is used by many broadband service providers to allow authentication and
maintain the familiar "dial-up experience" when connecting to the Internet
through a broadband modem. Although there are other PPPoE implementations for
Windows, this one still has its unmatched strong points:
- Designed exclusively for Windows 2000
from ground up and then ported to Windows
98/98SE/ME, not the other way around.
- Seamless integration into the operating system. This
protocol makes Ethernet Adapters appear as
"modems", allowing PPPoE to be easily used within the
standard Dial-Up Networking framework.
- Compatibility: This protocol supports Internet
Connection Sharing (including on-demand dialing),
power management (Standby and
Hibernate) as well as multiprocessor
systems.
- Completeness: This protocol can not only act as a PPPoE
Host (client), but also as an Access
Concentrator (server), fully implementing RFC 2516.
- Compactness: The complete protocol is less than
200 KB. Yet no concessions were made in the
implementation.
To install this protocol, please follow the installation
instructions carefully. If you have problems using it, see Troubleshooting
for help. If you are successfully using this protocol, you can check if you find
any of the advanced
features useful. You may also want to know about the known
issues. Users upgrading from a previous version of this protocol should
check the Revision
History to find out what changed. If you want to get in touch with me, see
Contacting
the Author.
- Robert Schlabbach
License and Disclaimer
This driver, installation files and documentation is all Copyright
(C) 2000-2001 by Robert Schlabbach. All rights reserved. It is
distributed without any warranty. Use at your own
risk. You may use and copy it complete and unmodified
free of charge for non-commercial purposes only. Commercial
exploitation, redistribution for commercial purposes, especially redistribution
by Internet service providers as "their" service to their customers, is
strictly prohibited. Internet service providers must purchase a
license for distribution to their customers. The licensed version additionally
features an installer, which typically requires no reboot and
leads the user to the first login for an "instant success"
customer experience. For licensing details please contact me.
2. Installing the PPP over Ethernet
Protocol
- WARNING: You are about to
install a driver. Since any driver installation poses a
non-zero risk of crashing your operating system, you are advised to save your
work and close all running applications before proceeding.
- Since you are about to install a driver, you will need
administrative privileges to perform the installation. If you
are logged on to a user account, log off and log on to an account with
administrative privileges before proceeding.
- If there is already a different PPPoE implementation
installed on your machine, it might get confused by the PPPoE traffic
generated by this protocol. This protocol was written to peacefully coexist
with other PPPoE implementations on the same machine, but other programmers
may not have been as thoughtful. Thus, it is recommended (but
not required!) that you uninstall any other
PPPoE implementations and reboot your machine before
proceeding.
- Unpack the downloaded archive to a temporary installation directory. Make
sure that the following files are correctly extracted:
README98.HTM, README2K.HTM,
NETPPPOE.INF, RASPPPOE.INF,
WINPPPOE.INF, WINPPPOE.DLL,
RASPPPOE.DLL, RASPPPOE.EXE and
RMSPPPOE.SYS. NOTE: The Intel Itanium
64-bit CPU release only contains the files README2K.HTM,
NETPPPOE.INF, RASPPPOE.INF,
RASPPPOE.DLL, RASPPPOE.EXE and
RMSPPPOE.SYS.
- If you are running Windows 2000, right-click the
My Network Places icon on your desktop and select
Properties to bring up the Network and Dial-up
Connections window.
- If you are running Windows XP/2002, click the
Start button, select Control Panel, then
click Network and Internet Connections and then click the
Network Connections control panel icon to bring up the
Network Connections window.
- Go to the menu and select View then
Details to bring up a detailed view of the network
connections on your machine.
- You should find one or more Local Area Connection
objects. Locate the one for the network adapter connected to your broadband
modem (you should be able to tell by the name in the Device
Name column), right-click it and select Properties.
- In the properties dialog box, click the Install...
button.
- In the Select Network Component Type window, select
Protocol and click the Add... button.
(Note: It could take a few seconds for the following window
to come up.)
- In the Select Network Protocol window, click the
Have Disk... button.
- In the Install From Disk window, either type the name of
your temporary installation directory or click the Browse...
button to navigate to it (it does not matter which of the three
INF files you select, Windows will
automatically pick the right one later). Then click the OK
button. A new window opens, offering the PPP over Ethernet
Protocol for installation. Click OK to start
installing the protocol.
- During installation, a window titled Digital Signature Not
Found (Windows 2000) or Hardware Installation
(Windows XP/2002) may come up several times (typically four
times per installed network adapter), warning you that the
driver has no digital signature or Windows Logo. Make sure you click
"Yes" (Windows 2000) or "Continue Anyway"
(Windows XP/2002) every time you are prompted to allow
successful installation of the protocol.
- Back at the Local Area Connection Properties window,
click Close to close the window. Note: If
you have a network adapter dedicated to your broadband modem,
it is recommended that you first clear the checkboxes for
all other components listed and leave only PPP over
Ethernet Protocol checked.
- If you have more than one network adapter in your system, you may want to
disable the PPP over Ethernet Protocol for all adapters but
the one your broadband modem is actually connected to. To do this, bring up
the properties of each network adapter to want to disable the
protocol for and clear the checkbox next to PPP over Ethernet
Protocol in the listed components. BEWARE: If you
accidentally disable the protocol for the network adapter you want to connect
through, simply re-checking the checkbox, even if you do so immediately, may
not be enough to make the protocol functional on that network
adapter again. See Known
Issues for a more detailed explanation and possible workarounds.
- The protocol is now fully functional, but you still need to create a
dial-up connection to use it. See the next section for details.
3. Creating PPP over Ethernet Dial-up
Connections
PPP over Ethernet dial-up connections can be most conveniently created with
the Dial-up Connection Setup application provided with the
protocol, which creates dial-up connections with all the correct settings at the
click of a button.
- Click the Start button on the taskbar and select
Run... to bring up the Run dialog box.
- Type RASPPPOE in the edit field and click the
OK button to run the Dial-up Connection
Setup application.
- If the application quits with an error message, follow the advice it
gives.
- A dialog box comes up with a combo box labeled Query available PPP
over Ethernet Services through Adapter: at the top. Select the
network adapter your broadband modem is connected to from the list. If the
protocol is only operating on one network adapter, the box will be grayed out
as there is no choice to make.
- Generally, it is recommended that you create a connection
for an adapter, not for a specific service, so that it
continues to work even if your service provider changes the server or service
name. To do this, simply click the Create a Dial-up Connection for the
selected Adapter button now. Shortly afterwards, a shortcut to the
new dial-up connection named Connection through
Adapter Name should show up on your
desktop.
- If you want to create a connection for a specific
service, click the Query Available Services button.
The application will send out a query for offered services and display the
result in the list view below. If an error message is displayed, see Troubleshooting
for help. Otherwise, select the desired service and the button below will
change to Create a Dial-up Connection for the selected
Service. Click the button to create a connection for this service.
Shortly afterwards, a shortcut to the new dial-up connection named
Connection to Service Name
at Access Concentrator or
Connection to Access Concentrator
(if the connection is for the default service) should show up on your desktop.
- After you have created the connection(s) you need, click the
Exit button to quit the application.
- Double-click the desktop icon for the dial-up connection you created.
- In the Connect Connection Name
window, enter your user name and password if your service provider requires
authentication.
- Click on the Dial button. If all goes well, you should be
connected to the Internet almost instantly. If not, see Troubleshooting.
4. Removing the PPP over Ethernet
Protocol
- WARNING: You are about to
remove a driver. Since any driver removal poses a non-zero
risk of crashing your operating system, you are advised to save your work and
close all running applications before proceeding.
- Since you are about to remove a driver, you will need
administrative privileges to perform the removal. If you are
logged on to a user account, log off and log on to an account with
administrative privileges before proceeding.
- If you are running Windows 2000, right-click the
My Network Places icon on your desktop and select
Properties to bring up the Network and Dial-up
Connections window.
- If you are running Windows XP/2002, click the
Start button, select Control Panel, then
click Network and Internet Connections and then click the
Network Connections control panel icon to bring up the
Network Connections window.
- First, you may want to remove all dial-up connections you created for
connecting through this protocol. To do so, right-click each of the dial-up
connections you created for this protocol and select Delete.
If you had created any shortcuts to these dial-up connections on your desktop,
right-click them and select Delete as well.
- If you are running Windows 2000, you must first unbind
the protocol from all network adapters to ensure that it is
unloaded from memory. This step is not
necessary if you are running Windows XP/2002. BEWARE: Do NOT do this
if you currently have a RASPPPOE version prior to
0.95 installed as these versions may CRASH the
operating system when unbinding the protocol from the last network adapter. In
that case, skip the next step and reboot
after uninstalling the protocol to remove it from memory.
- To unbind the protocol from all network adapters, right click each
Local Area Connection, select Properties and
clear the checkbox next to PPP over Ethernet
Protocol and close the properties dialog with the OK
button. After clearing the last checkbox, the protocol is unloaded from memory
- Right-click any Local Area Connection
and select Properties.
- In the list of components, select PPP over Ethernet
Protocol and click Uninstall.
- A dialog box comes up asking you to confirm the removal. Make sure that
you are really about to uninstall the PPP over Ethernet
Protocol and click Yes.
- Back at the Local Area Connection Properties window,
click Close to close the window.
Note: The protocol is not completely
removed from your machine at this point due to shortcomings of
Windows, which prohibit a complete removal. The pieces that are
left behind are not harmful in any way, but if you want to get
rid of every little bit of this protocol, here is what's left behind:
- If you are running Windows 2000, the protocol's
Notify Object, named RASPPPOE.DLL, is left
behind in your \WINNT\SYSTEM32 directory. You can safely
delete it at this point. Automatic deletion fails due to a bug in
Windows 2000 (see Known
Issues). In Windows XP/2002, this file is automatically
deleted.
- In your \WINNT\INF directory, the protocol's
INF file and its precompiled version is left behind, named
oem#.inf and oem#.PNF, respectively.
"#" stands for a number that varies with the number of third
party drivers you installed on your machine. This means that you will have to
identify the INF by loading each of your
oem#.inf files into a text editor, e.g.
NOTEPAD. The PPP over Ethernet Protocol
INF identifies itself as such right in the second line of the
file. Once you have identified the INF, delete it and the
corresponding PNF file as well. This is not a bug, but
Microsoft's design. These files cannot be removed automatically due to the
varying name.
- Even if the protocol has been completely removed from hard disk and
memory, the dial-up devices that were exposed by it will be
shown in the properties of any dial-up connection until you
reboot. This is a bug in Windows (see Known
Issues).
5. Advanced Protocol Features
This section covers the advanced features of the protocol. Average users
should be perfectly happy with the default settings, although specifying
the link speed to display may be of interest. Users having problems with VPN
software might try if overriding
the MTU reported by the protocol helps. Users with flat rate Internet access
may be interested in making the
connection "always on". If you are interested in using the protocol's server
capability, please see Enabling the
protocol to act as a PPPoE Access Concentrator.
To bring up the protocol settings for an adapter:
- If you are running Windows 2000, right-click the
My Network Places icon on your desktop and select
Properties to bring up the Network and Dial-up
Connections window.
- If you are running Windows XP/2002, click the
Start button, select Control Panel, then
click Network and Internet Connections and then click the
Network Connections control panel icon to bring up the
Network Connections window.
- Locate the Local Area Connection (Note well:
not your dial-up connection entry!) of the adapter the
protocol settings of which you wish to modify, right-click it and select
Properties.
- In the list of components used by this connection, select PPP over
Ethernet Protocol (BEWARE: You must
not click on the checkbox, as this will disable the protocol
for this adapter! Make sure you click on the protocol name)
then click the Properties button to bring up the protocol's
settings for this adapter.
- Changes to the protocol settings take effect when you close the
PPP over Ethernet Protocol Properties window with the
OK button unless noted otherwise.
The General tab offers the following settings:
5.1 Limit TCP MSS Maximum Segment Size
(MSS) Option
When using Internet Connection Sharing, the client
machines are completely unaware of the packet size restrictions imposed by the
nature of PPP over Ethernet (in contrast to e.g.
modem or ISDN connections, which allow
passing arbitrarily sized packets). Typically, a client assumes that packets
of up to 1500 bytes can be passed and thus indicates a
Maximum Segment Size of 1460 bytes (1500
bytes minus 40 bytes for the TCP and IP headers) when opening a
TCP session, resulting in either side of the connection
sending packets up to 1500 bytes in size, too large to pass
through a PPP over Ethernet connection, which can only pass packets up to
1492 bytes in size. These oversized packets are then often
silently dropped at either side of the PPP over
Ethernet connection, leading to delays or
hangs when accessing the Internet from a client.
To work around this problem, this option makes the protocol scan all
network packets it sends and receives for the TCP Maximum Segment Size
(MSS) option and, if a value greater than either the default
(1492) or the overridden MTU minus
40 for the IP and TCP headers (i.e. 1452 in case of
the default MTU) is found, change it to this value,
recalculate the TCP checksum and pass the modified packet. This option is
enabled by default. If you are not using
Internet Connection Sharing, you can disable
this option to save a little (very little) CPU power, although leaving it
enabled has no negative side effects.
5.2 Override Maximum Transfer
Unit
By default, the protocol will report an MTU of 1492 bytes,
the maximum possible for PPP over Ethernet. However, you can use this option
to override the MTU initially reported by the protocol. Making the protocol
initially report a lower MTU was found to help with certain
VPN software packages which "blindly" add their own overhead without paying
any respect to the MTU reported by the driver, making the network packets too
large to pass through a PPP over Ethernet connection. Check the
Override Maximum Transfer Unit checkbox and type the MTU the
protocol should report in the Maximum Transfer Unit (MTU)
edit box. The valid range is 576 through
1492 bytes. Reducing the MTU by 32 bytes to
1460 should generally suffice to make misbehaved VPN software
work. Note: Regardless of this setting, the protocol will
always send and receive packets of up to 1492 bytes. Only the
MTU initially reported by the protocol (the
MaxFrameSize value in response to the
OID_WAN_GET_INFO request) and, if enabled, the TCP MSS
option limit are affected by this setting.
For any changes to this setting to take effect, you need to
disable and re-enable the Local Area
Connection for the corresponding network adapter once, or
reboot.
NOTE: This option will only "stick" if you enter an MTU
other than 1492. If you only check the checkbox, but leave
the MTU at 1492, the protocol will recognize the default
value and clear the checkbox the next time you open the
properties dialog, because the MTU was not actually overridden.
5.3 Number of lines (WAN
endpoints)
The protocol is capable of running several simultaneous PPP over Ethernet
sessions through one adapter. This feature will probably be very rarely - if
ever - needed. To allow this, you can configure the number of WAN endpoints
(dial-up devices) the protocol exposes for a network adapter. The default is
1, and up to 10 WAN endpoints can be configured. This setting requires a
reboot to take effect.
The Advanced tab offers the following settings:
5.4 Specify Link Speed
By default, the protocol will report the speed of the network adapter you
are connecting through as the speed of a dial-up connection you make through
it, as it cannot find out the actual speed of your broadband modem. However,
you can specify the connection speed the protocol should report for
connections through a specific adapter. To do this, check the Specify
Link Speed checkbox and type the link speed the protocol should
report in the Link Speed (kbps) edit box, in kilobits per
second. If you want to revert to displaying the adapter's link speed, clear
the Specify Link Speed checkbox. Note: This
setting has absolutely no effect on the network traffic
through this adapter; it is purely a cosmetic setting. This
setting takes effect the next time you establish a PPP over
Ethernet connection.
5.5 Event Logging options
The protocol can inform you about informational events, warnings and errors
during operation by logging events to the System event log.
By default, the protocol logs all types of events, which
should result in no log entries during flawless operation. If you find the
event log flooded with repeated entries despite flawless operation, you can
disable logging that type of event by clearing the corresponding checkbox.
Clearing all checkboxes prevents the protocol from logging
any events.
- Log Informational Events will log any vendor-specific
information received.
- Log Warnings will log non-fatal warnings that do not
necessarily prevent successful operation.
- Log Errors will log fatal errors that prevent correct
function of the protocol.
You use Event Viewer to view any events logged by this
protocol:
- Right-click the My Computer icon on your desktop and
select Manage to bring up the Computer
Management window.
- In the tree on the left-hand side, expand the Event
Viewer branch, select the System sub branch and
press F5 to refresh the view on the right-hand side. Look
for log entries from source RMSPPPOE there.
- To get a detailed description of a logged event, double click the event
in the view on the right-hand side.
Beyond these settings, the protocol offers the following possibilities:
5.6 Making a dial-up connection "always
on"
Users who enjoy flat rate Internet access may find it desirable to turn
their connection into an "always on" connection that is
established once when the machine boots (before any user logs in) and kept
until the machine is shut down. To make your dial-up connection
"always on", follow these steps:
- If your service provider requires authentication, make sure you have
saved the password by checking the Save Password checkbox
in the Connect Connection Name
window and connecting at least once.
- Right-click the My Network Places icon on your desktop
and select Properties to bring up the Network and
Dial-up Connections window.
- Locate the Dial-up connection you created for
PPP over Ethernet, right-click it and select
Properties.
- Select the Options tab and clear all
checkboxes under Dialing options.
- Under Redialing options, set Idle time before
hanging up: to never and check the Redial
if line is dropped checkbox.
- Click OK to save the changes.
- Now click the Start button, select
Settings then Control Panel to open the
Control Panel window.
- In the Control Panel window, double-click
Scheduled Tasks.
- In the Scheduled Tasks window, double-click Add
Scheduled Task.
- On the welcome screen of the Scheduled Task Wizard,
click Next.
- At the program selection step, click Browse... and
browse to your WINNT\System32 directory.
- Type RASPHONE.EXE (note the
spelling!) in the File name: edit box or locate it in the
directory and select it and click Open.
- Make up a name for this task and under Perform this
task: select When my computer starts. Click
Next.
- Enter your password. Note: The task
must be run under the same account which the dial-up entry
was created under.
- At the final step, make sure that Open advanced properties for
this task when I click finish is checked and click
Finish.
- In the advanced properties, edit the Run: edit box and
append the command-line parameters " -d
"Connection Name"".
- Go to the Settings tab and clear all
checkboxes on that page.
- Click OK to close the task's properties.
- Finally, you need to make a little registry change to prevent
Windows from disconnecting when a user logs on and off
again:
Run REGEDIT and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon
Then right-click the right-hand pane, select New -> String
Value, name the value KeepRasConnections and set
it to 1.
- Reboot. Windows will establish the
connection automatically and keep it until you shut the machine down.
- NOTE: The connection will not be
properly terminated when shutting the machine down or rebooting. This can
cause problems with service providers who take very long to detect such a
dropped connection and limit the number of concurrent connections. See Known
Issues for further details.
5.7 Addressing a specific Service and/or
Access Concentrator
In most cases, there is no need to address a specific
Service or Access Concentrator. But should you have a need to do so, you can
use the phone number field of your dial-up connection to
specify a Service, Access Concentrator or
both. The following phone number formats are possible:
- Blank or "0": The protocol will
connect to the default Service of the
first Access Concentrator that replies to
the connection request.
- "Service-Name": The protocol will connect to the
first Access Concentrator that replies
offering the requested Service.
- "Access-Concentrator\": The protocol will connect to
the default Service of the named Access
Concentrator.
- "Access-Concentrator\Service-Name": The protocol will
connect to the requested Service of the
named Access Concentrator.
The RASPPPOE application uses format A
for the phone number if you create a connection for an
adapter and format C or D
if you create a connection for a specific service.
5.8 Enabling the protocol to act as a
PPPoE Access Concentrator
The protocol is able to act as a PPPoE Access Concentrator
(server). This feature can be used for testing purposes, but also offers a
future potential for advanced provider services like
instant messaging or instant e-mail even for
users who are offline at the time a message is received. The
server capability is fully integrated with the operating system's
Incoming connections component. No PPPoE-specific
configuration is needed. The protocol uses the current Computer
Name as the Access Concentrator Name and offers
any Service Name requested by a client. Note that the
protocol will not offer any services until you
explicitly enable its dial-up devices to accept incoming
connections. To do this, follow these steps:
- Right-click the My Network Places icon on your desktop
and select Properties to bring up the Network and
Dial-up Connections window.
- Double-click Make New Connection and click
Next.
- Select Accept incoming connections and click
Next.
- The list of Connection devices should contain the names
of the network adapters in your system. Check all network adapters through
which you want to accept incoming connections and click
Next.
- Choose whether you want to allow virtual private
connections and click Next.
- Select the user accounts which should be allowed to connect to your
machine and click Next.
- Select the networking components you want to enable for the incoming
connections. Note that PPP over Ethernet Protocol will also
be shown in this list, but its checkbox will be grayed out.
- If you enable the Internet Protocol (TCP/IP) for
incoming connections, you may also want to click on the
Properties button to define the IP
addresses to use for the incoming connections.
- Click Next and then click Finish to
finish the wizard and enable the server. The Network and Dial-up
Connections window will now contain an additional item named
Incoming Connections.
- If you want to disable the server only for a specific network adapter,
right-click the Incoming Connections item, select
Properties, clear the checkbox next to the
name of that network adapter and click OK to stop the
protocol from offering services on that network adapter.
- If you want to disable accepting any connection on your
machine (not only through this protocol, but through all
dial-up devices installed on your machine), right-click the Incoming
Connections item, select Delete and confirm to
stop the protocol from offering any services.
For further help on using Incoming Connections, please
refer to the operating system's documentation on this topic.
6. Troubleshooting
This section helps you with possible problems you might encounter during the
installation and use of the protocol.
6.1 Right after installation of the
protocol, the Local Area Connection properties window lists no
components
This happens when the protocol could not be properly installed and appears
to be a bug in Windows. Clicking the OK
button at this point gives an error message that no components are installed.
Click the Cancel button to close the properties dialog and
then re-open it again to get the list of components back. Select PPP
over Ethernet Protocol in the list, click the
Uninstall button and confirm to remove the bad installation.
Before you make another installation attempt, make sure that
Windows is not set to block
the installation of unsigned drivers:
- Right-click the My Computer icon on your desktop and
select Properties.
- Select the Hardware tab and click the Driver
Signing... button.
- Make sure that File signature verification is
not set to Block - Prevent installation of unsigned
files.
- Change the setting if required and click OK to put the
change into effect.
If File Signature verification is set to Warn -
Display a message before installing an unsigned file, make sure you
click "Yes" (Windows 2000) or "Continue
Anyway" (Windows XP/2002) every time in the warning
dialog box that comes up during the protocol installation. Clicking any other
button even just once will prevent proper installation and result in the same
problem.
If you still cannot install the protocol properly, do the following: Locate
the file SETUPAPI.LOG in your WINNT
directory and delete it. Make another installation attempt
(which will probably fail as well). Then check your WINNT
directory again for the file SETUPAPI.LOG and load it into a
text editor, e.g. NOTEPAD. The contents of this file should
give you some hints abut the cause of the installation failure.
6.2 RASPPPOE application does not list the
desired adapter
First, be aware that you can use this protocol only on
Ethernet adapters. As PPP over Ethernet only
works over Ethernet, the protocol will only bind itself to Ethernet adapters
(NdisMedium802_3). Adapters that do not support this medium
type (e.g. internal or USB broadband modems that do not
expose a standard Ethernet interface through their driver)
are not supported by this protocol.
You should make sure that the Local Area Connection for
the adapter in question is enabled:
- Right-click the My Network Places icon on your desktop
and select Properties to bring up the Network and
Dial-up Connections window.
- Go to the menu and select View then
Details to bring up a detailed view of the network
connections on your machine.
- You should find one or more Local Area Connection
objects. Locate the one for the network adapter in question, and check the
Status column.
- If the Status is disabled, right-click the
Local Area Connection and select Enable.
- If enabling fails, check in Device Manager for possible
problems with this adapter.
- If you successfully enabled the adapter, re-run the
RASPPPOE application and check whether the adapter is
listed now.
If the adapter still does not show up, make sure that the protocol is
enabled for the adapter in question:
- Right-click the Local Area Connection of the adapter in
question and select Properties.
- In the properties dialog box, check the list of installed components.
Make sure that the checkbox next to PPP over Ethernet
Protocol is checked.
- If the checkbox is clear, check it. You may be prompted
about the digital signature again. Make sure you click
"Yes" every time you are prompted.
- If the Local Area Connection properties dialog box
lists no components now, see above.
- Click OK to close the Local Area
Connection properties dialog box.
- Right-click the Local Area Connection in the
Network Connections window and select
Disable.
- Right-click the Local Area Connection again and select
Enable.
- Re-run the RASPPPOE application and check if the
adapter is listed now.
If the adapter still does not show up, try the
following:
- Right-click the Local Area Connection in the
Network Connections window and select
Disable.
- Right-click the Local Area Connection again and select
Enable.
- The RASPPPOE application should list the desired
adapter now.
6.3 RASPPPOE application reports "RASPPPOE
- No Service Offers Received" when querying available services
This error message means that the protocol did not receive
any response from your service provider. You should check the
following things in order:
- Check if your broadband modem has successfully established a link with
its counterpart. Most DSL modems have a Sync LED on them
which indicates this status. If your modem has such an LED and it indicates
that the link is down, contact your service provider for assistance.
- Check in Device Manager if the network
adapter your broadband modem is connected to is enabled and working
properly.
- Check if your network adapter is correctly configured: Bring up
Device Manager, select the network adapter your broadband
modem is connected to and click Properties. In the
Properties window, select the Advanced
tab, look through the options and make sure that the correct Line
Speed and duplex mode is selected (most DSL modems
only support 10Mbps half duplex mode). If your network
adapter has several connectors at the back, make sure the correct connector
is selected, which is most likely Twisted Pair (TP).
- Check that the cable connecting your broadband modem to your network
adapter is properly attached and of the correct type. Note that broadband
modems typically have a "crossed" connector on them, so you
will need a straight cable to connect it
directly to a network adapter, while you need to use a
crossed cable or use an
uplink port to connect it to a hub or
switch.
- Check with your service provider whether they currently have a service
outage.
6.4 Connection attempt fails with "Error
797: The connection failed because the modem (or other connecting device) was
not found."
This can be the result of unbinding the protocol from an adapter and then
re-binding it, which may not have taken effect (see Known
Issues). Follow these steps to put the change into effect:
- Right-click the My Network Places icon on your desktop
and select Properties to bring up the Network and
Dial-up Connections window.
- Go to the menu and select View then
Details to bring up a detailed view of the network
connections on your machine.
- You should find one or more Local Area Connection
objects. Locate the one for the network adapter in question, right-click it
and select Disable.
- Right-click the Local Area Connection again and select
Enable.
- Make another connection attempt and see if it works.
If that did not help, the dial-up connection you created
may be configured to connect through a "ghost" dial-up device
that no longer exists. Do the following to remedy this:
- Right-click the dial-up connection that failed to
connect and select Properties.
- In the Connect using: list view, take a close look at
the name of the dial-up device that is checked. A "ghost"
dial-up device has the name format ISDN channel -
Adapter Name (xx), while
a correct entry is of the format ISDN channel -
Adapter Name, i.e. the extra
(xx) identifies a "ghost" device.
- If the checked device is indeed a "ghost" device, clear
it, look through the list for the correct dial-up device
and check that one instead.
- Make another connection attempt.
6.5 Connection attempt fails with "Error
678: There was no answer."
First, you should check whether you can get any reply from
your service provider with the Dial-up Connection Setup
application provided with the protocol:
- Click the Start button on the taskbar and select
Run... to bring up the Run dialog box.
- Type RASPPPOE in the edit field and click the
OK button to run the Dial-up Connection
Setup application.
- If the application quits with an error message, follow the advice it
gives.
- A dialog box comes up with a combo box labeled Query available
PPP over Ethernet Services through Adapter: at the top. Select the
network adapter your broadband modem is connected to from the list. If the
protocol is only operating on one network adapter, the box will be grayed
out as there is no choice to make.
- Click the Query Available Services button. If an error
message is displayed, continue here
for further help.
- If the list view shows one or more offered services and you had tried to
connect to a specific Service and/or
Access Concentrator, make sure the one you had tried to
connect to is listed. If you find your provider has changed the Service Name
and/or the Access Concentrator name, simply create a new connection with the
new name(s) or edit the Phone number field in your existing
dial-up connection accordingly.
- Click the Exit button to quit the application.
If you do not want to connect to a specific
Service and/or Access Concentrator, make
sure the Phone number field of your dial-up connection is
really completely blank.
6.6 Connection attempt fails with "Error
651: The Modem (or other connecting device) has reported an error."
If you have not rebooted since the installation of the protocol and the
machine was in Standby mode since, this is a known
issue. Simply click the Redial button. The second
connection attempt will proceed without this error. You'll get it once each
time after waking the machine from Standby until you reboot
the machine. Then the protocol will work flawlessly even right after waking
the machine.
6.7 Connection is successfully established,
but some (or all) Internet websites do not load properly
This is usually a sign of an MTU problem. You should
determine the Path MTU to the problem site(s)
(Note: The method described here does not work with all
servers. If you get no reply at all from a server or a number below
548, you cannot determine the Path MTU to this server):
Connect, open a Command Prompt and run
ping -f -l xxxx
Address
Where Address is the name or IP
address of the server you have problems accessing. 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 Path MTU.
Example: You start getting replies at ping -f -l
1372 Address. The Path MTU is 1372 + 28 =
1400 bytes in this case.
Normally, the Path MTU to all servers should be 1492.
However, some service providers appear to have a configuration problem which
reduces the Path MTU. If you determine a Path MTU lower than
1492 to several (or all) servers on the Internet, you should
enable the MTU
override option and set it to the Path MTU you
determined. After that setting has taken effect, all sites with a Path MTU
greater than or equal to the value you set should load properly.
6.8 Cannot get the Routing and Remote
Access Service (RRAS) to work with the PPPoE connection
A common cause of this is that RRAS was
incorrectly set up to use a network adapter
for Internet access, which bypasses the PPP over
Ethernet Protocol. When setting up RRAS with the
configuration wizard, you are first presented with a list of network adapters
in your system. Do not select any of these entries. Instead,
look for an option to create an on-demand dial connection
below and select that. A few steps later, an on-demand dial
wizard should come up, which offers a list of dial-up
devices, in which you should find an ISDN channel
with the name of your network card. Select this device to make
RRAS work with your PPPoE connection.
If the list of dial-up devices does not
contain the mentioned device, you may first have to enable it
for use with RRAS. Look through the RRAS Management
Console for a list of ports. This list should
contain the mentioned dial-up device. You can right-click the device in this
list and find an option to enable it for use with RRAS.
6.9 The "Override Maximum Transfer Unit"
option does not remain checked
This option will only "stick" if you enter an MTU other than
1492. If you only check the checkbox, but leave the MTU at
1492, the protocol will recognize the default value and
clear the checkbox the next time you open the properties
dialog, because the MTU was not actually overridden.
6.10 The System Event Log contains
"Received a PPPoE Session packet for an unknown session" warnings
This warning merely means that the protocol received a PPPoE packet it
could not attribute to any of its connections and is usually
not a sign of any malfunction. One possible cause of this is
your service provider sending one more packets after the connection has been
terminated. This can also be caused by using another PPPoE
implementation on the same machine. In that case, the
System Event Log may end up being flooded with these
warnings. You can prevent this by disabling the Log Warnings
checkbox in the protocol's Event
Logging options.
7. Known Issues
This section documents known issues with the protocol.
7.1 Binding/unbinding the protocol
to/from a network adapter takes effect immediately and cannot be
canceled
When you bring up the Properties of a Local Area
Connection and toggle the checkbox next to PPP over Ethernet
Protocol, the binding change takes effect
immediately, i.e. it is not deferred until
you click OK or Cancel, and you cannot
cancel the change. This is merely annoying when accidentally
checking the checkbox, as you can clear it again with no harm
done. However, if you accidentally clear the checkbox, simply
re-checking the checkbox may not be sufficient to make the
protocol work on that adapter again, due to this
known issue.
Background: This protocol is implemented as an
NDIS intermediate driver with a different upper edge
(ndiswan) than lower edge (ndis4, ndis5). As such, it does
not qualify as a filter driver and thus
requires its own Notify Object (implemented in
RASPPPOE.DLL) to install and remove miniport instances for
the bound adapters and to communicate the names of the installed device
instances to the protocol portion of the driver via the registry. When the
user brings up the connection properties dialog box, the only way for the
Notify Object to tell whether the user clicked OK or
Cancel is that its ApplyRegistryChanges()
and ApplyPnpChanges() member functions are only called in the
former case, but not in the latter. So the right thing to do would be
install and remove the miniport instance(s) in one of these functions - but
that does not work, because a reentrancy
check in the Windows network configuration library
blocks all calls to
INetCfgClassSetup::Install() and
INetCfgClassSetup::DeInstall() at that point for fear the
developer might have overlooked the possibility that these calls could lead to
another invocation of the Notify Object's member functions that requested the
installation or removal, which could lead to endless installation loops if the
writer of the Notify Object was not smart enough to set a flag to prevent
this. This makes it impossible to install and remove miniport instances from
these Notify Object member functions. To work around this problem, the
PPP over Ethernet Protocol does all installation and removal
in the Notify Object's NotifyBindingPath() member function,
which is unfortunately called immediately when the user
toggles the checkbox. Thus, the change takes effect immediately and cannot be
canceled.
7.2 After initial installation, binding
the protocol to a network adapter may not take effect
If you unbound the protocol from a network adapter by clearing the checkbox
next to the PPP over Ethernet Protocol in the
Properties of a Local Area Connection,
binding the protocol to the network adapter by checking the checkbox again may
not take effect, although you get no notification of this. If
you unbound the protocol from all network adapters, the
first binding you re-enable will take
effect, but subsequent ones will not. There are three possible solutions in
this situation:
- Locate the Local Area Connection of the adapter in
question, right-click it and select Disable. Then,
right-click it again and select Enable. This will make the
protocol work again. Note, though, that this temporarily disrupts any other
network traffic you might run through this adapter.
- Click the Uninstall button to remove the protocol
completely and then click the Install button to re-install
it. After re-installation, you will be able to use the protocol over that
adapter immediately without a reboot, but you will see
"ghost" dial-up devices in your dial-up connection
properties. These will go away when you reboot. See this
known issue.
- Reboot. After the reboot, the protocol will work on
this adapter again.
Background: After the initial installation, the protocol
driver is already running in memory. When the user checks the checkbox next to
PPP over Ethernet Protocol, the Notify Object receives
notification of a new adapter to bind to and calls
INetCfgClassSetup::Install() to install a corresponding
miniport device instance - and the Windows network
configuration library makes the bad mistake of invoking the
protocol driver's ProtocolBindAdapter() function
before returning control to the Notify Object. This creates a
semi-deadlock situation:
ProtocolBindAdapter() needs the name of the
installed miniport device instance before exiting, but only
the Notify Object can provide that information, and the Notify Object
cannot find out the name before the
INetCfgClassSetup::Install() function returns control - and
that will not return control until ProtocolBindAdapter()
exits. Thus, the ProtocolBindAdapter() function fails to
initialize the miniport device instance and the protocol will not work on the
adapter. The Notify Object will still create the required registry values
afterwards, and when re-initializing the adapter by disabling and re-enabling
its Local Area Connection or upon the next reboot,
ProtocolBindAdapter() will successfully initialize the
miniport device instance and the protocol will work on the
adapter.
7.3 The protocol's dial-up devices show
up as ISDN channels and a meaningless ISDN Configuration is offered
When you open the properties of a dial-up connection, you will find the
protocol's dial-up devices listed as "ISDN channel -
Adapter Name". Selecting a
dial-up device and clicking the Configure... button brings up
an ISDN Configuration window with settings that are
meaningless to PPP over Ethernet. The reason for this is that
the dial-up devices are declared as ISDN devices to the system to make
on-demand dialing for Internet Connection
Sharing work. While the incorrect display can be confusing, it does
no harm.
Background: It was found that the Remote Access
Auto Connection Manager service will only use
modems, ISDN and X.25
devices for on-demand dialing, but not "generic" devices, as this protocol's
dial-up devices were formerly declared. This is apparently a bug in
Windows 2000.
7.4 After uninstalling the protocol or
unbinding it from a network adapter, its dial-up devices are still shown until
you reboot
When you unbind the protocol from an adapter or even completely uninstall
the protocol, the dial-up devices it created are still shown in a dial-up
connection's Properties box and will not go away until you
reboot. When you re-bind to an adapter or re-install the protocol without
rebooting, you will see double entries per adapter, with one having an
additional number in brackets in the name. This is a bug in
Windows; even WAN miniports shipping with the operating
system exhibit this behavior. While the additional entries do no harm, they
can be confusing. They will be gone after a reboot.
Background: This issue is known to Microsoft and currently
intended behavior. They found that TAPI is leaking
memory when a line device is removed and thus temporarily "fixed"
this by simply blocking line device removal. Microsoft is
supposedly working on a fix.
7.5 Uninstalling the protocol leaves
files behind and the driver may not be unloaded from memory
If you are running Windows 2000, when you uninstall the
protocol, the protocol's Notify Object,
RASPPPOE.DLL is left behind in your
\WINNT\SYSTEM32 directory and the driver may remain loaded in
memory until you reboot. The DLL left behind can be safely deleted after
uninstalling the protocol. The latter issue poses a problem should you
upgrade to a newer version of this protocol. Although the
installation will put the new driver file on the hard disk, Windows
2000 will continue to use the old driver version still resident in
memory instead of loading the new version from hard disk. To unload the driver
from memory, you must first unbind the protocol from
all network adapters by clearing the checkbox next to
PPP over Ethernet Protocol in each Local Area
Connection on your machine. Then click the Uninstall
button to remove the protocol. If you uninstalled the protocol without
unbinding it from all network adapters first, you will have to reboot for any
new driver version to be actually loaded.
Background: Although there is a DelFiles
directive in the protocol's INF file to delete RASPPPOE.DLL,
the DLL is still locked in memory at the time the directive is supposed to be
carried out. Microsoft has already acknowledged that this is a bug in the
Windows 2000 binding engine which they need to fix. The
driver unloading issue occurs with Microsoft's PASSTHRU DDK
sample as well and has been acknowledged by Microsoft. Both issues are
fixed in Windows XP/2002.
7.6 If there was no reboot since
installation, the first connection attempt after waking the machine from
Standby fails with error 651
When the machine has not been rebooted since installation and is woken from
Standby, the first connection attempt through this protocol
fails with "Error 651: The Modem (or other connecting device) has
reported an error." Any further connection attempts proceed without
this problem. If the machine is rebooted, the problem goes away entirely.
Background: The cause of this problem is unknown. In this
situation, the protocol receives the same TAPI OIDs as for any other
(successful) connection attempt and handles them just the same, but just at
the point where the OID_TAPI_MAKE_CALL request would have to
come, this error message comes up instead. The protocol did not show any
extraordinary failures, so the error must occur within
NDISTAPI itself. This is probably a bug in Windows
2000.
7.7 When a dial-up connection is made
"always on", it is not properly terminated when shutting the machine down or
rebooting
When you configure a PPP over Ethernet dial-up connection
to be "always
on", the connection will not be properly terminated when
shutting the machine down or rebooting. This causes problems with service
providers who take very long to detect such a dropped connection and limit the
number of concurrent connections - after several reboots, you may find
yourself to log on to your service provider for some time. To work around this
problem, always disconnect your "always on"
connection manually before rebooting.
Background: Investigation revealed that the protocol
receives no indication that the system is going down. Neither
the MiniportHalt(), nor the
ProtocolUnbindAdapter(), nor the
ProtocolPnPEvent() and not even the
ProtocolStatus() handler are called to indicate the shutdown.
Thus, it is not possible for the protocol to terminate its outstanding
connections prior to the shutdown. This is apparently a shortcoming of
Windows 2000.
8. Revision History
-
Version 0.96, May 29th, 2001
- First release with Intel Itanium 64-bit CPU support!
The IA64 version is distributed in a
separate archive for now.
- Fixed: Some code paths in the
ProtocolReceivePacket() 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.
- Changed: The watchdog timer that
checks every ten seconds whether any packets have been
received will now send up to three LCP Echo-Requests before
terminating the connection. Thus, a connection loss will now be detected
within 40 to 50 seconds. 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.
- Changed: When connecting to the unnamed default
service, the protocol will now connect to the first
offered service, even if it is not unnamed. This enhances
compatibility with service providers who are not fully RFC
2516 compliant.
-
Version 0.95, December 29th, 2000
- Added: A no-reboot installer (fully licensed version only) that
installs, repairs or
upgrades the protocol from a single, self-extracting
executable, typically without requiring a reboot on
any of the supported platforms. Additionally, it creates a
dial-up connection and then prompts the user to connect to allow an
"instant success" experience. The protocol will be added to
the list of installed programs in Add/Remove Programs in
Control Panel for convenient and complete
uninstallation. Optional command-line switches allow silent
installation, upgrade and removal for licensees who wish to provide their
own installer front-end.
- Added: Server capability. If one of
the dial-up devices exposed by the protocol is configured to accept incoming
connections, the protocol will offer the unnamed default
service on the corresponding adapter and use the computer
name set in the networking configuration as the Access
Concentrator name. If the connection is accepted, the protocol will
do a left-to-right (big-endian) comparison of the adapter's MAC
address with the one of the connecting host, and generate an
even (LSB 0) session identifier is the
adapter's MAC address is lower, or an
odd (LSB 1) one if it is higher, to ensure
that two machines connecting to each other simultaneously do not generate
identical session identifiers. The server is not
industry-strength. There is no limit on the
connections per MAC address, nor is any encryption being
used in the Access Concentrator Cookies generated by the
protocol, so a malicious user on the same Ethernet segment
could occupy all incoming lines with a
denial-of-service attack, but do no harm beyond that. Great
care has been taken to minimize the load on the system if
such an attack is made.
- Added: Timers. The protocol now times
out connection requests and resends requests two times, once after
one second, then after two seconds, and
three seconds after that indicates no
answer. Incoming connections are offered for
five seconds before being rejected. When a connection is
established, a watchdog timer checks every ten
seconds whether any packets been received, and generates and sends
an LCP Echo-Request 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 no answer.
Thus, a connection that was dropped by the other end without proper
termination will be detected as lost within 20 to 30
seconds.
- Added: In Windows 98/98SE/ME,
RASPPPOE.EXE now checks whether Dial-up
Networking is installed and gives an error message if it is not.
Additionally, it checks if NDIS.VXD version
4.10.2222 is installed, and warns the user to install fix
Q243199 if it is.
- Added: In Windows 98/98SE/ME,
WINPPPOE.DLL now adds a new value to the Packet
Size setting of the Dial-Up Adapter called
PPP over Ethernet, which sets the packet size to either the
default (1492) or the overridden MTU.
- Fixed: RASPPPOE.EXE would show
erroneous query results if more than one
Access Concentrator offered services, because the driver
was returning an incorrect query result length. Fixed this by correcting the
length calculation in the driver.
- Fixed: In Windows 98/98SE/ME,
RASPPPOE.EXE was unable to properly retrieve the names of
network adapters which were 58 characters or more long, which led to it
displaying a blank 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.
- Fixed: Windows 98/98SE/ME was unable
to tell apart the dial-up devices exposed for two network adapters of the
same name. Fixed this by appending a "#X" suffix to the
dial-up device name if the protocol is already bound to a network adapter of
the same name.
- Fixed: In Windows 98SE/ME,
NDIS.VXD versions 4.10.2224 (from fix
Q243199 for Windows 98SE) and
4.90.3000 (included in Windows ME)
randomly dropped packets received from the
NE2000 or the Realtek RTL8029(AS) driver
without indicating them to the protocol for an unknown reason. Worked around
this problem by adding NDIS_PACKET_TYPE_ALL_LOCAL to the
packet filter if Windows 98/98SE/ME and one of these two
drivers is detected, which makes NDIS.VXD work reliable
again.
- Fixed: If TAPI requested to
drop a call, the protocol would not transition to the
idle call state, because I had misunderstood a paragraph in
the DDK documentation. This might also have been the cause of
TAPISRV.EXE causing crashes in RPCRT4.DLL
in Windows ME. Fixed this by reviewing all
TAPI call state transitions and making sure the behavior is
compliant with the DDK documentation.
- Fixed: When running a repair or
upgrade install on Windows 2000, the
protocol could crash the operating system with a blue
screen indicating that RASPPPOE.SYS was unloaded without
canceling pending operations. Investigation revealed that Windows
2000 was trying to call the protocol's
ProtocolPnPEventHandler() function after it had been
unloaded, because the protocol had not been deregistered. Further
investigation revealed that the ProtocolUnload() handler is
never called in Windows 2000, which is not
documented in the Windows 2000 DDK documentation.
Fixed this by providing a DriverUnload() handler again to
deregister the protocol, and by putting the pointer to this function
directly into the driver object in DriverEntry() to omit
the NdisMRegisterUnloadHandler() call, which is not
available in Windows 98. The
ProtocolUnload() handler is still provided for
Windows 98/98SE/ME.
- Changed: RASPPPOE.EXE now displays a
different 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.
- Changed: If more than one WAN Endpoint
is configured for a network adapter, "Line X" suffixes will
now be appended in Windows 2000 as well. Previously, they
were only appended in Windows 98/98SE/ME.
- Changed: In Windows 2000, the protocol
no longer logs query results to the event log.
RASPPPOE.EXE made this function obsolete.
- Changed: Removed the
NCF_NOT_USER_REMOVEABLE flag from the WAN miniport
(PPP over Ethernet Protocol) INF file for Windows
2000, allowing manual removal of any miniport instances left behind
in Device Manager.
- Changed: Replaced the previously imported
strncmp() and _strnicmp() kernel functions
with inline functions. Removed the need for the
_snwprintf() kernel function by generating the
"Line X" suffixes directly in the code.
- Changed: During protocol initialization and shutdown,
the MiniportQueryInformation(),
MiniportSetInformation(), MiniportReset()
and MiniportWanSend() handlers now return
NDIS_STATUS_ADAPTER NOT_READY instead of
NDIS_STATUS_FAILURE.
- Changed: The protocol service name and the driver
binary name were changed to RMSPPPOE and
RMSPPPOE.SYS, respectively, to enhance compatibility with
future Windows versions.
-
Version 0.94, May 17th, 2000
- First release with Windows 98/98SE/ME support! No
thanks to Microsoft's complete lack of documentation on
NDIS intermediate drivers in Windows 98/98SE/ME.
- Added: Windows 98/98SE/ME support.
Figured out the INF format for NDIS intermediate drivers in
Windows 98/98SE/ME and where WAN.TSP
expects an NDIS intermediate driver's TAPI registry subkey
to be located in the registry. Added a 16-bit Windows DLL
(WINPPPOE.DLL) with an NDI procedure to
create that registry subkey upon installation, set the Dial-Up
Adapter's IPMTU registry parameter to the MTU for PPP over
Ethernet (Windows 98/98SE/ME was found to
ignore the maximum frame size returned by the driver) and
offer the protocol properties GUI. Changed the driver
unload function to ProtocolUnload(), since
NdisMRegisterUnloadHandler() is not supported in
Windows 98/98SE/ME. Removed the
NdisIMAssociateMiniport() call from the
DriverEntry() function, since that call is not supported in
Windows 98.
- Added: RASPPPOE.EXE user-mode
application for easy dial-up connection setup.
- Added: Limit TCP MSS Option to make
MTU changes on Internet Connection Sharing client machines
unnecessary. A new function scans all incoming and outgoing packets for the
TCP Maximum Segment Size (MSS) option and, if necessary,
limits it to either the default (1492) or the
overridden MTU (see below) minus 40 for
the IP and TCP headers (i.e. 1452 in case of the default
MTU) and recalculates the TCP checksum.
- Added: MTU Override option to override
the MTU initially reported by the driver. If an override value is specified,
it will be reported as the MaxFrameSize in response to the
OID_WAN_GET_INFO request. In Windows
98/98SE/ME, the Dial-Up Adapter's IPMTU registry
parameter is also set to the override value. It will furthermore be taken
into account when limiting the TCP MSS option. Making the
protocol initially report a lower MTU was found to help
with certain VPN software packages which "blindly" add their own overhead
without paying any respect to the MTU reported by the driver.
- Added: WAN Endpoints GUI option to easily change the
number of dial-up devices exposed for a network adapter.
- Fixed: Dial on demand in
Windows 2000 never triggered a connection. Windows
2000 apparently only dials modems, ISDN and X.25 devices on demand.
Changed the device type of the dial-up devices exposed by the protocol to
ISDN to work around this bug.
- Fixed: The protocol could lose one of its internal
packets each time an NdisTransferData() call failed, until
it would eventually be unable to receive any data. It appears that never
actually happened to anyone, though.
- Fixed: The PPPoE version and type fields were reversed
in the declaration. As the current PPPoE version and type are both 1, this
bug went unnoticed.
- Changed: The protocol will now no longer log a warning
to the event log if it receives a PADT packet for a session
that does not exist (or no longer does).
- Changed: The Event Logging Options now
default to logging all types of events. This should now
produce no log entries during flawless operation.
-
Version 0.92, February 6th, 2000
- Fixed: No data transfer possible after successfully
establishing a connection. The protocol was corrupting data packets it had
to retrieve through NdisTransferData(). I had made the
incorrect assumption that NdisTransferData() would use the
ByteOffset parameter on the destination buffer as
well, but instead it just starts at offset zero in the first buffer chained
to the passed packet. Fixed this by chaining an additional buffer descriptor
pointing to the desired destination location to the front of the packet
before calling NdisTransferData().
- Fixed: Connection Error "Opening port... Error
797: The connection failed because the modem (or other connecting device)
was not found." after waking the machine from
Standby. There were no OID_PNP_XXX
handlers in the protocol. Additionally, it turned out that
TAPI requests OID_TAPI_PROVIDER_INITIALIZE
after returning from Standby, although it
never shuts the provider down with
OID_TAPI_PROVIDER_SHUTDOWN. The protocol did not allow
re-initialization without shutdown. Fixed this by adding the missing
OID_PNP_XXX handlers and allowing TAPI provider
re-initialization without a prior shutdown.
-
Version 0.90, January 30th, 2000
- First release that actually works! A wholehearted
Thank You! to Jerome
Whelan who invested so much time to provide me with the
comprehensive feedback that I needed to make this protocol functional.
- Fixed: Installation Error "Could not add the
requested component. The error is: Invalid access to memory
location." on some machines. On those, the loader
crashed when loading RASPPPOE.DLL, because I had linked it
with the /align:16 linker switch. Removed the switch from
the build settings.
- Fixed: Connection Error "Disconnected. Error
619: The specified port is not connected." on all
connection attempts. NDISWAN failed to recognize the PPP
frames within the complete received Ethernet frames the protocol passed to
it, although I had specified the HeaderPadding correctly as
outlined in the DDK documentation. Fixed this by setting the
HeaderPadding to zero and only passing the portion of the
buffer with the actual PPP frame to NDISWAN.
- Fixed: Ping Timeouts with
certain packet sizes. NDISWAN passes up to
four bytes more to a WAN miniport's send handler than the
WAN miniport indicated as its MaxFrameSize. Apparently a
WAN miniport driver writer is expected to make assumptions about the PPP
HDLC overhead NDISWAN adds before passing
a packet to the miniport - four bytes of simple PPP HDLC framing (Address
and Control fields and Protocol Identifier). Fixed this by adjusting the
maximum frame and total sizes accordingly and changing the size limit
comparisons.
-
Version 0.80, January 15th, 2000
9. Contacting the author
Before contacting me, please bear in mind that you are getting this piece of
software for free. You cannot expect me to spend my time
providing "tech support". If you have a problem that you cannot resolve after
reading above documentation thoroughly, please do the
following:
- Check if there is updated information or a newer version
of this protocol available on the RASPPPOE Home Page.
- Check the System Event Log for any events logged by the
protocol:
- Right-click the My Computer icon on your desktop and
select Manage to bring up the Computer
Management window.
- In the tree on the left-hand side, expand the Event
Viewer branch and select the System sub branch.
- Look through the list on the right-hand side for any entries from source
RMSPPPOE.
- Double-click each entry you find to bring up the Event
Properties window.
- If the event Description still does not help you find
the culprit, please include all log entry
data in your e-mail:
- Click the copy button in the Event Properties window
(it has two little pieces of paper on it) and then
paste the log entry into your e-mail to me.
Of course, developer suggestions for fixing the known
issues, success stories (please mention your service provider, so that I
know which ones this protocol works with) or just "thank you" notes are always
welcome.
You can contact me via the e-mail address normanb@cs.TU-Berlin.DE.
*EOF*
|
