| Age | Commit message (Collapse) | Author |
|---|
|
Fix issue #204
Proposed by https://github.com/achillelamb
|
|
handling.
When a link has a relatively high throughput, the 32-bit packet and byte counters could overflow multiple times between accounting runs.
To accommodate this limitation, directly use 64-bit interface statistics.
This also gets rid of the internal giga-word counters.
|
|
When receiving IPCP packet on channel handler, check unit handler to
avoid sending a LCP Protocol Reject because ppp unit has not been
created yet.
This patch allows accel-ppp to handle higher pressure (handle 300
connections per second).
Signed-off-by: Gabriel Jeanneau <gabriel.jeanneau@6wind.com>
|
|
* Fix errors found by valgrind
==12312== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
==12312== at 0x486CCF0: sendmsg (in /lib/libpthread-2.22.so)
==12312== by 0x12F57F: rtnl_talk (libnetlink.c:316)
==12312== by 0x132DA3: genl_resolve_mcg (genl.c:52)
==12312== by 0x484E1CB: init (vlan_mon.c:528)
==12312== by 0x484CDC0: vlan_mon_register_proto (vlan_mon.c:48)
==12312== by 0x510B763: load_vlan_mon (pppoe.c:1914)
==12312== by 0x510BFF2: load_config (pppoe.c:2064)
==12312== by 0x510C22A: pppoe_init (pppoe.c:2108)
==12312== by 0x483E9EB: triton_load_modules (triton.c:704)
==12312== by 0x1384B2: main (main.c:339)
==12312== Address 0xbedacdd8 is on thread 1's stack
==12312== in frame #2, created by genl_resolve_mcg (genl.c:23)
==12312== 15 bytes in 1 blocks are definitely lost in loss record 352 of 836
==12312== at 0x482A9A9: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12312== by 0x4B97524: strdup (in /lib/libc-2.22.so)
==12312== by 0x12C30C: init (telnet.c:769)
==12312== by 0x483E9EB: triton_load_modules (triton.c:704)
==12312== by 0x1384B2: main (main.c:339)
==12312==
==12312== 15 bytes in 1 blocks are definitely lost in loss record 353 of 836
==12312== at 0x482A9A9: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12312== by 0x4B97524: strdup (in /lib/libc-2.22.so)
==12312== by 0x12D60A: init (tcp.c:392)
==12312== by 0x483E9EB: triton_load_modules (triton.c:704)
==12312== by 0x1384B2: main (main.c:339)
* Fix another warnings by cppcheck
[accel-pppd/ctrl/ipoe/arp.c:256]: (error) Uninitialized variable: n
[accel-pppd/ctrl/pppoe/mac_filter.c:90]: (warning) %x in format string (no. 1) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:90]: (warning) %x in format string (no. 2) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:90]: (warning) %x in format string (no. 3) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:90]: (warning) %x in format string (no. 4) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:90]: (warning) %x in format string (no. 5) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:90]: (warning) %x in format string (no. 6) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:129]: (warning) %x in format string (no. 1) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:129]: (warning) %x in format string (no. 2) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:129]: (warning) %x in format string (no. 3) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:129]: (warning) %x in format string (no. 4) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:129]: (warning) %x in format string (no. 5) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:129]: (warning) %x in format string (no. 6) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:158]: (warning) %x in format string (no. 1) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:158]: (warning) %x in format string (no. 2) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:158]: (warning) %x in format string (no. 3) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:158]: (warning) %x in format string (no. 4) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:158]: (warning) %x in format string (no. 5) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/mac_filter.c:158]: (warning) %x in format string (no. 6) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ctrl/pppoe/pppoe.c:738]: (warning) Possible null pointer dereference
[accel-pppd/ipv6/dhcpv6.c:911]: (warning) %x in format string (no. 1) requires 'unsigned int *' but the argument type is 'int *'.
[accel-pppd/ipv6/dhcpv6.c:911]: (warning) %x in format string (no. 2) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ipv6/dhcpv6.c:911]: (warning) %x in format string (no. 3) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ipv6/dhcpv6.c:911]: (warning) %x in format string (no. 4) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/libnetlink/libnetlink.c:515]: (warning) Possible null pointer dereference
[accel-pppd/ppp/ipv6cp_opt_intfid.c:185]: (warning) %x in format string (no. 1) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ppp/ipv6cp_opt_intfid.c:298]: (warning) %x in format string (no. 1) requires 'unsigned int *' but the argument type is 'int *'.
[accel-pppd/ppp/ipv6cp_opt_intfid.c:298]: (warning) %x in format string (no. 2) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ppp/ipv6cp_opt_intfid.c:298]: (warning) %x in format string (no. 3) requires 'unsigned int *' but the argument type is 'signed int *'.
[accel-pppd/ppp/ipv6cp_opt_intfid.c:298]: (warning) %x in format string (no. 4) requires 'unsigned int *' but the argument type is 'signed int *'.
* Suppress compiler warnings
* Fix locking errors
/opt/pvs/accel-ppp/accel-pppd/extra/pppd_compat.c 279 warn V1020 The function exited without calling the 'sigchld_unlock' function. Check lines: 279, 249.
/opt/pvs/accel-ppp/accel-pppd/extra/pppd_compat.c 333 warn V1020 The function exited without calling the 'sigchld_unlock' function. Check lines: 333, 315.
/opt/pvs/accel-ppp/accel-pppd/extra/pppd_compat.c 422 warn V1020 The function exited without calling the 'sigchld_unlock' function. Check lines: 422, 372.
/opt/pvs/accel-ppp/accel-pppd/extra/pppd_compat.c 488 warn V1020 The function exited without calling the 'sigchld_unlock' function. Check lines: 488, 468.
/opt/pvs/accel-ppp/accel-pppd/triton/mempool.c 119 warn V1020 The function exited without calling the 'pthread_spin_unlock' function. Check lines: 119, 116.
* Fix array len errors
/opt/pvs/accel-ppp/accel-pppd/triton/conf_file.c 75 warn V557 Array underrun is possible. The value of 'len - 1' index could reach -1.
/opt/pvs/accel-ppp/accel-pppd/triton/conf_file.c 76 warn V557 Array underrun is possible. The value of '-- len' index could reach -1.
* Fix possible memory leaks
/opt/pvs/accel-ppp/accel-pppd/radius/radius.c 936 err V773 The function was exited without releasing the 'str' pointer. A memory leak is possible.
/opt/pvs/accel-ppp/accel-pppd/radius/serv.c 622 err V773 The function was exited without releasing the 'str' pointer. A memory leak is possible.
/opt/pvs/accel-ppp/accel-pppd/triton/conf_file.c 144 err V773 The function was exited without releasing the 'raw' pointer. A memory leak is possible.
* Fix unsafe code
/opt/pvs/accel-ppp/accel-pppd/cli/tcp.c 364 warn V1004 The 'host' pointer was used unsafely after it was verified against nullptr. Check lines: 338, 364.
/opt/pvs/accel-ppp/accel-pppd/cli/telnet.c 701 warn V1004 The 'host' pointer was used unsafely after it was verified against nullptr. Check lines: 675, 701.
/opt/pvs/accel-ppp/accel-pppd/extra/ippool.c 241 err V614 Potentially uninitialized pointer 'pos' used.
/opt/pvs/accel-ppp/accel-pppd/radius/dict.c 165 err V614 Uninitialized pointer 'parent_items' used.
* Remove duplicate code
/opt/pvs/accel-ppp/accel-pppd/radius/serv.c 202 warn V547 Expression 'ts.tv_sec < req->serv->fail_time' is always false.
* Fix treating signed bool variables as unsigned
* Add nullptr checking
/opt/pvs/accel-ppp/accel-pppd/ipv6/dhcpv6.c 886 err V595 The 'opt->val' pointer was utilized before it was verified against nullptr. Check lines: 886, 890.
/opt/pvs/accel-ppp/accel-pppd/ipv6/nd.c 479 err V595 The 'opt->val' pointer was utilized before it was verified against nullptr. Check lines: 479, 483.
/opt/pvs/accel-ppp/accel-pppd/radius/auth.c 152 err V595 The 'rpd->auth_ctx' pointer was utilized before it was verified against nullptr. Check lines: 152, 154.
/opt/pvs/accel-ppp/accel-pppd/triton/conf_file.c 114 err V595 The 'cur_sect' pointer was utilized before it was verified against nullptr. Check lines: 114, 117.
* Add logging of exit conditions
* Clarify calculation
[accel-pppd/ppp/ccp_mppe.c:281]: (style) Clarify calculation precedence for '&' and '?'.
[accel-pppd/ppp/ccp_mppe.c:282]: (style) Clarify calculation precedence for '&' and '?'.
[accel-pppd/ppp/ccp_mppe.c:283]: (style) Clarify calculation precedence for '&' and '?'.
[accel-pppd/ppp/ccp_mppe.c:284]: (style) Clarify calculation precedence for '&' and '?'.
[accel-pppd/ppp/ccp_mppe.c:285]: (style) Clarify calculation precedence for '&' and '?'.
[accel-pppd/ppp/ccp_mppe.c:286]: (style) Clarify calculation precedence for '&' and '?'.
[drivers/ipoe/ipoe.c:307]: (style) Clarify calculation precedence for '&' and '?'.
* Fix void calculations
[accel-pppd/ctrl/pppoe/disc.c:211]: (portability) 'pkt' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/ctrl/pptp/pptp.c:150]: (portability) 'buf' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/radius/acct.c:37]: (portability) 'req.pack.buf' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/radius/auth.c:35]: (portability) 'req.pack.buf' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/radius/auth.c:79]: (portability) 'req.pack.buf' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/radius/dm_coa.c:43]: (portability) 'pack.buf' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/radius/dm_coa.c:47]: (portability) 'pack.buf' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/radius/dm_coa.c:57]: (portability) 'pack.buf' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/radius/dm_coa.c:65]: (portability) 'req.buf' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/radius/dm_coa.c:97]: (portability) 'req.buf' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/radius/serv.c:364]: (portability) 'req.pack.buf' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/triton/mempool.c:115]: (portability) 'mmap_ptr' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/triton/mempool.c:122]: (portability) 'mmap_ptr' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/triton/mempool.c:276]: (portability) 'ptr' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
* Fix void part 2
[accel-pppd/ipv6/dhcpv6.c:844]: (portability) 'conf_dnssl' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/ipv6/nd.c:199]: (portability) '(void*)dnsslinfo' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
[accel-pppd/ipv6/nd.c:432]: (portability) 'conf_dnssl' is of type 'void *'. When using void pointers in calculations, the behaviour is undefined.
* Fix null pointer dereference
[accel-pppd/ctrl/ipoe/ipoe.c:2048]: (warning) Possible null pointer dereference: eth
[accel-pppd/ctrl/ipoe/ipoe.c:2049]: (warning) Possible null pointer dereference: iph
* Remove redundant check
/opt/pvs/accel-ppp/accel-pppd/ctrl/l2tp/packet.c 656 warn V547 Expression 'attr->length <= 16' is always false.
* PR fixes
* PR fixes 2
|
|
|
|
lcp auth doesn't take into account auth extra bytes
for lcp request buffer allocation for chap/mschap/mschapv2
protocols, so last byte corrupts memory with undefined behavior
incl. crash.
|
|
|
|
sstp-client sends SSTP_MSG_CALL_CONNECTED message too early,
before auth response, so HLAK can't be known yet and subsequent
HLAK-based validation fails.
workaround the issue by defer accepting SSTP_MSG_CALL_CONNECTED
after auth either has been succeeded or bypassed.
|
|
If you move an interface into a namespace where there is alreay an
interface with the same index, the moved interface will get a new index
assigned to it. We need to update our data structure accordingly.
Signed-off-by: Simon Chopin <s.chopin@alphalink.fr>
|
|
let check-ip setting from [ppp]/[ipoe] sections has prio over [common]
for compatibility with older configs.
|
|
|
|
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>
|
|
This callback isn't used anymore. Let's remove it from all
authentication backends.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
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>
|
|
If wins_opt->addr is NULL, then we have no address to propose (none
defined in accel-ppp.conf and none provided by RADIUS). Currently,
in that case, accel-ppp accepts and acks the address found in the peer's
configuration request. But the peer would normally use the undefined IP
address, so if we ack it, we explicitely tell the peer that 0.0.0.0 is
the primary/secondary NBNS server.
If the peer already knows a NBNS server IP address, it doesn't have to
negociate it with accel-ppp. It can just use it directly, after it
retrieved its own IP address. Therefore there is no need for accel-ppp
to blindly accept addresses proposed by the peer.
This patch rejects *-NBNS-Address if accel-ppp has no NBNS server to
propose, making it explicit to the peer that its request can't be
satisfied.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
When handling the EV_WINS event, IPCP assumes that the ->wins1 and
->wins2 fields of the event structure are properly set. But that may
not be the case.
If only one of the MS-Primary-NBNS-Server or MS-Secondary-NBNS-Server
RADIUS attributes was received, then only ->wins1 or ->wins2 is set,
while the other keeps a non initialised value. This uninitialised value
is then copied by ev_wins() and proposed to the peer when negociating
the Primary-NBNS-Address or Secondary-NBNS-Address IPCP options.
That leaks four bytes of the stack to the network and prevents using
the values found in the [wins] section of accel-ppp.conf as fallback.
Fix this by initialising the whole event structure in rad_proc_attrs().
Then, in ev_wins(), we can check if ->wins1 or ->wins2 is properly set
before copying them. That allows to propery fallback to accel-ppp.conf
values when one of the values was not provided by RADIUS.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
If dns_opt->addr is NULL, then we have no address to propose (none
defined in accel-ppp.conf and none provided by RADIUS). Currently,
in that case, accel-ppp accepts and acks the address found in the peer's
configuration request. But the peer would normally use the undefined IP
address, so if we ack it, we explicitely tell the peer that 0.0.0.0 is
the primary/secondary DNS server.
If the peer already knows a DNS server IP address, it doesn't have to
negociate it with accel-ppp. It can just use it directly, after it
retrieved its own IP address. Therefore there is no need for accel-ppp
to blindly accept addresses proposed by the peer.
This patch rejects *-DNS-Address if accel-ppp has no DNS server to
propose, making it explicit to the peer that its request can't be
satisfied.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
When handling the EV_DNS event, IPCP assumes that the ->dns1 and ->dns2
fields of the event structure are properly set. But that may not be the
case.
If only one of the MS-Primary-DNS-Server or MS-Secondary-DNS-Server
RADIUS attributes was received, then only ->dns1 or ->dns2 is set,
while the other keeps a non initialised value. This uninitialised value
is then copied by ev_dns() and proposed to the peer when negociating
the Primary-DNS-Address or Secondary-DNS-Address IPCP options.
That leaks four bytes of the stack to the network and prevents using
the values found in the [dns] section of accel-ppp.conf as fallback.
Fix this by initialising the whole event structure in rad_proc_attrs().
Then, in ev_dns(), we can check if ->dns1 or ->dns2 is properly set
before copying them. That allows to propery fallback to accel-ppp.conf
values when one of the values was not provided by RADIUS.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
We need to include <stdint.h> to define 'uint16_t' and "triton.h" for
'struct triton_timer_t'.
Also, let's include "ppp.h" so that we don't need a forward declaration
for 'struct ppp_t'.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
We need to include <stdint.h> to define 'uint8_t' and "ppp.h" for
'struct ppp_t'.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
We need to include "ppp.h" to define 'struct ppp_layer_data_t' and
'struct ppp_handler_t'.
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>
|
|
|
|
|
|
|
|
Now, if lcp-echo-timeout is specified this is considered as idle timeout.
So if link is idling (no any packet was received) in specified interval accel-ppp starts to send LCP Echo-Request with lcp-echo-interval period.
If peer responds to echo request new idle period is being started.
If peer does not responds to lcp-echo-failure attempts accel-ppp terminates session with Acct-Terminate-Cause Lost-Carrier.
If lcp-echo-timeout is not specified or equals zero accel-ppp works in old behaviour (unconditionally sends LCP Echo-Request with lcp-echo-interval period).
This patch intended to prevent unexpected sessions termination due to lcp echo loses.
|
|
|
|
|
|
Fixed problem while connecting with clients in which mru not
negotiating lcp option is set
|
|
|
|
Signed-off-by: François Cachereul <f.cachereul@alphalink.fr>
|
|
This reverts commit 07ca3acb40df7668cfd0c6abbdcefc21d944d993.
Signed-off-by: François Cachereul <f.cachereul@alphalink.fr>
|
|
|
|
|
|
If set to 1 then allocate unit (interface) before authorization, so Nas-Port and Nas-Port-Id would be defined in Access-Request phase
|
|
This files aren't used (and aren't even compiled) anymore.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
The kernel flag used for setting PFC is SC_COMP_PROT (SC_COMP_AC is for
Address-and-Control-Field-Compression).
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
|
|
|
|
|
|
|
|
This reverts commit fc098b3062badfd802f91241533069cad4886b6f.
|
|
|
|
|
|
|
|
destroing"
|
|
|
|
|
|
|
|
|
