Frederick Ros wrote:
> It usualy goes to /var/log/syslog ...
Ok. I was finally able to get the logging verbosity on
pppd increased. I had to set *.* /var/log/messages in
my syslog.conf rather than the *.debug and others that
were there before.
Now, the logging gives me only a little bit more
information so I am hoping that perhaps you guys will
be able to help me analyze the problem.
I started using startadsl -d >& /tmp/startadsl.out,
and you can see from that output:
=====
pppd options in effect:
debug debug # (from /etc/ppp/peers/adsl)
updetach # (from /etc/ppp/peers/adsl)
persist # (from /etc/ppp/peers/adsl)
ktune # (from /etc/ppp/peers/adsl)
dump # (from /etc/ppp/peers/adsl)
noauth # (from /etc/ppp/peers/adsl)
user [EMAIL PROTECTED] # (from
/etc/ppp/peers/adsl)
# (from /etc/ppp/options)
connect /bin/true # (from
/etc/ppp/peers/adsl)
pty /usr/local/sbin/pppoe -I eth0 #
(from /etc/ppp/peers/adsl)
local # (from /etc/ppp/peers/adsl)
noaccomp # (from /etc/ppp/peers/adsl)
default-asyncmap # (from
/etc/ppp/peers/adsl)
mru 1492 # (from /etc/ppp/peers/adsl)
mtu 1492 # (from /etc/ppp/peers/adsl)
nopcomp # (from /etc/ppp/peers/adsl)
lcp-echo-failure 3 # (from
/etc/ppp/peers/adsl)
lcp-echo-interval 20 # (from
/etc/ppp/peers/adsl)
novj # (from /etc/ppp/peers/adsl)
novjccomp # (from /etc/ppp/peers/adsl)
ipcp-accept-local # (from
/etc/ppp/peers/adsl)
ipcp-accept-remote # (from
/etc/ppp/peers/adsl)
noipdefault # (from /etc/ppp/peers/adsl)
defaultroute # (from /etc/ppp/peers/adsl)
usepeerdns # (from /etc/ppp/peers/adsl)
noccp # (from /etc/ppp/peers/adsl)
nobsdcomp # (from /etc/ppp/peers/adsl)
nodeflate # (from /etc/ppp/peers/adsl)
noipx # (from /etc/ppp/peers/adsl)
Serial connection established.
using channel 14
Using interface ppp0
Connect: ppp0 <--> /dev/pts/13
sent [LCP ConfReq id=0x1 <mru 1492> <magic
0x7f761f36>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic
0x7f761f36>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic
0x7f761f36>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic
0x7f761f36>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic
0x7f761f36>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic
0x7f761f36>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic
0x7f761f36>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic
0x7f761f36>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic
0x7f761f36>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic
0x7f761f36>]
LCP: timeout sending Config-Requests
Connection terminated.
pppoe: Timeout waiting for PADO packets
Script /usr/local/sbin/pppoe -I eth0 finished (pid
5925), status = 0x1
=====
Now the above by itself does not give us too much
information. The question to be asked is whether the
PADI packets are actually getting to the modem. For
this, I checked two sources. The first was by looking
at tcpdump for the eth0 interface. And you can see:
09:55:42.526854 PPPoE PADI
09:55:47.526108 PPPoE PADI
09:55:57.524592 PPPoE PADI
09:56:43.949859 PPPoE PADI
09:56:48.948772 PPPoE PADI
09:56:58.947274 PPPoE PADI
Double checking:
32 137.701003 D-Link_99:5b:15 -> Broadcast PPPoED
Active Discovery Initiation (PADI)
33 142.700257 D-Link_99:5b:15 -> Broadcast PPPoED
Active Discovery Initiation (PADI)
34 152.698741 D-Link_99:5b:15 -> Broadcast PPPoED
Active Discovery Initiation (PADI)
35 199.124008 D-Link_99:5b:15 -> Broadcast PPPoED
Active Discovery Initiation (PADI)
36 204.122921 D-Link_99:5b:15 -> Broadcast PPPoED
Active Discovery Initiation (PADI)
37 214.121423 D-Link_99:5b:15 -> Broadcast PPPoED
Active Discovery Initiation (PADI)
So this is a good sign since it shows the dlink mac
address. To double check, i used eaglestat.1, this
shows:
==============
eagle-usb status display
-------------------------------------------------------------
Driver version 2
USB Bus : 002 USB Device : 003 Dbg mask: 0x0
Ethernet Interface : eth0
MAC: 00:05:5d:99:5b:15
Tx Rate 0000000128 Rx Rate 0000000384 Crc
0000000000
FEC 0000000000 Margin 0000000012 Atten
0000000032 dB
VID-CPE 0000000000 VID-CO 0000000028 HEC
0000000000
VPI 0000000000 VCI 0000000053 Delin
GOOD
Cells Rx 0000000000 Cells Tx 0000000179
Pkts Rx 0000000000 Pkts Tx 0000000110
OAM 0000000000 Bad VPI 0000000000 Bad CRC
0000000000
Oversiz. 0000000000
Modem is operational
==============
I'm not knowledgeable about the details of above. But
I can see that Cells Tx and Pkts Tx are incrementing
each time a PADI packet is sent on eth0. Note no rx is
observed. To me, I interpret this as the modem is
actually sending that out on the line but never
receiving anything. I don't see any bad CRC or
oversize so it seems everything physical is proper. Is
this assumption valid?
Assuming above is true, and the following facts:
1. we do not observe any PADO packet from the adsl
aggregator (according to tcpdump and eaglestat)
2. we know that the aggregator does respond when using
the same modem over windows
Then my first guess is that somehow the PADI packet is
being corrupted during transmission on to the wire?
Could this be the case?
I look forward to any suggestions/advice on how to
debug this issue. I will be happy to try anything.
Thanks,
Melkor
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
