Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE
cycle.

Prune svn:mergeinfo from the new branch, and rename it to RC1.

Update __FreeBSD_version.

Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and
the dvd1.iso packages population.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Cleanup unnecessary semicolons from utilities we all love.

Fix multiple instances of the following clang 3.6.0 warning in ppp:

usr.sbin/ppp/command.c:2054:74: error: address of array 'arg->bundle->radius.cfg.file'
will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
if (arg->bundle->radius.alive.interval && !arg->bundle->radius.cfg.file) {
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~

In all cases, the file field of struct radius is a char array, but the
intent was to check whether the string is empty, so add an indirection
to achieve that. Use a similar approach for the sockname field of
struct server.

remove duplicate semicolons where possible.

Approved by: cperciva
MFC after: 1 week

Add a new option for ppp.conf: rad_port_id. It allows to
change the way of what ppp submits to the RADIUS server
as NAS-Port-Id. Possible options are: the PID of the process
owning the corresponding interface, tun(4) interface number,
interface index (as it would get returned by if_nametoindex(3)),
or it's possible to keep the default behavior. Check the ppp(8)
manual page for details.

PR: bin/112764
Submitted by: novel (myself)
Reviewed by: flz
Approved by: flz
MFC after: 1 month

Check the return value from rad_cvt_ipv6prefix().

PR: bin/89808
MFC after: 1 week

Add a radius_Flush() function that waits for the response (or timeout) to
any pending RADIUS transaction. Use this before sending RAD_STOP RADIUS
messages so that we definitely ``stop'' the session.

It was discovered that sometimes when the link timed out, we got lucky
enough to have an un-ACK'd RADIUS accounting transaction in progress,
resulting in the RAD_STOP message failing to send.

Original report found on: A russion news group
Text translated by: glebius
Tested by: Alexey Popov llp at iteranet dot com
MFC after: 7 days

Send NAS-IP-Address as well as NAS-Identifier
Add ``disable NAS-IP-Address'' and ``disable NAS-Identifier'' options to
support pre-rfc2865 RADIUS servers.
This pushes our enable/disable items over the 32 bit limit, so reoganise
things to allow a bunch more options.
Go to version 3.4.1 so that any compatability problems can be identified.

Add a bunch of malloc() return checks

PR: 71592
Submitted by: Dan Lukes <dan@obluda.cz> with further changes

Make ppp WARNS=5 clean

Avoid casts as lvalues.

Support a ``set rad_alive N'' command to enable periodic RADIUS accounting
information being sent to the RADIUS server.

Logging of RADIUS accounting information moves to a ``set log [+-]radius''
level, along with the RADIUS alive info, and the version number is bumped
to 3.2 to reflect this.

Mostly submitted by: alx@sm.ukrtel.net (back in January)
MFC after: 3 weeks

Remove a stray backslash

If HISMACADDR is set in the environment (by pppoed), pass the value to
the RADIUS server as RAD_CALLING_STATION_ID.

PR: 44310
Submitted by: Gleb Smirnoff <glebius@cell.sick.ru>
MFC after: 2 weeks

Send RADIUS gigaword data when OctetsIn or OctetsOut go over UINT32_MAX.

PR: bin/61294
Submitted by: Boris Kovalenko
MFC after: 3 weeks

name union.

IPV6PREFIX is set when Framed-IPv6-Prefix is defined, You may
want to pass the value to upper layer protocol such as DHCPv6
for prefix delegation.

MFC after: 1 week

Do RADIUS accounting on IPV6CP.

MFC after: 1 week

Install routes specified by Framed-IPv6-Route. Since the format
of Framed-IPv6-Route is user defined, it follows Framed-IP-route.

MFC after: 1 week

Include the correct file (stdarg.h) and use va_list rather than _BSD_VA_LIST_

Suggested by: mike

Back out the previous revision

Objected to by: Andre Oppermann <oppermann@pipeline.ch>

After Andre's objection, I've re-examined rfc 2759 and noted that it
says that the domain name shouldn't be used when generating the
NT-Response field. So it looks like the bug is in freeradius rather
than in ppp.

If we've given a domain name prefix as the authentication name, strip
it off before passing it on to the RADIUS server for authentication.

Complain about (and fix) misformatted RADIUS attributes rather than silently
fixing them.

Add a hack to handle RADIUS responses from peers that forget that
there's an ``Ident'' field in the MS-CHAP2-Response and
MS-CHAP-Error attributes.

The RADIATOR server seems to be guilty of this.

Compensate for dodgy Win98/WinME MSCHAPv2 responses later in the code
path... after we've talked to any RADIUS servers involved, so that we
haven't touched the data before it gets to the server.

Make it clearer in the code that this compensation is done by setting
a flag to a value of zero, a flag which rfc2759 says *MUST* be zero.

While we're here, don't bother passing the peer challenge into
radius_Authenticate(). It's already part of the key we're passing in
(this becomes obvious now that I've structured that data...).

This ``fix'' doesn't help to authenticate Win98/WinME users in my test
environment as ports/net/freeradius seems to ignore the flag
completely anyway, but it may help with other RADIUS servers.

Remove whitespace at the end of lines.

Remove a forgotten diagnostic

Don't forget to process the Ident field on the front of
RAD_MICROSOFT_MS_CHAP_ERROR and RAD_MICROSOFT_MS_CHAP2_SUCCESS
messages, and remove the hack in chap.c to ignore that ident field
on the client side.

This anomoly was hacked around during development, and I forgot to
go back and fix it properly.

Spotted by: Sergey Korolew <ds@rt.balakovo.ru>

Understand the following Microsoft Vendor Specific RADIUS attributes:

RAD_MICROSOFT_MS_MPPE_ENCRYPTION_POLICY
RAD_MICROSOFT_MS_MPPE_ENCRYPTION_TYPES
RAD_MICROSOFT_MS_MPPE_RECV_KEY
RAD_MICROSOFT_MS_MPPE_SEND_KEY

These attributes may be supplied by a RADIUS server when MSCHAPv2 is
used to authenticate.

It *should* now be possible to build ppp with -DNODES and still support
CHAP/MSCHAP/MSCHAPv2/MPPE via a RADIUS server, but the code isn't yet
smart enough to do that (building with -DNODES just looses these
facilities).

Sponsored by: Monzoon

Cast pid_t to long for printf()ing

Obtained from: OpenBSD

Don't send a RAD_NAS_IP_ADDRESS attribute as RAD_NAS_IDENTIFIER is
sufficient.

In fact, using both breaks the radiator RADIUS daemon when used with
a db as it maps both attributes to the same field value and then
fails the insert.

I decided to remove RAD_NAS_IP_ADDRESS on the basis that rfc2138 says:

An Access-Request MUST contain a User-Name attribute. It SHOULD
contain either a NAS-IP-Address attribute or NAS-Identifier
attribute (or both, although that is not recommended). It MUST

despite the fact that this not recommended bit was removed from the
updated rfc.

Handle MS-CHAPv2 authentication correctly via the RADIUS server (if it's
configured).
Handle internal failures in radius_Authenticate() correctly.
Bump the ppp version number.

This doesn't yet work with MPPE. More will follow.

Sponsored by: Mozoon

o Clean up some #includes
o Bump version number to 3.0.4
o When talking to a RADIUS server, provide a NAS-Port-Type.

When the NAS-Port-Type is Ethernet, provide a NAS-Port value equal
to the SESSIONID from the environment in direct mode or the
NGM_PPPOE_SESSIONID message in other modes. If no SESSIONID is found,
default to the interface index in client mode or zero in server mode.

When the NAS-Port-Type is ISDN, set the NAS-Port to the minor number
of the physical device (ie, the N in /dev/i4brbchN).

This makes it easier for the RADIUS server to identify the client
WRT accounting data etc.

Prompted by: lsz8425 <lsz8425@mail.cd.hn.cn>

Add support for MS-CHAP authentication via a RADIUS server.
Add support for Reply-Message and MS-CHAP-Error.

Sponsored by: Monzoon

Understand the Session-Timeout RADIUS attribute
Store the Filter-Id attribute (we don't do anything with it yet)

Submitted mostly by: andrew pavlov <and@kremenchug.net>

o Add ipv6 support, abstracting most NCP addresses into opaque
structures (well, they're treated as opaque).

It's now possible to manage IPv6 interface addresses and routing
table entries and to filter IPV6 traffic whether encapsulated or
not.

IPV6CP support is crude for now, and hasn't been tested against
any other implementations.

RADIUS and IPv6 are independent of eachother for now.

ppp.linkup/ppp.linkdown aren't currently used by IPV6CP

o Understand all protocols(5) in filter rules rather than only a select
few.

o Allow a mask specification for the ``delete'' command. It's now
possible to specifically delete one of two conflicting routes.

o When creating and deleting proxy arp entries, do it for all IPv4
interface addresses rather than doing it just for the ``current''
peer address.

o When iface-alias isn't in effect, don't blow away manually (via ``iface
add'') added interface addresses.

o When listening on a tcp server (diagnostic) socket, bind so that a
tcp46 socket is created -- allowing both IPv4 and IPv6 connections.

o When displaying ICMP traffic, don't display the icmp type twice.
When display traffic, display at least some information about unrecognised
traffic.

o Bump version

Inspired after filtering work by: Makoto MATSUSHITA <matusita@jp.FreeBSD.org>

Don't assume challenges and responses don't contain embedded '\0's.

Mschapv2 response generation may produce embedded NULs... causing
us to send a bogus response to the radius server and end up
failing the client's valid response.

Problem pointed out by: Eugene Vigovskiy <vigov@com2com.ru>

MAXHOSTNAME includes space for a NUL

MAXPATHLEN -> PATH_MAX
Don't assume MAXHOSTNAMELEN includes the NUL
Correct a diagnostic
Use "localhost" in our prompt instead of ""

Don't send an authentication failure response if we fail sending
a radius accounting packet.

Allow ``set server closed'' to close the diagnostic socket.
Allow ``set server open'' to re-open the diagnostic socket.
Handle SIGUSR1 by re-opening the diagnostic socket
When receiving SIGUSR2 (and in ``set server none''), don't forget the
socket details so that ``set server open'' and SIGUSR1 open it again.

Don't create the diagnostic socket as uid 0 ! It's far to dangerous.

Use rad_acct_open() instead of rad_auth_open().

Suggested by: Victor Ivanov <v0rbiz@icon.bg>

Support radius accounting, and add a packet count to throughput
statistics as a side effect.

Submitted by: Marcin Cieslak <saper@system.pl>

with some tweaks to RAD_ACCT_SESSION_ID and
RAD_ACCT_MULTI_SESSION_ID generation by me.

Correct some typos introduced in the descriptor -> fdescriptor change.

Introduce LOCALNAT and LOCALRAD defines so that the sources can stay
exactly the same in FreeBSD & OpenBSD despite libalias and libradius
being local to the ppp sources under OpenBSD.

The interface list that comes back from the PF_ROUTE/NET_RT_IFLIST mib
is aligned. Teach this to ``show route''.

Clean up some of the sockaddr parsing routines.

To avoid namespace polution in NetBSD:

``struct descriptor'' -> ``struct fdescriptor''

Notice and warn about unterminated quoted strings in commands.
The entire command is ignored if the syntax is invalid...

Back out the bogus #ifdef __NetBSD__ #include <signal.h> lines.
The original report was due to a mis-installation of the NetBS
header files :-/

Submitted by: Kazuyoshi Kato <kazk@yyy.or.jp>

NetBSD has moved ``extern int errno;'' to signal.h :-/

Submitted by: Kazuyoshi Kato <kazk@yyy.or.jp>

When sending radius authentication requests:

Supply RAD_NAS_IDENTIFIER if we have a `hostname` and
RAD_IP_ADDRESS if that hostname resolves.

Supply RAD_NAS_PORT using the ttyslot() of the tty that
we're authenticating on if it's a tty device.

Partially submitted by: Andriy I Pilipenko <bamby@marka.net.ua>
PR: 12225

$Id$ -> $FreeBSD$

o Redesign the layering mechanism and make the aliasing code part of
the layering.

We now ``stack'' layers as soon as we open the device (when we figure
out what we're dealing with). A static set of `dispatch' routines are
also declared for dealing with incoming packets after they've been
`pulled' up through the stacked layers.

Physical devices are now assigned handlers based on the device type
when they're opened. For the moment there are three device types;
ttys, execs and tcps.

o Increment version number to 2.2
o Make an entry in [uw]tmp for non-tty -direct invocations (after
pap/chap authentication).
o Make throughput counters quad_t's
o Account for the absolute number of mbuf malloc()s and free()s in
``show mem''.
o ``show modem'' becomes ``show physical''.

int -> size_t

Correct some ntohl/htonl bogons in the netmask handling.
This was pretty harmless as netmasks on a POINTOPOINT
interface are pretty much ignored, but it looked funny.

Mention the configured netmask in ``show ipcp''.

Describe in more detail what a proxy arp entry is.

Decouple pap & chap output routines from the corresponding
input routines and take advantage of the new init/continue
interface in libradius. This allows a timely response on
other links in an MP setup while RADIUS requests are in
progress as well as the ability to handle other data from
the peer in parallel. It should also make the future addition
of PAM support trivial.

While I'm in there, validate pap & chap header IDs if
``idcheck'' is enabled (the default) for other FSM packet
types.

NOTE: This involved integrating the generation of chap
challenges and the validation of chap responses
(and commenting what's going on in those routines).
I currently have no way of testing ppps ability
to respond to M$Chap CHALLENGEs correctly, so if
someone could do the honours, it'd be much
appreciated (it *looks* ok!).

Sponsored by: Internet Business Solutions Ltd., Switzerland

o Send a CHAP challenge of 16 random digits when RADIUS is
configured. This isn't strictly necessary according to the
rfc, but it's suggested there....
o Don't forget to include our authname when sending a
CHAP challenge when RADIUS is configured.
o Don't supply the ``16'' representing the chap answer
length to radius_Authenticate() - libradius does this
for us.
o When we successfully authenticate via radius_Authenticate(),
continue with datalink_AuthOk() as expected.

Sponsored by: Internet Business Solutions Ltd., Switzerland

Initial RADIUS support (using libradius). See the man page for
details. Compiling with -DNORADIUS (the default for `release')
removes support.

TODO: The functionality in libradius::rad_send_request() needs
to be supplied as a set of routines so that ppp doesn't
have to wait indefinitely for the radius server(s). Instead,
we need to get a descriptor back, select() on the descriptor,
and ask libradius to service it when necessary.
For now, ppp blocks SIGALRM while in rad_send_request(), so
it misses PAP/CHAP retries & timeouts if they occur.

Only PAP is functional. When CHAP is attempted, libradius
complains that no User-Password has been specified... rfc2138
says that it *mustn't* be used for CHAP :-(

Sponsored by: Internet Business Solutions Ltd., Switzerland