diff options
author | Guillaume Nault <g.nault@alphalink.fr> | 2018-11-19 17:44:36 +0100 |
---|---|---|
committer | Dmitry Kozlov <xeb@mail.ru> | 2018-11-27 09:56:54 +0300 |
commit | 75a880700071b9d8a4a36f7c0beae5220e8c4853 (patch) | |
tree | 7d3176ad26729bbb0857793a5198eb4e8ebdc0e5 /accel-pppd/iprange.c | |
parent | 9ccaedcacc5ab257b18bdac4e35d4ed96a3dad08 (diff) | |
download | accel-ppp-75a880700071b9d8a4a36f7c0beae5220e8c4853.tar.gz accel-ppp-75a880700071b9d8a4a36f7c0beae5220e8c4853.zip |
lcp: reject Authentication-Protocol option in Configure-Request packets
If we receive a Configure-Request packet, that means the peer wants us
to authenticate to him. However, none of our authentication backends
(PAP, CHAP and MSCHAP v1/v2) supports authenticating ourself to the
peer. Therefore, the LCP negotiation completes, but we hang in the
authentication phase because accel-ppp never sends any credential.
We should reject the Authentication-Protocol option found in
Configure-Request packets sent by the peer. This way, the peer knows
that we won't authenticate to him. Then it's up to him to keep
connecting without authentication from our side or to drop the
connection.
This doesn't change the way we request the peer to authenticate to us.
That part of the negotiation is handled by Configure-Request packets
that are sent by us (not those sent by the peer).
In practice some PPP clients wouldn't connect with the previous
behaviour, but are perfectly happy with their Authentication-Protocol
option being rejected. They just resend their Configure-Request without
requesting authentication from our side.
Also, since the peer_auth field of struct auth_option_t is never set
anymore, we can remove the conditionals in auth_recv_conf_nak() and
auth_recv_conf_rej().
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Diffstat (limited to 'accel-pppd/iprange.c')
0 files changed, 0 insertions, 0 deletions