Fixing Serial Line Speed Problems
Dial-in servers can
experience problems because of to conflicting speed settings. The next procedure
helps you isolate the cause of the link problem to conflicting serial-line
speeds.
The following are typical causes for speed problems:
pppd changes the speed that was originally set for the line
to the speed that was set by
/bin/login or
mgetty, which causes the line to fail.
How to Diagnose and Fix Serial Line Speed Problems
Log in to the dial-in server and call the peer with debugging turned
on.
If you need instructions, see "How to Turn on PPP Debugging".
Display the resulting /var/log/pppdebug log.
Check the output for the following message:
LCP too many configure requests |
This message indicates that the speeds of serial lines that were
configured for PPP might potentially be in conflict.
Check if PPP is invoked through a program such as /bin/login and the line speed that was set.
In such a situation, pppd changes the originally
configured line speed to the speed that is specified in /bin/login.
Check if a user started PPP from the mgetty command
and accidentally specified a bit rate.
This action also causes conflicting serial-line speeds.
Fix the conflicting serial-line speed problem as follows:
Lock the DTE rate on the modem.
Do not use autobaud.
Do not change the line speed after it has been configured.
Fixing Leased-Line Problems
The most common problem with leased
lines is poor performance. In most situations, you need to work with the telephone
company to fix the problem.
Table 35-6 Common Leased-Line Problems
Symptom | Problem | Solution |
|---|
The link does not start. | CSU
bio-polar violations (CSU BPVs) can be the cause. One end of the link is set
up for AMI lines and the other is set up for ESF bit 8 zero substitute (B8Zs). | If you are in the United States
or Canada, you can directly fix this problem from the menu of the CSU/DSU.
Check the CSU/DSU manufacturer's documentation for details. In other locales, the provider might be responsible for fixing CSU BPVs. |
The link has poor performance. | The pppd debug output shows CRC errors when sustained traffic
is on the link. Your line might have a clocking problem, caused by misconfigurations
between the telephone company and your network. | Contact the telephone company to ensure that it has used "loop clocking." On some unstructured leased lines, you might have to supply clocking.
North American users should use loop clocking. |
Diagnosing and Fixing Authentication Problems
Table 35-7 General Authentication Problems
Symptom | Problem | Solution |
|---|
pppd debug output shows the message Peer is not authorized to use remote address address. | You are using PAP authentication,
and the IP address for the remote peer is not in the /etc/ppp/pap-secrets file. | Add an asterisk (*) after the
entry for the peer in the /etc/ppp/pap-secrets file. |
pppd debug output shows that LCP comes
up but terminates shortly afterward. | The password
might be incorrect in the database for the particular security protocol. | Check the password for the peer in the /etc/ppp/pap-secrets or /etc/ppp/chap-secrets file. |
Diagnosing and Fixing PPPoE Problems
You can use PPP and standard UNIX utilities to identify problems with
PPPoE. This section explains how to obtain debugging information for PPPoE
and fix PPPoE-related problems.
How to Obtain Diagnostic Information for PPPoE
When you experience problems on
the link and suspect PPPoE is the cause, use the following diagnostic tools
to obtain troubleshooting information.
Become superuser on the machine that runs the PPPoE tunnel, either PPPoE
client or PPPoE access server.
Turn on debugging, as explained in the procedure "How to Turn on PPP Debugging".
View the contents of the log file /var/log/pppdebug.
The following example shows part of a log file that was generated for
a link with a PPPoE tunnel.
Example 35-3 Log File for a Link With a PPPoE Tunnel
Sep 6 16:28:45 enyo pppd[100563]: [ID 702911 daemon.info] Plugin
pppoe.so loaded.
Sep 6 16:28:45 enyo pppd[100563]: [ID 860527 daemon.notice] pppd
2.4.0b1 (Sun Microsystems, Inc.,
Sep 5 2001 10:42:05) started by troot, uid 0
Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] connect option:
'/usr/lib/inet/pppoec
-v hme0' started (pid 100564)
Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.info] Serial connection established.
Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.info] Using interface sppp0
Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.notice] Connect: sppp0
<--> /dev/sppptun
Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] /etc/ppp/pap-secrets
is apparently empty
Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] /etc/ppp/chap-secrets
is apparently empty
Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] sent
[LCP ConfReq id=0xef <mru 1492>
asyncmap 0x0 <magic 0x77d3e953><pcomp><acomp>
Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] rcvd
[LCP ConfReq id=0x2a <mru 1402>
asyncmap 0x0 <magic 0x9985f048><pcomp><acomp
|
If the debugging output does not help you isolate the problem, continue
on with this procedure.
Get diagnostic messages from PPPoE.# pppd connect "/usr/lib/inet/pppoec -v interface-name" |
pppoec sends diagnostic information to the stderr. If you run pppd in the foreground, the
output appears on the screen. If pppd runs in the background,
the output is sent to /etc/ppp/connect-errors.
The next example shows the messages that are generated as the PPPoE
tunnel is negotiated.
Example 35-4 PPPoE Diagnostic Messages
Connect option: '/usr/lib/inet/pppoec -v hme0' started (pid 100564)
/usr/lib/inet/pppoec: PPPoE Event Open (1) in state Dead (0): action SendPADI (2)
/usr/lib/inet/pppoec: Sending PADI to ff:ff:ff:ff:ff:ff: 18 bytes
/usr/lib/inet/pppoec: PPPoE State change Dead (0) -> InitSent (1)
/usr/lib/inet/pppoec: Received Active Discovery Offer from 8:0:20:cd:c1:2/hme0:pppoed
/usr/lib/inet/pppoec: PPPoE Event rPADO+ (5) in state InitSent (1): action SendPADR+ (5)
/usr/lib/inet/pppoec: Sending PADR to 8:0:20:cd:c1:2: 22 bytes
/usr/lib/inet/pppoec: PPPoE State change InitSent (1) -> ReqSent (3)
/usr/lib/inet/pppoec: Received Active Discovery Session-confirmation from
8:0:20:cd:c1:2/hme0:pppoed
/usr/lib/inet/pppoec: PPPoE Event rPADS (7) in state ReqSent (3): action Open (7)
/usr/lib/inet/pppoec: Connection open; session 0002 on hme0:pppoe
/usr/lib/inet/pppoec: PPPoE State change ReqSent (3) -> Convers (4)
/usr/lib/inet/pppoec: connected
|
If the diagnostic messages do not help you isolate the problem, continue
on with this procedure.
Run snoop and save the trace to a file.
For information about snoop,
refer to the snoop(1M)
man page.
# snoop -o pppoe-trace-file
|
View the snoop trace file.# snoop -i pppoe-trace-file -v pppoe |
Example 35-5 PPPoE snoop trace
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 1 arrived at 6:35:2.77
ETHER: Packet size = 32 bytes
ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast)
ETHER: Source = 8:0:20:78:f3:7c, Sun
ETHER: Ethertype = 8863 (PPPoE Discovery)
ETHER:
PPPoE: ----- PPP Over Ethernet -----
PPPoE:
PPPoE: Version = 1
PPPoE: Type = 1
PPPoE: Code = 9 (Active Discovery Initiation)
PPPoE: Session Id = 0
PPPoE: Length = 12 bytes
PPPoE:
PPPoE: ----- Service-Name -----
PPPoE: Tag Type = 257
PPPoE: Tag Length = 0 bytes
PPPoE:
PPPoE: ----- Host-Uniq -----
PPPoE: Tag Type = 259
PPPoE: Tag Length = 4 bytes
PPPoE: Data = Ox00000002
PPPoE:
.
.
.
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 5 arrived at 6:35:2.87
ETHER: Packet size = 60 bytes
ETHER: Destination = 8:0:20:78:f3:7c, Sun)
ETHER: Source = 0:2:fd:39:7f:7,
ETHER: Ethertype = 8864 (PPPoE Session)
ETHER:
PPPoE: ----- PPP Over Ethernet -----
PPPoE:
PPPoE: Version = 1
PPPoE: Type = 1
PPPoE: Code = 0 (PPPoE Session)
PPPoE: Session Id = 24383
PPPoE: Length = 20 bytes
PPPoE:
PPP: ----- Point-to-Point Protocol -----
PPP:
PPP-LCP: ----- Link Control Protocol -----
PPP-LCP:
PPP-LCP: Code = 1 (Configure Request)
PPP-LCP: Identifier = 80
PPP-LCP: Length = 18
|
