pon network problem

pon network problem

Post by Michael Robertso » Sun, 10 Nov 2002 03:08:18



Greetings!

I have just installed Debian 3.0 for the first time. I'm using pon to dial
up my isp.  I am connecting ok (I am getting carrier detect) but if I try
to load a web page and I have tried several, I recieve no data whatsoever.
 I can't ping any websites either.

I can dial my isp from my "red hat" partition without any problems (same
computer different partition).  That is where I am posting this message
from!

I have checked to permissions of the configuration files and I am using a
standard user to run pon.

I have tried both static and dynamic ip.

Why can't I load and web pages?

How can I rectify this problem?

TIA

PS: FWIW, here is the tail of syslog.

Nov  8 18:12:11 dalamatia pppd[543]: sent [CCP ConfReq id=0x4 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Nov  8 18:12:11 dalamatia pppd[543]: rcvd [CCP TermAck id=0x4]
Nov  8 18:12:14 dalamatia pppd[543]: sent [CCP ConfReq id=0x4 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Nov  8 18:12:14 dalamatia pppd[543]: rcvd [CCP TermAck id=0x4]
Nov  8 18:12:17 dalamatia pppd[543]: sent [CCP ConfReq id=0x4 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Nov  8 18:12:17 dalamatia pppd[543]: rcvd [CCP TermAck id=0x4]
Nov  8 18:12:20 dalamatia pppd[543]: sent [CCP ConfReq id=0x4 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Nov  8 18:12:20 dalamatia pppd[543]: rcvd [CCP TermAck id=0x4]
Nov  8 18:12:23 dalamatia pppd[543]: sent [CCP ConfReq id=0x4 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Nov  8 18:12:23 dalamatia pppd[543]: rcvd [CCP TermAck id=0x4]
Nov  8 18:12:26 dalamatia pppd[543]: sent [CCP ConfReq id=0x4 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Nov  8 18:12:26 dalamatia pppd[543]: rcvd [CCP TermAck id=0x4]
Nov  8 18:12:28 dalamatia pppd[543]: sent [LCP EchoReq id=0x2 magic=0x14af1aa2]
Nov  8 18:12:28 dalamatia pppd[543]: rcvd [LCP EchoRep id=0x2 magic=0x41c1ec1f]
Nov  8 18:12:29 dalamatia pppd[543]: sent [CCP ConfReq id=0x4 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Nov  8 18:12:29 dalamatia pppd[543]: rcvd [CCP TermAck id=0x4]
Nov  8 18:12:32 dalamatia pppd[543]: CCP: timeout sending Config-Requests
Nov  8 18:12:58 dalamatia pppd[543]: sent [LCP EchoReq id=0x3 magic=0x14af1aa2]
Nov  8 18:12:58 dalamatia pppd[543]: rcvd [LCP EchoRep id=0x3 magic=0x41c1ec1f]
Nov  8 18:13:28 dalamatia pppd[543]: sent [LCP EchoReq id=0x4 magic=0x14af1aa2]
Nov  8 18:13:28 dalamatia pppd[543]: rcvd [LCP EchoRep id=0x4 magic=0x41c1ec1f]
Nov  8 18:13:58 dalamatia pppd[543]: sent [LCP EchoReq id=0x5 magic=0x14af1aa2]
Nov  8 18:13:58 dalamatia pppd[543]: rcvd [LCP EchoRep id=0x5 magic=0x41c1ec1f]
Nov  8 18:14:28 dalamatia pppd[543]: sent [LCP EchoReq id=0x6 magic=0x14af1aa2]
Nov  8 18:14:28 dalamatia pppd[543]: rcvd [LCP EchoRep id=0x6 magic=0x41c1ec1f]
Nov  8 18:14:58 dalamatia pppd[543]: sent [LCP EchoReq id=0x7 magic=0x14af1aa2]
Nov  8 18:14:58 dalamatia pppd[543]: rcvd [LCP EchoRep id=0x7 magic=0x41c1ec1f]
Nov  8 18:15:28 dalamatia pppd[543]: sent [LCP EchoReq id=0x8 magic=0x14af1aa2]
Nov  8 18:15:28 dalamatia pppd[543]: rcvd [LCP EchoRep id=0x8 magic=0x41c1ec1f]

 
 
 

pon network problem

Post by Clifford Kit » Sun, 10 Nov 2002 23:59:02



> I have just installed Debian 3.0 for the first time. I'm using
> pon to dial up my isp.  I am connecting ok (I am getting carrier
> detect) but if I try to load a web page and I have tried several,
> I recieve no data whatsoever.
>  I can't ping any websites either.

What are the symptoms when you try?

Quote:> I can dial my isp from my "red hat" partition without any problems
> (same computer different partition).  That is where I am posting
> this message from!
> I have checked to permissions of the configuration files and I am
> using a standard user to run pon.
> I have tried both static and dynamic ip.

Huh?

Quote:> Why can't I load and web pages?

Insufficient data for a meaningful response.

Quote:> How can I rectify this problem?

Insufficient data for a meaningful response.

Quote:> TIA
> PS: FWIW, here is the tail of syslog.

It's worth the tail of the syslog.  Post an exact copy - not a hand-copy -
of the entire section of PPP negotiation messages (and chat -v messages
if they are present), but don't include the CCP or the Echo-{Req,Rep}
messages.

Also an exact copy of the output of "route -n" during a PPP connection
would be appropriate.

Quote:> Nov  8 18:12:11 dalamatia pppd[543]: sent [CCP ConfReq id=0x4 <deflate
> 15> <deflate(old#) 15> <bsd v1 15>]
> Nov  8 18:12:11 dalamatia pppd[543]: rcvd [CCP TermAck id=0x4]

Repeated ad nauseum.  The ISP is broken in sending "CCP TermAck" unless
pppd sent a "CCP TermReq" previously, which probably didn't happen.
The ISP doesn't want CCP so add the pppd "noccp" option, and also the
"echo request <n>" option unless you *know* that you want it


PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/
/* All the world's a net!  And all the data in it merely packets
   come to store-and-forward in the queues a while and then are
   heard no more.  'Tis a network waiting to be switched!
           -Vint Cerf, RFC 1121 */

 
 
 

pon network problem

Post by Clifford Kit » Mon, 11 Nov 2002 01:30:02



> The ISP doesn't want CCP so add the pppd "noccp" option, and also the

                                                               ^^^^^^^^
Quote:> "echo request <n>" option unless you *know* that you want it

  ^^^^^^^^^^^^^^^^^^^^^^^^^
Make that "also remove the "lcp-echo-interval <n>" option."

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/
/* For every credibility gap, there is a gullibility fill.
                -- R. Clopton */

 
 
 

pon network problem

Post by Michael Robertso » Wed, 13 Nov 2002 17:43:01


Hi,

Sorry for the delay in replying, been a bit busy the last few days.

Quote:>>  I can't ping any websites either.

> What are the symptoms when you try?

no error messages.  The prompt just hangs there.

Quote:

>> I have tried both static and dynamic ip.

> Huh?

I mean the dns addresses are detected automatically.

Quote:> It's worth the tail of the syslog.  Post an exact copy - not a hand-copy
> - of the entire section of PPP negotiation messages (and chat -v
> messages if they are present), but don't include the CCP or the
> Echo-{Req,Rep} messages.

ok here it is:

Nov 12 19:15:30 dalamatia kernel: CSLIP: code copyright 1989 Regents of the University of California
Nov 12 19:15:30 dalamatia kernel: PPP: version 2.3.7 (demand dialling)
Nov 12 19:15:30 dalamatia kernel: PPP line discipline registered.
Nov 12 19:15:30 dalamatia kernel: registered device ppp0
Nov 12 19:15:30 dalamatia pppd[502]: pppd 2.4.1 started by root, uid 0
Nov 12 19:15:31 dalamatia chat[503]: abort on (BUSY)
Nov 12 19:15:31 dalamatia chat[503]: abort on (NO CARRIER)
Nov 12 19:15:31 dalamatia chat[503]: abort on (VOICE)
Nov 12 19:15:31 dalamatia chat[503]: abort on (NO DIALTONE)
Nov 12 19:15:31 dalamatia chat[503]: abort on (NO DIAL TONE)
Nov 12 19:15:31 dalamatia chat[503]: abort on (NO ANSWER)
Nov 12 19:15:31 dalamatia chat[503]: abort on (DELAYED)
Nov 12 19:15:31 dalamatia chat[503]: send (ATZ^M)
Nov 12 19:15:31 dalamatia chat[503]: expect (OK)
Nov 12 19:15:31 dalamatia chat[503]: ATZ^M^M
Nov 12 19:15:31 dalamatia chat[503]: OK
Nov 12 19:15:31 dalamatia chat[503]:  -- got it
Nov 12 19:15:31 dalamatia chat[503]: send (ATDT99232000^M)
Nov 12 19:15:31 dalamatia chat[503]: expect (CONNECT)
Nov 12 19:15:31 dalamatia chat[503]: ^M
Nov 12 19:15:58 dalamatia chat[503]: ATDT99232000^M^M
Nov 12 19:15:58 dalamatia chat[503]: CONNECT
Nov 12 19:15:58 dalamatia chat[503]:  -- got it
Nov 12 19:15:58 dalamatia chat[503]: send (\d)
Nov 12 19:15:59 dalamatia pppd[502]: Serial connection established.
Nov 12 19:15:59 dalamatia pppd[502]: Using interface ppp0
Nov 12 19:15:59 dalamatia pppd[502]: Connect: ppp0 <--> /dev/ttyS1
Nov 12 19:16:00 dalamatia pppd[502]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 12 19:16:00 dalamatia pppd[502]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x7f95f168> <pcomp> <accomp>]
Nov 12 19:16:00 dalamatia pppd[502]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x7f95f168> <pcomp> <accomp>]
Nov 12 19:16:01 dalamatia pppd[502]: rcvd [LCP ConfReq id=0x2 <mru 1500> <asyncmap 0xa0000> <auth pap> <magic
0x757c462> <pcomp> <accomp> <mrru 1506>]
Nov 12 19:16:01 dalamatia pppd[502]: sent [LCP ConfRej id=0x2 <mrru 1506>]
Nov 12 19:16:01 dalamatia pppd[502]: rcvd [LCP ConfReq id=0x3 <mru 1500> <asyncmap 0xa0000> <auth pap> <magic
0x757c462> <pcomp> <accomp>]
Nov 12 19:16:01 dalamatia pppd[502]: sent [LCP ConfAck id=0x3 <mru 1500> <asyncmap 0xa0000> <auth pap> <magic
0x757c462> <pcomp> <accomp>]
Nov 12 19:16:01 dalamatia pppd[502]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
Nov 12 19:16:01 dalamatia pppd[502]: sent [PAP AuthReq id=0x1 user="david05" password=<hidden>]
Nov 12 19:16:01 dalamatia pppd[502]: rcvd [PAP AuthAck id=0x1 ""]
Nov 12 19:16:01 dalamatia pppd[502]: Couldn't set pass-filter in kernel: Invalid argument
Nov 12 19:16:01 dalamatia pppd[502]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Nov 12 19:16:02 dalamatia pppd[502]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 00> <addr 192.168.84.41>]
Nov 12 19:16:02 dalamatia pppd[502]: sent [IPCP ConfAck id=0x1 <compress VJ 0f 00> <addr 192.168.84.41>]
Nov 12 19:16:02 dalamatia pppd[502]: rcvd [IPCP ConfNak id=0x1 <addr 210.50.222.91> <ms-dns1 203.134.24.70> <ms-dns3 203.134.26.70>]
Nov 12 19:16:02 dalamatia pppd[502]: sent [IPCP ConfReq id=0x2 <addr 210.50.222.91> <compress VJ 0f 01> <ms-dns1 203.134.24.70> <ms-dns3 203.134.26.70>]
Nov 12 19:16:02 dalamatia pppd[502]: rcvd [IPCP ConfAck id=0x2 <addr 210.50.222.91> <compress VJ 0f 01> <ms-dns1 203.134.24.70> <ms-dns3 203.134.26.70>]
Nov 12 19:16:02 dalamatia pppd[502]: not replacing existing default route to tap0 [0.0.0.0]
Nov 12 19:16:02 dalamatia pppd[502]: Cannot determine ethernet address for proxy ARP
Nov 12 19:16:02 dalamatia pppd[502]: local  IP address 210.50.222.91
Nov 12 19:16:02 dalamatia pppd[502]: remote IP address 192.168.84.41
Nov 12 19:16:02 dalamatia pppd[502]: primary   DNS address 203.134.24.70
Nov 12 19:16:02 dalamatia pppd[502]: secondary DNS address 203.134.26.70

Why these addresses?

This is my resolv.conf:

nameserver 203.134.64.66

nameserver 203.134.65.65

Nov 12 19:16:02 dalamatia pppd[502]: Script /etc/ppp/ip-up started (pid 504)
Nov 12 19:16:02 dalamatia pppd[502]: Script /etc/ppp/ip-up finished (pid 504), status = 0x1
Nov 12 19:16:02 dalamatia fetchnews[519]: 1.9.19: verbosity level is 0
Nov 12 19:17:44 dalamatia init: Switching to runlevel: 6
Nov 12 19:17:46 dalamatia modprobe: modprobe: Can't locate module char-major-10-134
Nov 12 19:17:46 dalamatia diald[190]: SIGTERM. Termination request received.
Nov 12 19:17:46 dalamatia diald[190]: Diald is dying with code 0
Nov 12 19:17:46 dalamatia xfs[240]: terminating
Nov 12 19:17:47 dalamatia rpc.statd[172]: Caught signal 15, un-registering and exiting.
Nov 12 19:17:47 dalamatia kernel: Kernel logging (proc) stopped.
Nov 12 19:17:47 dalamatia kernel: Kernel log daemon terminating.
Nov 12 19:17:47 dalamatia exiting on signal 15
Nov 12 19:16:02 dalamatia pppd[502]: Script /etc/ppp/ip-up started (pid 504)
Nov 12 19:16:02 dalamatia pppd[502]: Script /etc/ppp/ip-up finished (pid 504), status = 0x1
Nov 12 19:16:02 dalamatia fetchnews[519]: 1.9.19: verbosity level is 0
Nov 12 19:17:44 dalamatia init: Switching to runlevel: 6
Nov 12 19:17:46 dalamatia modprobe: modprobe: Can't locate module char-major-10-134
Nov 12 19:17:46 dalamatia diald[190]: SIGTERM. Termination request received.
Nov 12 19:17:46 dalamatia diald[190]: Diald is dying with code 0
Nov 12 19:17:46 dalamatia xfs[240]: terminating
Nov 12 19:17:47 dalamatia rpc.statd[172]: Caught signal 15, un-registering and exiting.
Nov 12 19:17:47 dalamatia kernel: Kernel logging (proc) stopped.
Nov 12 19:17:47 dalamatia kernel: Kernel log daemon terminating.
Nov 12 19:17:47 dalamatia exiting on signal 15
Nov 12 19:16:02 dalamatia pppd[502]: Script /etc/ppp/ip-up started (pid 504)
Nov 12 19:16:02 dalamatia pppd[502]: Script /etc/ppp/ip-up finished (pid 504), status = 0x1
Nov 12 19:16:02 dalamatia fetchnews[519]: 1.9.19: verbosity level is 0
Nov 12 19:17:44 dalamatia init: Switching to runlevel: 6
Nov 12 19:17:46 dalamatia modprobe: modprobe: Can't locate module char-major-10-134
Nov 12 19:17:46 dalamatia diald[190]: SIGTERM. Termination request received.
Nov 12 19:17:46 dalamatia diald[190]: Diald is dying with code 0
Nov 12 19:17:46 dalamatia xfs[240]: terminating
Nov 12 19:17:47 dalamatia rpc.statd[172]: Caught signal 15, un-registering and exiting.
Nov 12 19:17:47 dalamatia kernel: Kernel logging (proc) stopped.
Nov 12 19:17:47 dalamatia kernel: Kernel log daemon terminating.
Nov 12 19:17:47 dalamatia exiting on signal 15

Quote:> Also an exact copy of the output of "route -n" during a PPP connection
> would be appropriate.

 Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.84.41   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.0.2     0.0.0.0         255.255.255.255 UH    1      0        0 tap0
0.0.0.0         0.0.0.0         0.0.0.0         U     1      0        0 tap0

Quote:>> Nov  8 18:12:11 dalamatia pppd[543]: sent [CCP ConfReq id=0x4 <deflate
>> 15> <deflate(old#) 15> <bsd v1 15>]
>> Nov  8 18:12:11 dalamatia pppd[543]: rcvd [CCP TermAck id=0x4]

> Repeated ad nauseum.  The ISP is broken in sending "CCP TermAck" unless
> pppd sent a "CCP TermReq" previously, which probably didn't happen. The
> ISP doesn't want CCP so add the pppd "noccp" option,

ok i did this but still no joy

Quote:> and also the "echo
> request <n>" option unless you *know* that you want it

I did this also.

I hope this can shed a bit more light on my problem.

Regards,

Michael

 
 
 

pon network problem

Post by Clifford Kit » Thu, 14 Nov 2002 02:33:35



>>>  I can't ping any websites either.

>> What are the symptoms when you try?
> no error messages.  The prompt just hangs there.

This usually means that the ping echo-request is being routed through
a local interface that is not functional, or the routing dead-ends at
that interface for some other reason - usually a default route that
doesn't pass traffic to the Internet.

Quote:>> It's worth the tail of the syslog.  Post an exact copy - not a hand-copy
>> - of the entire section of PPP negotiation messages (and chat -v
>> messages if they are present), but don't include the CCP or the
>> Echo-{Req,Rep} messages.
> ok here it is:
> Nov 12 19:15:30 dalamatia kernel: PPP: version 2.3.7 (demand dialling)
> Nov 12 19:15:30 dalamatia kernel: PPP line discipline registered.
> Nov 12 19:15:30 dalamatia kernel: registered device ppp0
> Nov 12 19:15:30 dalamatia pppd[502]: pppd 2.4.1 started by root, uid 0
...
> Nov 12 19:15:31 dalamatia chat[503]: send (ATZ^M)
> Nov 12 19:15:31 dalamatia chat[503]: expect (OK)
> Nov 12 19:15:31 dalamatia chat[503]: ATZ^M^M

Not the problem, but AT&F would almost certainly be better unless you
*know* that the profile set by ATZ is good.

There was no sign of anything wrong with the modem negotiations.

Quote:> Nov 12 19:15:59 dalamatia pppd[502]: Serial connection established.
> Nov 12 19:15:59 dalamatia pppd[502]: Using interface ppp0
> Nov 12 19:15:59 dalamatia pppd[502]: Connect: ppp0 <--> /dev/ttyS1
...
> Nov 12 19:16:01 dalamatia pppd[502]: rcvd [LCP ConfReq id=0x2 <mru 1500>
> <asyncmap 0xa0000> <auth pap> <magic> 0x757c462> <pcomp> <accomp>
> <mrru 1506>]
> Nov 12 19:16:01 dalamatia pppd[502]: sent [LCP ConfRej id=0x2 <mrru 1506>]
> Nov 12 19:16:01 dalamatia pppd[502]: rcvd [LCP ConfReq id=0x3 <mru 1500>
> <asyncmap 0xa0000> <auth pap> <magic> 0x757c462> <pcomp> <accomp>]
> Nov 12 19:16:01 dalamatia pppd[502]: sent [LCP ConfAck id=0x3 <mru 1500>
> <asyncmap 0xa0000> <auth pap> <magic> 0x757c462> <pcomp> <accomp>]

Not the problem but you can eliminate all this unnecessary Multilink PPP
negotiation by adding the pppd "nomp" option.
...

Quote:> Nov 12 19:16:01 dalamatia pppd[502]: Couldn't set pass-filter in kernel:
> Invalid argument

The Linux 2.4.1 pppd filter options are not ready for prime time.  You
can remove the filter options, and eliminate this message.  Again, not
the problem.
...

Quote:> Nov 12 19:16:02 dalamatia pppd[502]: not replacing existing default
> route to tap0 [0.0.0.0]

This is the problem.  You have an existing default route, and pppd won't
replace it with a default route through the PPP interface even with the
"defaultroute" option.  You very likely don't need the existing default
route and permanently removing it will fix the problem.

Quote:> Nov 12 19:16:02 dalamatia pppd[502]: Cannot determine ethernet
> address for proxy ARP

You almost certainly don't need the pppd "proxyarp" option and removing it
will get rid of this message.

Quote:> Nov 12 19:16:02 dalamatia pppd[502]: local  IP address 210.50.222.91
> Nov 12 19:16:02 dalamatia pppd[502]: remote IP address 192.168.84.41
> Nov 12 19:16:02 dalamatia pppd[502]: primary   DNS address 203.134.24.70
> Nov 12 19:16:02 dalamatia pppd[502]: secondary DNS address 203.134.26.70
> Why these addresses?

Which one?  The local IP address is routable, the remote IP address is
not routable but that doesn't make any difference - the PPP connection
will work fine anyway.  The remote IP address may be the IP address of
a NIC on your connection host and accepted by the ISP, or it could be
provided by the ISP.  If it is the IP address of the connection host on
a LAN then you can add the pppd "noipdefault" option and the ISP should
provide a different remote IP address.

Quote:> This is my resolv.conf:
> nameserver 203.134.64.66
> nameserver 203.134.65.65

Any of these *may* work.  I don't know where you got the ones in
resolv.conf but the ones provided by the pppd "usepeerdns" option
should be good.  These are nameservers provided by the Microsoft hack
for getting nameserver IP addresses during PPP negotiation but they
are not automatically added to /etc/resolv.conf.  They can be found
in /etc/ppp/resolv.conf.  It's either a multiple choice for you, or
a case of "whatever works."
...

Quote:> Nov 12 19:17:46 dalamatia modprobe: modprobe: Can't locate module
> char-major-10-134

You can get rid of this message by putting the line

alias char-major-10-134 off

in /etc/modules.conf.  I don't know what this module does but if modprobe
can't find it anyway...
...

Quote:>> Also an exact copy of the output of "route -n" during a PPP connection
>> would be appropriate.
>  Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 192.168.84.41   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
> 192.168.0.2     0.0.0.0         255.255.255.255 UH    1      0        0 tap0
> 0.0.0.0         0.0.0.0         0.0.0.0         U     1      0        0 tap0

The problem is diald and the tap0 interface.  The last route is a default
route through the tap0 interface, and the reason pppd didn't create a
default route through the ppp0 interface.

Diald is a frontend to pppd and I've never used it.  So I can't say
how to fix such a problem and get the default route through the PPP
interface instead of through tap0.  A possible alternative to diald
for demand-dialing is the pppd demand-pppd.gz at the web site in my
signature, but there is no filtering capability such as diald has.

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/
/* Speak softly and carry a +6 two-handed sword. */

 
 
 

pon network problem

Post by Michael Robertso » Thu, 14 Nov 2002 18:16:03


Hi Clifford,

Still no luck, please see my responses below:

Quote:> This is the problem.  You have an existing default route, and pppd won't
> replace it with a default route through the PPP interface even with the
> "defaultroute" option.  You very likely don't need the existing default
> route and permanently removing it will fix the problem.
>> Nov 12 19:16:02 dalamatia pppd[502]: local  IP address 210.50.222.91
>> Nov 12 19:16:02 dalamatia pppd[502]: remote IP address 192.168.84.41
>> Nov 12 19:16:02 dalamatia pppd[502]: primary DNS address 203.134.24.70
>> Nov 12 19:16:02 dalamatia pppd[502]: secondary DNS address 203.134.26.70

>> Why these addresses?

> Which one?  The local IP address is routable, the remote IP address is
> not routable but that doesn't make any difference - the PPP connection
> will work fine anyway.  The remote IP address may be the IP address of a
> NIC on your connection host and accepted by the ISP, or it could be
> provided by the ISP.  If it is the IP address of the connection host on
> a LAN then you can add the pppd "noipdefault" option and the ISP should
> provide a different remote IP address.

I was refering to the dns addresses.

I added the noipdefault option.

Quote:>> This is my /etc/resolv.conf:
>> nameserver 203.134.64.66
>> nameserver 203.134.65.65
> Any of these *may* work.  I don't know where you got the ones in
> resolv.conf

From the isp web site (www.iprimus.com.au).  They only specified the dns addresses for macos
for some reason.  I just thought I would try those out.  I suspect modify
the /etc/resolv.conf was unnecessary.

Quote:> but the ones provided by the pppd "usepeerdns" option should
> be good.

Do you mean 203.134.24.70 and 203.134.26.70?

Quote:> These are nameservers provided by the Microsoft hack for
> getting nameserver IP addresses during PPP negotiation but they are not
> automatically added to /etc/resolv.conf.

yes, i put them there ;)

Quote:> They can be found in
> /etc/ppp/resolv.conf.  It's either a multiple choice for you, or a case
> of "whatever works."

Ok, would you recomend that I put  203.134.24.70 and 203.134.26.70 in
/etc/resolv.conf and /etc/ppp/resolv.conf.

Quote:> The problem is diald and the tap0 interface.  The last route is a
> default route through the tap0 interface, and the reason pppd didn't
> create a default route through the ppp0 interface.

> Diald is a frontend to pppd and I've never used it.  So I can't say how
> to fix such a problem and get the default route through the PPP
> interface instead of through tap0.  A possible alternative to diald for
> demand-dialing is the pppd demand-pppd.gz at the web site in my
> signature, but there is no filtering capability such as diald has.

I tried demand-pppd but I got the following errors:

Nov 13 19:09:37 dalamatia pppd[866]: The remote system is required to authenticate itself
Nov 13 19:09:37 dalamatia pppd[866]: but I couldn't find any suitable secret (password) for it to use to do so.
Nov 13 19:09:37 dalamatia pppd[866]: (None of the available passwords would let it use an IP address.)

I checked man pppd.  I could not find any option that might be causing this.

My pap-secrets and chap-secrets files seem ok.

This is my (modified) script:

exec /usr/sbin/pppd connect '/usr/sbin/chat -v ABORT "NO DIALTONE" \
ABORT BUSY ABORT "NO CARRIER" ABORT "PROTOCOL: NONE" ABORT ERROR \
"" AT\&F OK ATDT55532000 CONNECT \\c'\
/dev/ttyS1 user freddy 115200 lock debug crtscts asyncmap 0 defaultroute \
demand idle 240000 ipcp-accept-local ipcp-accept-remote \
noipdefault holdoff 0 -detach ktune

btw I never knew you could use "\" for a new line continuation in bash!,
thanks.

Thanks and Regards,

Michael

 
 
 

pon network problem

Post by Clifford Kit » Thu, 14 Nov 2002 23:52:27



>>> Nov 12 19:16:02 dalamatia pppd[502]: local  IP address 210.50.222.91
>>> Nov 12 19:16:02 dalamatia pppd[502]: remote IP address 192.168.84.41
>>             The local IP address is routable, the remote IP address is
>> not routable but that doesn't make any difference - the PPP connection
>> will work fine anyway.  The remote IP address may be the IP address of a
>> NIC on your connection host and accepted by the ISP, or it could be
>> provided by the ISP.  If it is the IP address of the connection host on
>> a LAN then you can add the pppd "noipdefault" option and the ISP should
>> provide a different remote IP address.
> I added the noipdefault option.

It's not needed here, but won't hurt.  What I said wasn't correct; it's
the local IP address that this option affects, not the remote IP address.
The ISP must be deliberately using the non-routable IP address, or somewhere
in the configuration files it is assigned as the remote IP address and
the ISP accepts it.

Quote:> Ok, would you recomend that I put  203.134.24.70 and 203.134.26.70 in
> /etc/resolv.conf and /etc/ppp/resolv.conf.

They should work fine.  Here is some additional information on the choices,
as well as two more candidates:

~/mail$ host 203.134.24.70
70.24.134.203.IN-ADDR.ARPA domain name pointer nc1.mel.iprimus.com.au
~/mail$ host 203.134.26.70
70.26.134.203.IN-ADDR.ARPA domain name pointer nc2.mel.iprimus.com.au
~/mail$ host 203.134.64.66
66.64.134.203.IN-ADDR.ARPA domain name pointer nc1.syd.iprimus.com.au
~/mail$ host 203.134.65.65
65.65.134.203.IN-ADDR.ARPA domain name pointer vlan05.sw04.syd.iprimus.net.au

This is an excerpt from whois iprimus.com.au:

Tech Name:               Internet Primus

Name Server:             ns2.iprimus.com.au
Name Server IP:          203.134.65.67
Name Server:             ns1.iprimus.com.au
Name Server IP:          203.134.64.67

...

Quote:> I tried demand-pppd but I got the following errors:
> Nov 13 19:09:37 dalamatia pppd[866]: The remote system is required to
> authenticate itself
> Nov 13 19:09:37 dalamatia pppd[866]: but I couldn't find any suitable
> secret (password) for it to use to do so.
> Nov 13 19:09:37 dalamatia pppd[866]: (None of the available passwords
> would let it use an IP address.)
> I checked man pppd.  I could not find any option that might be causing
> this.

There used to be a tiny bug in pppd that would trigger this.  Now it
*should* mean that somewhere in the pppd configuration files in /etc/ppp
there is an option requiring that the peer authenticate itself to you.
Check the options file for "auth", "require-pap", or "require-chap" and
remove any such option.

Quote:> My pap-secrets and chap-secrets files seem ok.

I don't know any reason for that message other than requiring that
the ISP authenticate itself to you (which it won't do), but if you
can't find one of the options above and remove it then put a * in
the fourth field of the secrets lines:

username  *  password  *

Quote:> This is my (modified) script:
> exec /usr/sbin/pppd connect '/usr/sbin/chat -v ABORT "NO DIALTONE" \
> ABORT BUSY ABORT "NO CARRIER" ABORT "PROTOCOL: NONE" ABORT ERROR \
> "" AT\&F OK ATDT55532000 CONNECT \\c'\
> /dev/ttyS1 user freddy 115200 lock debug crtscts asyncmap 0 defaultroute \
> demand idle 240000 ipcp-accept-local ipcp-accept-remote \
> noipdefault holdoff 0 -detach ktune

If you want to terminate the PPP connection manually rather than use the
idle option then simply remove "idle 240000" from the script.

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/
/* Emacs vs vi:
   Sort of like a Swiss Army knife versus a rapier. */

 
 
 

pon network problem

Post by Clifford Kit » Fri, 15 Nov 2002 00:25:06



> I don't know any reason for that message other than requiring that
> the ISP authenticate itself to you (which it won't do), but if you
> can't find one of the options above and remove it then put a * in
> the fourth field of the secrets lines:
> username  *  password  *

Actually this won't work if pppd requires that the ISP authenticate
itself to pppd.  The ISP will refuse to do so and PPP negotiations
will fail.  That is, you *must not* require the ISP to authenticate
itself to pppd.

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/

 
 
 

pon network problem

Post by Michael Robertso » Fri, 15 Nov 2002 17:50:22


Hello again Clifford,

I have resolved my problem, I can now access the internet!!!  Please see my
comments below:

> It's not needed here, but won't hurt.  What I said wasn't correct; it's
> the local IP address that this option affects, not the remote IP
> address. The ISP must be deliberately using the non-routable IP address,
> or somewhere in the configuration files it is assigned as the remote IP
> address and the ISP accepts it.

> They should work fine.  Here is some additional information on the
> choices, as well as two more candidates:

> This is an excerpt from whois iprimus.com.au:

> Tech Name:               Internet Primus Tech Email:            

> Name Server:             ns2.iprimus.com.au Name Server IP:        
> 203.134.65.67 Name Server:             ns1.iprimus.com.au Name Server
> IP:          203.134.64.67

I changed the addresses in the /etc/resolv.conf file to 203.134.24.70 and
203.134.6.70 but after running pon, the addresses where changed back to
203.134.64.66 and 203.134.65.65.  So it would seem that the isp is
dynamically allocating the dns's, right?

I checked syslog to see what was creating the tap0.  I saw it was diald
so I removed diald from my system.  Now pon uses pppd to do the
negotiating.

I'm assuming I don't need diald on my system at all?

One final question:

Is there a command that I can run to tell me the baud rate of my
connection?

Thank you very much for your help.  I learnt a lot from this exercise.

Regards,

Michael

 
 
 

pon network problem

Post by Clifford Kit » Fri, 15 Nov 2002 21:49:29



>> This is an excerpt from whois iprimus.com.au:

>> Tech Name:               Internet Primus Tech Email:            

>> Name Server:             ns2.iprimus.com.au Name Server IP:        
>> 203.134.65.67 Name Server:             ns1.iprimus.com.au Name Server
>> IP:          203.134.64.67

> I changed the addresses in the /etc/resolv.conf file to 203.134.24.70 and
> 203.134.6.70 but after running pon, the addresses where changed back to
> 203.134.64.66 and 203.134.65.65.  So it would seem that the isp is
> dynamically allocating the dns's, right?

The ISP is providing DNS server IP addresses though the PPP negotiations
when pppd uses the usepeerdns option.  Pppd itself will *not* change
the server IP addresses in /etc/resolv.conf; the changes are being
made by something else, something Debian-specific.  I can only *guess*
that /ect/ppp/ip-up has something to do with the IP addresses changing.

It really doesn't matter what server IP addresses are in /etc/resolv.conf
as long as they work.

Quote:> I checked syslog to see what was creating the tap0.  I saw it was diald
> so I removed diald from my system.  Now pon uses pppd to do the
> negotiating.
> I'm assuming I don't need diald on my system at all?

Correct.  Diald has some filtering capability, and one or two other
features that can sometimes be useful, but are generally not necessary.

Quote:> One final question:
> Is there a command that I can run to tell me the baud rate of my
> connection?

The modem initialization ATs95=47, the chat directive REPORT CONNECT, and
the pppd updetach option should do it.

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/
/* The wealth of a nation is created by the productive labor of its
 * citizens. */

 
 
 

1. pon modem problem

Hallo,

when trying to dial out using pon the execution is interrupted and the
following messages can afterwards be read by means of plog:

chat[410]: send (ATZW2^M)
chat[410]: expect (OK)
chat[410]: ATZW2^M^M
chat[410]: OK
chat[410]:  -- got it
chat[410]: send (ATDT<put^M)
chat[410]: expect (phone)
chat[410]: ^M
chat[410]: ATDT<put^M^M
chat[410]: ERROR^M

Nonetheless it is possible to use minicom to make the modem dial and
connect properly using the ATDT<phone number> command.

Does anyone have any idea why it does not appear to work with pon
(after being configured with pppconfig).

The modem in question is a Xircom Creditcard 33.6 pcmcia.

Thanks.

//Regards, Johan

2. Platform independent IPsec

3. pon dsl-provider segfaults - ADSL connections fails

4. Using Dos Kermit as terminal for Linux

5. pon demand failing initial connect

6. RPM and thin clients

7. row to set up auto-redial if busy in Debian, i use pon command line.

8. Arun Shourie, on FLOSS v.s proprietory

9. no prompt after pon

10. PON question.

11. What app Is a better Dialup alternative to pon/poff???

12. Debian pon fails to make PAP connection

13. pon won't run with 2.4.17 kernel