Re: PPPoE

From: Yohan (yohanphilip_at_yahoo.com)
Date: 06/21/04

Next message: Gleb Smirnoff: "Re: PPPoE"

Previous message: Long Le: "Blasting UDP packets on a 1-Gbps link"
Maybe in reply to: Yohan: "Re: PPPoE"
Next in thread: Gleb Smirnoff: "Re: PPPoE"
Reply: Gleb Smirnoff: "Re: PPPoE"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Mon, 21 Jun 2004 06:04:32 -0700 (PDT)
To: Gleb Smirnoff <glebius@cell.sick.ru>, freebsd-net@freebsd.org

Gleb,

I sort of anticipated you would require the tcpdump
output. Its attached below. The Windows driver README
is the furthest below. The windows connection works
flawlessly but i wouldnt want to use windows unless
its the last resort. The instructions by the isp for
linux are as follows ...

FOR LINUX
----------
For redhat 7.2 or higher

Installing using RPM

Copy RPM rp-pppoe-3.5-1.i386.rpm in the root
directory.

Execute the command
rpm -Uvh rp-pppoe-3.5-1.i386.rpm

To configure
/usr/sbin/adsl-setup

To connect
/usr/sbin/adsl-start

To stop/disconnect
/usr/sbin/adsl-stop

To install GUI based PPPoE
rpm -Uvh rp-pppoe-3.5-1.i386.rpm
rp-pppoe-gui-3.5-1.i386.rpm

To connect GUI based PPPoE
/usr/bin/tkpppoe

Thanks and Regards

Yohann

Output of tcpdump -e -i rl1

17:47:58.383405 0:4:e6:2:44:12 Broadcast arp 64: arp
who-has 172.16.40.22 tell 172.16.40.17
17:48:04.718691 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:04.732330 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:04.732347 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:06.724827 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:09.603009 0:4:e6:2:44:12 Broadcast arp 64: arp
who-has 172.16.40.23 tell 172.16.40.17
17:48:09.875429 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:09.889090 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:09.889105 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:11.884908 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:15.035656 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:15.049217 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:15.049232 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:17.044982 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:20.195576 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:20.209343 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:20.209357 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:20.822597 0:4:e6:2:44:12 Broadcast arp 64: arp
who-has 172.16.40.23 tell 172.16.40.17
17:48:22.205063 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:25.355677 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:25.369222 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:25.369237 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:27.365137 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:30.515748 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:30.529471 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:30.529486 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:32.042197 0:4:e6:2:44:12 Broadcast arp 64: arp
who-has 172.16.40.23 tell 172.16.40.17
17:48:32.525219 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:35.675836 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:35.689479 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:35.689494 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:37.685297 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:40.847982 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:40.861730 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:40.861764 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:42.855374 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:43.261813 0:4:e6:2:44:12 Broadcast arp 64: arp
who-has 172.16.40.24 tell 172.16.40.17
17:48:46.006119 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:46.019730 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:46.019745 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:48.015450 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:51.166074 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:51.179734 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:51.179750 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:53.175528 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:54.481397 0:4:e6:2:44:12 Broadcast arp 64: arp
who-has 172.16.40.24 tell 172.16.40.17
17:48:56.326122 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:48:56.339611 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:48:56.339626 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:48:58.335606 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:49:01.486231 0:8:a1:5f:b5:4b Broadcast 8863 60:
PPPoE PADI [Host-Uniq UTF8]
17:49:01.499862 0:4:e6:4:41:1 0:8:a1:5f:b5:4b 8863 76:
PPPoE PADO [AC-Name "BANYAN"] [AC-Cookie UTF8]
[Service-Name] [Relay-Session-ID UTF8] [Host-Uniq
UTF8]
17:49:01.499878 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]
17:49:03.495683 0:8:a1:5f:b5:4b 0:4:e6:4:41:1 8863 60:
PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name
"BANYAN"]

RASPPPOE
PPP over Ethernet Protocol
for Windows 2000/XP/.NET

(If you are using Windows 95/98/98SE/ME, please click
here)
(If you are using Windows NT 4.0, please click here)
written by Robert Schlabbach
Licensed to Banyan Networks.
Version 0.98, October 3rd, 2002
Contents

    1. Introduction
    2. Installing the PPP over Ethernet Protocol
    3. Creating PPP over Ethernet Dial-Up Connections
    4. Removing the PPP over Ethernet Protocol
    5. Advanced Protocol Features
    6. Troubleshooting
    7. Known Issues
    8. Revision History

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 your broadband
service provider 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.
License

This driver, installation files and documentation is
all Copyright (C) 2000-2002 by Robert Schlabbach. All
rights reserved. This version of RASPPPOE is licensed
to:

Banyan Networks, India

Redistribution to third parties is strictly
prohibited, unless you have a license agreement which
permits the limited distribution of this software to
end users.
2. Installing the PPP over Ethernet Protocol

To install RASPPPOE, simply open the media on which
you received this software in Explorer and
double-click the file PPPOE098.EXE (or
PPPOE098_IA64.EXE if you are using an Intel Itanium
64-bit system) to run the automated installer, which
guides you through the installation process to your
first broadband connection. Only if the automated
installer should fail to work properly on your
machine, you need to do a manual installation. To
install the protocol manually, follow these steps:

* 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.

* If you already have a previous version of this
PPP over Ethernet Protocol installed, you must first
remove the old version. See Removing the PPP over
Ethernet Protocol for details.

* Create a temporary folder on your hard disk and
copy the file PPPOE098.EXE (or PPPOE098_IA64.EXE if
you are using an Intel Itanium 64-bit system) to it.

* Click the Start button on the taskbar and select
Run... to bring up the Run dialog box.

* Click the Browse... button, browse to the
temporary folder you create, select PPPOE098.EXE (or
PPPOE098_IA64.EXE if you are using an Intel Itanium
64-bit system) and click Open.

* Back at the Run dialog box, edit the name of the
program to run and append a space character followed
by /X to the name.

* Click OK. This will extract the installation
files to your temporary folder. You should check in
Explorer if the following required files (among
others, which are not used on Windows 2000/XP/.NET)
were correctly extracted: 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.

* 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/.NET, 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
get 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 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/.NET) 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/.NET)
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 you
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

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.

* 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

If the protocol was installed with the automated
installer, it was added to the list of installed
programs and can be conveniently removed through
Control Panel: Click on the Start button, select
Settings then Control Panel to open the Control Panel
window. In that window, double-click Add/Remove
Programs. In the upcoming dialog, locate the entry PPP
over Ethernet Protocol 0.98, select it and click
Change/Remove. The automated installer will guide you
through the removal process.

If the protocol was installed manually or you cannot
find the protocol in the list of installed programs,
you need to remove the protocol manually. To do this,
follow these steps:

* 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.

* 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/.NET.
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/.NET, 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:

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.

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
Connection Name window and connecting at least once.
        * 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/.NET, 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 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
(Windows 2000) or to your Windows\System32 directory
(Windows XP/.NET).
        * 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:

       1. Blank or "0": The protocol will connect to
the default Service of the first Access Concentrator
that replies to the connection request.
       2. "Service-Name": The protocol will connect to
the first Access Concentrator that replies offering
the requested Service.
       3. "Access-Concentrator\": The protocol will
connect to the default Service of the named Access
Concentrator.
       4. "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:

        * 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/.NET, 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.
        * 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/.NET) 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
Windows directory and delete it. Make another
installation attempt (which will probably fail as
well). Then check your Windows 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:

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" (Windows 2000) or "Continue
Anyway" (Windows XP/.NET) 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:

       1. 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.
       2. Check in Device Manager if the network
adapter your broadband modem is connected to is
enabled and working properly.
       3. 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).
       4. 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.
       5. 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:

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 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.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:

       1. 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.
       2. 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.
       3. 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/.NET.

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(),
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 2000/XP/.NET.

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

* Initial public release

*EOF*

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

Next message: Gleb Smirnoff: "Re: PPPoE"

Previous message: Long Le: "Blasting UDP packets on a 1-Gbps link"
Maybe in reply to: Yohan: "Re: PPPoE"
Next in thread: Gleb Smirnoff: "Re: PPPoE"
Reply: Gleb Smirnoff: "Re: PPPoE"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]