LCP options doesn't work if a network delay is created at pppoe server
srikanth436 opened this issue · 7 comments
hi,
I have a ppp client in a residential router running pppd 2.4.9
Steps:
- In /etc/ppp/options append below options
lcp-restart 1
lcp-max-configure 2 - Create a network delay equal to lcp-restart duration which is 1s.
tc qdisc change dev veth0 root netem delay 1.1s - observer ppp doesn't come up and more number of configure requests sent than defined in options.
ppd logs snip:
rcvd [LCP ConfReq id=0x3c <mru 1492> <magic 0x14675282>]
sent [LCP ConfReq id=0x3c <mru 1492> <magic 0xe15b3ce>]
sent [LCP ConfAck id=0x3c <mru 1492> <magic 0x14675282>]
rcvd [LCP ConfAck id=0x3b <mru 1492> <magic 0x23ce1a1>]
sent [LCP ConfReq id=0x3c <mru 1492> <magic 0xe15b3ce>]
rcvd [LCP ConfAck id=0x3c <mru 1492> <magic 0xe15b3ce>]
sent [LCP EchoReq id=0x0 magic=0xe15b3ce]
rcvd [LCP EchoReq id=0x0 magic=0x14675282]
sent [LCP EchoRep id=0x0 magic=0xe15b3ce]
rcvd [CHAP Challenge id=0x49 , name = "51410a273420"]
No CHAP secret found for authenticating us to 51410a273420
sent [CHAP Response id=0x49 <87e1739bb0fcf5b1928bef87d494ec46>, name = "sample@sample.com"]
rcvd [LCP ConfReq id=0x3d <mru 1492> <magic 0x5658243b>]
sent [LCP ConfReq id=0x3d <mru 1492> <magic 0x5c7c89a7>]
sent [LCP ConfAck id=0x3d <mru 1492> <magic 0x5658243b>]
rcvd [LCP ConfAck id=0x3c <mru 1492> <magic 0xe15b3ce>]
sent [LCP ConfReq id=0x3d <mru 1492> <magic 0x5c7c89a7>]
rcvd [LCP ConfAck id=0x3d <mru 1492> <magic 0x5c7c89a7>]
sent [LCP EchoReq id=0x0 magic=0x5c7c89a7]
rcvd [LCP EchoReq id=0x0 magic=0x5658243b]
sent [LCP EchoRep id=0x0 magic=0x5c7c89a7]
rcvd [CHAP Challenge id=0x5a , name = "51410a273420"]
No CHAP secret found for authenticating us to 51410a273420
sent [CHAP Response id=0x5a , name = "sample@sample.com"]
rcvd [LCP ConfReq id=0x3e <mru 1492> <magic 0x7a8a861b>]
sent [LCP ConfReq id=0x3e <mru 1492> <magic 0x704cdefe>]
sent [LCP ConfAck id=0x3e <mru 1492> <magic 0x7a8a861b>]
rcvd [LCP ConfAck id=0x3d <mru 1492> <magic 0x5c7c89a7>]
sent [LCP ConfReq id=0x3e <mru 1492> <magic 0x704cdefe>]
rcvd [LCP ConfAck id=0x3e <mru 1492> <magic 0x704cdefe>]
sent [LCP EchoReq id=0x0 magic=0x704cdefe]
rcvd [LCP EchoReq id=0x0 magic=0x7a8a861b]
sent [LCP EchoRep id=0x0 magic=0x704cdefe]
rcvd [CHAP Challenge id=0x5e , name = "51410a273420"]
No CHAP secret found for authenticating us to 51410a273420
sent [CHAP Response id=0x5e , name = "sample@sample.com"]
rcvd [LCP ConfReq id=0x3f <mru 1492> <magic 0x44e1d92a>]
sent [LCP ConfReq id=0x3f <mru 1492> <magic 0xe7b0277f>]
sent [LCP ConfAck id=0x3f <mru 1492> <magic 0x44e1d92a>]
@paulusmack, @enaess, @jkroonza: What do you think?
@Neustradamus I'm afraid I'm not familiar with that code.
What I suspect is that because LCP gets restarted in a shorter timeframe than the delay it's effectively impossible for LCP to complete. I suspect that when LCP gets restarted, so does the counter for max-configure.
Not really code I'm familiar enough with I'm afraid.
What do you expect to happen?
It looks to me that LCP does come up successfully, despite the artificial delay, and the real problem is that we cannot authenticate ourselves to the peer.
In any case, it is the peer that keeps on restarting LCP by sending us a new LCP ConfReq. I don't know what you are expecting with this setup (you seem to have gone out of your way to make it fail to work), but if you expect the negotiations to terminate with an error, you'll have to configure the peer to stop sending LCP ConfReqs.
I'm not seeing anything that needs to be fixed in pppd here.
Hi @paulusmack thanks for your reply and analysis.
I was expecting the pppd to terminate after sending configure requests equal to lcp-max-configure which is 2.
Correct my understanding if I am wrong.
Is it that lcp-max-configure is the retransmission counter rather than actual count of configure requests sent?
Is there any option to configure maximum number of configure requests which can be sent and then pppd to terminate after that? My goal of the test is that pppd terminate if link cant be established rather than going into loop which is in my setup.
@paulusmack: Have you seen the latest @srikanth436 comment?
The lcp-max-configure value is the number of times that pppd will send an individual configure-request and wait for the corresponding configure-ack. In the trace above, the conf-req with id=0x3c is sent twice and then we see the conf-ack with id=0x3c, and similarly for the other id values. So it's working as intended.
Closing per previous comment, thanks.