IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Update comment to be a bit more specific.
Change match to blacklist the serial number of the broken devices
instead of whitelisting the serial number of the fixed devices.
This allows to do something useful with the serial number in the
future.
safe_close_pair() is more like safe_close(), except that it handles
pairs of fds, and doesn't make and misleading allusion, as it works
similarly well for socketpairs() as for pipe()s...
If you allocate a message with bus==NULL and then unref the main bus,
it will free your message underneath and your program will go boom!
To fix that, we really need to figure out what the semantics for
self-references (m->bus) should be and when/where/what accesses are
actually allowed.
Same is true for the pseudo-thread-safety we employ..
In sd_bus_unref() we check for self-reference loops and destruct our
queues in case we're the only reference holders. However, we do _not_
modify our own ref-count, thus effectively causing the
message-destructions to enter with the same reference count as we did.
The only reason this doesn't cause an endless recursion (or trigger
assert(m->n_ref > 0) in sd_bus_message_unref()) is the fact that we
decrease queue-counters _before_ calling _unref(). That's not obvious at
all, so add a big fat note in bus_reset_queues() to everyone touching that
code.
Like sd-bus, sd-rtnl can have self-references through queued messages. In
particular, each queued message has the following self-ref loop:
rtnl->wqueue[i]->rtnl == rtnl
Same is true for "rqueue".
When sd_rtnl_unref() gets called, we must therefore make sure we correctly
consider each self-reference when deciding to destroy the object. For each
queued message, there _might_ be one ref. However, rtnl-messages can be
created _without_ a bus-reference, therefore we need to verify the
actually required ref-count.
Once we know exactly how many self-refs exist, and we verified none of the
queued messages has external references, we can destruct the object.
We must immediately drop our own reference, then flush all queues and
destroy the bus object. Otherwise, each sd_rtnl_message_unref() call would
recurse into the same destruction logic as they enter with the same
rtnl-refcnt.
Note: We really should verify _all_ queued messages have m->rtnl set to
the bus they're queued on. If that's given, we can change:
if (REFCNT_GET(rtnl->n_ref) <= refs)
to
if (REFCNT_GET(rtnl->n_ref) == refs)
and thus avoid recalculating the required refs for each message we
remove from the queue during destruction.
One end of the socketpair is closed by the library, so only close our end. Also switch to
the safe_close() so we get notified about problems with closing.
This does not belong in shared as it is mostly a detail of our networking subsystem.
Moreover, now we can use libudev here, which will simplify things.
Increase the chance of using the same link local address between reboots. The
pseudo random sequence of addresses we attempt is now seeded with data that is
very likely to stay the same between reboots, but at the same time be unique
to the specific machine/nic.
First we try to use the ID_NET_NAME_* data from the udev db combined with the
machin-id, which is guaranteed to be unique and persistent, if available. If
that is not possible (e.g., in containers where we don't have access to the
udev db) we fallback to using the MAC address of the interface, which is
guaranteed to be unique, and likely to be persistent.
[tomegun: three minor changes:
- don't expose HASH_KEY in the siphash24 header
- get rid of some compile-warnings (and some casts at the same time),
by using uint8_t[8] rather than uint64_t in the api
- added commit message]
If necessary, restart the clients to deal with a changing mac address
at runtime. This will solve the problem of starting clients on bridges
before they have received their final MAC address.
Some DHCP servers gives you a netmask of 255.255.255.255 so the gateway is not
routable. Other DHCP client implementations look through the existing routes to
figure out if they should add an explicit host route. See below for a link.
However, it makes sense to just create the route explicitly whether it is
needed or not since it is explicit, makes the dhcp route entries independent of
other entries and saves us from knowing the state of the kernel tables.
After patch route table on a machine with a network (common case):
default via 10.0.2.2 dev ens3
10.0.2.0/24 dev ens3 proto kernel scope link src 10.0.2.15
10.0.2.2 dev ens3 scope link
After patch route table on a machine without a network (this case):
default via 10.240.0.1 dev ens4v1
10.240.0.1 dev ens4v1 scope link
The code from dhcpcd that works around this issue is on line 637.
https://android.googlesource.com/platform/external/dhcpcd/+/master/configure.c
The DHCP RFC does not require the DHCP server to send a subnet mask, so if it
is missing, let's try to use the default subnet masks based on address class.
In case the class the address belongs to does not have a default subnet mask,
we fail as before.
Also improve logging when handling invalid dhcp messages, and simply ignore them
rather than stop the whole dhcp client.
Accept any lease lifetime greater than one second. Server should not
hand out extremely short leases, but let's not be the ones to fail.
Do not fail when arming a timer in the past, but also only arm one such
timer.
Avoid rounding errors when computing the default timeouts, this may be
an issue if we are handed a very short lease.
Also, don't pass 'time_now' around, as that can be found in the event
object when needed.
Pass the mac address on to ipv4ll and dhcp clients so they always have
up-to-date information, and may react appropriately to the change.
Also drop setting the mac address from uevent, and only log when the
address actually changes.
Even though client identifiers SHOULD be treated as opaque objects by
DHCP servers, follow the recommendation of a hardware type field with
value 0x01 (ethernet) followed by the hardware address as described in
RFC 2132.
A service with PrivateNetwork= cannot access abstract namespace sockets
of the host anymore, hence let's better not use abstract namespace
sockets for this, since we want to make sure that PrivateNetwork=
is useful and doesn't break sd_notify().
Let's automatically initialize the kill, exec and cgroup contexts of the
various unit types when the object is constructed, instead of
invididually in type-specific code.
Also, when PrivateDevices= is set, set DevicePolicy= to closed.
