Re: could not determine remote ip address

[email protected] wrote:
> Kostas wrote:
> michael1471 zonnet nl wrote:
> who knows about the IPCP negotiation of ppp?
> I've searched in this and other newsgroups for this error message:
>     Could not determine remote IP Address,
> but did not find a solution. Got this message when trying to start pppd.
> Just before this message it gives in the debug log:
>     rcvd [IPCP ConfAck id=0x2 <addr 62.59.16.49> <compress VJ 0f 01>
> 
>>Would i be asking too much if i would ask you to sent the entire
> 
> negotiation ?
> 
>>OR at least all the lines of the negotiation of ppp that speak about IPCP .
> 
> 
> (...)
> 
> Not at all. Here is the log:
> 
> What I find strange that
> * or the remote server does not offer/tell an IP address of itself
> * or the local (the linux box) does ask what the remote IP is
> Likely both. Why?
> 
> 
>>Aug 10 00:37:42 Magellan pppd[2378]: rcvd [IPCP ConfReq id=0x1 <addr
> 
> Remote.IP>]
> 
>>Here with the ConfReq , my dialin server says that he will configure my IP
> 
> Address and the
> 
>>remote IP ( that will provide my with my new IP is addr Remote.IP )
>>
>>Aug 10 00:37:42 Magellan pppd[2378]: sent [IPCP ConfAck id=0x1 <addr
> 
> Remote.IP>]
> 
>>now when the PPP Daemon on my computer receives that he ACKnowledges with
> 
> the
> 
>>above line , saying that he will ACCEPT the configuration provided by addr
> 
> Remote.IP
> 
>>Aug 10 00:37:42 Magellan pppd[2378]: rcvd [IPCP ConfRej id=0x1 <compress VJ
> 
> 0f 01>]
> 
>>Aug 10 00:37:42 Magellan pppd[2378]: sent [IPCP ConfReq id=0x2 <addr
> 
> 10.0.0.2> <ms-dns1 >0.0.0.0> <ms-dns3 0.0.0.0>]
> 
>>Now with this line my PPP Daemon says to my Dialin Server i want 3 IPs
>>1.  My new IP
>>2. The IP of the Primary      DNS Server
>>3. The IP of the Secondary DNS Server
> 
> (.....)
> 
>>Compare the lines i just gave you and sent back yours
>>
>>Kind Regards,
>> Kostas
> 
> 
> Thank you for this detailed explanation. I do not all the codes. But here
> below is the dump of one failed ppp session. The strange this is
> 
> Aug  4 11:57:19 localhost pppd[1233]: pppd 2.3.5 started by root, uid 0
> Aug  4 11:57:48 localhost pppd[1233]: Serial connection established.
> Aug  4 11:57:49 localhost pppd[1233]: Using interface ppp0
> Aug  4 11:57:49 localhost pppd[1233]: Connect: ppp0 <--> /dev/modem
> Aug  4 11:57:49 localhost pppd[1233]: sent [LCP ConfReq id=0x1 <magic
> 0xe3c6c989> <pcomp> <accomp>]
> Aug  4 11:57:51 localhost pppd[1233]: rcvd [LCP ConfReq id=0x1 <mru 1500>
> <asyncmap 0xa0000> <magic 0x5f114f5d> <pcomp> <accomp>]

The Remote Server sents you the following settings :

mru stands for Maximum Receive Unit . It defines how many bytes the
Remote Server can receive in one packet . It's value is 1500 bytes .
This means that you are allowed to sent to the Remote Server at most
  1500 bytes in one packet . If you want to sent to the Remote Server a 
file
that is for example 1600 bytes , then you will have to do it in two 
packets .
The pppd manpage has more .

asyncmap 0xa0000 , the asyncmap contains the charachters that should
be escaped during the time you are connected , man pppd for more details .

> Aug  4 11:57:51 localhost pppd[1233]: sent [LCP ConfAck id=0x1 <mru 1500>
> <asyncmap 0xa0000> <magic 0x5f114f5d> <pcomp> <accomp>]

Here you sent an LCP ConfAck as a response . An LCP ( Link Control 
Protocol )
ConfAck ( Configuration Acknowledgement ) is a message that says to the 
Remote
Server that you ACCEPT the settings that were just sent .


> Aug  4 11:57:52 localhost pppd[1233]: sent [LCP ConfReq id=0x1 <magic
> 0xe3c6c989> <pcomp> <accomp>]
> Aug  4 11:57:52 localhost pppd[1233]: rcvd [LCP ConfAck id=0x1 <magic
> 0xe3c6c989> <pcomp> <accomp>]


Observing my logs though . I have a remark to make . There is
no authentication method offered here .

Aug 10 00:37:41 Magellan pppd[2378]: sent [LCP ConfReq id=0x1 <asyncmap 
0x0>
<magic 0xb75e7c2c> <pcomp> <accomp>]
Aug 10 00:37:42 Magellan pppd[2378]: rcvd [LCP ConfReq id=0x44 <asyncmap 
0xa0000>
<auth pap> <magic 0xda9ed9a> <pcomp> <accomp>]

Observe the <auth pap> ( It means Authentication is done with the use of
Password Authentication Protocol , which means that i am required to sent
a username and a password in order to properly authenticate .


While am not an expert , this by itself can cause the entire LCP 
Negotiation
to fail , since you have no means of authenticating

Line A:
> Aug  4 11:57:52 localhost pppd[1233]: sent [IPCP ConfReq id=0x1 <addr
> 0.0.0.0>]

Here is the IPCP ( IP Control Protocol ) negotiation .  Here you request
( IPCP ConfReq )  an IP Address from the Remote Server . The IP
Address 0.0.0.0 is reserved for special use . So when the Remote Server 
examines
this lines and observes the value of 0.0.0.0 he will try to sent you a 
new valid IP
Address

> Aug  4 11:57:52 localhost pppd[1233]: rcvd [IPCP ConfReq id=0x1 <compress VJ
> 0f 00>]
> Aug  4 11:57:52 localhost pppd[1233]: sent [IPCP ConfRej id=0x1 <compress VJ
> 0f 00>]

> Aug  4 11:57:52 localhost pppd[1233]: rcvd [IPCP ConfNak id=0x1 <addr
> 62.59.16.90>]

With the above line the Remote Server says that he dissagress with you 
on the
mater of the IP Address 0.0.0.0 that you sent before at Line A.
ConfNak means Conf( iguration ) Negative Acknowledgment . At the same time
though the Remote Server sents you the IP that will sent you the correct
values for  your IP Address , and the DNS Servers that you will use .

Line 1:
> Aug  4 11:57:52 localhost pppd[1233]: sent [IPCP ConfReq id=0x2 <addr
> 62.59.16.90>]




> Aug  4 11:57:52 localhost pppd[1233]: rcvd [CCP ConfReq id=0x1 < 12 06 00 00
> 00 01>]
> Aug  4 11:57:52 localhost pppd[1233]: sent [CCP ConfReq id=0x1]
> Aug  4 11:57:52 localhost pppd[1233]: sent [CCP ConfRej id=0x1 < 12 06 00 00
> 00 01>]
> Aug  4 11:57:52 localhost pppd[1233]: rcvd [IPCP ConfReq id=0x2]
> Aug  4 11:57:52 localhost pppd[1233]: sent [IPCP ConfNak id=0x2 <addr
> 0.0.0.0>]

Line 3:
> Aug  4 11:57:52 localhost pppd[1233]: rcvd [IPCP ConfAck id=0x2 <addr
> 62.59.16.90>]


Line 3 , is the match of Line 1 ( they both have id=0x2 ) but in place
Line one has IPCP ConfReq , the second one has an IPCP ConfAck

> Aug  4 11:57:52 localhost pppd[1233]: rcvd [CCP ConfAck id=0x1]
> Aug  4 11:57:52 localhost pppd[1233]: rcvd [CCP ConfReq id=0x2 < 11 05 00 01
> 04>]
> Aug  4 11:57:52 localhost pppd[1233]: sent [CCP ConfRej id=0x2 < 11 05 00 01
> 04>]
> Aug  4 11:57:53 localhost pppd[1233]: rcvd [IPCP ConfReq id=0x3]
> Aug  4 11:57:53 localhost pppd[1233]: sent [IPCP ConfAck id=0x3]


This line represent a mess . After you have accepted with Line 3 that the
IP that will sent you the settings that you are going to use is
62.59.16.90,  YOU would have to SENT  another request IPCP ConfReq
with id=0x3 asking for your Local IP , and the IPs of the Primary and 
Secondary
DNS Servers .

Look at a snapshot of my logs :

Aug 10 00:37:42 Magellan pppd[2378]: sent [IPCP ConfReq id=0x2 <addr 
0.0.0.0>
  <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]

You see the buggy IP Address 0.0.0.0 is used in order to ask for the 
correct values



Aug 10 00:37:42 Magellan pppd[2378]: rcvd [IPCP ConfNak id=0x2 <addr 
x.x.x.x>
  <ms-dns1 y.y.y.y> <ms-dns3 z.z.z.z>]

The Remote Server doesn't  accept ( IPCP ConfNak ) the values give and 
provides new ones

Aug 10 00:37:42 Magellan pppd[2378]: sent [IPCP ConfReq id=0x3 <addr 
x.x.x.x>
<ms-dns1 y.y.y.y> <ms-dns3 z.z.z.z>]

This is the final step where i ask the Remote Server with the values 
given with the
IPCP ConfNak id=0x2

Aug 10 00:37:42 Magellan pppd[2378]: rcvd [IPCP ConfAck id=0x3 <addr 
x.x.x.x>
  <ms-dns1 y.y.y.y> <ms-dns3 z.z.z.z>]

Here my Remote Server accepts ( IPCP ConfAck ) and am done .




Are you certain that the dialin scripts that you use at least in
the IPCP Negotiation phase are correct ?


> The command that does not work looks like this:
>    pppd /dev/modem 38400  connect ./dialscript
> This generates a debug log like above.
> 
> The command that does work looks like this
>       pppd /dev/modem 38400  connect ./dialscript :1.1.1.1


If the two dialscript are the same , then the only difference that
can be observed is the :1.1.1.1 at the end of the seconf command line .
Well i can only say check the man page of pppd to see what that thing
does .

> This creates a succesfull dialup connection (although i use DNS statically)
> and I can ping to for example www.abc.com.
> 
> The /etc/ppp/options looks like this:
> detach
> debug
> noipdefault
> ipcp-accept-local
> ipcp-accept-remote
> lock
> defaultroute
> 
> I hoped that the option "ipcp-accept-remote" would solve the problem, but it
> did not...

Well i don't think that the problem is with the /etc/ppp/options file .
Mine for example has the word lock only