RASPPPOE
PPP over Ethernet Protocol
for Windows NT 4.0
(If you are using Windows
95/98/98SE/ME, please click
here)
(If you are using Windows 2000/XP/.NET,
please click here)
written by Robert Schlabbach
Version 0.98, October 3rd, 2002
Contents
1. Introduction
Welcome to RASPPPOE, a PPP over
Ethernet (short: PPPoE) implementation
for Windows 95, 98, 98SE,
ME, NT 4.0, 2000,
XP and .NET. 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:
- Seamless integration into the operating
system. This protocol makes Ethernet network
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 250 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-2002 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 (except
on Windows NT 4.0) and leads the user to the
first login for an "instant success"
customer experience. For licensing details please contact:
Monzoon Networks AG
Hardstrasse 235
CH-8005 Zurich
Switzerland
e-mail: raspppoe@monzoon.net
Web: http://www.monzoon.net
2. Installing the PPP over
Ethernet Protocol
- ATTENTION:
RASPPPOE requires Service Pack 4 or
later for operation on Windows NT 4.0.
If you are currently using an older or no Service Pack,
please update your operating system with the latest
Service Pack available.
- NOTE:
During installation, you may be asked for Windows
NT files. If possible, specify the location of
the Service Pack you had applied. This
will save you the step of having to re-apply
the Service pack after installation of this protocol.
- WARNING:
You are about to install a driver. Since any
driver installation poses a non-zero risk of crashing
your operating system, and since you need to restart
your computer to complete this installation
anyway, 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: README9X.HTM, READMENT.HTM,
README2K.HTM, NETPPP95.INF,
RASPPP95.INF, WINPPPOE.INF,
OEMSETNT.INF, NETPPPOE.INF,
RASPPPOE.INF, WINPPPOE.DLL,
RASPPPOE.DLL, RASPPPOE.EXE,
RASPPPOE.SYS and RMSPPPOE.SYS.
The Intel Itanium 64-bit CPU release
only contains the files README2K.HTM, NETPPPOE.INF,
RASPPPOE.INF, RASPPPOE.DLL,
RASPPPOE.EXE and RMSPPPOE.SYS.
NOTE:
Explorer may be configured to hide
DLL and SYS files, so
it may not display these files.
- Right-click the Network Neighborhood
icon on your desktop and select Properties
to bring up the Network window.
- Click on the Protocols tab.
- On the Protocols property sheet, click
the Add... button.
- In the Select Network Protocol window,
click the Have Disk... button.
- In the Insert Disk window, type the full
path of your temporary folder. 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, you may be asked for Windows
NT files. If possible, specify the location of
the Service Pack you had applied. If you
specify the location of the original
Windows NT files, you will have to re-apply
the Service Pack after the installation of the protocol.
- Back at the Network window, click on the
Bindings tab.
- On the Bindings property sheet, select Show
Bindings for: all adapters.
- If you have a network adapter dedicated
to your broadband modem, it is recommended
that you disable the bindings to all
other components and leave only PPP over Ethernet
Protocol bound. To do this, double-click the
dedicated network adapter in the list to expand it and
right-click each unneeded component below it and select Disable.
After you are done, all components below that adapter except
the PPP over Ethernet Protocol should
have a little stop sign next to them.
- 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,
double-click each network adapter in the list you want to
disable the protocol for, right-click
the PPP over Ethernet Protocol item
below it and select Disable.
- Click on the Close button to close the Network
window and restart your computer to make
the protocol functional. After the reboot, you need to
create a dial-up connection to use it. See the next
section for details.
- IMPORTANT:
If you were prompted for Windows NT files
during the installation and you specified the location of
the original Windows NT files, you will
first have to re-apply the latest Service
Pack after the restart and then restart your
computer again to make the protocol functional.
3. Creating PPP over
Ethernet Dial-Up Connections
If you installed the protocol with the automated installer, it
already created a dial-up connection for you. If you installed
the protocol manually, you can create a PPP over
Ethernet dial-up connection 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 to bring up the Dial-Up Networking
window.
- In the Dial-Up Networking window, click
on the Dial button.
- In the Connect to Connection
Name window, enter your user name and
password if your service provider requires authentication.
- Click on the OK 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 and since you need to restart
your computer to complete the removal anyway,
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.
- First, you may want to remove all dial-up connections you
created for connecting through this protocol. To do so,
double-click the My Computer icon on
your desktop, and then the Dial-Up Networking
icon in the upcoming window. Select each of the dial-up
connections you created for this protocol under Phonebook
entry to dial:, then click on the More
button, select Delete entry... and
confirm. If you had created any shortcuts to these dial-up
connections on your desktop, right-click them and select Delete
as well.
- Right-click the Network Neighborhood
icon on your desktop and select Properties
to bring up the Network window.
- Click on the Protocols tab.
- On the Protocols property sheet, select PPP
over Ethernet Protocol and click the Remove
button.
- 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 Network window, click Close
to close the window. You will be prompted to restart
your computer. After the restart, the protocol
is completely removed from your computer.
Note: If you do not have any other dial-up
devices in your machine, the Remote Access
Service will bring up an error message when closing the Network
window, saying it is incorrectly configured. Also, you will get a
notification that a service was unable to start upon each restart
of your computer. If you do not intend to use Dial-Up
Networking for the time being, you can fix this by re-opening
the Network window, going to the Services
tab, selecting Remote Access Service, clicking
the Remove button and confirming. Note that the Remote
Access Service can be reinstalled later should you need
it again.
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:
- Right-click the Network Neighborhood
icon on your desktop and select Properties
to bring up the Network window.
- Click on the Protocols tab, select PPP
over Ethernet Protocol in the list and click the
Properties... button.
- In the PPP over Ethernet Protocol Properties
window, select the network adapter the protocol settings
of which you wish to modify under Configure PPP
over Ethernet Protocol on 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 an Internet Connection Sharing
or Network Address Translation (NAT)
application to share the the Internet access in a LAN, 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 or Network Address
Translation (NAT), 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 restart your computer.
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 you to restart your computer
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:
- Click on the Start button, select Programs,
then Administrative Tools (Common)
and finally Event Viewer.
- Click on Log and select System.
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.
NOTE: If you
are using another PPP over Ethernet software
on the same machine, you will find the event
log flooded with Warnings from source RMSPPPOE
that it received a PPPoE packet for an unknown session. To
fix this, either use solely this protocol on the machine, or disable
the Log Warnings option as described above.
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
to Connection Name
window and connecting at least once.
- Obtain a tool which allows you to run an application
as a service, e.g. the SRVANY tool
from the Windows NT Resource Kit and
create a service which runs the command line "RASPHONE.EXE
-d "Connection Name""
(note the spelling!).
- Alternatively, if you cannot obtain such a tool, you
can copy the dial-up connection shortcut to the Startup
folder of the Start menu, which
will, however, require you to log in once
to establish the connection after the system has
booted. To do this, right-click the Start
button, select Explore, in the
upcoming Explorer window, double-click
the Programs folder, then drag the
dial-up connection shortcut on your desktop with the right
mouse button and drop it on the Startup
folder and select Copy Here.
- Finally, you need to make a little registry change to
prevent Windows NT 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 NT
will establish the connection automatically (or when
you log in if you chose the alternative method) 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 Remote Access
Service 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 Network Neighborhood
icon on your desktop and select Properties
to bring up the Network window.
- Click on the Services tab, select Remote
Access Service in the list and click the Properties...
button.
- Select the Port (from device RASPPPOE,
of type PPPoE) which you want to
accept incoming connections on and click the Configure...
button. Note: If you do not know
which network adapter a port belongs to, check the
properties of a dial-up connection you created for
that network adapter. On the Basic
tab under Dial using: you will find
the name of the port in brackets after the network
adapter name.
- In the Configure Port Usage window,
select either Receive calls only or Dial
out and Receive calls and close the window
with the OK button.
- You may now want to click on the Network...
button to configure the protocols for the incoming
connections, e.g. to define the IP addresses
to use.
- Close the Remote Access Setup window
with the Continue button, then close
the Network window with the Close
button and confirm to restart your computer.
- If you want to disable the server on a port again,
simply set the port usage back to Dial out
only.
NOTE: If
there are any changes to the number of network adapters the
protocol is bound to, or to the number of lines per any
adapter, the port usage for all PPPoE ports
will be reset to Dial out only and you will
have to reconfigure any ports you had configured to accept
incoming connections.
For further help on using the Remote Access
Service, 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 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 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 adapter in question is
properly installed:
- Right-click the Network Neighborhood
icon on your desktop to bring up the Network
window, select the Adapters tab and
check if the adapter in question is listed there.
- Check if the adapter is correctly configured: Select
it in the list and click the Properties...
button. Make sure the configuration matches the
hardware settings.
- If you changed any settings, close the Network
window with the Close button, restart
your computer, then 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 bound to the adapter in question:
- Right-click the Network Neighborhood
icon on your desktop to bring up the Network
window, click on the Bindings tab
and select Show Bindings for: all adapters.
- Double-click the adapter in question in the list to
expand it and look for the component PPP over
Ethernet Protocol. If it has a little stop
sign next to it, right-click it and select Enable.
If you find it already enabled, try disabling it,
closing the Network window with the Close
button, then re-enabling it.
- If you changed any settings, close the Network
window with the Close button and restart
your computer.
- After the restart the RASPPPOE
application should list the desired adapter.
6.2 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.
- Right-click the Network Neighborhood
icon on your desktop to bring up the Network
window, select the Adapters tab and
check if the network adapter your
broadband modem is connected to is listed there.
- Check if your network adapter is correctly configured:
Select it in the list and click the Properties...
button. If your network adapter offers such settings,
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.3 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
service 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.4 Connection attempt
fails with "Error 691: Access was denied because the
user name and/or password was invalid on the domain."
If this error occurs despite using a valid user name and
password, this may mean that the service provider you are
connecting with negotiates a lower MTU than
the one configured on your machine, which leads to this
confusing error message due to this
known issue. To fix this, use the MTU
override option to lower the MTU to e.g.
1400 and then try connecting again. If you can successfully
connect with the lower MTU, you can try increasing the MTU
again to the maximum value that still allows you to connect
successfully.
6.5 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.6 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.7 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 RAS Autodial
service does not work with RASPPPOE
The RAS Autodial service does not
recognize the dial-up devices offered by RASPPPOE
and thus will not automatically establish a connection
through it. There is currently no workaround for this issue.
Background: The RAS Autodial
service only recognizes dial-up devices of the types COM,
ISDN, VPN and X.25.
However, RASPPPOE uses a custom type, PPPoE,
for its dial-up devices to avoid conflicts with existing
modems, ISDN adapters, VPN software or X.25 adapters when
autoconfiguring its dial-up devices without the RAS
control panel.
7.2 PPP
authentication fails when Access Concentrator requests a
lower MTU
When the Access Concentrator being
connected to requests a PPP MRU lower than
the MTU configured in RASPPPOE,
the PPP authentication will fail with error 691
(Access was denied because the user name and/or password was
invalid on the domain.). To fix this, use the MTU override option to lower
the MTU to a value less than or equal to the Access
Concentrator's PPP MRU requested value.
Background: The cause of this issue is
undetermined.
7.3 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(),
nor the ProtocolStatus() handler and not
even a handler registered with the NdisMRegisterAdapterShutdownHandler()
are called to indicate the shutdown. Thus, it is not possible
for the protocol to terminate its open connections prior to
the shutdown. This is apparently a shortcoming of Windows
NT.
8. Revision History
Version 0.98, October 3rd, 2002
- First release with Windows 95 and Windows NT
4.0 support! The Windows 95
version uses a different driver binary, while Windows
NT 4.0 runs the same binary as Windows
98/98SE/ME/2000/XP/.NET.
- Added: Windows 95
support. Requires Microsoft Dial-Up
Networking Upgrade 1.2 or later on the original
Windows 95 release (4.00.950). Figured out how to
make the fragments of NDIS
Intermediate driver support in NDIS.VXD
version 4.00.1111 work and how to
install the driver. Created two new INF
files for installation and added installation support
to WINPPPOE.DLL to install and
remove virtual miniport instances as needed. Wrote
function replacements for NDIS
functions not available in Windows 95.
Changed the functions NdisMIndicateStatus(),
NdisMIndicateStatusComplete(), NdisMResetComplete(),
NdisMWanIndicateReceive(), NdisMWanIndicateReceiveComplete()
and NdisMWanSendComplete() from
macros back to imports. Added NdisRecalculatePacketCounts()
and NdisQueryPacket() macro
invocations for compatible packet initialization.
Added #ifdefs to the driver source
so that the Windows 95 driver binary
can be compiled from the same source.
- Added: Windows NT 4.0
support. Requires Service Pack 4 or later.
Also requires a reboot after
installation since Windows NT cannot
start NDIS miniports dynamically.
Wrote a completely new OEMSETNT.INF
installation script from scratch which installs and
removes virtual miniports on demand and automatically
initializes the RAS TAPI devices
exposed by the driver without having to go through
the RAS configuration panel. Added a
standalone, exported WindowsNTControlPanel
function to RASPPPOE.DLL which is
invoked from OEMSETNT.INF for
configuration of the protocol properties. Changed and
expanded the TAPI provider portion
of the driver for compatibility with Windows
NT 4.0.
- Fixed: In Windows 2000/XP/.NET,
the protocol properties dialog could not retrieve the
current protocol configuration if more than one line
per adapter was configured. Fixed this by stripping
the "line X" suffix from the TAPI
line name before the string comparison.
- Fixed: In Windows 98/98SE/ME,
the protocol properties did not allow specifying
values greater than 3276 kbps for
the Link Speed option due to
improper 16/32-bit handling. Fixed this by cleaning
up the string-to-integer conversion calls. Now link
speeds up to 65535 kbps can be
entered in Windows 95/98/98SE/ME.
- Fixed: The MiniportQueryInformation()
handler made a call to NdisUnicodeStringToAnsiString(),
which is not allowed at the IRQL the
handler may be invoked at. Fixed this by moving the
call to the ProtocolBindAdapter()
handler.
- Changed: RASPPPOE.EXE
now uses TAPI version 1.3
to communicate with the running protocol for
compatibility with Windows 95.
- Changed: RASPPPOE.EXE
now changes the characters [ and ]
to ( and ),
respectively, and strips trailing space
characters from the connection name when
creating a dial-up connection for compatibility with Windows
NT 4.0.
Version 0.97, August 23rd, 2001
- Added: An application
manifest for RASPPPOE.EXE
to enable the Windows XP visual style
in its user interface.
- Changed: The self-deleting
code in RASPPPOE.EXE (fully licensed version only)
was changed from an x86 assembly routine to a CPU
independent method that is also compatible
with Windows XP.
- Fixed: The IA64
version caused STOP errors due to data
misalignment. Fixed this by padding
data structures where possible and by using the UNALIGNED
compiler macro where misalignment cannot be avoided.
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:
- Click the Start button, then
select Programs, then Administrative
Tools (Common), then Event
Viewer.
- In the upcoming Event Viewer
window, open the Log menu and
select System.
- Look through the list in the window for any
entries from source RMSPPPOE.
- Double-click each entry you find to bring up the Event
Detail window.
- If the event Description still
does not help you find the culprit, please
include all log entry data in
your e-mail:
- Right-click in the field under Description:,
select Select All, right-click
again and select Copy, then paste
the text into your e-mail to me.
- Right-click in the field under Data:,
select Select All, right-click
again and select Copy, then paste
the text 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: Robert.Schlabbach@gmx.net.
*EOF*
|
|
|