| Age | Commit message (Collapse) | Author |
|---|
|
|
|
openssl's thread locking/calbacks is noop since 1.1.0, internal
locking is used automagically.
|
|
In DSL setups, it's common to have an intermediate equipment,
potentially managed by a different operator, between the two PPP
endpoints. In such setups, the client establishes a PPPoE or L2TP
session with the intermediate equipment. They perform LCP negotiation
and eventually get to the authentication phase. Based on the client's
username, the intermediate equipment then establishes another L2TP
session with the final PPP endpoint (accel-ppp). At this point, the
intermediate equipment forwards any PPP frame received on one side to
the other side, so that it becomes transparent to PPP frames.
Then accel-ppp starts an LCP negotiation again, performs
authentication, negotiates NCPs and finally forwards IP packets to and
from the client.
+--------+ +--------------+ +-----------+
| Client |------------------------| Intermediate |--------------------| accel-ppp |
| | | equipment | | |
+--------+ +--------------+ +-----------+
<-- First hop PPPoE --> <-- Second hop -->
or L2TP session L2TP session
<----------------- End to end PPP session ----------------->
Therefore, from the client point of view, two LCP negotiations occur.
LCP re-negotiation is explicitly handled by RFC 1661 and even
non-conforming PPP clients generally cope with this situation well
enough (as long as LCP re-negotiation occurs before the authentication
phase completes).
However, accel-ppp always starts its LCP negotiation with an identifier
set to 1. If the previous LCP negotiation also used identifier 1, then
some clients (at least MikroTik products) consider that the
Configure-Request sent by accel-ppp is part of the previous LCP
negotiation and refuse to return to link establishment phase as
mandated by section 3.4 of RFC 1661.
We can easily work around this problem by using random identifiers.
This maximises the chances that accel-ppp picks a different identifier
than the intermediate equipment and avoids falling into the MikroTik
problem. In case of bad luck and the chosen identifier is the same as
the one used for the original LCP negotiation, then PPP establishment
fails and the client tries to reconnect until the intermediate
equipment and accel-ppp pick up different numbers. So the connection
eventually succeeds.
The identifier is set in ppp_fsm_init(), so it also affects NCPs.
Therefore, IPCP and IPv6CP now also use random identifiers.
We need to define 'id' and 'recv_id' in struct ppp_fsm_t as uint8_t,
otherwise they could be chosen larger than 255 and comparing their
value with the 8-bits values found in received packets would fail (this
was generally not a problem when id was initially set to 1 and wouldn't
grow much).
Also, let's seed random() at startup, so that we don't end up with the
same sequences across restarts. This also benefits other users of
random(), like LCP magic numbers.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
The openssl/ssl.h header file is already included at the beginning of
this file.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
It's often useful to let a program crash on SIGSEGV and let an external
daemon, like monit or systemd, restart it when needed. This allows to
generate core dumps and do post-mortem analysis based on the collected
traces.
This patch add the new '--no-sigsegv' option to disable accel-ppp's
SIGSEGV handler and use the system's core(5) mechanism instead.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
SIGSEGV, SIGILL, SIGFPE and SIGBUS aren't blocked, but they're added to
the set of signals passed to sigwait(). This is confusing (should these
signals be consumed by sigwait() or by their respective signal
handler?) and is undefined according to the POSIX man page
(http://man7.org/linux/man-pages/man3/sigwait.3p.html).
In practice, sigwait() was only triggered when manually sending the
signals to accel-pppd ("pkill -FPE accel-pppd"). On normal
circumstances though, these signals are triggered by invalid
operations run by the program. In these cases the signal handler was
run and sigwait() wasn't woken up.
So let's remove SIGSEGV, SIGILL, SIGFPE and SIGBUS from the set passed
to sigwait(). This simplifies the code, avoids undefined behaviour and
doesn't change accel-ppp behaviour for real-world use cases.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
|
|
|
|
|
|
* l2tp: Fix allocation checking when adding octets AVP
* cli, tcp: Fix non-NULL terminated string reception
* Fix va_end() missing calls
* chap-secrets: implemented encryption
* auth_pap: make messages like other auth modules
* cli: check xmit_buf is not null at enter to write function
* pppoe: implemented regular expression support
* chap-secrets: implemented encryption
* ippool: fixed initialization order
* optional shaper compiling
* ppp: dns/wins code cleanup
|
|
|
|
cli: introduced 'restart' command to restrat daemon
|
|
|
|
|
|
determine limit of maximum number of opened files
|
|
|
