Accept SIGHUP as a "re-open logfile" signal. As ppp
doesn't set it's serial line to it's controlling terminal,
we can use HUP :)
This is a candidate for 2.2. The log.[ch] changes won't
conflict, but the main.c changes will. We just want to change the
kill(...,SIGHUP) to a SIGTERM and change the signal(SIGHUP,Hangup)
to a pending_signal(SIGHUP,LogReOpen).
These changes should fix the signal "problems" in ppp.
The signal changes should really be put into 2.2 too !
The following patches should do it. There were some other
changes made by Andrey recently that havn't been brought
into 2.2, it may be worth doing them now.
we need now.
Don't assume that file descriptor can't be 0 (many places)
Protect FD_* macros from being used with negative descriptors
Shorten MS EXT show help to fit 80 cols
dangerous! Signal handlers themself must be fixed to not call malloc,
but no pended handlers, it will be correct fix. In finite case each signal
handler can set some variable which will be analized later, but calling
handler functions manually is too dangerous (f.e. signals not blocked while
the handler or handlers switch executed in this case). Of course this
code can be fixed instead of removing, but it not worth fixing in any case.
Should go into 2.2
In addition sig.c code shows following dangerous fragments (there can be more,
but I stop after two):
This fragment
if (fn == SIG_DFL || fn == SIG_IGN) {
handler[sig-1] = (sig_type)0;
<------------- here
signal(sig,fn);
} else {
cause NULL pointer reference when signal comes
"here", but more worse fragment is below:
void handle_signals() {
int sig;
if (caused)
for (sig=0; sig<__MAXSIG; sig++, caused>>=1)
if (caused&1)
(*handler[sig])(sig+1);
}
caused is bitmask which set corresponding bit on each signal coming.
And now imagine, what happens when some signal comes (bit sets) while loop
is executed (see caused>>=1 !!!)
In this light carrier drop situation was (as gdb shows)
1. SIGSEGV in handle_signals because some junk called as *handler reference.
2. Since SIGSEGV was pended too (== never happens),
it can cause various range of disasters.
1) When carrier dropped, old variant often forget to detect it cause
unkillable loop forever (because SIGTERM pended too, but it will be
separate commit)
2) Time intervals accuracy reasons
Should go into 2.2
Remove #include's from sig.h and get dependant modules to include them
themselves. Make inclusion of if_var.h depend on __FreeBSD_version so
that the -current version of ppp can be used with 2.1.*
2.2 Candidate ?
All signal() calls have been changed to pending_signal() calls.
pending_signal() is defined in the new sig.c file. It remembers
the handler and traps the signal with a function that will remember
the signal.
main.c now calls handle_signals() to actually call the required
handlers (if the above handler was called).
If this doesn't close PR2662 (was PR2347), I'll cry.
Joerg, I think this should go into 2.2, but I havn't done anything
about it because I'm bound to botch it with the new sig.[ch] files.
I've just "cvs add"'d sig.[ch] so far.... can you update to 2.2 and
tell me what you did ? Thanks.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
This has the effect of making every link a "passthrough" which means the
TCP or UDP port won't be freed after link deletion -- so there could be
eventual port exhaustion if the program were allowed to operate long
enough.
Submitted by: Charles Mott <cmott@srv.net>
to be used to expand things beyond the size of the buffer passed in. Also
do a general cleanup of sprintf -> snprintf as well as strcpy and strncat
safety. Also expand some buffers to allow for the largest possible data
that might be used.
This is a 2.2 candidate. However, it needs to be vetted on -current
since little testing has been done on this due to my lack of PPP on
this machine.
Reviewed by: Jordan Hubbard, Peter Wemm, Guido van Rooij
connecting to a host immediately in the foreground.
I would like to be able to run ppp from a script so that my script can be
sure that it is connected to the 'net before it continues running:
# Dial up the internet.
ppp -background myprovider || exit 1
do-some-net-command
# Hang up the modem.
kill -HUP `cat /var/run/ppp.tun0.pid`
Another problem is that the current ppp calls its process id file
`/var/run/PPP.server', which may conflict if you have more than one IP
tunnel interface available.
Closes PR#1469
Submitted by: Gord Matzigkeit <gord@enci.ucalgary.ca>
new 'aliased' packets. Note, if the original packet has a bogus cksum,
we will *NOT* re-compute the cksum, therefore the new packet will also
be wrong (but passed on).
Found by: MartinRenters@awfulhak.demon.co.uk
Reviewed by: Brian Somers <brian@awfulhak.demon.co.uk>
Submitted by: Charles Mott <cmott@srv.net>
(otherwise ppp's behavior remains unchanged) and documented by myself,
Steve Sims, Nate Williams, Martin Renters and god-only-knows who else. :-)
Submitted by: nate
Obtained from: Charles Mott <cmott@srv.net>
do it themselves. (Some of these programs actually depended on this
beyond compiling the definition of struct ifinfo!) Also fix up some
other #include messes while we're at it.
to keep the link up, so it re-dials whenever it detects the link go
down. This is useful for 'dedicated' links who use PPP.
It's been used for over a year w/out problems at different sites.
required. a core is not dumped at first connecting time and
dumped at second or third time. (patch I)
2. A routine for "show route" refers out of allocated space.
Values pointed by "lp" should be read as CHAR, I think.
there is also no free() for disallocation. (patch II)
Here is also a patch for an improvement: In current imprementation,
even if PPP connection is disconnected by time out, prompt of
interactive mode does not change from "PPP>" to "ppp>" to
indicate the disconnection on a terminal.
So I modified the code to do that. (patch III)
Submitted-By: NAKAMURA Motonori <motonori@econ.kyoto-u.ac.jp>
on their own without even attempting to get concensus in the IETF, but
there are also lots of Win95/NT boxes out there.
CLoses PR#1494
Submitted-By: Peter Childs <pjchilds@imforei.apana.org.au>
