"ksriram29@gmail.com" writes:
> What will happen if a ppp peer receives a PAP authenticate
> Ack with an identifier different from the one it sent in PAP
> authenticate request?

It's supposed to ignore it silently. It's also not supposed to happen
at all, so it probably doesn't matter.

> Can somebody explain me the behavior from the below log?
> Is the behavior correct one?

It looks like it to me.

> rcvd [LCP ConfReq id=0x1 ]

This system demands that the peer authenticate itself to the local
system.

> sent [LCP ConfReq id=0x1 ]

The peer also demands that you authenticate to it. You're using
bidirectional authentication.

This is legal, but highly unusual.

> sent [LCP ConfAck id=0x1 ]
> rcvd [LCP ConfAck id=0x1 ]

Both agree.

> sent [PAP AuthReq id=0x1 user="root" password=]

The system sends an authentication request, as demanded by the peer.

> sent [PAP AuthReq id=0x2 user="root" password=]

After a timeout, the local system sends another message. The first
must have been dropped.

> rcvd [PAP AuthAck id=0x3 "login ok"]

The peer responds with bogus ID number.

> Remote message: login ok
> PAP authentication succeeded

The local system accepts that. Oh, well. Not a big failing.

> sent [LCP TermReq id=0x2 "Authentication failed"]
> sent [LCP TermReq id=0x3 "Authentication failed"]

The remote system is broken. It never bothered to send a PAP
Authentication-Request, even though it *agreed* to do so above.
That's what caused the failure.

I suspect you might have "requirepap" in your configuration, and that
you don't really want it.

--
James Carlson 42.703N 71.076W

"ksriram29@gmail.com" writes:

>What will happen if a ppp peer receives a PAP authenticate
>Ack with an identifier different from the one it sent in PAP
>authenticate request?

>The below is the log of what actually happened. I am simulating
>one of the peer and using pppd in Linux as the other peer.
>The log is that of the pppd.

>Can somebody explain me the behavior from the below log?
>Is the behavior correct one?

You do not have time stamps on this. Always include the time stamps from
the logs. Many things ae time sensitive.


Both the local and the remote systems demand that the other authenticate
themselves. Both agree. You send them an authentication which succeeds, they never send
one to you. Thus after a while your system will say they have failed, which
it does.

Note that if the remote side is an ISP, they almost never willl
authenticate themselves to you. In they case they say they will, but don't.
I have no idea what "I am simulating
one of the peer and using pppd in Linux as the other peer" means. If this
is you playing silly buggers, then it is not surprising that all kinds of
nonesense can happen.



>Log:
>====

>Using interface ppp0
>Connect: ppp0 <--> /dev/pts/10
>rcvd [LCP ConfReq id=0x1 ]
>sent [LCP ConfReq id=0x1 ]
>sent [LCP ConfAck id=0x1 ]
>rcvd [LCP ConfAck id=0x1 ]
>sent [PAP AuthReq id=0x1 user="root" password=]
>sent [PAP AuthReq id=0x2 user="root" password=]
>rcvd [PAP AuthAck id=0x3 "login ok"]
>Remote message: login ok
>PAP authentication succeeded
>sent [LCP TermReq id=0x2 "Authentication failed"]
>sent [LCP TermReq id=0x3 "Authentication failed"]
>Connection terminated.

I removed the require-pap from the options file of pppd. Now I am
using unidirectional authentication. The authentication succeeds
and goes to the IPCP phase.

I am interested in knowing about why the pppd accepts the PAP
Auth-Ack packet with the bogus identifier. Shouldn't it ignore that
packet and continue sending PAP Auth-Req till it receives a PAP
Auth-Ack with a valid identifier or the maximum times it is configured
to send Auth-Req before terminating the connection.

How do I make the logs to include timestamps? By saying "I am
simulating
one of the peer " what I mean is that I am sending the PPP packets from
my
own program.

Thanks,
Sriram K

log:
===
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
rcvd [LCP ConfReq id=0x1 ]
sent [LCP ConfReq id=0x1]
sent [LCP ConfAck id=0x1 ]
rcvd [LCP ConfAck id=0x1]
sent [PAP AuthReq id=0x1 user="root" password=]
sent [PAP AuthReq id=0x2 user="root" password=]
rcvd [PAP AuthAck id=0x3 "login ok"]
Remote message: login ok
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 ]
sent [IPCP ConfReq id=0x1 ]
sent [IPCP ConfReq id=0x1 ]
sent [IPCP ConfReq id=0x1 ]
sent [IPCP ConfReq id=0x1 ]
sent [IPCP ConfReq id=0x1 ]
sent [IPCP ConfReq id=0x1 ]
sent [IPCP ConfReq id=0x1 ]
sent [IPCP ConfReq id=0x1 ]
sent [IPCP ConfReq id=0x1 ]
IPCP: timeout sending Config-Requests
sent [LCP TermReq id=0x2 "No network protocols running"]
sent [LCP TermReq id=0x3 "No network protocols running"]
Connection terminated.


Unruh wrote:
> "ksriram29@gmail.com" writes:
>
> >What will happen if a ppp peer receives a PAP authenticate
> >Ack with an identifier different from the one it sent in PAP
> >authenticate request?
>
> >The below is the log of what actually happened. I am simulating
> >one of the peer and using pppd in Linux as the other peer.
> >The log is that of the pppd.
>
> >Can somebody explain me the behavior from the below log?
> >Is the behavior correct one?
>
> You do not have time stamps on this. Always include the time stamps from
> the logs. Many things ae time sensitive.
>
>
> Both the local and the remote systems demand that the other authenticate
> themselves. Both agree. You send them an authentication which succeeds, they never send
> one to you. Thus after a while your system will say they have failed, which
> it does.
>
> Note that if the remote side is an ISP, they almost never willl
> authenticate themselves to you. In they case they say they will, but don't.
> I have no idea what "I am simulating
> one of the peer and using pppd in Linux as the other peer" means. If this
> is you playing silly buggers, then it is not surprising that all kinds of
> nonesense can happen.
>
>
>
> >Log:
> >====
>
> >Using interface ppp0
> >Connect: ppp0 <--> /dev/pts/10
> >rcvd [LCP ConfReq id=0x1 ]
> >sent [LCP ConfReq id=0x1 ]
> >sent [LCP ConfAck id=0x1 ]
> >rcvd [LCP ConfAck id=0x1 ]
> >sent [PAP AuthReq id=0x1 user="root" password=]
> >sent [PAP AuthReq id=0x2 user="root" password=]
> >rcvd [PAP AuthAck id=0x3 "login ok"]
> >Remote message: login ok
> >PAP authentication succeeded
> >sent [LCP TermReq id=0x2 "Authentication failed"]
> >sent [LCP TermReq id=0x3 "Authentication failed"]
> >Connection terminated.

"ksriram29@gmail.com" writes:

>I removed the require-pap from the options file of pppd. Now I am
>using unidirectional authentication. The authentication succeeds
>and goes to the IPCP phase.

>I am interested in knowing about why the pppd accepts the PAP
>Auth-Ack packet with the bogus identifier. Shouldn't it ignore that
>packet and continue sending PAP Auth-Req till it receives a PAP
>Auth-Ack with a valid identifier or the maximum times it is configured
>to send Auth-Req before terminating the connection.

>How do I make the logs to include timestamps? By saying "I am
>simulating

put
daemon.* /var/log/daemonlog
into /etc/sysconfig.conf

Then run
killall -1 syslogd
Then post the lines from /var/log/daemonlog after you have tried to
connect.


>one of the peer " what I mean is that I am sending the PPP packets from
>my
>own program.

Again I have no idea what you are saying.


>Thanks,
>Sriram K

>log:
>===
>Using interface ppp0
>Connect: ppp0 <--> /dev/pts/3
>rcvd [LCP ConfReq id=0x1 ]
>sent [LCP ConfReq id=0x1]
>sent [LCP ConfAck id=0x1 ]
>rcvd [LCP ConfAck id=0x1]
>sent [PAP AuthReq id=0x1 user="root" password=]
>sent [PAP AuthReq id=0x2 user="root" password=]
>rcvd [PAP AuthAck id=0x3 "login ok"]
>Remote message: login ok
>PAP authentication succeeded
>sent [IPCP ConfReq id=0x1 ]
>sent [IPCP ConfReq id=0x1 ]
>sent [IPCP ConfReq id=0x1 ]
>sent [IPCP ConfReq id=0x1 ]
>sent [IPCP ConfReq id=0x1 ]
>sent [IPCP ConfReq id=0x1 ]
>sent [IPCP ConfReq id=0x1 ]
>sent [IPCP ConfReq id=0x1 ]
>sent [IPCP ConfReq id=0x1 ]
>sent [IPCP ConfReq id=0x1 ]
>IPCP: timeout sending Config-Requests
>sent [LCP TermReq id=0x2 "No network protocols running"]
>sent [LCP TermReq id=0x3 "No network protocols running"]
>Connection terminated.


>Unruh wrote:
>> "ksriram29@gmail.com" writes:
>>
>> >What will happen if a ppp peer receives a PAP authenticate
>> >Ack with an identifier different from the one it sent in PAP
>> >authenticate request?
>>
>> >The below is the log of what actually happened. I am simulating
>> >one of the peer and using pppd in Linux as the other peer.
>> >The log is that of the pppd.
>>
>> >Can somebody explain me the behavior from the below log?
>> >Is the behavior correct one?
>>
>> You do not have time stamps on this. Always include the time stamps from
>> the logs. Many things ae time sensitive.
>>
>>
>> Both the local and the remote systems demand that the other authenticate
>> themselves. Both agree. You send them an authentication which succeeds, they never send
>> one to you. Thus after a while your system will say they have failed, which
>> it does.
>>
>> Note that if the remote side is an ISP, they almost never willl
>> authenticate themselves to you. In they case they say they will, but don't.
>> I have no idea what "I am simulating
>> one of the peer and using pppd in Linux as the other peer" means. If this
>> is you playing silly buggers, then it is not surprising that all kinds of
>> nonesense can happen.
>>
>>
>>
>> >Log:
>> >====
>>
>> >Using interface ppp0
>> >Connect: ppp0 <--> /dev/pts/10
>> >rcvd [LCP ConfReq id=0x1 ]
>> >sent [LCP ConfReq id=0x1 ]
>> >sent [LCP ConfAck id=0x1 ]
>> >rcvd [LCP ConfAck id=0x1 ]
>> >sent [PAP AuthReq id=0x1 user="root" password=]
>> >sent [PAP AuthReq id=0x2 user="root" password=]
>> >rcvd [PAP AuthAck id=0x3 "login ok"]
>> >Remote message: login ok
>> >PAP authentication succeeded
>> >sent [LCP TermReq id=0x2 "Authentication failed"]
>> >sent [LCP TermReq id=0x3 "Authentication failed"]
>> >Connection terminated.

I build the PPP packet with whatever options I want using a socket
program
and put it on the wire.
Thanks,
Sriram K

Unruh wrote:
> "ksriram29@gmail.com" writes:
>
> >I removed the require-pap from the options file of pppd. Now I am
> >using unidirectional authentication. The authentication succeeds
> >and goes to the IPCP phase.
>
> >I am interested in knowing about why the pppd accepts the PAP
> >Auth-Ack packet with the bogus identifier. Shouldn't it ignore that
> >packet and continue sending PAP Auth-Req till it receives a PAP
> >Auth-Ack with a valid identifier or the maximum times it is configured
> >to send Auth-Req before terminating the connection.
>
> >How do I make the logs to include timestamps? By saying "I am
> >simulating
>
> put
> daemon.* /var/log/daemonlog
> into /etc/sysconfig.conf
>
> Then run
> killall -1 syslogd
> Then post the lines from /var/log/daemonlog after you have tried to
> connect.
>
>
> >one of the peer " what I mean is that I am sending the PPP packets from
> >my
> >own program.
>
> Again I have no idea what you are saying.
>
>
> >Thanks,
> >Sriram K
>
> >log:
> >===
> >Using interface ppp0
> >Connect: ppp0 <--> /dev/pts/3
> >rcvd [LCP ConfReq id=0x1 ]
> >sent [LCP ConfReq id=0x1]
> >sent [LCP ConfAck id=0x1 ]
> >rcvd [LCP ConfAck id=0x1]
> >sent [PAP AuthReq id=0x1 user="root" password=]
> >sent [PAP AuthReq id=0x2 user="root" password=]
> >rcvd [PAP AuthAck id=0x3 "login ok"]
> >Remote message: login ok
> >PAP authentication succeeded
> >sent [IPCP ConfReq id=0x1 ]
> >sent [IPCP ConfReq id=0x1 ]
> >sent [IPCP ConfReq id=0x1 ]
> >sent [IPCP ConfReq id=0x1 ]
> >sent [IPCP ConfReq id=0x1 ]
> >sent [IPCP ConfReq id=0x1 ]
> >sent [IPCP ConfReq id=0x1 ]
> >sent [IPCP ConfReq id=0x1 ]
> >sent [IPCP ConfReq id=0x1 ]
> >sent [IPCP ConfReq id=0x1 ]
> >IPCP: timeout sending Config-Requests
> >sent [LCP TermReq id=0x2 "No network protocols running"]
> >sent [LCP TermReq id=0x3 "No network protocols running"]
> >Connection terminated.
>
>
> >Unruh wrote:
> >> "ksriram29@gmail.com" writes:
> >>
> >> >What will happen if a ppp peer receives a PAP authenticate
> >> >Ack with an identifier different from the one it sent in PAP
> >> >authenticate request?
> >>
> >> >The below is the log of what actually happened. I am simulating
> >> >one of the peer and using pppd in Linux as the other peer.
> >> >The log is that of the pppd.
> >>
> >> >Can somebody explain me the behavior from the below log?
> >> >Is the behavior correct one?
> >>
> >> You do not have time stamps on this. Always include the time stamps from
> >> the logs. Many things ae time sensitive.
> >>
> >>
> >> Both the local and the remote systems demand that the other authenticate
> >> themselves. Both agree. You send them an authentication which succeeds, they never send
> >> one to you. Thus after a while your system will say they have failed, which
> >> it does.
> >>
> >> Note that if the remote side is an ISP, they almost never willl
> >> authenticate themselves to you. In they case they say they will, but don't.
> >> I have no idea what "I am simulating
> >> one of the peer and using pppd in Linux as the other peer" means. If this
> >> is you playing silly buggers, then it is not surprising that all kinds of
> >> nonesense can happen.
> >>
> >>
> >>
> >> >Log:
> >> >====
> >>
> >> >Using interface ppp0
> >> >Connect: ppp0 <--> /dev/pts/10
> >> >rcvd [LCP ConfReq id=0x1 ]
> >> >sent [LCP ConfReq id=0x1 ]
> >> >sent [LCP ConfAck id=0x1 ]
> >> >rcvd [LCP ConfAck id=0x1 ]
> >> >sent [PAP AuthReq id=0x1 user="root" password=]
> >> >sent [PAP AuthReq id=0x2 user="root" password=]
> >> >rcvd [PAP AuthAck id=0x3 "login ok"]
> >> >Remote message: login ok
> >> >PAP authentication succeeded
> >> >sent [LCP TermReq id=0x2 "Authentication failed"]
> >> >sent [LCP TermReq id=0x3 "Authentication failed"]
> >> >Connection terminated.

"ksriram29@gmail.com" writes:
> I am interested in knowing about why the pppd accepts the PAP
> Auth-Ack packet with the bogus identifier.

Because, quite simply, it doesn't do that. Look at the code in
upap_input and upap_rauthack -- it does not do the check you're asking
about.

What more do you need to know?

> Shouldn't it ignore that
> packet and continue sending PAP Auth-Req till it receives a PAP
> Auth-Ack with a valid identifier or the maximum times it is configured
> to send Auth-Req before terminating the connection.

Yes ... but since this just never happens, why do you care?

--
James Carlson 42.703N 71.076W

Thanks Carlson. One last thing, is it compliant with the RFC? Because
from what I have read I feel that it isn't.

Thank you.
Sriram K

James Carlson wrote:
> "ksriram29@gmail.com" writes:
> > I am interested in knowing about why the pppd accepts the PAP
> > Auth-Ack packet with the bogus identifier.
>
> Because, quite simply, it doesn't do that. Look at the code in
> upap_input and upap_rauthack -- it does not do the check you're asking
> about.
>
> What more do you need to know?
>
> > Shouldn't it ignore that
> > packet and continue sending PAP Auth-Req till it receives a PAP
> > Auth-Ack with a valid identifier or the maximum times it is configured
> > to send Auth-Req before terminating the connection.
>
> Yes ... but since this just never happens, why do you care?
>
> --
> James Carlson 42.703N 71.076W

"ksriram29@gmail.com" writes:
> Thanks Carlson. One last thing, is it compliant with the RFC? Because
> from what I have read I feel that it isn't.

Yes, it's compliant. RFC 1334 does not say that you must discard
Authenticate-{Ack,Nak} packets with the wrong Identifier value. It
says only:

Identifier

The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Authenticate-Request which caused this
reply.

In other words, the authenticator is *required* to copy the Identifier
value from the Authenticate-Request message into the corresponding
reply. The authenticatee is under no obligation to validate this
field in any particular way.

Why do you feel that it is not compliant with the RFC? What
requirement is it violating?

Once again, I must ask: why do you care? What are you doing that
would produce this result, and why do you insist that there must be a
"purity test" here?

My take on it is that testing the received Identifier value would
actually be a bad thing to do, because it violates the cardinal rule:
"be conservative in what you send, liberal in what you expect."
Consider the case where you have a very slow external authentication
server: you send AuthReq ID=1, and before it can respond, you send
AuthReq ID=2. The server finally replies with AuthAck ID=1 -- why
would you want to discard that? And aren't you risking an unending
timing problem -- getting further and further behind as requests queue
up?

I can see no actual problem that is fixed by being overly picky about
the Identifier value, and several problems that may be caused by
adding such logic. (I can recommend a book that discusses some of the
pitfalls involved in PPP implementation, if you're interested.)

I could add logic as you suggest to pppd, but I see no reason to do
so.

--
James Carlson 42.703N 71.076W

Thanks once again Carlson. I am just a novice and in a learning curve.
Your detailed explanations has helped me. I would like to know the
book's
title and its author.

Thanks,
Sriram K

James Carlson wrote:
> "ksriram29@gmail.com" writes:
> > Thanks Carlson. One last thing, is it compliant with the RFC? Because
> > from what I have read I feel that it isn't.
>
> Yes, it's compliant. RFC 1334 does not say that you must discard
> Authenticate-{Ack,Nak} packets with the wrong Identifier value. It
> says only:
>
> Identifier
>
> The Identifier field is one octet and aids in matching requests
> and replies. The Identifier field MUST be copied from the
> Identifier field of the Authenticate-Request which caused this
> reply.
>
> In other words, the authenticator is *required* to copy the Identifier
> value from the Authenticate-Request message into the corresponding
> reply. The authenticatee is under no obligation to validate this
> field in any particular way.
>
> Why do you feel that it is not compliant with the RFC? What
> requirement is it violating?
>
> Once again, I must ask: why do you care? What are you doing that
> would produce this result, and why do you insist that there must be a
> "purity test" here?
>
> My take on it is that testing the received Identifier value would
> actually be a bad thing to do, because it violates the cardinal rule:
> "be conservative in what you send, liberal in what you expect."
> Consider the case where you have a very slow external authentication
> server: you send AuthReq ID=1, and before it can respond, you send
> AuthReq ID=2. The server finally replies with AuthAck ID=1 -- why
> would you want to discard that? And aren't you risking an unending
> timing problem -- getting further and further behind as requests queue
> up?
>
> I can see no actual problem that is fixed by being overly picky about
> the Identifier value, and several problems that may be caused by
> adding such logic. (I can recommend a book that discusses some of the
> pitfalls involved in PPP implementation, if you're interested.)
>
> I could add logic as you suggest to pppd, but I see no reason to do
> so.
>
> --
> James Carlson 42.703N 71.076W

"ksriram29@gmail.com" writes:

>Thanks once again Carlson. I am just a novice and in a learning curve.
>Your detailed explanations has helped me. I would like to know the
>book's
>title and its author.

The author is one James Carlson. PPP Design and Debugging
He tends to be coy about it.


>Thanks,
>Sriram K

>James Carlson wrote:
>> "ksriram29@gmail.com" writes:
>> > Thanks Carlson. One last thing, is it compliant with the RFC? Because
>> > from what I have read I feel that it isn't.
>>
>> Yes, it's compliant. RFC 1334 does not say that you must discard
>> Authenticate-{Ack,Nak} packets with the wrong Identifier value. It
>> says only:
>>
>> Identifier
>>
>> The Identifier field is one octet and aids in matching requests
>> and replies. The Identifier field MUST be copied from the
>> Identifier field of the Authenticate-Request which caused this
>> reply.
>>
>> In other words, the authenticator is *required* to copy the Identifier
>> value from the Authenticate-Request message into the corresponding
>> reply. The authenticatee is under no obligation to validate this
>> field in any particular way.
>>
>> Why do you feel that it is not compliant with the RFC? What
>> requirement is it violating?
>>
>> Once again, I must ask: why do you care? What are you doing that
>> would produce this result, and why do you insist that there must be a
>> "purity test" here?
>>
>> My take on it is that testing the received Identifier value would
>> actually be a bad thing to do, because it violates the cardinal rule:
>> "be conservative in what you send, liberal in what you expect."
>> Consider the case where you have a very slow external authentication
>> server: you send AuthReq ID=1, and before it can respond, you send
>> AuthReq ID=2. The server finally replies with AuthAck ID=1 -- why
>> would you want to discard that? And aren't you risking an unending
>> timing problem -- getting further and further behind as requests queue
>> up?
>>
>> I can see no actual problem that is fixed by being overly picky about
>> the Identifier value, and several problems that may be caused by
>> adding such logic. (I can recommend a book that discusses some of the
>> pitfalls involved in PPP implementation, if you're interested.)
>>
>> I could add logic as you suggest to pppd, but I see no reason to do
>> so.
>>
>> --
>> James Carlson 42.703N 71.076W

Unruh writes:

> "ksriram29@gmail.com" writes:
>
> >Thanks once again Carlson. I am just a novice and in a learning curve.
> >Your detailed explanations has helped me. I would like to know the
> >book's
> >title and its author.
>
> The author is one James Carlson. PPP Design and Debugging
> He tends to be coy about it.

Nah. I just figure that google and amazon searches are universally
available. ;-}

--
James Carlson 42.703N 71.076W

James Carlson writes:

>Unruh writes:

>> "ksriram29@gmail.com" writes:
>>
>> >Thanks once again Carlson. I am just a novice and in a learning curve.
>> >Your detailed explanations has helped me. I would like to know the
>> >book's
>> >title and its author.
>>
>> The author is one James Carlson. PPP Design and Debugging
>> He tends to be coy about it.

>Nah. I just figure that google and amazon searches are universally
>available. ;-}

Actually probably a bit more of a hint is required, although I must admit
that the first book listed on an Amazon search of "ppp" is the One.
Google is more useless since the first item is Pogo Producing Company




>--
>James Carlson 42.703N 71.076W