On Thu, 17 Feb 2000, Chan Yiu Wah wrote:

> ======= options.tty00 (Server) =======
> 202.66.33.77:202.66.50.159
> nodefaultroute
> ======= options.tty00 (Server) =======

> Peer is not authorized to use remote address 202.66.50.159

Try adding 'noauth' to the server's config file.  The authentication is
fairly complex, and can optionally be based on IP address.

If:
 noauth on the server solves your problem
 you want to use ppp-level (as opposed to login-level) authentication on
  the server
then:
 read the pppd(8) manual page carefully about all that authentication
  knobs.  It's explained there, but it's hard to understand and even
  harder to remember.  I doubt I could explain it better than they do.

BTW I completely agree with Frederick that you should assign the ppp link
addresses on a seperate subnet, _not_ addresses from Lan A or Lan B. At
this point, this advice shouldn't be taken any more lightly than the other
suggestions we've made.  It's a bigger change than some of the other
suggestions, but Frederick provided command line and config file examples,
while I provided a network diagram, so between the two of us you should be
off to a good start on implementing this. From your options file and error
message it looks like you haven't taken us up on this suggestion yet.

The whole story behind this advice is as follows.  While PPP has special
features to work without a separate subnet for the PPP link, it's a
special case, and you do not need to be exploring its subtle implications
unless you are an ISP with hundreds of customers.  I'm certainly not up to
the challenge.  Especially when you haven't gotten it working the easy way
(with a separate subnet for the ppp link) first. 

If this suggestion plus noauth on the server doesn't solve your problem, i
guess we'll have to keep thinking.

-- 
Miles Nordin / v:+1 720 841-8308 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US