Enable ppp debug mode что это

Модем не находит сервер PPPoE в сети.
Обычно причиной является одно из двух:
1. Некорректно указаны VPI, VCI
2. Проблемы со стороны провайдера.

Обратитесь в техническую поддержку Вашего провайдера. Пусть посмотрят логи на сервере, видны ли с его стороны попытки соединиться.

Работаю в сервисном центре, у самого дома 2540U (не BRU/D и не BRU/C, а самый обычный 2540U) настраиваю модемы уже в течении года, поэтому знаю, что все настройки верные. Однако попался мне 2540U/BRU/C, и нивкакую не поднимает сессию. вот логи.
Провайдер ЮТК, Краснодарский край (Усть-Лабинск)

Источник

Enable ppp debug mode что это

DSL-2540 в режиме роутера отваливается инет каждые 5-10 минут.

Судя по прочитанным темам на этом форуме я не одинок. Вижу проблема наблюдается и на некоторых других моделях этой линейки (2500, 2520). В общем, тестировал уже на двух модемах этой модели (благо работаю в торгующей организации и есть возможность взять на тест). Сначала грешил на провайдера, долго разбирался с поддержкой, пока в конце концов, настроив модем в режиме моста, не установил PPPoE соединение с компьютера. Все работает идеально, никаких разрывов. А ведь этот модем как раз приобретался мной именно для того, чтобы он работал в режиме роутера (дома комп, ноутбук, приставка для IPTV + подключение к локальной сети).
На сколько я понял проблема связана с периодическим обновлением DHCP-сервером динамического внешнего IP, который при этом остается неизменным? (хотя это всего лишь предположение, у меня провайдер ЮТК, Краснодарский край, но как я понял проблема наблюдается и у других провайдеров). Так же очевидно, что данная ситуация вполне корректно обрабатывается минипортом PPPoE встроенным в WinXP (так как на нем проблема не наблюдается).
Собственно вопрос: есть ли на данный момент какое либо решение проблемы? Если нет, то ведутся ли какие либо работы по этому поводу, ожидается ли прошивка с исправлениями?

ЗЫ чуть не забыл указать:
DSL-2540U/BRU/D
прошивка 1.2

Последний раз редактировалось amphasis Вт ноя 11, 2008 16:34, всего редактировалось 1 раз.

соединение то восстанавливается, если включен KeepAlive, вот только за эту минуту разрываются все закачки, происходит вылет из любой онлайн игры и другие пренеприятнейшие последствия
(советую еще раз перечитать мой первый пост ПОЛНОСТЬЮ)

по-моему проще сменить модем на что-нибудь по-лучше

Последний раз редактировалось d25 Вт ноя 11, 2008 16:10, всего редактировалось 1 раз.

Последний раз редактировалось amphasis Вт ноя 11, 2008 16:48, всего редактировалось 2 раз(а).

amphasis

Вы бы всеж-таки показали свои настройки роутера. Где и какие галочки ставили, а также желателен лог и статистика. Вот тогда можно что-то советовать. А пока, все это бесполезный флуд и флейм.

PORT 0
VPI 0
VCI 35
Service Category UBR without PCR

режим PPPoE
Authentication method AUTO

Use the following default gateway
Use IP address 85.172.0.2 либо
Use WAN interface с указанием соответствующего интерфейса (а он там настроен всего один)
с любой из этих настроек проблема проявляется

Retry PPP password on authentication error On|Off при любом значении этой настройки проблема проявляется

Следующие настройки выключены:
Dial on demand (with idle timeout timer)
Use Static IP Address
Retry PPP password on authentication error
Enable PPP Debug Mode
Bridge PPPoE Frames Between WAN and Local Ports
PPP IP extension
Advanced DMZ

Enable NAT on
Enable Firewall on
Enable IGMP Multicast off
Enable WAN Service on

Это все что касается соединения PPPoE
firewall (IP filtering), QoS, PortMapping, PortTriggering выключены

настройки DSL (с этими же настройками соединение с компьютера работает нормально)
G.Dmt Enabled
G.lite Enabled
T1.413 Enabled
ADSL2 Enabled
AnnexL Enabled
ADSL2+ Enabled
AnnexM Disabled

Select the phone line pair below.
X Inner pair
Outer pair

Capability
Bitswap Enable
SRA Disable

Хмм, попробовал включить
Enable PPP Debug Mode
и
Bridge PPPoE Frames Between WAN and Local Ports

Хмм, попробовал включить
Enable PPP Debug Mode
и
Bridge PPPoE Frames Between WAN and Local Ports

Enable PPP Debug Mode можно выключить, а то будет спамить в лог всякой фигней.
Также оставить включенными:
Bridge PPPoE Frames Between WAN and Local Ports
Retry PPP password on authentication error
Keep alive PPP connection

Можно оставить G.Dmt Enabled только, с остальных снять. Повысит стабильность ADSL.

Часовой пояс: UTC + 3 часа

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 28

Источник

Debugging PPP

Causes the debug ppp command to display PPP packets being sent and received. (This command displays low-level packet dumps.)

Causes the debug ppp command to display PPP packets transmitted during PPP startup, where PPP options are negotiated

Causes the debug ppp command to display protocol errors and error statistics associated with PPP connection negotiation and operation.

Causes the debug ppp command to display authentication protocol messages, including Challenge Authentication Protocol (CHAP) packet exchanges and Password Authentication Protocol (PAP) exchanges.

Causes the debug ppp command to display information specific to the exchange of PPP connections using MPPC. This command is useful for obtaining incorrect packet sequence number information where MPPC compression is enabled.

Causes the debug ppp command to display protocol errors and statistics associated with PPP connection negotiations using MSCB.

© 2001, Cisco Systems, Inc. All rights reserved. Cisco CCIE Prep v1.0—Module 3-88

© 2001, Cisco Systems, Inc. All rights reserved. Cisco CCIE Prep v1.0—Module 3-88

Use the debug ppp EXEC command to display information on traffic and exchanges in an internetwork implementing the Point-to-Point Protocol (PPP). The no form of this command disables debugging output.

Use the debug ppp commands when trying to find the following:

■ The Network Control Protocols (NCPs) that are supported on either end of a PPP connection

■ Any loops that might exist in a PPP internetwork

■ Nodes that are (or are not) properly negotiating PPP connections

■ Errors that have occurred over the PPP connection

■ Causes for CHAP session failures

■ Causes for PAP session failures

■ Information specific to the exchange of PPP connections using the Callback Control Protocol (CBCP), used by Microsoft clients

PPP Bri0/0 s state = ACKSENT fsm_rconfack(C021)s rcvd id 5

ppps config ACK received, type = 4 (CI_QUALITYTYPE), value = C025

ppps config ACK received, type = 5 (CI_MAGICNUMBER), value = 3D56CAC ppps ipcp_reqcis returning CONFACK.

PPP Bri0/0 s state = ACKSENT fsm_rconfack(8021)s rcvd id 4

• Determines if a client is passing the PPP negotiation phase

Cisco CCIE Prep v1.0—Module 3-8!

Use the debug ppp negotiation command to see if a client is passing PPP negotiation. This command is useful for verifying address negotiation.

The sample output shown is from the debug ppp negotiation command. This is a normal negotiation, where both sides agree on Network Control Program (NCP) parameters. In this case, protocol type IP is proposed and acknowledged.

The following table describes significant fields in the output. Table 3-5: Interpreting debug ppp negotiation Output

debug ppp negotiation Field Descriptions

This is PPP debugging output.

The router sent a configuration request.

type = 4 (CI_QUALITYTYPE)

The type of LCP configuration option that is being negotiated and a descriptor. A type value of 4 indicates Quality Protocol negotiation; a type value of 5 indicates Magic Number negotiation.

For Quality Protocol negotiation, indicates NCP type and reporting period. In the example, C025 indicates LQM; 3E8 is a hexadecimal value translating to about 10 seconds (in hundredths of a second).

For Magic Number negotiation, indicates the Magic Number being negotiated.

The receiving node has received the proposed option negotiation for the indicated option type.

Acknowledgment and acceptance of options.

Specific PPP state in the negotiation process.

debug ppp negotiation Field Descriptions

IPCP notification message; sending CONFACK.

The procedure fsm rconfack processes received CONFACKs, and the protocol (8021) is IP.

The following two lines of syntax indicate that the router is trying to bring up LCP and will use the indicated negotiation options (Quality Protocol and Magic Number). The value fields are the values of the options themselves. C025/3E8 translates to Quality Protocol LQM. 3E8 is the reporting period (in hundredths of a second). 3D56CAC is the value of the Magic Number for the router.

ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8 ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 3D56CAC

The next two lines indicate that the other side negotiated for options 4 and 5 as requested and acknowledged both. If the responding end does not support the options, a CONFREJ is sent by the responding node. If the responding end does not accept the value of the option, a CONFNAK is sent with the value field modified.

ppp: received config for type = 4 (QUALITYTYPE) acked ppp: received config for type = 5 (MAGICNUMBER) value = 3D567F8 acked (ok)

The next three lines indicate that the router received a CONFACK from the responding side and displays accepted option values. Use the rcvd id field to verify that the CONFREQ and CONFACK have the same id field.

PPP Bri0/0: state = ACKSENT fsm_rconfack(C021): rcvd id 5

ppp: config ACK received, type = 4 (CI_QUALITYTYPE), value = C025

ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 3D5 6CAC

The next line indicates that the router has IP routing enabled on this interface and that the IPCP NCP negotiated successfully:

ppp: ipcp_reqci: returning CONFACK.

In the last line, the router’s state is listed as ACKSENT. PPP Bri0/0: state = ACKSENT fsm_rconfack(C021): rcvd id 5\

BriO/O BriO/O BriO/O BriO/O

Unable to authenticate. No name received from peer

Unable to validate CHAP response. USERNAME pioneer not found.

Unable to validate CHAP response. No password defined for USERNAME pioneer

Failed CHAP authentication with remote.

Remote message is Unknown :

remote passed CHAP authentication. Passed CHAP authentication with remote. CHAP input code = 4 len = 48

Monitors PPP authentication process

Cisco CCIE Prep v1.0—Module 3-91

Shown here is sample output from the debug ppp authentication command. Use this command to determine why authentication is failing between two peer routers.

In general, these messages are self-explanatory. Fields that can show optional output are outlined in the following table.

debug ppp authentication Field Descriptions Field

Interface number associated with this debugging information and CHAP access session in question

USERNAME pioneer not found.

The name pioneer in this example is the name received in the CHAP response. The router looks up this name in the list of usernames that are configured for the router

Remote message is Unknown name

The following messages can appear: No name received to authenticate Unknown name No secret for given name Short MD5 response received MD compare failed

debug ppp authentication Field Descriptions Field

Specific CHAP type packet detected. Possible values are as follows:

Источник

Configuring and Troubleshooting PPP Password Authentication Protocol (PAP)

Available Languages

Download Options

Contents

Introduction

Point-to-Point Protocol (PPP) currently supports two authentication protocols: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Both are specified in RFC 1334 and are supported on synchronous and asynchronous interfaces.

PAP provides a simple method for a remote node to establish its identity using a two-way handshake. After the PPP link establishment phase is complete, a username and password pair is repeatedly sent by the remote node across the link (in clear text) until authentication is acknowledged, or until the connection is terminated.

PAP is not a secure authentication protocol. Passwords are sent across the link in clear text and there is no protection from playback or trial-and-error attacks. The remote node is in control of the frequency and timing of the login attempts.

For more information on troubleshooting PPP authentication (using either PAP or CHAP), refer to Troubleshooting PPP (CHAP or PAP) Authentication for a complete, step-by-step flow chart for troubleshooting the PPP authentication phase. For more information on troubleshooting all the PPP phases (LCP, Authentication, NCP), refer to document PPP Troubleshooting Flowchart for a complete flowchart for step-by-step troubleshooting of all related PPP phases and negotiated parameters.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

CHAP is considered to be more secure because the user password is never sent across the connection. For more information on CHAP, refer to Understanding and Configuring PPP CHAP Authentication.

Despite its shortcomings, PAP may be used in the following environments:

A large installed base of client applications that do not support CHAP

Incompatibilities between different vendor implementations of CHAP

Situations where a plaintext password must be available to simulate a login at the remote host

Unidirectional Vs Bi-directional Authentication

As with most types of authentication, PAP supports bi-directional (two way) and unidirectional (one way) authentication. With unidirectional authentication, only the side receiving the call (NAS) authenticates the remote side (client). The remote client does not authenticate the server.

With bi-directional authentication, each side independently sends an Authenticate-Request (AUTH-REQ) and receives either an Authenticate-Acknowledge (AUTH-ACK) or Authenticate-Not Acknowledged (AUTH-NAK). These can be seen with the debug ppp authentication command. An example of this debug at the client is shown below:

In the above debug output, the authentication was bi-directional. However if unidirectional authentication had been configured, we would only see the first two debug lines.

Configuration Commands

There are three commands required for normal PAP authentication described below:

ppp authentication pap [callin]

The router that the ppp authentication pap command is configured on will use PAP to verify the identity of the other side (peer). This means the other side (peer) must present it’s username/password to the local device for verification.

The callin option says the router that the ppp authentication pap callin command is configured on will only authenticate the other side during an incoming call. For an outgoing call, it will not authenticate the other side. This means the router initiating the call does not require a request for authentication (AUTH-REQ) from the other side

The following table shows when to configure the callin option:

username password

This is the username and password used by the local router to authenticate the PPP peer. When the peer sends its PAP username and password, the local router will check whether that username and password are configured locally. If there is a successful match, the peer is authenticated.

Note: The function of the username command for PAP is different than its function for CHAP. With CHAP, this username and password are used to generate the response to the challenge, but PAP only uses it to verify that an incoming username and password are valid.

For one-way authentication, this command is only required on the called router. For two-way authentication this command is necessary on both sides.

PPP pap sent-username password

Enables outbound PAP authentication. The local router uses the username and password specified by the ppp pap sent-username command to authenticate itself to a remote device. The other router must have this same username/password configured using the username command described above.

If you are using one-way authentication, this command is only necessary on the router initiating the call. For two-way authentication this command must be configured on both sides.

Configuration Example

The following configuration sections show the necessary PAP commands for a one way authentication scenario.

Note: Only the relevant sections of the configuration are shown.

Calling Side (Client) Configuration

Receiving Side (Server) Configuration

Debug Outputs

To debug a PPP PAP issue use the debug ppp negotiation and debug ppp authentication commands. There are two main issues that you must watch out for:

Do both sides agree that PAP is the method of authentication?

If so, does the PAP authentication succeed?

Refer to the debugs below for information on how to properly answer the these questions. Also, please refer to Understanding debug ppp negotiation Output for an explanation of all the different debugging lines with their relative meaning during the different PPP phases, including PPP authentication. This document is useful in quickly determining the cause of PPP negotiation failures. For more information on troubleshooting PPP authentication (using either PAP or CHAP), refer to Troubleshooting PPP (CHAP or PAP) Authentication for a complete, step-by-step flow chart for troubleshooting the PPP authentication phase.

Calling Side (client) debug for a successful one-way PAP authentication

Called Side (server) debug for a successful one-way PAP authentication

Troubleshooting PAP

When troubleshooting PAP, answer the same questions shown in the Debug Output Section:

Do both sides agree that PAP is the method of authentication?

If so, does the PAP authentication succeed?

For more information on troubleshooting PPP authentication (using either PAP or CHAP), refer to Troubleshooting PPP (CHAP or PAP) Authentication for a complete, step-by-step flow chart for troubleshooting the PPP authentication phase.

The two sides do not agree on PAP as the authentication protocol

In certain configuration you may observe that the two sides do not agree on PAP as the authentication protocol or instead agree on CHAP (when you wanted PAP). Use the following steps to troubleshoot such issues:

Verify that the router receiving the call has one of the following authentication commands

Verify that the router making the call has ppp authentication pap callin configured.

Configure the command ppp chap refuse in interface configuration mode on the calling router.

Cisco routers will, by default, accept CHAP as the authentication protocol. In a situation where the client wishes to do PAP but the access server can do PAP or CHAP ( ppp authentication chap pap configured), the ppp chap refuse command can be used to force the client to accept PAP as the authentication protocol.

PAP Authentication Does not Succeed

If the two sides agree on PAP as the authentication protocol, but the PAP connection fails, it is most likely a username/password issue.

Verify that the calling side has the command ppp pap sent-username username password password correctly configured, where the username and password match the one configured on the receiving router.

For two-way authentication, verify that the receiving side has the command ppp pap sent-username username password password correctly configured, where the username and password match the one configured on the calling router.

When doing two-way authentication, if the command ppp pap sent-username username password password were not present on the receiving router and the PPP client attempts to force the server to authenticate remotely, the output of debug ppp negotiation (or debug ppp authentication) would indicate

This error message is an indication of a configuration issue and not necessarily a security breach.

3. Verify that the username and password, matches the one configured in the command ppp pap sent-username username password password on the peer.

Источник

• Популярная книга Круть доступна для чтения прямо сейчас на нашем сайте boochi.ru. Скачать книгу в формате FB2, TXT, PDF, EPUB бесплатно без регистрации. →