Hi there, FWIW my ADSL has been down for 5 hours with a similar error to those reported today.
I've noticed a bunch of posts about ADSL lately and so I've put together a few observations about ADSL debugging. I thought they might help those of you having troubles with your link. Comments welcome as its very incomplete. Maybe we can get a decent ADSL-Australia-Debug-HowTo out of it all? I use pppoe from the Roaring Penguin guys. It's great. Its connected to an ethernet port (eth1 in my case) 1) If you want to see if your connection's concentrator: eurekait>pppoe -i eth1 -A (ie eth1 is the ethernet port your modem is connected to, yours may be eth0, etc) which returns: Access-Concentrator: nkw2-kent AC-Ethernet-Address: 00:03:42:15:80:02 -------------------------------------------------- All this proves to my thinking is that the phone line is in place and works as far as the exchange, your modem is up, talking through the ethernet port and can communicate, to some degree, to the Access Concentrator. This is a good start.. 2) This will tell you what's been happening in the syslog re: ADSL Modem Hangups. eurekait>echo 'This shows the various connect times for the ADSL line based on hangups';grep 'Connect time' /var/log/syslog Heres the last bit of mine: Jan 30 01:41:41 eurekait pppd[13169]: Connect time 17.2 minutes. Jan 30 02:52:00 eurekait pppd[13169]: Connect time 70.4 minutes. Jan 30 05:26:18 eurekait pppd[13169]: Connect time 154.3 minutes. Jan 30 07:23:01 eurekait pppd[13169]: Connect time 116.7 minutes. Last hangup was at 7:23 my time. As you can see, the line dropped a lot last night. 3) If you're having issues connecting, this will probably be in your syslog. eurekait> tail -f /var/log/syslog Jan 30 10:30:26 eurekait pppd[5568]: Connect: ppp0 <--> /dev/pts/0 Jan 30 10:30:26 eurekait /etc/hotplug/net.agent: assuming ppp0 is already up Jan 30 10:30:57 eurekait pppd[5568]: LCP: timeout sending Config-Requests Jan 30 10:30:57 eurekait pppd[5568]: Connection terminated. >From what I can tell, having chatted to the guys at the other end, this requires a 'physical reset' at the Telstra end.. YKMV (Your Kilometers May Vary) 4) Debugging pppoe the verbose way. Built into pppoe is a script that can be altered to provide TONS of debug information. In my ugly hack of the script I insert a line to indicate that I require DEBUG. eurekait>which adsl-start /usr/sbin/adsl-start eurekait>vi /usr/sbin/adsl-start I <scroll down to a blank line>DEBUG="1"<RETURN> ESC :wq eurekait>adsl-start This will leave a debug directory in your /tmp/ for example : /tmp/pppoe-debug-30410/ This file will tell all: pppoe-debug.txt An example: Mine. ..skip lots of config data.... useful to check but boring... Using interface ppp0 Connect: ppp0 <--> /dev/pts/15 sent [LCP ConfReq id=0x9 <mru 1492> <magic 0xe8464a70>] sent [LCP ConfReq id=0x9 <mru 1492> <magic 0xe8464a70>] PADS: System-Error: No more sessions allowed for this host Script /usr/sbin/pppoe -p /var/run/-adsl.pid.pppoe -I eth1 -T 40 -U -m 1412 -D /tmp/pppoe-debug-30410/pppoe-debug.txt-0 finished (pid 30745), status = 0x100Modem hangup Connection terminated. using channel 239 .. skip lots more debug stuff... This line>PADS: System-Error: No more sessions allowed for this host Indicates that the exchange thinks I'm already connected, which is not really possible since I know I'm not???? Once the ISP guy heard this he contacted Telstra to 'reset' the connection (Don't ask me). 5) The old firewall trick. pppoe can be made to startup a firewall script once connected. ie there are options NONE, STANDALONE, MASQUERADE. These point to scripts for shorewall firewall stuff (on Mandrake anyway). I prefer to use NONE and have a seperate IPTABLES firewall script that is always up. One chap who rang me for help, this was the problem, the firewall was blocking some of the required communication. Make sure of your firewall rules and where they are being ran from. The Mandrake defaults are pretty good but there are better out there. Example from /var/log/syslog Jan 22 09:25:23 morticia kernel: Shorewall:OUTPUT:REJECT:IN= OUT=ppp0 SRC=144.137.111.174 DST=61.9.192.14 LEN=85 TOS=0x00 PREC=0x00 TTL=64 ID=33579 DF PROTO=UDP SPT=1029 DPT=53 LEN=65 Jan 22 09:25:23 morticia kernel: Shorewall:OUTPUT:REJECT:IN= OUT=ppp0 SRC=144.137.111.174 DST=61.9.192.15 LEN=85 TOS=0x00 PREC=0x00 TTL=64 ID=33579 DF PROTO=UDP SPT=1029 DPT=53 LEN=65 I think that the connection was fine but to the user, it looked like the link wasn't working. 6) Your /etc/resolv.conf When PPPOE starts up it call pppd which, if it establishes, adds lines to the resolv.conf to indicate the nameservers send to it from the ISP. Sometimes this seems to cause name resolution problems, don't ask me why but deleting the duplicated lines causes the problem to go. eurekait>cat /etc/resolv.conf search com dsl.xxxxxx.net.au nameserver 127.0.0.1 nameserver 61.8.0.113 nameserver 210.23.129.34 # ppp temp entry nameserver 61.8.0.113 # ppp temp entry nameserver 210.23.129.34 # ppp temp entry nameserver 61.8.0.113 # ppp temp entry nameserver 210.23.129.34 # ppp temp entry nameserver 61.8.0.113 # ppp temp entry nameserver 210.23.129.34 # ppp temp entry nameserver 61.8.0.113 # ppp temp entry nameserver 210.23.129.34 # ppp temp entry nameserver 61.8.0.113 # ppp temp entry nameserver 210.23.129.34 # ppp temp entry yadda yadda yadda.... See what I mean. Not that this should really upset name resolving but it does. Guess that's it, HTH Stu -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
