How to set up dial-up on debian after a wrong pppoe config
David
3.0 install. I uninstallled the PPPOE modules via dselect but now I
can't seem to get my dial up working. For some reason (I don't know
if it's related, but I can't add a 127.0.0.0 default route either.
Here's the output of some files/commands:
netstat -rn:(notice nothing)
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window
irtt Iface
The command I used was "route add -net 127.0.0.0" but I get the
following error:
Invalid arguments
ifconfig: (notice no ppp0)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:300 errors:0 dropped:0 overruns:0 frame:0
TX packets:300 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21399 (20.8 KiB) TX bytes:21399 (20.8 KiB)
After trying to configure ppp via Bill Unruh's(spl?) HOW-TO and
getting as far as sending a chat command line to see how the ISP wants
me to connect, here is a ps x after the command:
796 pts/2 S 0:00 tail -f /var/log/ppp-connect-errors
814 ttyS1 S 0:00 /usr/sbin/pppd /dev/ttyS1 57600 debug
connect /usr/sbin/chat -v '' AT OK ATD9889615 CONNECT '\d\c'
815 ttyS1 S 0:00 /usr/sbin/chat -v AT OK ATD9889615 CONNECT
\d\c
816 pts/1 R 0:00 ps x
And here is the ppp-connect-errors log file:
Mar 21 20:03:48 coastsurf pppd[1512]: pppd 2.4.1 started by root, uid
0
Mar 21 20:03:49 coastsurf chat[1513]: send (AT^M)
Mar 21 20:03:49 oastsurf chat[1513]: expect (OK)
Mar 21 20:04:34 coastsurf chat[1513]: alarm
Mar 21 20:04:34 coastsurf chat[1513]: Failed
Mar 21 20:04:34 coastsurf pppd[1512]: Connect script failed
Mar 21 20:04:35 coastsurf pppd[1512]: Exit.
I get a big hang after the "send AT" command then always followed by a
"connect script failed error" I tried the setserial command but it
doesn't seem to matter. My modem is on ttyS1. I had it working under
RH6.2 previous to this install. I have not been able to find any
"drivers" for my modem online. It is a 3CXM056-BNW 3COM Noteworthy
used in a Toshiba 4020CDT. I can not get pon to work, or wvdial,
either. I am able to dial in with minicom using a ATZ init, but when
the login: prompt comes up it echos a couple of times and disconnects.
Thanks much. David
Cameron Kerr
> The command I used was "route add -net 127.0.0.0" but I get the
> following error:
> Invalid arguments
Because you didn't specify where traffic to 127.0.0.0 should go (nor did
you specify the netmask)
PS. Try configuring with 'pppconfig', IIRC. It's been a long time since
I've dealt with dialup.
--
Cameron Kerr
camero...@paradise.net.nz : http://nzgeeks.org/cameron/
Empowered by Perl!
Tauno Voipio
>
> And here is the ppp-connect-errors log file:
> Mar 21 20:03:48 coastsurf pppd[1512]: pppd 2.4.1 started by root, uid
> 0
> Mar 21 20:03:49 coastsurf chat[1513]: send (AT^M)
> Mar 21 20:03:49 oastsurf chat[1513]: expect (OK)
> Mar 21 20:04:34 coastsurf chat[1513]: alarm
> Mar 21 20:04:34 coastsurf chat[1513]: Failed
> Mar 21 20:04:34 coastsurf pppd[1512]: Connect script failed
> Mar 21 20:04:35 coastsurf pppd[1512]: Exit.
>
Your modem is not responding. Please check the connections
and modem power.
Test with minicom that the modem and processor are
connected.
HTH
Tauno Voipio
tauno voipio @ iki fi
Clifford Kite
> I believe I mistakenly installed ADSL/PPPOE support on a new debian
> 3.0 install. I uninstallled the PPPOE modules via dselect but now I
> can't seem to get my dial up working. For some reason (I don't know
> if it's related, but I can't add a 127.0.0.0 default route either.
> Here's the output of some files/commands:
> netstat -rn:(notice nothing)
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window
> irtt Iface
> The command I used was "route add -net 127.0.0.0" but I get the
> following error:
> Invalid arguments
For some reason you have to use
route add -net 127.0.0.0/8 lo
Why I do not know, since 127.0.0.0 is the network address for the old
classful A network (but it seems that everything works even without a
localhost network route). The classful network route has been added
automatically to Ethernet interfaces upon creation by ifconfig for all
stable kernels from versions 2.2.x on, but not so for lo, the localhost
interface.
There's nothing wrong with the chat script so the driver module for the
modem is very likely incompatible with the (presumably newer) Debian
kernel. From the sound of it the modem cannot echo it's responses to
AT commands correctly.
Many (including myself) view Winmodems, as well as their relatives,
as abominations. I'd highly recommend buying a real external modem
if you stay with Linux.
--
Clifford Kite Email: "echo xvgr_yv...@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
David
Yes, that worked for getting a route to localhost
>
> There's nothing wrong with the chat script so the driver module for the
> modem is very likely incompatible with the (presumably newer) Debian
> kernel. From the sound of it the modem cannot echo it's responses to
> AT commands correctly.
Well I'm at a loss. It worked with RH6.2 I think the serial_cs.o
module should work. I used pppd on RH7.2 also on another machine. I
think it has something to do with the IRQ's that the modem/serial port
is trying to use because it's a laptop with card services. I don't
really know enough about this to know what to do. I have to say that
with linux it is always something (for me) over my experience. It
seem like I have always have to upgrade to get what I am looking for,
and then comes the problems. I thought Debian was the cure becuase it
has a slick dselect/apt-get program that tracks dependencies and
upgrades them accordingly. But now something as simple as pppd is not
working. I think half the time you can not rely on what people tell
you to do on these message boards. And finding adequate documentation
that addresses exactly how things work so you can remedy problems is
very rare. They do a good job about some specific fix for some
specific machine/install/etc, but you never learn "why?" I thought I
starting to get past the learning curve with linux, but I guess I need
to learn how IO is assigned now. Where would I learn that?
Clifford Kite
>> modem is very likely incompatible with the (presumably newer) Debian
>> kernel. From the sound of it the modem cannot echo it's responses to
>> AT commands correctly.
> Well I'm at a loss. It worked with RH6.2 I think the serial_cs.o
> module should work. I used pppd on RH7.2 also on another machine. I
> think it has something to do with the IRQ's that the modem/serial port
> is trying to use because it's a laptop with card services. I don't
> really know enough about this to know what to do. I have to say that
That's a distinct possibility, an IRQ conflict will almost certainly
cause trouble, as would an incorrect IRQ assignment (although I don't
think that's the case here). I don't have laptop experience and so
can't comment on how "card services" on one would led you to believe
the IRQ is involved.
If you haven't already, to be sure there is an IRQ conflict, do
cat /proc/interrupts
to see if something else uses the IRQ used by the modem's serial device.
> with linux it is always something (for me) over my experience. It
> seem like I have always have to upgrade to get what I am looking for,
> and then comes the problems. I thought Debian was the cure becuase it
You might think of it as gathering Karma. :) But, yes, there can be
problems with upgrading and they are at times annoying.
> has a slick dselect/apt-get program that tracks dependencies and
> upgrades them accordingly. But now something as simple as pppd is not
Debian is highly regarded by a friend of mine, who has his own computer
farm (many networked computers), and seems to have very few problems
updating with those package upgrade programs. I use Slackware and as
a result have a fairly high Karma - but it's been worth it to me; I've
learned a lot.
Note that technically this is not a pppd problem, but rather a problem
with modem, or serial device configuration, or the modem driver.
> working. I think half the time you can not rely on what people tell
> you to do on these message boards. And finding adequate documentation
That I can't deny. :/
> that addresses exactly how things work so you can remedy problems is
> very rare. They do a good job about some specific fix for some
> specific machine/install/etc, but you never learn "why?" I thought I
> starting to get past the learning curve with linux, but I guess I need
> to learn how IO is assigned now. Where would I learn that?
The best answer I can give to "how IO is assigned" is manually or, for
PCI, automatically and perhaps according to the order the cards are put
in the MB slots. Manually can mean using setserial, or reordering the
cards, or, in some cases, it might mean configuring the BIOS to reserve
an interrupt and then using setserial.
As to never learning "why," are things really any different for other
operating systems? Especially closed source OSs - unless you pay for
support and even then I'm not sure how detailed the reply to a "why"
question would be.
If it turns out not to be caused by an IRQ configuration then you might
try replacing the "AT OK" in the chat script with "ATZ OK" that your
first post said minicom used on a successful dial out. Or AT&F might
be even better, if it works at all. I'd also check the serial device
setting of minicom.
--
Clifford Kite Email: "echo xvgr_yv...@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* In my book, the first poster to resort to personal abuse in a Usenet
debate loses by default. - Rod Smith */