CHAP Auth issue at CentOS-6.8

CHAP Auth issue at CentOS-6.8

[Sekar D]

Hi Friends,

I am using CentOS-6.8 and ppp-2.4.5 , rp-pppoe-3.10-16.

I am getting CHAP Authentication failed when do the following

ifup ppp0

ifdown ppp0

sleep 20;

ifup ppp0


The same line working fine if I wait 2 minutes to bring it up after
shutdown the line.

I did not see kind of issue on CentOS-5.11 . Please let me know if I
need to change any config parameters.

Thanks.

Re: CHAP Auth issue at CentOS-6.8

[James Carlson]

On 09/13/2016 08:33 AM, Sekar D wrote:
> I did not see kind of issue on CentOS-5.11 . Please let me know if I
> need to change any config parameters.

It's a little hard to tell.  What are your current configuration parameters?

Have you tried running pppd with debugging enabled?  It would help to
have a trace of the connection in order to diagnose the failure mode.
The starting point is the pppd "debug" option, but if you're controlling
this connection with ifup/ifdown scripts, you'll have to look at your
system configuration to find out what pppd options are in use for that
link.  One possible answer, if all else fails, would be to run this
while the link is in the process of establishing:

  ps -fp `pgrep -d, pppd` | cat

(Yes, the "cat" is important; it tricks ps into printing the whole line.)

What kind of connection is this?  That is, what's the underlying serial
link?  Is it a physical wire on a serial port?  Is it a USB serial port?
 Is it ISDN?  Is it PPPoE or PPTP or L2TP?  Is it something else?

At a guess, the problem is on the remote end.  Typically, a user's PPP
connection is set up to be a "client" -- that is, to reply to
authentication requests from the peer and not to request authentication
from the peer.  This means that the remote system you're talking to
asked for your CHAP credentials, your system supplied them, and the
remote system denied your access based on those credentials.

If that only happens "sometimes" or is dependent on timing, then it
sounds like the remote system has some kind of usage restriction.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: CHAP Auth issue at CentOS-6.8

[Sekar D]

Hi James,

Thanks for helping me.

Yes. It happens only when I bring up DSL line before 2 minutes. The
same DSL lines are working fine without any issue at CentOS-5.11. I
could see the issue only at CentOS-6.8. So I would like to know that I
need to configure more to avoid these issues.

debug log:
-------------
Sep 13 15:16:15 Linux pppd[9425]: pppd 2.4.5 started by it-amazon, uid 0
Sep 13 15:16:15 Linux pppd[9425]: using channel 62
Sep 13 15:16:15 Linux pppd[9425]: Using interface ppp0
Sep 13 15:16:15 Linux pppd[9425]: Connect: ppp0 <--> /dev/pts/6
Sep 13 15:16:15 Linux pppoe[9426]: PADS: Service-Name: ''
Sep 13 15:16:15 Linux pppoe[9426]: PPP session is 11525 (0x2d05)
Sep 13 15:16:16 Linux pppd[9425]: sent [LCP ConfReq id=0x1 <mru 1492>
<magic 0x539b3bc6>]
Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP ConfReq id=0x4c <mru 1492>
<auth chap MD5> <magic 0x22bf9b51>]
Sep 13 15:16:16 Linux pppd[9425]: sent [LCP ConfAck id=0x4c <mru 1492>
<auth chap MD5> <magic 0x22bf9b51>]
Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP ConfAck id=0x1 <mru 1492>
<magic 0x539b3bc6>]
Sep 13 15:16:16 Linux pppd[9425]: sent [LCP EchoReq id=0x0 magic=0x539b3bc6]
Sep 13 15:16:16 Linux pppd[9425]: rcvd [CHAP Challenge id=0x1
<24a06e14743d399c933b61865730ea63>, name = "BSLYO656"]
Sep 13 15:16:16 Linux pppd[9425]: sent [CHAP Response id=0x1
<502b6f4ee944310f014e0033e9b5438b>, name = "fti/hbufbty"]
Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP EchoRep id=0x0 magic=0x22bf9b51]
Sep 13 15:16:16 Linux pppd[9425]: rcvd [CHAP Failure id=0x1 "CHAP
authentication failure, unit 509"]
Sep 13 15:16:16 Linux pppd[9425]: CHAP authentication failed: CHAP
authentication failure, unit 509
Sep 13 15:16:16 Linux pppd[9425]: CHAP authentication failed
Sep 13 15:16:16 Linux pppd[9425]: sent [LCP TermReq id=0x2 "Failed to
authenticate ourselves to peer"]
Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP TermReq id=0x4d]
Sep 13 15:16:16 Linux pppd[9425]: sent [LCP TermAck id=0x4d]
Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP TermAck id=0x2]
Sep 13 15:16:16 Linux pppd[9425]: Connection terminated.
Sep 13 15:16:16 Linux pppd[9425]: Waiting for 1 child processes...
Sep 13 15:16:16 Linux pppd[9425]:   script /usr/sbin/pppoe -p
/var/run/pppoe-adsl-0.pid.pppoe -I eth1.101 -T 0 -U  -m 1412   , pid
9426
Sep 13 15:16:16 Linux pppoe[9426]: read (asyncReadFromPPP): Session
11525: Input/output error
Sep 13 15:16:16 Linux pppoe[9426]: Sent PADT
Sep 13 15:16:16 Linux pppd[9425]: Script /usr/sbin/pppoe -p
/var/run/pppoe-adsl-0.pid.pppoe -I eth1.101 -T 0 -U  -m 1412
finished (pid 9426), status = 0x1
Sep 13 15:16:16 Linux pppd[9425]: Exit.
Sep 13 15:16:16 Linux pppoe-connect: PPPoE connection lost; attempting
re-connection.

My config file :

USERCTL=yes
BOOTPROTO=dialup
NAME=DSLppp0
DEVICE=ppp0
TYPE=xDSL
ONBOOT=no
PIDFILE=/var/run/pppoe-adsl-0.pid
FIREWALL=NONE
PING=.
PPPOE_TIMEOUT€
LCP_FAILURE=3
LCP_INTERVAL0
CLAMPMSS\x1412
CONNECT_POLL=6
CONNECT_TIMEOUT 
SYNCHRONOUS=no
ETH=eth1
PROVIDER=DSLppp0
USER="xxxxxx"
PEERDNS=no
DEMAND=no
DEFAULTROUTE=no


Thanks,


On Tue, Sep 13, 2016 at 6:40 PM, James Carlson <carlsonj@workingcode.com> wrote:
> On 09/13/2016 08:33 AM, Sekar D wrote:
>> I did not see kind of issue on CentOS-5.11 . Please let me know if I
>> need to change any config parameters.
>
> It's a little hard to tell.  What are your current configuration parameters?
>
> Have you tried running pppd with debugging enabled?  It would help to
> have a trace of the connection in order to diagnose the failure mode.
> The starting point is the pppd "debug" option, but if you're controlling
> this connection with ifup/ifdown scripts, you'll have to look at your
> system configuration to find out what pppd options are in use for that
> link.  One possible answer, if all else fails, would be to run this
> while the link is in the process of establishing:
>
>   ps -fp `pgrep -d, pppd` | cat
>
> (Yes, the "cat" is important; it tricks ps into printing the whole line.)
>
> What kind of connection is this?  That is, what's the underlying serial
> link?  Is it a physical wire on a serial port?  Is it a USB serial port?
>  Is it ISDN?  Is it PPPoE or PPTP or L2TP?  Is it something else?
>
> At a guess, the problem is on the remote end.  Typically, a user's PPP
> connection is set up to be a "client" -- that is, to reply to
> authentication requests from the peer and not to request authentication
> from the peer.  This means that the remote system you're talking to
> asked for your CHAP credentials, your system supplied them, and the
> remote system denied your access based on those credentials.
>
> If that only happens "sometimes" or is dependent on timing, then it
> sounds like the remote system has some kind of usage restriction.
>
> --
> James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: CHAP Auth issue at CentOS-6.8

[James Carlson]

On 09/13/2016 09:25 AM, Sekar D wrote:
> Yes. It happens only when I bring up DSL line before 2 minutes. The
> same DSL lines are working fine without any issue at CentOS-5.11. I
> could see the issue only at CentOS-6.8. So I would like to know that I
> need to configure more to avoid these issues.

I don't think there's anything you can do.  The peer is refusing your
request.  I think it's game over at that point.

There's nothing obviously wrong on your end, at least in what's revealed
in this short debug log.

I suggest calling the provider's technical support line.  You'll need
their help in finding out why your connection request is being refused.

If you can't do that, or if they can't help, then you'll need to find a
new provider.

> Sep 13 15:16:15 Linux pppoe[9426]: PADS: Service-Name: ''
> Sep 13 15:16:15 Linux pppoe[9426]: PPP session is 11525 (0x2d05)

PPPoE is in use.  That helps a bit.  It would help to know if there's
anything different about a successful connection.

Could it be that it just takes a *very* long time for this provider to
tear down a previous connection?

Could there be a bug in PPPoE rather than in pppd itself?  (Note that
PPPoE is just a transport; it's completely distinct from PPP.)

> Sep 13 15:16:16 Linux pppd[9425]: sent [LCP ConfReq id=0x1 <mru 1492>
> <magic 0x539b3bc6>]
> Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP ConfReq id=0x4c <mru 1492>
> <auth chap MD5> <magic 0x22bf9b51>]
> Sep 13 15:16:16 Linux pppd[9425]: sent [LCP ConfAck id=0x4c <mru 1492>
> <auth chap MD5> <magic 0x22bf9b51>]
> Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP ConfAck id=0x1 <mru 1492>
> <magic 0x539b3bc6>]

That looks like a perfectly reasonable LCP negotiation, with the peer
asking for CHAP authentication.

> Sep 13 15:16:16 Linux pppd[9425]: sent [LCP EchoReq id=0x0 magic=0x539b3bc6]
> Sep 13 15:16:16 Linux pppd[9425]: rcvd [CHAP Challenge id=0x1
> <24a06e14743d399c933b61865730ea63>, name = "BSLYO656"]
> Sep 13 15:16:16 Linux pppd[9425]: sent [CHAP Response id=0x1
> <502b6f4ee944310f014e0033e9b5438b>, name = "fti/hbufbty"]
> Sep 13 15:16:16 Linux pppd[9425]: rcvd [LCP EchoRep id=0x0 magic=0x22bf9b51]

They challenge and you respond.  No problem there.

> Sep 13 15:16:16 Linux pppd[9425]: rcvd [CHAP Failure id=0x1 "CHAP
> authentication failure, unit 509"]

The peer refuses your request, and gives a pretty bogus error message to
boot.  What the heck does "unit 509" mean?  It's certainly not any kind
of standard PPP error message.  If anybody knows, it would have to be
the technical support people at your provider.

> Sep 13 15:16:16 Linux pppd[9425]: CHAP authentication failed: CHAP
> authentication failure, unit 509
> Sep 13 15:16:16 Linux pppd[9425]: CHAP authentication failed
> Sep 13 15:16:16 Linux pppd[9425]: sent [LCP TermReq id=0x2 "Failed to
> authenticate ourselves to peer"]

Due to the authentication failure, we shut things down.  This is all normal.

> /var/run/pppoe-adsl-0.pid.pppoe -I eth1.101 -T 0 -U  -m 1412   , pid
> 9426

This part is sort of interesting.  Why "-U"?  I'm far from an expert in
Roaring Penguin's PPPoE client, but I think that would imply that you
have multiple simultaneous PPPoE sessions running.  Does your provider
even allow that?

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: CHAP Auth issue at CentOS-6.8

[James Carlson]

On 09/13/2016 09:25 AM, Sekar D wrote:
> Hi James,
> 
> Thanks for helping me.
> 
> Yes. It happens only when I bring up DSL line before 2 minutes. The
> same DSL lines are working fine without any issue at CentOS-5.11. I
> could see the issue only at CentOS-6.8. So I would like to know that I
> need to configure more to avoid these issues.

One other thing you might consider doing, now that we know that this is
a PPPoE connection: try running wireshark and capturing traffic from a
failed connection, a long delay, and then a successful one.

At a guess, PPPoE is the problem.  I suspect the logs will show PADT
messages coming from your system (which may or may not be malformed),
along with either no response from the peer, or retransmitted messages
from the peer that are being ignored by your system.

My current hypothesis is that PPPoE is keeping the previous connection
up too long, and the peer doesn't like seeing you log in more than once
at a time.

I don't believe anything is going wrong with PPP itself.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: CHAP Auth issue at CentOS-6.8

[Bill Unruh]

On Tue, 13 Sep 2016, James Carlson wrote:

> On 09/13/2016 08:33 AM, Sekar D wrote:
>> I did not see kind of issue on CentOS-5.11 . Please let me know if I
>> need to change any config parameters.
>
> It's a little hard to tell.  What are your current configuration parameters?
>
> Have you tried running pppd with debugging enabled?  It would help to
> have a trace of the connection in order to diagnose the failure mode.
> The starting point is the pppd "debug" option, but if you're controlling
> this connection with ifup/ifdown scripts, you'll have to look at your
> system configuration to find out what pppd options are in use for that
> link.  One possible answer, if all else fails, would be to run this
> while the link is in the process of establishing:
>
>  ps -fp `pgrep -d, pppd` | cat

-www argument to ps should do the same thing without cat.

>
> (Yes, the "cat" is important; it tricks ps into printing the whole line.)
>