This removes a bad latency problem during initial setup where we
end up waiting for too long before reading the connected message
and time the connection out.
Problem figured out by: Andre Albsmeier <andre@albsmeier.net>
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.
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>
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
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.
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 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>
just send PROTO_IP packets when we've got only one link up in multi-link
mode.
Problem noted by: Adrian Close <adrian@fernhilltec.com.au>
MFC after: 1 week
instead of u_char *.
The changes are cosmetic except:
RecvConfigAck() now displays the options that are being ACK'd
Huge (bogus) options sent from the peer won't cause an infinite loop
SendIdent and ReceiveIdent are displayed consistenlty with other FSM data
LCP AUTHPROTO options that aren't understood are NAK'd, not REJ'd
discipline to do the async escaping, but no other benefits are available yet.
Change ``ifdef HAVE_DES'' to ``ifndef NODES'' for consistency.
Make the Makefile a little more sane WRT RELEASE_CRUNCH.
deprecated in favor of the POSIX-defined lowercase variants.
o Change all occurrences of NTOHL() and associated marcros in the
source tree to use the lowercase function variants.
o Add missing license bits to sparc64's <machine/endian.h>.
Approved by: jake
o Clean up <machine/endian.h> files.
o Remove unused __uint16_swap_uint32() from i386's <machine/endian.h>.
o Remove prototypes for non-existent bswapXX() functions.
o Include <machine/endian.h> in <arpa/inet.h> to define the
POSIX-required ntohl() family of functions.
o Do similar things to expose the ntohl() family in libstand, <netinet/in.h>,
and <sys/param.h>.
o Prepend underscores to the ntohl() family to help deal with
complexities associated with having MD (asm and inline) versions, and
having to prevent exposure of these functions in other headers that
happen to make use of endian-specific defines.
o Create weak aliases to the canonical function name to help deal with
third-party software forgetting to include an appropriate header.
o Remove some now unneeded pollution from <sys/types.h>.
o Add missing <arpa/inet.h> includes in userland.
Tested on: alpha, i386
Reviewed by: bde, jake, tmm
using the part after the ``\'' if the original name is not found.
This allows M$ clients to use domain\user as their authname.
Reviewed by: Ian West <ian@niw.com.au>
to the routing socket.
The local address on a point-to-point interface is not actually a
gateway address - despite it appearing in the second column of
netstat -r's output. Providing a gateway to an RTM_CHANGE will
currently change the route's interface so that it's using the
specified gateway - not what we want.
Patiently explained to me by: ru
up in the same way that we expect them to be when we read them.
This is a no-op on i386 and probably on alphas, as we currently
only support AF_INET and AF_INET6.
of 0.0.0.0.
The OpenBSD PF_ROUTE/NET_RT_DUMP sysctl is sending back routes with
RTAX_NETMASK set, but the corresponding sockaddr being 4 zero bytes
(with an address family of zero). ppp was getting confused by this
and ending up interpreting it as a 0.0.0.0/32 routing table
destination and subsequently failing to do anything with the route.
Specifically, after this fix, ppp under OpenBSD can successfully
change and delete the default route again !
ncprange structure.
Don't write() the netmask for IPv6 sockaddrs to the routing socket if
the prefixlen is 128.
It seems that messages written to the routing socket with the scopeid
set for link local addresses are not understood. Instead, we have to
put the scopeid in the 5th and 6th bytes of the address (see
adjust_linklocal() in ncpaddr.c). I think this may be a bug in the
KAME implementation - it should really understand both forms.
Add an ``UPTIME'' variable to indicate the bundle uptime.
It's now possible to put something like this in ppp.linkdown
for a server setup:
MYADDR:
log Session closing: User USER, address HISADDR, up UPTIME
Fixed some memory leakage with commands that expand words.
Made some functions static.
Fixed a diagnostic bug (iface add .... SIOCDIFADDR)
not setting any timer. Instead, set a 1 millisecond timer.
This ensures that ppp will come out of it's select() call after
losing carrier in -ddial mode with a reconnect period of 0 and
going to ST_OPENING, rather than waiting indefinitely for some
other event to wake ppp up.
Bump the ppp version number to indicate the event.
MFC after: 3 days
allowed either because of the transport or configuration, send a
MRU NAK only once, then allow the negotiations to proceed.
rfc1661 says that 1500 should always be allowed and rfc2516 says
that 1492 is the maximum for PPPoE. This changes ppp so that it
only weakly suggests 1492, then goes with the default (leaving
the problem in the hands of the peer WRT how they set their MTU).
MFC after: 1 week
1) Allow the sending of more than one control message at a time
over a unix domain socket. This should cover the PR 29499.
2) This requires that unp_{ex,in}ternalize and unp_scan understand
mbufs with more than one control message at a time.
3) Internalize and externalize used to work on the mbuf in-place.
This made life quite complicated and the code for sizeof(int) <
sizeof(file *) could end up doing the wrong thing. The patch always
create a new mbuf/cluster now. This resulted in the change of the
prototype for the domain externalise function.
4) You can now send SCM_TIMESTAMP messages.
5) Always use CMSG_DATA(cm) to determine the start where the data
in unp_{ex,in}ternalize. It was using ((struct cmsghdr *)cm + 1)
in some places, which gives the wrong alignment on the alpha.
(NetBSD made this fix some time ago).
This results in an ABI change for discriptor passing and creds
passing on the alpha. (Probably on the IA64 and Spare ports too).
6) Fix userland programs to use CMSG_* macros too.
7) Be more careful about freeing mbufs containing (file *)s.
This is made possible by the prototype change of externalise.
PR: 29499
MFC after: 6 weeks
dictionaries are out of sync.
This avoids the complications that happen when our original reset
request gets lost in transit (quite likely in hind sight, given a
lossy link) when we end up ignoring the peer for the next (up to)
256 packets.
Submitted by: Nick Sayer <nsayer@quack.kfu.com>
when we ioctl(TUNSIFINFO) under OpenBSD)
o Don't bring the interface up immediately
o Don't complain about unrecognised interface flags in ``show iface''.
and mask to the routing socket, otherwise the update fails.
Warning provided by: markm
The code here was broken for FreeBSD when IPv6 support was added, but
was fixed for OpenBSD. OpenBSD expects the gateway and mask to be
supplied and fails the update otherwise.
and implement a far more subtle and correct fix.
The reason behind the infinite loop was that ppp was trying to make up
initial IPv6 numbers and wasn't giving up when it failed unexpectedly to
assign the addresses it just fabricated to it's interface (thinking that
the reason was because another interface was using the same address).
It now attempts this up to 100 times before just failing and trying to
muddle along (in reality, this should never happen more than a couple
of times unless our random number generator doesn't work).
Also, when IPv6 is not available, don't even try to assign the IPv6
interface address in the first place...
sizes on a route.
IMHO this shouldn't be necessary (the destination & mask/prefixlen
should be enough), but without it, the default route update under
OpenBSD will fail.
Thanks to: Russell T Hunt <alaric@MIT.EDU>
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>
options used to build ppp.
Currently, this is a no-op and only handles LOCALNAT and LOCALRAD cases.
This will be used for the upcoming ipv6 changes, and allows a shared
man page between OpenBSD and FreeBSD.
Avoid using parenthesis enclosure macros (.Pq and .Po/.Pc) with plain text.
Not only this slows down the mdoc(7) processing significantly, but it also
has an undesired (in this case) effect of disabling hyphenation within the
entire enclosed block.
When encryption (MPPE) is enabled, WindowsME and Windows98 both
fail because of the extra byte, suggesting that they autheticated
successfully in their log and then dropping the connection, telling
the user that the peer doesn't support compatible encryption
options.
MFC after: 1 week
byte of the packet to contain '\0'.
Windows 98 gets this wrong, dropping garbage into the last byte and
failing authentication.
Now, we notice this and whinge to our log file that we're compensating
for the corrupt data.
doing PPPoE and the default MRU is therefore too big.
When negotiating with win2k, we ask for MRU 1492 and the win2k box
NAKs us saying ``MRU 1492''. This doesn't make sense to me. When
we continue to request MRU 1492, the win2k box eventually REJs our
MRU. This fix allows negotiations to continue at that point,
bringing the link up and potentially allowing the win2k box to send
us frames that are too large. AFAICT this is better than failing
to bring the link up.... probably !
I have no idea how to do the equivalent of ``route get'' or
``ifconfig -a'' under win2k, so I can't tell what MTU it actually
ends up using.
I believe the bug is in win2k (it's certainly mis-negotiating).
I'll MFC given the release engineers permission as code freeze
begins on August 1.
PR: 29277
MFC after: 3 days
once. If they repeat the request (again without the IPADDR option)
ACK it.
I've had reports that some ppp implementations will not assign
themselves an IP number. This should negotiate with such things.
MFC after: 3 days
