| Age | Commit message (Collapse) | Author |
|---|
|
references into a STANDARDS section;
|
|
OK markus@ henning@ phessler@ jmc@
|
|
pointed out by Frank Brodbeck <fab at guug.de>, actual change with & ok jmc
|
|
stays;
ok henning
|
|
noticed by zepard at gmail
OK henning@
|
|
pointed out by sthen@
|
|
This basically adds the "rtable %d" keyword to "listen on", "server",
"servers" keywords, to specify which routing table to use.
OK henning@ claudio@ sthen@
manpage reviewed by jmc@
|
|
|
|
the forground until we receive a reply or hit the 15 second timeout.
with theo, evolved out of sth completely different
|
|
|
|
switched a while back.
ok miod, kettenis
|
|
pointed out by Running Razor <runningrazor at web dot de>
|
|
deserves to get credited for this, but I have no idea where that came from
|
|
ok henning@
|
|
problem reported with the obvious fix for bgpd by Sebastian Benoit
<benoit-lists at fb12.de>, also PR 6432
applied to all the others by yours truly. ok theo
isn't it amazing how far this parser (and more) spread?
|
|
by the dns engine.
ok henning@
|
|
Minor bump for libutil.
Previous versions of this diff and man page looked at by various people.
"you should just commit" deraadt
|
|
ibuf, buf_read to ibuf_read, READ_BUF_SIZE to IBUF_READ_SIZE.
ok henning gilles claudio jacekm deraadt
|
|
ok eric
|
|
by returning ENXIO instead of ENOENT, to essentially indicate hotplug
sensor that has gone away. Accessing beyond the end of the sensordev
list still returns ENOENT, so that you can see there are no further devices.
ok kettenis oga
|
|
If this happens the imsg may no longer be usable as there may be queued
messages, but this is a) already the case with the code now, and b)
would be the case if recvmsg() fails anyway, so we can document that -1
from imsg_read() invalidates the struct imsgbuf.
discussed with and ok eric
|
|
function, which is additionally exported for use by others.
It will be needed by smtpd's SSL module when the SMTP client code
is changed to replace libevent's evbuffers with our msgbuf_* API.
ok gilles@ henning@ guenther@ eric@
|
|
freeing the msgbuf.
While here also remove an unnecessary while loop.
ok eric pyr
|
|
bytes that were filled, not the whole buffer.
ok pyr@ gilles@
|
|
|
|
|
|
|
|
spotted the hard way by theo on armish, pinned to this changed by me.
no cookie for ckuethe for not testing on machines with bad clocks.
|
|
Make the imsg protocol network-safe.
it might be network safe, but half the imsg based daemons on my firewalls
dont run anymore.
|
|
Currently the receiver fetches an imsg via imsg_get() and if he expects
an fd, he then calls imsg_get_fd() to fetch the next fd queued on the
imsgbuf from which the imsg came.
This changes hides the fd queueing mechanism to the API user. When closing
an imsg with an fd, the message is flagged so that the receiving end knows
it must dequeue the fd in imsg_get() and return it with the imsg structure.
This way there is no (less) possible screw up from imsg_get_fd() not being
called directly after imsg_get() by the user. The retreived imsg is
self-contained.
ok pyr@, "I like that" henning@
|
|
ok pyr@
|
|
add a flag field, use u_int32_t for pid_t and extend type to 32 bits
for padding.
ok pyr@
|
|
time corrections. Once the clock is synced again, start computing a fresh
frequency correction.
ok henning
|
|
corrections more often. Due to physical effects crystal oscillators aren't
really stable beyond 1000s or so - at least not the kind found in pc's.
ok henning
|
|
behavior change.
ok eric@
|
|
offset. This avoids future frequency adjustments based on measurements of a
clock that was being adjusted. End result: more stable clock and better
frequency convergence.
Also, fix a mis-ordered structure member while I'm here.
ok henning
|
|
i remember we already had the confusion and bgpd doesn't have the endpwent
|
|
reply instead of doing it in ntpd itself by getting the time we read
from the socket. based on a diff from mickey hacked in shape by me,
lots of testing and review from ckuethe and sthen, theo and claudio like it
too
|
|
junk. from thorsten glaser.
|
|
"fine by me. it's maybe not ideal, but it's better" jmc@
|
|
the first query we will never do the settime because
SENSOR_QUERY_INTERVAL (30s) is greater than SETTIME_TIMEOUT (15s). so
during the settime period only, be more aggressive and use
SETTIME_TIMEOUT/3 for the query interval.
ok henning@
|
|
input & ok theo
|
|
allocations fails.
looks right deraadt, krw
ok henning
|
|
Don't log kiss code for now.
|
|
|
|
|
|
|
|
|
|
ok henning@, 'I think I agree' otto@
|
|
|
