Make sure all variable-length inputs are properly terminated or that
their length is encoded in some way. This avoids ambiguity of
adjacent inputs.
E.g., in case of a hash function taking two strings, compressing "ab"
followed by "c" is now distinct from "a" followed by "bc".
All our hash functions are based on siphash24(), factor out
siphash_init() and siphash24_finalize() and pass the siphash
state to the hash functions rather than the hash key.
This simplifies the hash functions, and in particular makes
composition simpler as calling siphash24_compress() repeatedly
on separate chunks of input has the same effect as first
concatenating the input and then calling siphash23_compress()
on the result.
The reason for the crippled hash function is to reduce the distribution
of the hash function, do this by truncating the domain rather than the
range. This does introduce a change in behavoir as the range is no longer
contiguous, which greatly reduces collisions.
This is needed as a follow-up patch will no longer allow individual hash
functions to alter the output directly.
Verify the state of the hash-function according to the reference paper,
also verify that we can decompose the input and hash the chunks one
by one and still get the same result.
The last compression is special as it deals with the length byte, and padding. Move
it to the finalization step in preparation for making compression decomposable.
ForwardDelaySec: forward delay
HelloTimeSec: hello time
MaxAgeSec: maximum message age
for more information see
http://www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/set-up-the-bridge.html
In kernel
br_dev_newlink: does not have the this functionality to set while
creation.
br_changelink: after creation we can change the parameters.
we need to first create then set it the parameters.
Introduce new callback post_create .This should
set the properties after the creation.
By default we set as NLM_F_CREATE | NLM_F_EXCL in
sd_rtnl_message_new_link
But incase of bridge we need to set NLM_F_REQUEST | NLM_F_ACK.
If NLM_F_EXCL is set then we are unable to set the parameters. As bridge
supports setting properties after creation not during creation.
Much like the result of the service itself we should not reset the
reload result unless we actually start from the beginning, so that
clients can query it at any time.
Specifically, let's reset the result states only when we begin with a
start operation (for both the main result, and the reload result), when
we begin with a reload operation (only for the load result), or when the
use explicitly asks for that via "systemctl reset-failed".
This is a more generic fix for #1447.
Fixes#1447.
Implement a maximum limit on number of journal files to keep around.
Enforcing a limit is useful on this since our performance when viewing
pays a heavy penalty for each journal file to interleve. This setting is
turned on now by default, and set to 100.
Also, actully implement what 348ced9097
promised: use whatever we find on disk at startup as lower bound on how
much disk space we can use. That commit introduced some provisions to
implement this, but actually never did.
This also adds "journalctl --vacuum-files=" to vacuum files on disk by
their number explicitly.
Let's try to use O_NOATIME if we can when vacuuming old journal files,
if we have the permissions for it, so that vacuuming doesn't count as
proper journal read access.
tlv_packet_read_bytes() and tlv_packet_read_string() returned the
wrong length when called after other functions which modify the offset
in the container.
In other words, if the TLV data length is X and we do a
tlv_packet_read_u8(), a subsequent tlv_packet_read_bytes() should
return a length of (X - 1).
In order to implement tests for the LLDP state machine, we need to
mock lldp_network_bind_raw_socket(). Move the other function
lldp_receive_packet() to another file so that we can replace the first
function with a custom one and keep the second one.
LLDP TLVs of type 127 are used to carry organizationally specific
information and include additional fields to specify the OUI and
subtype.
Add support for parsing such fields and functions to access the most
common IEEE 802.1 specific TLVs.
It can be useful to know the destination address of a LLDP frame
because it determines the scope of propagation of the frame and thus
this information be used to know whether the neighbor is connected to
the same physical link.
See clause 7.1 of IEEE Std 802.1AB-2009.
Add a public function to get a list of current LLDP neighbours' TLV
packets. The function populates an array of pointers to the opaque
type sd_lldp_packet and returns the number of elements found. Callers
must take care of freeing the array and decreasing the refcount of
elements when done.
Tom Gundersen
Lukas Nykryn
Daniel Mack
Daniel Machon
Daniel Mack
Susant Sahani
Kay Sievers
Lennart Poettering
Martin Pitt
Марко М. Костић (Marko M. Kostić)
Evgeny Vereshchagin
Beniamino Galvani