summaryrefslogtreecommitdiff
path: root/libnm
Commit message (Collapse)AuthorAgeFilesLines
* libnm: remove unused import from "generate-setting-docs.py"Thomas Haller2020-05-071-1/+1
|
* libnm: fix redundant line constructing dbus_type_name_map in ↵Thomas Haller2020-05-071-1/+0
| | | | "generate-setting-docs.py"
* libnm: remove early return statement in test_nm_auth_permissions()Beniamino Galvani2020-05-071-1/+1
| | | | | | | | | Reported by coverity: >>> CID 210230: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "i = 0;". Fixes: 09e17888f7f0 ('libnm: add mapping functions between string and NMClientPermission enum')
* libnm: fix assertion in NML_IS_DBUS_OBJECT()Beniamino Galvani2020-05-071-1/+2
| | | | | | | | | | Reported by coverity: >>> CID 210228: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "dbobj" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. Fixes: ce0e898fb476 ('libnm: refactor caching of D-Bus objects in NMClient')
* libnm: sort entires in libnm.verThomas Haller2020-05-061-7/+7
|
* settings: add match for driverAdrian Freihofer2020-05-061-0/+7
| | | | | | Add a new "driver" match option to nm-settings. It allows to disable a network connection configuration if a pattern is found or is not found in the device driver name.
* settings: add match for proc cmdlineAdrian Freihofer2020-05-061-0/+7
| | | | | | Add a new "kernel-command-line" match option to nm-settings. It allows to disable a network connection configuration if a pattern is found or is not found in /proc/cmdline.
* nm-setting-bridge: add 'multicast-startup-query-interval' bridge optionAntonio Cardace2020-05-041-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-startup-query-count' bridge optionAntonio Cardace2020-05-041-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-query-response-interval' bridge optionAntonio Cardace2020-05-041-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-query-interval' bridge optionAntonio Cardace2020-05-041-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-querier-interval' bridge optionAntonio Cardace2020-05-041-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-membership-interval' bridge optionAntonio Cardace2020-05-041-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-last-member-interval' bridge optionAntonio Cardace2020-05-041-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-last-member-count' bridge optionAntonio Cardace2020-05-041-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-hash-max' bridge optionAntonio Cardace2020-05-041-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* libnm/doc: fix spelling in nm_client_add_and_activate_connection2() ↵Thomas Haller2020-04-281-3/+3
| | | | documentation
* libnm/meson.build: stop using env -i (just env)Michael Stapelberg2020-04-261-1/+1
| | | | | | | | | | env -i starts with an empty environment, which is undesired when the build environment needs certain environment variables to function. One such example is a custom PYTHONPATH, which gets dropped by env -i and results in the nm-settings-docs.xml generator not finding the gi Python module. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/478
* libnm: fix symbol versioning for nm_setting_connection_get_mud_url()Thomas Haller2020-04-241-1/+5
|
* dhcp: add support for MUD URL (RFC 8520)Eliot Lear2020-04-241-0/+1
| | | | | | | | | | | [thaller@redhat.com: rewritten commit message] https://tools.ietf.org/html/rfc8520 https://blog.apnic.net/2019/05/14/protecting-the-internet-of-things-with-mud/ https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/402 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/463
* nm-setting-bridge: add 'multicast-querier' bridge optionac/bridge_optionsAntonio Cardace2020-04-061-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-query-use-ifaddr' bridge optionAntonio Cardace2020-04-061-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'multicast-router' bridge optionAntonio Cardace2020-04-061-0/+1
| | | | | | Also add related unit test. https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'vlan-stats-enabled' bridge optionAntonio Cardace2020-04-061-0/+1
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'vlan-protocol' bridge optionAntonio Cardace2020-04-061-0/+1
| | | | | | Also add related unit test. https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* nm-setting-bridge: add 'group-address' bridge optionAntonio Cardace2020-04-061-0/+1
| | | | | | Also add related unit test. https://bugzilla.redhat.com/show_bug.cgi?id=1755768
* libnm: ignore "Peer" property on Device.Veth interfaceThomas Haller2020-03-301-0/+3
| | | | | | With LIBNM_CLIENT_DEBUG=trace we get warnings: libnm-dbus: <warn > [31459.06461] nmclient[cc68a57bb44f1427]: get-managed-objects: [/org/freedesktop/NetworkManager/Devices/11]: ignore unknown property org.freedesktop.NetworkManager.Device.Veth.Peer
* meson: merge branch 'inigomartinez/meson-license'Thomas Haller2020-03-282-0/+4
|\ | | | | | | | | | | | | | | | | | | Add SPDX license headers for meson files. As far as I can tell, according to RELICENSE.md file, almost everybody who contributed to the meson files agreed to the LGPL-2.1+ licensing. This entails the vast majority of code in question. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/397
| * license: Add license using SPDX identifiers to meson build filesIñigo Martínez2020-02-172-0/+4
| | | | | | | | | | License is missing in meson build files. This has been added using SPDX identifiers and licensed under LGPL-2.1+.
* | Add domain_match mode for wifi certificate domain comparisonNiklas Goerke2020-03-231-0/+2
| | | | | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/308 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/437
* | all: use nm_clear_pointer() instead of g_clear_pointer()Thomas Haller2020-03-235-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | g_clear_pointer() would always cast the destroy notify function pointer to GDestroyNotify. That means, it lost some type safety, like GPtrArray *ptr_arr = ... g_clear_pointer (&ptr_arr, g_array_unref); Since glib 2.58 ([1]), g_clear_pointer() is also more type safe. But this is not used by NetworkManager, because we don't set GLIB_VERSION_MIN_REQUIRED to 2.58. [1] https://gitlab.gnome.org/GNOME/glib/-/commit/f9a9902aac826ab4aecc25f6eb533a418a4fa559 We have nm_clear_pointer() to avoid this issue for a long time (pre 1.12.0). Possibly we should redefine in our source tree g_clear_pointer() as nm_clear_pointer(). However, I don't like to patch glib functions with our own variant. Arguably, we do patch g_clear_error() in such a manner. But there the point is to make the function inlinable. Also, nm_clear_pointer() returns a boolean that indicates whether anything was cleared. That is sometimes useful. I think we should just consistently use nm_clear_pointer() instead, which does always the preferable thing. Replace: sed 's/\<g_clear_pointer *(\([^;]*\), *\([a-z_A-Z0-9]\+\) *)/nm_clear_pointer (\1, \2)/g' $(git grep -l g_clear_pointer) -i
* | all: use nm_clear_g_free() instead of g_clear_pointer()Thomas Haller2020-03-231-1/+1
| | | | | | | | | | | | | | | | | | I think it's preferable to use nm_clear_g_free() instead of g_clear_pointer(, g_free). The reasons are not very strong, but I think it is overall preferable to have a shorthand for this frequently used functionality. sed 's/\<g_clear_pointer *(\([^;]*\), *\(g_free\) *)/nm_clear_g_free (\1)/g' $(git grep -l g_clear_pointer) -i
* | libnm: drop unused codeThomas Haller2020-03-231-6/+0
| |
* | libnm: advise using D-Bus instead of deprecated synchronous methodsThomas Haller2020-03-232-24/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With 1.22, various synchronous functions for invoking D-Bus methods were deprecated. The reason was that D-Bus is fundamentally asynchronous, and providing synchronous API in NMClient is inherently wrong. That is because NMClient essentially is a cache of the D-Bus API, and invoking g_dbus_connection_call_sync() messes up the order of events from D-Bus. In particular, when the synchronous function completes, the content of the cache does not yet reflect the change. Since they got deprecated, the question is with what to replace them. Instead of adding a (e.g.) nm_client_networking_set_enabled_async() for nm_client_networking_set_enabled(), just expect the user to call D-Bus directly. D-Bus itself defines a reasonable API, and with GDBusConnection it is fine (and convenient) to just call D-Bus operations directly. Often libraries try to abstract D-Bus by providing convenience wrappers around D-Bus API. I think that often is wrong and unnecessary. Note that libnm's NMClient does a lot more than just wrapping simple D-Bus calls. It provides a complete client-side cache of the D-Bus interface. As such, what libnm's NMClient does is more than simple wrappers around D-Bus. NMClient is a reasonable thing to do. However, it is unnecessary to add API like nm_client_networking_set_enabled_async() that only calls g_dbus_connection_call(). Don't pretend that we would need such trivial wrappers in libnm. Instead, recommend to use g_dbus_connection_call(). Or alternatively, the convenience wrappers nm_client_dbus_call() and nm_client_dbus_set_property().
* | libnm: add nm_client_dbus_set_property() APIThomas Haller2020-03-233-0/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to nm_client_dbus_call(), but useful for setting a D-Bus property on NetworkManager's D-Bus interface. Note that we currently have various synchronous API for setting D-Bus properties (like nm_client_networking_set_enabled()). Synchronous API does not play well with the content of NMClient's cache, and was thus deprecated. However, until now no async variant exists. Instead of adding multiple async operations, I think it should be sufficient to only add one nm_client_dbus_set_property() property. It's still reasonably convenient to use for setting a property.
* | libnm: add nm_client_dbus_call() APIThomas Haller2020-03-233-0/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an API for calling D-Bus methods arbitrary objects of NetworkManager's API. Of course, this is basically just a call to g_dbus_connection_call(), using the current name owner, nm_client_get_dbus_connection() and nm_client_get_main_context(). All of this could also be achieved without this new API. However, nm_client_dbus_call() also gracefully handles if the current name owner is %NULL. It's a valid concern whether such API is useful, as the users already have all pieces to do it themself. I think it is.
* | libnm/doc: fix gtk-doc for deprecated markers in libnmThomas Haller2020-03-2327-66/+66
| |
* | nm-device: expose via D-Bus the 'hw-address' propertyAntonio Cardace2020-03-1339-681/+248
| | | | | | | | | | | | | | Drop device-specific 'hw-address' GObject properties which are now redundant. https://bugzilla.redhat.com/show_bug.cgi?id=1786937
* | libnm: cleanup 'NML_DBUS_META_IFACE_INIT_PROP' macroAntonio Cardace2020-03-131-4/+10
| |
* | nm-setting-bond: add API to libnm to get the normalized bond option valueAntonio Cardace2020-03-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add 'nm_setting_bond_get_option_normalized()', the purpose of this API is to retrieve a bond option normalized value which is the option that NetworkManager will actually apply to the bond when activating the connection, this takes into account default values for some options that NM assumes. For example, if you create a connection: $ nmcli c add type bond con-name nm-bond ifname bond0 bond.options mode=0 Calling 'nm_setting_bond_get_option_normalized(s_bond, "miimon")' would return "100" as even if not specified NetworkManager enables miimon for bond connections. Another example: $ nmcli c add type bond con-name nm-bond ifname bond0 bond.options mode=0,arp_interval=100 Calling 'nm_setting_bond_get_option_normalized(s_bond, "miimon")' would return NULL in this case because NetworkManager disables miimon if 'arp_interval' is set explicitly but 'miimon' is not.
* | all: unify spelling of "fall-through" comment for switch statementsThomas Haller2020-02-211-1/+1
| | | | | | | | | | We used "/* fall through */" and "/* fall-through */" inconsistently. Rename to use only one variant.
* | build/meson: fix missing dependency when building nm-libnm-auxThomas Haller2020-02-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [351/932] Compiling C object libnm/fdede0a@@nm-libnm-aux@sta/.._shared_nm-libnm-aux_nm-libnm-aux.c.o. FAILED: libnm/fdede0a@@nm-libnm-aux@sta/.._shared_nm-libnm-aux_nm-libnm-aux.c.o gcc -Ilibnm/fdede0a@@nm-libnm-aux@sta -Ilibnm -I../libnm -Ilibnm-core -I../libnm-core -I. -I../ -Ishared -I../shared -I/usr/include/gio-unix-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=gnu11 -O2 -g -Wall -Wextra -Wdeclaration-after-statement -Wfloat-equal -Wformat-nonliteral -Wformat-security -Wimplicit-fallthrough -Wimplicit-function-declaration -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes -Wpointer-arith -Wshadow -Wshift-negative-value -Wstrict-prototypes -Wundef -Wvla -Wno-duplicate-decl-specifier -Wno-format-truncation -Wno-format-y2k -Wno-missing-field-initializers -Wno-pragmas -Wno-sign-compare -Wno-unknown-pragmas -Wno-unused-parameter -Wpointer-arith -Wshadow -Wstrict-prototypes -Wundef -fno-strict-aliasing -fPIC -pthread -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40 -DG_LOG_DOMAIN=libnmc -DNETWORKMANAGER_COMPILATION=NM_NETWORKMANAGER_COMPILATION_CLIENT -MD -MQ libnm/fdede0a@@nm-libnm-aux@sta/.._shared_nm-libnm-aux_nm-libnm-aux.c.o -MF libnm/fdede0a@@nm-libnm-aux@sta/.._shared_nm-libnm-aux_nm-libnm-aux.c.o.d -o libnm/fdede0a@@nm-libnm-aux@sta/.._shared_nm-libnm-aux_nm-libnm-aux.c.o -c ../shared/nm-libnm-aux/nm-libnm-aux.c In file included from ../libnm-core/nm-connection.h:14, from ../libnm/nm-types.h:12, from ../libnm/nm-object.h:14, from ../libnm/nm-access-point.h:14, from ../libnm/NetworkManager.h:11, from ../shared/nm-default.h:288, from ../shared/nm-libnm-aux/nm-libnm-aux.c:3: ../libnm-core/nm-core-types.h:13:10: fatal error: nm-core-enum-types.h: No such file or directory 13 | #include "nm-core-enum-types.h" | ^~~~~~~~~~~~~~~~~~~~~~ compilation terminated.
* | libnm: move nm_setting_ip6_config_get_ra_timeout() to "libnm_1_22_8" symbol ↵Thomas Haller2020-02-171-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | version nm_setting_ip6_config_get_ra_timeout() was backported to nm-1-22 branch, and will be released as 1.22.8. As such, on the stable branch the symbol will be placed in a separate symbol version ("libnm_1_22_8"). To support the upgrade path from 1.22.8+ to 1.23+, we want this symbol also present on master. At that point, we don't need to duplicate the symbol. Just add the same linker symbol version also to master.
* | libnm,cli,ifcfg-rh: add ipv6.ra-timeout configuration optionThomas Haller2020-02-171-0/+1
|/
* shared: drop _STATIC variant of macros that define functionsThomas Haller2020-02-131-1/+2
| | | | | | | | | | | | | | | | | | Several macros are used to define function. They had a "_STATIC" variant, to define the function as static. I think those macros should not try to abstract entirely what they do. They should not accept the function scope as argument (or have two variants per scope). This also because it might make sense to add additional __attribute__(()) to the function. That only works, if the macro does not pretend to *not* define a plain function. Instead, embrace what the function does and let the users place the function scope as they see fit. This also follows what is already done with static NM_CACHED_QUARK_FCN ("autoconnect-root", autoconnect_root_quark)
* shared/trivial: rename time related functions to use "nsec"/"msec" ↵Thomas Haller2020-02-101-1/+1
| | | | | | | abbreviation instead of "ns"/"ms" The "ns" abbreviation doesn't look too nice. We mostly use "nsec" at other places. Rename.
* all: add nm_utils_error_is_cancelled() and ↵Thomas Haller2020-02-102-11/+11
| | | | | | | | nm_utils_error_is_cancelled_or_disposing() Most callers would pass FALSE to nm_utils_error_is_cancelled(). That's not very useful. Split the two functions and have nm_utils_error_is_cancelled() and nm_utils_error_is_cancelled_is_disposing().
* libnm: hide NMActiveConnection until NMRemoteConnection is readyThomas Haller2020-02-103-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generally, libnm's NMClient cache only wants to expose NMObjects that are fully initalized. Most objects don't require anything special, except NMRemoteConnection which waits for the GetSettings() call to complete. NMObjects reference each other. For example, NMActiveConnection references NMDevice and NMRemoteConnection. There is a desire that an object is only ready, if the objects that it references are ready too. In practice that is not done, because usually every objects references other objects, that means all objects would be declared as non-ready as long as any of them is still initializing. That does not seem desirable. Instead, most objects (except NMRemoteConnection and now NMActiveConnection) are considered ready and visible, once their first notification completes. In case the objects reference any object that is not yet ready, the references is NULL (but the source object is visible already). This is also done this way, to cope with cycles where objects reference each other. In practice, such cycles should not be exposed by NetworkManager. However, libnm should be robust against that. This has the undesired effect that when you call AddAndActivate(), then the NMActiveConnection might already be visible while its NMRemoteConnection isn't. That means, ac.get_connection() will initially return NULL, until the remote connection becomes ready. Also add a special handling that NMActiveConnection waits for their NMRemoteConnection to be ready, before being ready itself. Fixes: ce0e898fb476 ('libnm: refactor caching of D-Bus objects in NMClient')
* libnm: minor cleanup of libnm trace loggingThomas Haller2020-02-101-3/+3
|
* libnm/secret-agent: rework NMSecretAgentOldThomas Haller2020-01-284-721/+1368
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note that the name "NMSecretAgentOld" comes from when libnm was forked from libnm-glib. There was a plan to rework the secret agent API and replace it by a better one. That didn't happen (yet), instead our one and only agent implementation is still lacking. Don't add a new API, instead try to improve the existing one, without breaking existing users. Just get over the fact that the name "NMSecretAgentOld" is ugly. Also note how nm-applet uses NMSecretAgentOld. It subtypes a class AppletAgent. The constructor applet_agent_new() is calling the synchronous g_initable_init() initialization with auto-register enabled. As it was, g_initable_init() would call nm_secret_agent_old_register(), and if the "Register" call failed, initialization failed for good. There are even unit tests that test this behavior. This is bad behavior. It means, when you start nm-applet without NetworkManager running, it will fail to create the AppletAgent instance. It would hence be the responsibility of the applet to recover from this situation (e.g. by retrying after timeout or watching the D-Bus name owner). Of course, nm-applet doesn't do that and won't recover from such a failure. NMSecretAgentOld must try hard not to fail and recover automatically. The user of the API is not interested in implementing the registration, unregistration and retry handling. Instead, it should just work best effort and transparently to the user of the API. Differences: - no longer use gdbus-codegen generate bindings. Use GDBusConnection directly instead. These generated proxies complicate the code by introducing an additional, stateful layer. - properly handle GMainContext and synchronous initialization by using an internal GMainContext. With this NMSecretAgentOld can be used in a multi threaded context with separate GMainContext. This does not mean that the object itself became thread safe, but that the GMainContext gives the means to coordinate multi-threaded access. - there are no more blocking calls except g_initiable_init() which iterates an internal GMainContext until initialization completes. - obtaining the Unix user ID with "GetConnectionUnixUser" to authenticate the server is now done asynchronously and only once per name-owner. - NMSecretAgentOld will now register/export the Agent D-Bus object already during initialization and stay registered as long as the instance is alive. This is because usually registering a D-Bus object would not fail, unless the D-Bus path is already taken. Such an error would mean that another agent is registered for the same GDBusConnection, that likely would be a bug in the caller. Hence, such an issue is truly non-recoverable and should be reported early to the user. There is a change in behavior compared to before, where previously the D-Bus object would only be registered while the instance is enabled. This makes a difference if the user intended to keep the NMSecretAgentOld instance around in an unregistered state. Note that nm_secret_agent_old_destroy() was added to really unregister the D-Bus object. A destroyed instance can no longer be registered. - the API no longer fully exposes the current registration state. The user either enables or disables the agent. Then, in the background NMSecretAgentOld will register, and serve requests as they come. It will also always automatically re-register and it can de-facto no longer fail. That is, there might be a failure to register, or the NetworkManager peer might not be authenticated (non-root) or there might be some other error, or NetworkManager might not be running. But such errors are not exposed to the user. The instance is just not able to provide the secrets in those cases, but it may recover if the problem can be resolved. - In particular, it makes no sense that nm_secret_agent_old_register*() fails, returns an error, or waits until registration is complete. This API is now only to enable/disable the agent. It is idempotent and won't fail (there is a catch, see next point). In particular, nm_secret_agent_old_unregister*() cannot fail anymore. - However, with the previous point there is a problem/race. When you create a NMSecretAgentOld instance and immediately afterwards activate a profile, then you want to be sure that the registration is complete first. Otherwise, NetworkManager might fail the activation because no secret agent registered yet. A partial solution for this is that g_initiable_init()/g_async_initable_init_async() will block until registration is complete (or with or without success). That means, if NetworkManager is running, initializing the NMSecretAgentOld will wait until registration is complete (or failed). However, that does not solve the race if NetworkManager was not running when creating the instance. To solve that race, the user may call nm_secret_agent_old_register_async() and wait for the command to finish before starting activating. While async registration no longer fails (in the sense of leaving the agent permanently disconnected), it will try to ensure that we are successfully registered and ready to serve requests. By using this API correctly, a race can be avoided and the user can know that the instance is now ready to serve request.
View Lorry Controller Status