device per argument rather than the old way of concatenating
everything then splitting the result at commas and whitespace.
Old syntax of ``set device /dev/cuaa0, /dev/cuaa1''
may no longer contain the comma, but syntax such as
``set device "!ssh host ppp -direct label"'' is now
possible.
receiver and one for the sender. This allows two simultaneous
chap conversations - something that I *thought* I was already
doing on a daily basis myself until the existence of the
problem was
Beaten into me by: sos
with our own if there are differing bits (last two revisions
of lcp.c). This change broke at least one negotiation
session.
Instead, we just use an OR of the two accmap values when
we're doing the ASYNC framing.
with more than one read(). When we detect one, don't
forget to pass it to async_Input() and drop our
terminal back into command mode.
Don't output an extraneous \r if we're passed \r\n
to prompt_vprintf in raw mode.
when recalculating the ip checksum. cp is not guaranteed to
be aligned. It now doesn't matter that cp isn't aligned as
the caller does another mbuf_Alloc() regardless.
need to process a signal (usually a SIGALRM). Check to see
if we need to process a signal both before *and* after calling
select() as older (pre-2.0) versions of ppp used to.
This handles the possibility that ppp may block at some
point (maybe due to an open() of a misconfigured device).
Previously, we'd potentially lock up in select().
The `necessary' marker reduces the increased signal checking
overhead so that at full speed with no compression transferring
an 83Mb file via a ``!ppp -direct'' device, we get a 1%
throughput gain.
ACCMAP being REQuested by the peer, also increment our FSM
id so that we don't end up sending out a new REQ with the
same ID and different data (the changed ACCMAP).
when we've simply missed a packet.
When our Predictor1 CRC is wrong (implying we've dropped
a packet), don't send a ResetReq(). Instead, send another
CCP ConfigReq(). *shrug* My tests show this as being far
worse than the ResetReq as we may have further Nak/Rejs etc
and we're basically resetting both our incoming and outgoing
compression dictionaries, but rfc1978 says the ConfigReq is
correct, so we'd better go along...
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.
peers by ORing the two together and NAKing or REQing
the result rather than allowing seperate local/peer
values.
If the peer REJs our ACCMAP and our ACCMAP isn't 0,
warn about it and ignore the rejection.
``closing''.
Pointed out by: archie
Don't do a TLF when we get a ``Catastrphic Protocol Reject'' event
in state ``closed'' or ``stopped''.
Pointed out but not suggested by: archie
This makes no difference in the current implementation as
LcpLayerFinish() does nothing but log the event, but I disagree
in principle because it unbalances the TLF/TLS calls which
(IMHO) doesn't fit with the intentions of the RFC.
Maybe the RFC author had a reason for this. It can only happen
in two circumstances:
- if LCP has already been negotiated then stopped or closed and we
receive a protocol reject, then we must already have done a TLF.
Why do one again and stay in the same state ?
- if LCP hasn't yet been started and we receive an unsolicted
protocol reject, why should we TLF when we haven't done a TLS ?
we're already in network phase and our autoload values
are set with no minimum threshold (the default).
Tell the autoload timer that it's ``coming up'' *before*
calling AutoLoadTimeout() directly... not after. This
prevents the very first demand-dial connection from
immediately disconnecting when there are other auto links.
Problem diagnosis: Ted Mittelstaedt <tedm@toybox.placo.com>
that are made in each of the FSMs (LCP, CCP & IPCP) and the
number of REQs/Challenges for PAP/CHAP by accepting more arguments
in the ``set {c,ip,l}cpretry'' and ``set {ch,p}apretry'' commands.
Change the non-convergence thresholds to 3 times the number of configured
REQ tries (rather than the previous fixed ``10''). We now notice
repeated NAKs and REJs rather than just REQs.
Don't suggest that CHAP 0x05 isn't supported when it's not configured.
Fix some bugs that expose themselves with smaller numbers of retries:
o Handle instantaneous disconnects (set device /dev/null) correctly
by stopping all fsm timers in fsm2initial.
o Don't forget to uu_unlock() devices that are files but are not
ttys (set device /dev/zero).
Fix a *HORRENDOUS* bug in RFC1661 (already fixed for an Open event in state
``Closed''):
According to the state transition table, a RCR+ or RCR- received in
the ``Stopped'' state are supposed to InitRestartCounter, SendConfigReq
and SendConfig{Ack,Nak}. However, in ``Stopped'', we haven't yet
done a TLS (or the last thing we did is a TLF). We must therefore
do the TLS at this point !
This was never noticed before because LCP and CCP used not use
LayerStart() for anything interesting, and IPCP tends to go into
Stopped then get a Down because of an LCP RTR rather than getting a
RCR again.
