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 !) :-]
o If we're using RADIUS and the RADIUS mtu is less than our
peers mru/mrru, reduce our mtu to this value for NetBSD too.
o Make struct throughput's sample period dynamic and tweak the ppp
version number to reflect the extra stuff being passed through
the local domain socket as a result (MP mode).
o Measure the current throughput based on the number of samples actually
taken rather than on the full sample period.
o Keep the throughput statisics persistent while being passed to
another ppp invocation through the local domain socket.
o When showing throughput statistics after the timer has stopped, use
the stopped time for overall calculations, not the current time.
Also show the stopped time and how long the current throughput has
been sampled for.
o Use time() consistently in throughput.c
o Tighten up the ``show bundle'' output.
o Introduce the ``set bandwidth'' command.
o Rewrite the ``set autoload'' command. It now takes three arguments
and works based on a rolling bundle throughput average compared against
the theoretical bundle bandwidth over a given period (read: it's now
functional).
negate the sense of rules.
o Remove the redundant (and undocumented) ``host'' and ``port''
words (README.changes updated).
o Don't permit (and ignore) garbage instead of the protocol.
Mostly submitted by: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>
callback option, and the server sends us CBCP_NONUM, proceed directly
to the network phase rather than insisting on our configured CBCP
option.
Mostly submitted by: kkphang <phang@dgate.po.my>
tables, copy them correctly back into our mbuf rather giving a
bzero'd count to memcpy() and ending up with a 0 byte fragment.
The old code resulted in a 0 byte write to the tun device which
tickled a bug that resulted in a panic :-(
expect-send-expect sequence, finish gracefully, don't core dump.
This bug has been there for over a year - I could never reproduce it !
Straw provided by: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
mode by padding out the ``struct device'' to the maximum
device size.
Bump the ppp version number to indicate the transfer format
change.
This should make MP over tty and udp devices functional again.
having different speed links in a bundle. This would manifest itself
by having the link occasionally hang, but revive when a new connection
is made....
Make ``show mp'' a bit prettier.
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().
being the same as the previous (still supported) ``host:port''
syntax for tcp socket devices.
A udp device uses synchronous ppp rather than async, and avoids
the double-retransmit overhead that comes with ppp over tcp (it's
usually a bad idea to transport IP over a reliable transport that
itself is using an unreliable transport). PPP over UDP provides
througput of ** 1.5Mb per second ** with all compression disabled,
maxing out a PPro/200 when running ppp twice, back-to-back.
This proves that PPPoE is plausable in userland....
This change adds a few more handler functions to struct device and
allows derivations of struct device (which may contain their own
data etc) to pass themselves through the unix domain socket for MP.
** At last **, struct physical has lost all the tty crud !
iov2physical() is now smart enough to restore the correct stack of
layers so that MP servers will work again.
The version number has bumped as our MP link transfer contents have
changed (they now may contain a `struct device').
Don't extract the protocol twice in MP mode (resulting in protocol
rejects for every MP packet). This was broken with my original
layering changes.
Add ``Physical'' and ``Sync'' log levels for logging the relevent
raw packets and add protocol-tracking LogDEBUG stuff in various
LayerPush & LayerPull functions.
Assign our physical device name for incoming tcp connections by
calling getpeername().
Assign our physical device name for incoming udp connections from
the address retrieved by the first recvfrom().
header in fsm_Input() we often end up with a NULL mbuf.
Deal with a possible NULL mbuf being passed into
mbuf_Prepend().
Adjust some spacing to make things more consistent.
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''.
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.
a bum name to return as 0.0.0.0... we don't want ``delete xxx''
to delete the default route when xxx doesn't resolve.
Support IP number specifications as the host when specifying
a tcp-style device (rather than *just* hostnames).
correctly by invoking the timer to get the value before
displaying the message.
Don't assume that a value of 0 is ``random'' in
``show datalink''.
Make the random value between 1 and DIAL_TIMEOUT rather
than between 0 and DIAL_TIMEOUT-1
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 :-(
is complete before checking carrier. If it's there,
the device supports carrier. If it's not it doesn't.
Add the ``set cd'' command for deciding how soon to check
for carrier, and for deciding if carrier is REQUIRED.
The default has changed: Pre 2.0 versions of ppp waited
for 1 second. Version 2 didn't wait, but this causes
problems with some (few?) modems that don't assert carrier
immediately on reporting CONNECT. The one second delay
is back now and can be removed with ``set cd 0''.
Bump the ppp version number in case this needs to be changed
again....
each time rather than making up a new one.
Increase the authname/authkey max sizes to 100 characters.
Allow ``authkey'' specifications beginning with ``!''.
When a challenge is received, the text following the
``!'' is executed as a program (expanding stuff in the same
way that ``sh'' and ``!bg'' do). The program is passed the
peer name, peer challenge and local ``authname'' on standard
input and is expected to output the name/key combination that
should be used to build the CHAP response.
This provides support for Secure ID cards (guess what I was
given at work recently!) using CHAP.
Examples will follow.
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
