| Age | Commit message (Collapse) | Author |
|---|
|
via an external program - otherwise we get no
throughput stats and connection count increase.
|
|
socket.
|
|
result of a pipe(). This matters under OpenBSD.
|
|
two bi-directional descriptors under OpenBSD.
|
|
in OpenBSD as well as FreeBSD (I still don't know why).
Add a debug diagnostic when creating a child process as
a link.
|
|
|
|
for adjusting the timeout.
|
|
redial timeouts.
|
|
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.
|
|
|
|
|
|
and ssl_expr_scan.c which are autogenerated.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
o new ioctls for getting/setting cache size (default == 100)
o changed SIOCBRDGRT -> SIOCBRDGRTS
o changed SIOCBRDGIDX -> SIOCBRDGIFS
|
|
mostly harmless otherwise).
|
|
|
|
``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>
|
|
|
|
|
|
Pending a check and a rewriting, as the documentation is misleading.
It seems to imply it looks thru installed packages first, whereas
code tells pkg_info looks thru package files first.
|
|
now tries to complete the package name with a version number while
scanning the installed list of packages.
Not foolproof. The pkg_* tools are atrocious anyway.
|
|
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.
|
|
nuke references to the original name of the program
add bugs section
|
|
|
|
|
|
|
|
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
|
|
mode (when there is more than one auto link) if there is
no data queued to go out.
Reviewed by: Tom Torrance <tom@tomqnx.com>
|
|
|
|
|
|
|
|
|
