Document the change from 0.0.0.1 to 0.0.0.* as `any remote address is OK'.

MFC after:	1 month
This commit is contained in:
Joerg Wunsch 2001-12-30 16:40:48 +00:00
parent 39b6f10cfb
commit 4e481b6c28

View File

@ -25,7 +25,7 @@
.\" .\"
.\" $FreeBSD$ .\" $FreeBSD$
.\" .\"
.Dd December 27, 2001 .Dd December 30, 2001
.Dt SPPP 4 .Dt SPPP 4
.Os .Os
.Sh NAME .Sh NAME
@ -120,11 +120,13 @@ late during the negotiation, which might cause the remote peer to make
wrong assumptions. wrong assumptions.
.Pp .Pp
In a similar spirit the remote address can be set to the magical In a similar spirit the remote address can be set to the magical
value 0.0.0.1 which means that we don't care what address the remote value
.Ns 0.0.0. Ns Em \&*
which means that we don't care what address the remote
side will use, as long as it is not 0.0.0.0. side will use, as long as it is not 0.0.0.0.
This is useful if your ISP has several dial-in This is useful if your ISP has several dial-in
servers. You can of course servers. You can of course
.Nm route Cm add Ar something_or_other 0.0.0.1 .Nm route Cm add Ar something_or_other 0.0.0. Ns Em \&*
and it will do exactly what you would want it to. and it will do exactly what you would want it to.
.Pp .Pp
The PAP and CHAP authentication protocols as described in RFC 1334, The PAP and CHAP authentication protocols as described in RFC 1334,