summaryrefslogtreecommitdiff
path: root/crypto
diff options
context:
space:
mode:
authorGuillaume Nault <g.nault@alphalink.fr>2018-11-19 17:44:36 +0100
committerDmitry Kozlov <xeb@mail.ru>2018-11-27 09:56:54 +0300
commit75a880700071b9d8a4a36f7c0beae5220e8c4853 (patch)
tree7d3176ad26729bbb0857793a5198eb4e8ebdc0e5 /crypto
parent9ccaedcacc5ab257b18bdac4e35d4ed96a3dad08 (diff)
downloadaccel-ppp-xebd-75a880700071b9d8a4a36f7c0beae5220e8c4853.tar.gz
accel-ppp-xebd-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 'crypto')
0 files changed, 0 insertions, 0 deletions