Age | Commit message (Collapse) | Author |
|
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>
|
|
|
|
The 'username' variable can be freed at the beginning of the function.
We have to use ppp->ses.username instead.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
|
|
|
|
|
|
This avaid allocating a ppp unit when authentication failed
Split establish_ppp in two functions estabish_ppp and
connect_ppp_channel. The fist one connect the channel on an instance of
/dev/ppp, allocate channel resources and start first ppp layer.
The second functions create ppp unit and connect the channel to this
unit. It is called after authentication.
destablish_ppp is also split in two function for symmetry and
ppp_terminate is adapted to handle the case when the unit is not
created.
Signed-off-by: François Cachereul <f.cachereul@alphalink.fr>
|
|
|
|
|
|
Wait for previous session completely terminated before continuing authorization new session.
|
|
|
|
|
|
Conflicts:
accel-pppd/ppp/ppp_auth.c
|
|
|
|
If enabled accel-pppd will not destroy interface immediately after corresponding session is terminated, instead interface will be brought down and placed to cache for later use for new sessions.
It should reduce kernel interface creation/deletion rate lack and increase responsibility of daemon
|
|
comes up (should fix unexpected ospf routes deletion)
|
|
|
|
|
|
|
|
single-session=replace (make ospf happy)
|
|
ppp: make IPCP and IPV6CP optional depends on configuration
|
|
|
|
|
|
|
|
|
|
authorized
|
|
|
|
|
|
|