| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
Basing it on krb4's CLOCK_SKEW value doesn't make any sense. We pick 900
because it is just over 128 + 256 + 512, the longest group of three timeouts in
the retransmit schedule used by the zephyrd. This allows us to miss two packets
in a row and still be fine.
|
| |
|
|
|
|
| |
If we see a duplicated packet, that means the server missed (or raced with) our
CLIENTACK, which means we should update the timestamp on the entry to reset the
aging.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively reverts 170736db76139ed9fff9dbf70a55d4ba4f25d9bd. That commit
didn't work anyway. It fails to update packet_len, so we computed the
Z_InputQ's header_len wrong and fail to truncate the garbage anyway. Plus
packets like that likely come from a broken cross-realm zephyrd without
f276622ace757977fec43633e43577350e0cf6fe, so we want to drop them.
That patch has yet to be in a released libzephyr, so if there are other sources
of notices with trailing garbage, no one was relying on them working anyway.
On the contrary, we were relying on them NOT working in that it masks broken
cross-realm zephyrds.
|
| |
|
|
|
| |
The holelist isn't kept sorted; we used to always append to the end. But it's a
singly-linked list, so prepending to it is going to be much much simpler.
|
| |
|
|
| |
messing it up
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Although the previous commit should make it very unlikely we screw up the
subscription sharding, be defensive about waiting for SERVACKs. ZSubscribeTo
does mess up, Z_SendFragmentedNotice will shard with a z_multiuid. In that
case, although the second packet will get a SERVACK, Z_ReadWait kindly drops it
on the floor. The ZIfNotice will then just hang.
Tested by bumping zwgc's BATCH_SIZE up to 200, reverting the previous commit,
and strace.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Header lengths are not constant-size because Zcode escapes bytes 0xFF and 0x00
into two bytes. If we end up filling up close to all the space we have and
Z_SendFragmentedNotice then computes a header length larger than ours by
enough, the message gets fragmented.
Getting it fragmented is especially unfortunate because only the first of a
fragmented notice ever has a SERVACK survive. (They all get SERVACKs, but
libzephyr kindly drops all but the first on the floor.)
This isn't a watertight fix; we may get really really unlucky and blow up 13
bytes in the authenticator and checksum. But that's not likely, and a proper
fix would involve either computing based on the maximum possible authenticator
size (wasteful and hard to bound tightly) or changing to protocol to use a less
inappropriate encoding.
|
| | |
|
| |
|
|
| |
Looks like it's the same as free right now, but may as well call the right one.
|
| |
|
|
| |
Minor memory leak, but we may as well fix it.
|
| |
|
|
|
|
| |
With a custom send_routine that mirrors ZSrvSendList. This allows for an
asynchronous version that replaces send_routine with non-blocking versions (and
waits for ACKs out-of-band).
|
| |
|
|
|
|
| |
It's only used by ZCancelSubscription, but the server rejects unauthenticated
CLIENT_CANCELSUB requests anyway. The unauthenticated codepath results in a
SERVNAK and doesn't drop subs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ACKs to fragmented notices keep the multiuid field, but multipart becomes "".
This is interpreted as 0/z_message_length. This means ACKs to non-initial
fragments look like an initial fragment from the multipart field, but not when
checking uid == multiuid. The result is that they get smashed when passing
through reassembly.
6e8ec12b0ba9d476e065957028e4cf9cf69d6ac2 addressed this. For SERVACKs and
SERVNAKs, it drops all but the initial ones (uid == multipart) on the floor. It
ignores the problem for HMACKs. Normally ZSendPacket blocks on the HMACK before
sending each successive fragment, so there's no opportunity for them to
collide. But if calling ZSrvSendNotice with a custom send_function that doesn't
block, the HMACKs can smash into each other depending on timing.
Instead, fix it by using z_uid instead of z_multiuid as the multiuid key. For
compatibility, keep the SERVACK dropping behavior. (I'd like to get all the
SERVACKs too, but potentially that'll confuse clients somewhat.)
|
| |
|
|
| |
May as well put it in .rodata
|
| |
|
|
|
| |
I would hope this codepath can never trigger, but good to clean up properly
here.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, it was difficult to detect the presence of the zephyr
library in autoconf, and required custom macros. However, the world
has since developed pkg-config, which is a simple tool for detecting
the presence of a package, its compile-time flags, and its link-time
flags, even in the presence of recursive dependencies. This adds
"zephyr.pc" as a file generated by the build process, and installs it
into the appropriate directory, allowing the target system to use
PKG_CHECK_MODULES([ZEPHYR], [zephyr])
AC_SUBST([ZEPHYR_CFLAGS])
AC_SUBST([ZEPHYR_LIBS])
to detect all necessary information to incorporate the zephyr library.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Based on a patch by Ray Link <rlink+git@cs.cmu.edu>
|
| |
|
|
| |
zwrite: Manpage update for -S
|
| |
|
|
| |
Style says return types go on their own line.
|
| | |
|
| |
|
|
| |
It's -m 755, but that's the default anyway.
|
| |
|
|
|
| |
Otherwise make -j2 may try to build it before the generated headers are ready
and error.
|
| | |
|
| |
|
|
|
|
|
| |
We currently have no support for obeying the TTLs on DNS records
containing the addresses of servers in other realms. For now, kludge
around this by rechecking these addresses once a day whether we need
to or not.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are using c-ares to resolve otherrealm server names asynchronously,
there is a period of time during startup during which a realm may have no
servers whose names we have successfully resolved. This can also happen
when a realm is added, or when servers for a realm are deleted, and even
without asynchronous resolution, it can happen if we are having trouble
resolving names.
We now avoid trying to send notices to realms for which there are no usable
servers (that is, servers which are not deleted, not marked nosend, and
whose names have been resolved). Currently, when this happens, the notice
to be sent is just dropped on the floor. Arguably, we should manage a
queue of packets waiting to be sent to such a realm, and resend them if we
ever discover a usable server. But that would be complicated.
In addition, since we are basically never ready to send realm wakeups when
processing the realm.list, they are now deferred until the first server's
name has been resolved (and then, until the timer queue is processed).
This has the additional effect of causing wakeups to be sent for realms
which appear during a realm.list reload.
|
| |
|
|
| |
This fixes #73
|
| |
|
|
|
|
|
|
|
|
|
|
| |
With asynchronous name resolution and timers, we need to keep around
pointers to individual other-realm servers. This, we cannot move
existing servers around in memory without causing data corruption.
But, realm_init() wants to reallocate the srvrs array for a realm when
adding servers.
Therefore, to allow ZRealm.srvrs to be reallocated without changing the
addresses of existing servers, it is converted from an array of servers
to an array of pointers to servers.
|
| |
|
|
|
|
| |
Add the bits we need to be able to use c-ares for DNS operations in the
server. This handles initialization and making sure the resolver's
sockets and timeouts are considered in the main loop.
|
| |
|
|
| |
It's sort of nice to be able to build with debugging.
|
| |
|
|
| |
If it's going to return a value, it needs to always return a value.
|
| |
|
|
|
|
|
|
| |
Notably, use realloc rather than allocating and copying a whole new
table.
Also be more consistent about operating in terms of array indices rather
then pointers.
|
| |
|
|
|
|
|
|
|
| |
Also, tweak the debian build infrastructure so that we can pass
in arbitrary CFLAGS.
New program test_server that links with the non-main.c parts of
the server. Currently only (as above) tests the low-level bits
of uloc.c.
|
| |
|
|
|
| |
Move global variables and one function out of main.c so that the rest of
the server can be linked with a test harness.
|
| | |
|
| |
|
|
| |
Now supports krb5 pricipals sanely.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When Z_ReadWait receives a packet which doesn't start with a zephyr
version header, it considers the packet to be "obviously non-zephyr".
Such packets are discarded and, previously, caused Z_ReadWait to return
ZERR_NONE. Unfortunately, this can cause things to block for up to 60s
when a caller was expecting a non-blocking call to pick up a new packet
if there is one.
This changes Z_ReadWait to return ZERR_BADPKT in this situation,
eliminating the potential wait.
This fixes #100
|
| |
|
|
|
|
|
|
| |
Provide a new zctl subcommand, flush_subs, to flush all subscriptions for
a specified recipient. This is implemented using a new library function,
ZFlushUserSubscriptions().
This is the client side of #103
|
| |
|
|
|
|
|
|
|
| |
This adds support to the server for a new client control message,
CLIENT_FLUSHSUBS, which flushes all subscriptions and pending retransmits
for clients belonging to a given principal. The target principal must be
the same as the sender, unless the sender is on the opstaff ACL.
This is the server side of #103
|
| |
|
|
|
|
|
|
| |
Provide a new library function, ZFlushUserLocations(), to flush locations
for a specified user. This can be called using zctl flush_locs, which
now takes an optional username parameter.
This is the client side of #102
|
| |
|
|
|
|
|
| |
This allows anyone on opstaff.acl to submit location updates, including
flushing all locations, for a user other than themselves.
This is the server side of #102
|
| |
|
|
| |
This fixes #101
|
David Benjamin
Karl Ramm
Alex Chernyakhovsky
Ray Link
Jeffrey Hutzelman