PPP log

The PPP protokoll is used for different types of network connections. In DEFENDO this includes:

• ADSL / VDSL
• L2TP/IPSec VPN

As soon as there's a physical connection the PPP protocol is used to negotiate different parameters like e.g. packet sizes, compression algorithms and IP addresses. Usually there's also user authentication. If the peers do not agree upon a parameter the connection is terminated. Use the PPP log to find the reason for this. The PPP log is available in menu "Monitoring > Log files" at "Log file".

If the log contains no message which corresponds to the connection you are investigating, the problem occured on the physical connection layer.

ADSL

The modem is unreachable or the connection between modem and provider is interrupted

L2TP/IPSec-VPN

The IPSec connection failed

The lines of the PPP log contain the following fields:
date time name process[PID]: direction [layer command ID options]

PID (process ID)

Multiple PPP connections might be running at the same time. Only those lines with the same PID belong the same connection. Consider filtering the log file by PID.

direction

For every PPP packet DEFENDO receives from the peer "rcvd" is logged. Outbound packets are indicated by "sent".

layer

The PPP protocol uses several layers. First of all the link parameters are negotiated (LCP). The next layer is the optional authentication layer (PAP or CHAP). Sometimes you will see an additional compression layer (CCP). It is unlikely to cause any problems. Finally the IP addresses are negotiated in the IPCP layer.

Now examine the log. Which is the highest layer reached?

LCP

If you find "sent" packets only, the peer does not reply to the connection attempt. All log entries will look like this one:
...: sent [LCP ConfReq id=0x1 <mru 1500> <magic 0x...> <pcomp> <accomp>] This is typical for a broken ADSL dial-up line. Please refer to ADSL connection broken for further instructions.

The PPP command "ConfRej" indicates that the peers do not agree upon an option. The message shows this option.

In the following example the peer refuses to authenticate itself with PAP:
...: rcvd [LCP ConfRej <auth pap>] Possible reasons:

• The DEFENDO interface is misconfigured. Not the peer has to authenticate, DEFENDO has to (e.g. internet provider)
• The peer is misconfigured. Either it doesn't want to authenticate at all or it requests a different protocol (e.g. CHAP).

The next examples shows the opposite problem: DEFENDO refuses to authenticate itself with PAP.
...: sent [LCP ConfRej <auth pap>] Possible reasons:

• The peer is misconfigured
• No credentials have been supplied in the configuration of the corresponding DEFENDO interface

For all other problems on LCP layer you should forward an excerpt of the log to technical support.

Authentication (PAP or CHAP)

The log messages of PAP and CHAP are completely different. The examples assume that DEFENDO tries to login with username "test".

A successful PAP authentication looks like this:
...: sent [PAP AuthReq user="test" ...]
...: rcvd [PAP AuthAck ... ] If the peer authenticates itself "sent" and "rcvd" would be swapped.

With CHAP there are three lines:
...: rcvd [CHAP Challenge ...]
...: sent [CHAP Response name="test" ...]
...: rcvd [CHAP Success ... ]

A failed authentication for PAP and CHAP respectively looks like this:
...: rcvd [PAP AuthNak ... ]
...: rcvd [CHAP Failure ... ] First of all you should make sure that the credentials you supplied are correct.

A provider might reject the authentication for the following reasons:

• the account has been suspended or it has not been unlocked yet
• the authentication servers of the ISP are down. The credentials are rejected even though they are correct
• somebody else uses the same credentials. Some providers deny using the same login multiple times. This applies in particular to flatrate contracts.
• the ISP router missed that the previous connection has been terminated. Therefore it does not accept a new connection yet.

No reply to an authentication request of DEFENDO also indicates a problem with the ISP's authentication servers.

In all of the cases above you should contact your ISP.

For incoming connections (e.g. RAS, L2TP/IPSec) it might be DEFENDO rejecting authentication. Please make sure the corresponding user exists and is member of the DEFENDO group "system-ras".

IPCP

The IPCP layer is used to negotiate the IP addresses used. Both, the address of the caller and of the callee are subject to this.

Usually the callee suggests both addresses and the caller accepts them. If however the caller insist on using a specific address which the callee cannot accept the connection will fail as in the example below:
...: rcvd [IPCP ConfReq <addr 192.168.0.111>]
...: sent [IPCP ConfNak <addr 10.1.1.99>]
...: rcvd [IPCP TermReq ...] The pper likes to use address "192.168.0.111". DEFENDO rejects it (ConfNak) and proposes "10.1.1.99" instead. The peer obviously is not willing to accept it as it terminates the connection (TermReq).

In individual cases the dial-in server might expect the caller to present a specific IP.