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
perform a key change, *and* our sequence numbers have wrapped,
ensure that the number of key changes is calculated correctly.
The previous code counted down from a negative number to zero,
re-encrypting the current key on each iteration - this took some
time and strangely enough got the answer wrong !!!
Fix a(nother) spelling mistake while I'm there.
envoked -- don't use them (as return values from open()), then
(say) close(STDIN_FILENO) when daemonising.
This is done by grabbing 3 descriptors to /dev/null at startup and
releasing them after we've daemonised.
MFC after: 1 week
This is necessary because MPPE will combine the protocol id with the
payload received on the tun interface, encrypt it, then prepend its
own protocol id, effectively increasing the payload by two bytes.
encryption compatibility with Windows 2000. Stateful encryption
uses less CPU but is bad on lossy transports.
The ``set mppe'' command has been expanded. If it's used with any
arguments, ppp will insist on encryption, closing LCP if the other
end refuses.
Unfortunately, Microsoft have abused the CCP reset request so that
receiving a reset request does not result in a reset ack when using
MPPE...
Sponsored by: Monzoon Networks AG and FreeBSD Services Limited
allow MRU/MTU negotiations to exceed 1492.
Add an optional ``max'' specifier to ``set m[rt]u'', ie.
set mtu max 1480
Bump the ppp version number.
Sponsored by: Monzoon Networks AG and FreeBSD Services Limited
TLU event handler).
This used to be done as a side effect of SIOCAIFADDR'ing the interface,
but now that duplicate SIOCAIFADDRs are optimised out, we can't depend
on that behaviour.
of a/x -> b and then negotiate a/x -> c by simply expecting SIOCAIFADDR
to do the change.
This was broken by the last commit that optimised out the deletion and
re-addition of the same a/x -> b combination, and forgot to compare
the old/new destination addresses.
Conveniently enough, this problem didn't effect setups where the
default route goes via the ppp link, and most other setups don't
care what the the destination address is actually set to. It broke
test environments where ppp connects to the local machine rather
badly though....
We now unwrap IP/IP and apply filter rules to both the outer
layer (with ``set filter blah x.x.x.x y.y.y.y ipip'') and to
the payload (reinterpreted by the filter rules).
``set log tcp/ip'' will now show both the outer wrapper and
the (reinterpreted) payload contents.
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>
aliases with the same netmask and destination, don't remove it and then
re-add exactly the same thing.
This means that static (non-sticky) routes that use the interface address
(or destination address) as a destination will not suddenly evaporate when
IPCP comes up (not unless the negotiated IPs have changed anyway).
to run PPP over Radiocontact T-Link Radio Modems which run best when something
is transmitted at least every 1.5 seconds.
Tested by: Jennifer Clark <jen@telepresence.strath.ac.uk>
Approved by: Brian
This works only because of bugs in current implementation: the
first .It after ``.Bd -unfilled'' re-enables filling mode and
does not restore (disable) it back afterwards.
is called prior to sending a CCP configure request for a
given protocol. The default is to send the request, but
this is overridden for MPPE which checks to see if the lcp
negotiations agreed CHAP81, and if not fails.
Use the same function to decide if we should reject peer
requests for MPPE.
This should get rid of those boring messages about not being
able to initialise MPPE when we don't negotiate CHAP81.
CLOSE_NORMAL meanings. CLOSE_NORMAL doesn't change the currently
required state, the others do. This should stop ppp from entering
DATALINK_READY when LCP shutdown doesn't end up happening cleanly.
Bump our version number to reflect this change.
Only show the mask in ``show bundle'' when it's been specified.
Complain about unexpected arguments after ``set server {none,open,closed}''
Log re-open failures as warnings rather than phase messages.
Fix some markup for the ``set server'' man page description.
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.
MPPE session keys correctly.
I'm a bit dubious about this code. It seems that the session keys
are initialised differently based on whether you're the client or
the server. One side is the server if it issues the first challenge,
but of course you can issue a challenge from both sides.... at the
same time. Sounds like another wonderful M$ assumption...
Ppp can now talk to itself correctly using encryption.
Problem solved by: Ustimenko Semen <semen@iclub.nsu.ru>
Hair torn out by: me
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.
isn't open and the links MRU >= our MRRU, send outbound traffic as
PROTO_IP rather than PROTO_MP. This shaves some bytes off the front
of each packet 'till the second link is brought up.
Idea obtained from: Cisco
of the two when calculating the MP throughput average for the ``set
autoload'' implementation.
This makes more sense as all links I know of are full-duplex. This
also means that people may need to adjust their autoload settings
as 100% bandwidth is now the theoretical maximum rather than 200%
(but of course, halfing the current settings is probably not the
correct answer either!).
This involves a ppp version bump as we need to pass an extra
throughput array through the MP local domain socket.
cumulative total of all active links rather than basing it on the
total of PROTO_MP traffic.
This fixes a problem whereby Cisco routers send PROTO_IP packets only
when there's only one link (hmm, what a good idea!).
effect the idle timer in different ways.
Submitted by: Stefan Esser <se@freebsd.org>
With adjustments by me to document the option in the man page and to
give the same semantics for outgoing traffic as incoming.
I made the style more consistent in ip.c - this should really have
been done as a separate commit.
o If the new ``filter-decapsulation'' is enabled, delve into UDP packets
that contain 0xff 0x03 as the first two bytes, and if we recognise it
as PROTO_IP, decapsulate it for the purpose of filter checking.
If we recognise it as PROTO_<anything else> mention this for logging
purposes only.
This change is aimed at people running PPPoUDP where the UDP traffic is
being sent over another PPP link. It's desireable to have the top level
link connected all the time, but to have the bottom level link capable
of decapsulating the traffic and comparing the payload against the filters,
thus allowing ``set filter dial ...'' to work in tunnelled environments.
The caveat here is that the top ppp cannot employ any compression layers
without making the data unreadable for the bottom ppp. ``disable deflate
pred1 vj'' and ``deny deflate pred1 vj'' is suggested.
