| CATEGORII DOCUMENTE |
| Asp | Autocad | C | Dot net | Excel | Fox pro | Html | Java |
| Linux | Mathcad | Photoshop | Php | Sql | Visual studio | Windows | Xml |
RASPPPOE
PPP over Ethernet Protocol
for Windows 2000/XP/2003
(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
Version 0.99, December 27th, 2005
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
9. Contacting the Author
Introduction
Welcome to RASPPPOE, a PPP over Ethernet (short: PPPoE) implementation for Windows 95, 98, 98SE, ME, NT 4.0, 2000, XP and Server 2003. 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:
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-2005 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
Riedthofstrasse 124
CH-8105 Regensdorf
Phone: +41 (0)43 388 99 99
Fax: +41 (0)43 388 99 88
Web: https://www.raspppoe.com
Installing the PPP over Ethernet Protocol
Creating PPP over Ethernet Dial-Up Connections
PPP over Ethernet dial-up connections can be most conveniently created with the Dial-Up Connection Setup application provided with the protocol, which creates dial-up connections with all the correct settings at the click of a button.
Removing the PPP over Ethernet Protocol
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:
Advanced Protocol Features
This section covers the advanced features of the protocol. Average users should be perfectly happy with the default settings, although limiting the send speed may improve the full-duplex performance of the connection. Also, 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:
Limit Send Speed
On links with asymmetric bandwidths (typically the case for xDSL or satellite links), TCP/IP is limited by the bandwidth of the slower direction. This option is intended to remedy this problem for links which have a lower upstream bandwidth. To use it, check the Limit Send Speed checkbox and type the actual upstream bandwidth of your broadband service in the Send Speed (kbps) edit box, in kilobits per second. Note that some broadband service providers do not specify the actually useable upstream bandwidth for their service, so you may have to enter a slightly lower number than the one specified by your service provider.
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.
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.
The Advanced tab offers the following settings:
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.
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.
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 simultaneously with this protocol (i.e. when establishing an outgoing connection with it or when it is configured to accept incoming connections), 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 exclusively this protocol, or disable the Log Warnings option as described above..
Beyond these settings, the protocol offers the following possibilities:
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/2003, 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 WINNTSystem32 directory (Windows 2000) or to your WindowsSystem32 directory (Windows XP/2003).
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_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon
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.
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:
A. Blank or '0': The protocol will connect to the default Service of the first Access Concentrator that replies to the connection request.
B. 'Service-Name': The protocol will connect to the first Access Concentrator that replies offering the requested Service.
C. 'Access-Concentrator': The protocol will connect to the default Service of the named Access Concentrator.
D. 'Access-ConcentratorService-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.
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/2003, 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.
Troubleshooting
This section helps you with possible problems you might encounter during the installation and use of the protocol.
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/2003) 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.
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 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/2003, 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 in question, and check the Status column.
If the Status is disabled, right-click the Local Area Connection and select Enable.
If enabling fails, check in Device Manager for possible problems with this adapter.
If you successfully enabled the adapter, re-run the RASPPPOE application and check whether the adapter is listed now.
If the adapter still does not show up, make sure that the protocol is enabled for the adapter in question:
Right-click the Local Area Connection of the adapter in question and select Properties.
In the properties dialog box, check the list of installed components. Make sure that the checkbox next to PPP over Ethernet Protocol is checked.
If the checkbox is clear, check it. You may be prompted about the digital signature again. Make sure you click 'Yes' (Windows 2000) or 'Continue Anyway' (Windows XP/2003) 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.
RASPPPOE application reports 'RASPPPOE - No Service Offers Received' when querying available services
This error message means that the protocol did not receive any response from your service provider. You should check the following things in order:
Check if your broadband modem has successfully established a link with its counterpart. Most DSL modems have a Sync LED on them which indicates this status. If your modem has such an LED and it indicates that the link is down, contact your service provider for assistance.
Check in Device Manager if the network adapter your broadband modem is connected to is enabled and working properly.
Check if your network adapter is correctly configured: Bring up Device Manager, select the network adapter your broadband modem is connected to and click Properties. In the Properties window, select the Advanced tab, look through the options and make sure that the correct Line Speed and duplex mode is selected (most DSL modems only support 10Mbps half duplex mode). If your network adapter has several connectors at the back, make sure the correct connector is selected, which is most likely Twisted Pair (TP).
Check that the cable connecting your broadband modem to your network adapter is properly attached and of the correct type. Note that broadband modems typically have a 'crossed' connector on them, so you will need a straight cable to connect it directly to a network adapter, while you need to use a crossed cable or use an uplink port to connect it to a hub or switch.
Check with your service provider whether they currently have a service outage.
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 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/2003, 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 in question, right-click it and select Disable.
Right-click the Local Area Connection again and select Enable.
Make another connection attempt and see if it works.
If that did not help, the dial-up connection you created may be configured to connect through a 'ghost' dial-up device that no longer exists. Do the following to remedy this:
Right-click the dial-up connection that failed to connect and select Properties.
In the Connect using: list view, take a close look at the name of the dial-up device that is checked. A 'ghost' dial-up device has the name format ISDN channel - Adapter Name (xx), while a correct entry is of the format ISDN channel - Adapter Name, i.e. the extra (xx) identifies a 'ghost' device.
If the checked device is indeed a 'ghost' device, clear it, look through the list for the correct dial-up device and check that one instead.
Make another connection attempt.
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.
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.
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.
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.
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.
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
Known Issues
This section documents known issues with the protocol.
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.
After initial installation, binding the protocol to a network adapter may not take effect
If you unbound the protocol from a network adapter by clearing the checkbox next to the PPP over Ethernet Protocol in the Properties of a Local Area Connection, binding the protocol to the network adapter by checking the checkbox again may not take effect, although you get no notification of this. If you unbound the protocol from all network adapters, the first binding you re-enable will take effect, but subsequent ones will not. There are three possible solutions in this situation:
Locate the Local Area Connection of the adapter in question, right-click it and select Disable. Then, right-click it again and select Enable. This will make the protocol work again. Note, though, that this temporarily disrupts any other network traffic you might run through this adapter.
Click the Uninstall button to remove the protocol completely and then click the Install button to re-install it. After re-installation, you will be able to use the protocol over that adapter immediately without a reboot, but you will see 'ghost' dial-up devices in your dial-up connection properties. These will go away when you reboot. See this known issue.
Reboot. After the reboot, the protocol will work on this adapter again.
Background: After the initial installation, the protocol driver is already running in memory. When the user checks the checkbox next to PPP over Ethernet Protocol, the Notify Object receives notification of a new adapter to bind to and calls INetCfgClassSetup::Install() to install a corresponding miniport device instance - and the Windows network configuration library makes the bad mistake of invoking the protocol driver's ProtocolBindAdapter() function before returning control to the Notify Object. This creates a semi-deadlock situation: ProtocolBindAdapter() needs the name of the installed miniport device instance before exiting, but only the Notify Object can provide that information, and the Notify Object cannot find out the name before the INetCfgClassSetup::Install() function returns control - and that will not return control until ProtocolBindAdapter() exits. Thus, the ProtocolBindAdapter() function fails to initialize the miniport device instance and the protocol will not work on the adapter. The Notify Object will still create the required registry values afterwards, and when re-initializing the adapter by disabling and re-enabling its Local Area Connection or upon the next reboot, ProtocolBindAdapter() will successfully initialize the miniport device instance and the protocol will work on the adapter.
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.
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.
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 WINNTSYSTEM32 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/2003.
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.
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/2003.
Revision History
First release with AMD64 support! The AMD64 version only runs on Windows x64 Editions and supports AMD's AMD64 as well as Intel's EM64T. It is distributed in a separate archive for now.
Added: Limit Send Speed option. This option can be used to limit the send speed of the protocol to the actual upstream bandwidth of the Internet link to remedy the poor full duplex performance of TCP/IP on links with asymmetric bandwidths.
Added: The installer (fully licensed version only) now picks up the optional files RASPPPOE.ICO and RASPPPOE.INI which can be used to customize the default icon for dial-up connections created for this protocol and the default protocol settings.
Added: The installer (fully licensed version only) can now be used to detect if the protocol is installed with the command-line arg /CHECKINSTALL. The installer returns 0 if the protocol is properly installed and operational.
Added: The installer (fully licensed version only) can now be used to check if any Access Concentrator can be reached with the command-line arg /CHECKCONNECTION. The installer returns 0 if it receives a response to a PPPoE PADI packet through any of the network adapters the protocol is operating on.
Changed: The installer (fully licensed version only) for the x86 platform now autodetects if it runs on one of the other two supported platforms (AMD64 and Intel Itanium) and automatically runs the corresponding installer executeable, so that the x86 installer executeable can be invoked to install the protocol on all supported platforms.
Changed: The protocol will now enable the reception of packets through the network adapter via the current packet filter only when it is actually needed, i.e. when either an outgoing connection has been initiated or when listening for incoming connections. This avoids unnecessary warnings logged to the event log when another PPPoE client software is used on the same machine and network adapter.
Changed: Increased all timeouts to allow use of the protocol over high-latency links such as satellite links. Now connection requests are resent after 5 seconds, then after 10 seconds and 15 seconds after that no answer is indicated, for a total timeout of 30 seconds. Incoming connections are now offered for up to 25 seconds. The watchdog timer during a connection now checks for traffic every 30 seconds and sends up to three LCP Echo-Requests before terminating the connection. Thus, a connection loss will now be detected within 120 to 150 seconds.
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/2003.
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/2003, 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.
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.
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.
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.
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.
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.
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.
Initial public release
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:
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*
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 1070
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
