Clifford Kite wrote:
>
> On Fri, 17 Sep 1999, Thomas J Pinkl wrote:
>
> | rcvd [IPCP ConfReq id=0x7 <compress VJ 0f 01> <addr 10.0.0.21>]
> | sent [IPCP ConfNak id=0x7 <addr 10.1.0.5>]
> | rcvd [IPCP ConfReq id=0x8 <compress VJ 0f 01> <addr 10.0.0.21>]
> | sent [IPCP ConfRej id=0x8 <addr 10.0.0.21>]
> | rcvd [IPCP ConfReq id=0x9 <compress VJ 0f 01>]
> | sent [IPCP ConfAck id=0x9 <compress VJ 0f 01>]
> | local IP address 10.1.0.6
> | remote IP address 10.1.0.5
> |
> |The remote address, 10.1.0.5, is never Ack'd. Yet pppd proceeds as if
> |everything is fine. Of course, I cannot send packets to 10.1.0.5.
>
> If you want to accept the IP address that the peer wants then use the pppd
> option ipcp-accept-remote . Otherwise I can't see anything wrong, the
> remote proposed not negotiating IP addresses and pppd agreed. You can't
> force the peer to use an IP address that it doesn't want to use.
I definitely do not want to accept the remote's address.
If my pppd and the peer cannot agree upon an IP address, why is the
link established? What would be the point?
I don't want to force a mis-configured peer to use my IP address.
However, since an IP address couldn't be negotiated, I would expect pppd
to fail the connection attempt and not establish a ppp# interface.
If I'm missing something here, please, someone explain it to me. Thanks.
--
Thomas J. Pinkl 738 Louis Drive
Unix Systems Programmer Warminster, Pa 18974
Health Business Systems, Inc. (215) 442-9300 x9260
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
