Revision tags: release/14.0.0 |
|
#
b3e76948 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
#
4d846d26 |
| 10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
show more ...
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0 |
|
#
1de7b4b8 |
| 27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
various: general adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error
various: general adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
No functional change intended.
show more ...
|
Revision tags: release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0, release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0, release/8.3.0_cvs, release/8.3.0, release/9.0.0, release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0, release/8.1.0_cvs, release/8.1.0, release/7.3.0_cvs, release/7.3.0, release/8.0.0_cvs, release/8.0.0, release/7.2.0_cvs, release/7.2.0, release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0, release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0, release/6.2.0_cvs, release/6.2.0, release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0, release/4.11.0_cvs, release/4.11.0, release/5.3.0_cvs, release/5.3.0 |
|
#
057f1760 |
| 05-Sep-2004 |
Brian Somers <brian@FreeBSD.org> |
Make ppp WARNS=5 clean
|
Revision tags: release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1, release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0, release/5.1.0_cvs, release/5.1.0, release/4.8.0_cvs, release/4.8.0, release/5.0.0_cvs, release/5.0.0, release/4.7.0_cvs, release/4.6.2_cvs, release/4.6.2, release/4.6.1, release/4.6.0_cvs |
|
#
250be50b |
| 17-Jun-2002 |
Brian Somers <brian@FreeBSD.org> |
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.
Mak
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.
show more ...
|
#
a16061b2 |
| 16-May-2002 |
Brian Somers <brian@FreeBSD.org> |
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
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
show more ...
|
#
de59e178 |
| 14-May-2002 |
Brian Somers <brian@FreeBSD.org> |
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 SES
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>
show more ...
|
#
ff8e577b |
| 10-May-2002 |
Brian Somers <brian@FreeBSD.org> |
Add support for MS-CHAP authentication via a RADIUS server. Add support for Reply-Message and MS-CHAP-Error.
Sponsored by: Monzoon
|
Revision tags: release/4.5.0_cvs, release/4.4.0_cvs |
|
#
30949fd4 |
| 14-Aug-2001 |
Brian Somers <brian@FreeBSD.org> |
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
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>
show more ...
|
#
65309e5c |
| 13-Jun-2001 |
Brian Somers <brian@FreeBSD.org> |
Convert IIJ copyrights to BSD copyrights.
Approved by: Toshiharu OHNO <tohno@sirius.ocn.ne.jp>
|
Revision tags: release/4.3.0_cvs, release/4.3.0 |
|
#
50ca6ec3 |
| 02-Apr-2001 |
Brian Somers <brian@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 fail
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>
show more ...
|
Revision tags: release/4.2.0, release/4.1.1_cvs, release/4.1.0 |
|
#
1038894e |
| 19-Jul-2000 |
Brian Somers <brian@FreeBSD.org> |
Support link identification from rfc1570 Two new commands are available; ``ident'' and ``sendident''.
|
Revision tags: release/3.5.0_cvs, release/4.0.0_cvs |
|
#
182c898a |
| 27-Dec-1999 |
Brian Somers <brian@FreeBSD.org> |
Add a bunch of `const's and fix a typo.
Submitted by: Rich Neswold <rneswold@MCS.Net>
|
#
26af0ae9 |
| 20-Dec-1999 |
Brian Somers <brian@FreeBSD.org> |
Cosmetic: Make struct mbuf more like kernel mbufs.
|
Revision tags: release/3.4.0_cvs |
|
#
b5c3c9ae |
| 26-Nov-1999 |
Brian Somers <brian@FreeBSD.org> |
Allow extended pap success messages by believing in the PAP headers length field rather than the one byte message length field embedded in the packet. This steps slightly outside of the protocol bou
Allow extended pap success messages by believing in the PAP headers length field rather than the one byte message length field embedded in the packet. This steps slightly outside of the protocol boundaries, but should not cause any problems.
Limitation noted by: Simon Winwood <simon@winwood.org>
show more ...
|
Revision tags: release/3.3.0_cvs |
|
#
442f8495 |
| 04-Sep-1999 |
Brian Somers <brian@FreeBSD.org> |
o Split the two IPCP queues into three - one for FSM data (LCP/CCP/IPCP), one for urgent IP traffic and one for everything else. o Add the ``set urgent'' command for adjusting the list of urgen
o Split the two IPCP queues into three - one for FSM data (LCP/CCP/IPCP), one for urgent IP traffic and one for everything else. o Add the ``set urgent'' command for adjusting the list of urgent port numbers. The default urgent ports are 21, 22, 23, 513, 514, 543 and 544 (Ports 80 and 81 have been removed from the default priority list). o Increase the buffered packet threshold from 20 to 30. o Report the number of packets in the IP output queue and the list of urgent ports under ``show ipcp''.
show more ...
|
#
97d92980 |
| 28-Aug-1999 |
Peter Wemm <peter@FreeBSD.org> |
$Id$ -> $FreeBSD$
|
#
eb6e5e05 |
| 06-Aug-1999 |
Brian Somers <brian@FreeBSD.org> |
Add ISDN support via isdnd & i4b. This requires version 0.81.1 of the i4b code - namely support of the I4B_VR_REQ ioctl via the i4brbchX device.
Ppp controls the phone number, but idle timers and S
Add ISDN support via isdnd & i4b. This requires version 0.81.1 of the i4b code - namely support of the I4B_VR_REQ ioctl via the i4brbchX device.
Ppp controls the phone number, but idle timers and SYNC/RAW decisions are still made by isdnd (in isdnd.rc).
This involves a new datalink state machine phase. The ``wait for carrier'' phase happens after dialing but before logging in. The whole dial state should really be abstracted so that each device type can deal with it in its own way (thinking about PPPoE) - but that'll have to wait.
The ``set cd'' symantics remain the same for tty devices, but we now delay until we either get CD or timeout waiting (at which time we drop the link if we require CD).
For i4b devices we always insist on carrier.
Thanks to hm@ for his help, and especially for pointing out that I *don't* need to re-implement isdnd (that was a huge waste of time !) :-]
show more ...
|
#
411675ba |
| 02-Jun-1999 |
Brian Somers <brian@FreeBSD.org> |
o Alter the mbuf type as it's processed by different layers. o Show more information about missing MP fragments in ``show mp''. o Do away with mbuf_Log(). It was showing mbuf stats twice on receip
o Alter the mbuf type as it's processed by different layers. o Show more information about missing MP fragments in ``show mp''. o Do away with mbuf_Log(). It was showing mbuf stats twice on receipt of LCP/CCP/IPCP packets.... ???!!? o Pre-allocate a bit extra when creating LQR packets to avoid having to allocate another mbuf in mbuf_Prepend().
show more ...
|
Revision tags: release/3.2.0 |
|
#
5d9e6103 |
| 08-May-1999 |
Brian Somers <brian@FreeBSD.org> |
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
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''.
show more ...
|
#
29b873f3 |
| 01-Apr-1999 |
Brian Somers <brian@FreeBSD.org> |
Drop PAP & CHAP packets if we're not in NETWORK or AUTHENTICATE phase.
|
#
eb2d27cf |
| 31-Mar-1999 |
Brian Somers <brian@FreeBSD.org> |
Avoid a few warnings on the alpha
|
#
b7ff18ad |
| 20-Feb-1999 |
Brian Somers <brian@FreeBSD.org> |
Handle empty PAP & CHAP packets (containing only an FSM header). Some CHAP implementations send no welcome message with their SUCCESS/FAILURE packets. This was being mis-identified as a truncated pa
Handle empty PAP & CHAP packets (containing only an FSM header). Some CHAP implementations send no welcome message with their SUCCESS/FAILURE packets. This was being mis-identified as a truncated packet by the new authentication code :-(
show more ...
|
Revision tags: release/3.1.0 |
|
#
f0cdd9c0 |
| 06-Feb-1999 |
Brian Somers <brian@FreeBSD.org> |
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 se
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
show more ...
|
#
aceaed92 |
| 02-Feb-1999 |
Brian Somers <brian@FreeBSD.org> |
Reimplement the previous fix (no response to PAP requests) at the authentication layer rather than at the PAP layer so that it also applies to CHAP (no response to CHAP challenges).
|