On Sun, 30 Apr 2000, james rich wrote:
|On Sun, 30 Apr 2000, Clifford Kite wrote:
|
|reply below quoted text (kept here for reference)
|
|> On Sun, 30 Apr 2000, james rich wrote:
|> |Apr 30 03:31:40 growler pppd[1123]: sent [IPCP ConfReq id=0x1 <addr
|> |0.0.0.0> <compress VJ 0f 00>]
|> |Apr 30 03:31:40 growler pppd[1123]: rcvd [IPCP ConfReq id=0x1 <compress VJ
|> |0f 00> <addr 209.197.2.2>]
|> |Apr 30 03:31:40 growler pppd[1123]: sent [IPCP ConfAck id=0x1 <compress VJ
|> |0f 00> <addr 209.197.2.2>]
|> |Apr 30 03:31:40 growler pppd[1123]: rcvd [IPCP ConfNak id=0x1 <addr
|> |192.168.1.23>]
|> |Apr 30 03:31:40 growler pppd[1123]: sent [IPCP ConfReq id=0x2 <addr
|> |192.168.1.23> <compress VJ 0f 00>]
|> |Apr 30 03:31:40 growler pppd[1123]: rcvd [IPCP ConfAck id=0x2 <addr
|> |192.168.1.23> <compress VJ 0f 00>]
|> |Apr 30 03:31:40 growler pppd[1123]: local IP address 192.168.1.23
|> |Apr 30 03:31:40 growler pppd[1123]: remote IP address 209.197.2.2
|>
|> I'm not entirely sure that the symptom is associated with this, but you
|> need a routable IP address as the local IP address for the PPP connection.
|
|That's what I thought - but the 192.168.1.23 I'm pretty sure is coming
|from the ISP. I don't have any interface in that subnet - all my
|interfaces are in the 172.16.0.0 subnet. 192.186.0.0 subnet is not in any
|config file. So I am left a little confused.
I don't blame you, I goofed on where the reserved address came from. It
*did* come from the ISP. All I can say is "Duh!"
|> Pppd starts out the right way in the IPCP negotiations, but then NAKs the
|> local IP address that the peer requests it use, and requests the private
|> (non-routable) 192.168.1.23 that it got from a local LAN interface, or a
|> configuration option. The ISP accepts it, and that might be causing the
|> problem.
|
|It looks to me like the peer sent IPCP ConfNak id=0x1 <addr 192.168.1.23>
|- so isn't the peer requesting 192.168.1.23 and my host complying with the
|request?
Right.
|Here is the syslog from a working connection that I am using right now -
|this is with 2.2.14 kernel. Note that now the peer NAKs IP address
|192.168.3.2 so I don't think that it comes from my box.
...
|Apr 30 12:14:59 growler pppd[27388]: sent [IPCP ConfReq id=0x1 <addr
|0.0.0.0> <compress VJ 0f 00>]
|Apr 30 12:14:59 growler pppd[27388]: rcvd [IPCP ConfReq id=0x1 <compress
|VJ 0f 00> <addr 209.197.2.10>]
|Apr 30 12:14:59 growler pppd[27388]: sent [IPCP ConfAck id=0x1 <compress
|VJ 0f 00> <addr 209.197.2.10>]
|Apr 30 12:14:59 growler pppd[27388]: rcvd [IPCP ConfNak id=0x1 <addr
|192.168.3.2>]
|Apr 30 12:14:59 growler pppd[27388]: sent [IPCP ConfReq id=0x2 <addr
|192.168.3.2> <compress VJ 0f 00>]
|Apr 30 12:14:59 growler pppd[27388]: rcvd [IPCP ConfAck id=0x2 <addr
|192.168.3.2> <compress VJ 0f 00>]
|Apr 30 12:14:59 growler pppd[27388]: local IP address 192.168.3.2
|Apr 30 12:14:59 growler pppd[27388]: remote IP address 209.197.2.10
Unless I'm still out to lunch, these IPCP messages show the same thing
happening that happened for the non-working connection.
The fact that this connection works and the other doesn't is strange. The
ISP must be NATing in order for pppd to be able to use the reserved IP
address as the local address, but then I see no reason why both connections
should not work. Or at least work as well as they can work when the ISP
uses NATing and supplies a local reserved IP address.
So, bottom line, I don't know why one works and the other doesn't. It
would seem to be connected to the new PPP code but I'm not able to comment
on that. I do know that I'd never use an ISP that NATs and provides it's
clients with local reserved IP addresses, since - I *think* - you can't
have full Internet access capability that way.
---
Clifford Kite Not a guru. (tm)
[EMAIL PROTECTED] Not even close.
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
