summaryrefslogtreecommitdiffstats
path: root/src/network/networkd-json.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* sd-dhcp-client: introduce sd_dhcp_lease_has_6rd() helper functionYu Watanabe2023-09-051-1/+1
| | | | No functional change, just refactoring.
* dhcp: introduce sd_dhcp_lease_get_timestamp()Yu Watanabe2023-09-051-8/+6
| | | | | | | | And drop sd_dhcp_client_get_lease_timestamp(). Also, this introduce sd_dhcp_lease_get_lifetime_timestamp() and friends, which provides timestamp of the lifetime and so on, while sd_dhcp_lease_get_lifetime() provides timestamp.
* sd-dhcp-client: store lifetime and friends in usec_tYu Watanabe2023-09-051-4/+3
|
* network: Fix memory leak PREF64 (#29064)Susant Sahani2023-09-041-5/+6
| | | | | Follow-up for 6e8f5e4c1f5fcdb3b63343268936f9c269b6a209. Fixes #29062.
* Merge pull request #29023 from pelaufer/dhcp-prefix-dbusYu Watanabe2023-09-041-2/+149
|\ | | | | Add dhcp client prefix lease information to networkd json output
| * Add dhcp client prefix lease information to networkd json outputpelaufer2023-09-021-2/+149
| |
* | network: ndisc - Allow to parse PREF64 prefixSusant Sahani2023-09-041-0/+32
|/
* json: rename json_append() → json_variant_merge_objectb()Lennart Poettering2023-08-241-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | json_append() is a useful wrapper around json_variant_merge(). However, I think the naming sould be cleaned up a bit of both functions. I thinker "merge" is the better word than "append", since it does decidedly more than just append: it replaces existing fields of the same name, hence "merge" sounds more appropriate. This is as opposed to the similar operations for arrays, where no such override logic is applied and we really just append, hence those functions are called "append" already. To make clearer that "merge" is about objects, and "append" about arrays, also include "object" in the name. Also, include "json_variant" in the name, like we do for almost all other functions in the JSON API that take a JSON object as primary input, and hence are kinda object methods. Finally, let's follow the logic that helpers that combine json_build() with some other operation get suffixed with "b" like we already have in some cases. Hence: json_variant_merge() → json_variant_merge_object() json_append() → json_variant_merge_objectb() This mirrors nicely the existing: json_variant_append_array() json_vairant_append_arrayb() This also drops the variant of json_append() that takes a va_arg parameter (i.e. json_appendv()). We have no user of that so far, and given the nature as a helper function only I don#t see that happening, and if it happens after all it's trivial to bring back.
* tree-wide: use json_variant_append_arrayb() at many placesLennart Poettering2023-08-241-39/+26
|
* networkd: Add T1 and T2 DHCPv6 options to expose in dbus APINandakumar Raghavan2023-08-231-0/+41
| | | | | | | Include T1 and T2 DHCPv6 options to expose in dbus API. Introduced new field DHCPv6lease where these options are added. This will be added to the JSON output when we query org.freedesktop.network1.Manager object.
* Merge pull request #28387 from yuwata/network-route-table-nameLuca Boccassi2023-07-141-2/+2
|\ | | | | network: cleanups for route table name
| * network: do not append table number in TableString field in json outputYu Watanabe2023-07-141-2/+2
| | | | | | | | | | The json output already contains table number, hence, it is not necessary to include number in the string.
* | network: use json_append() and json_variant_append_array()Yu Watanabe2023-07-131-629/+305
|/
* json: free array in json_variant_unref_many()Daan De Meyer2023-07-121-200/+122
| | | | | | This allows using it with CLEANUP_ARRAY(). For the 2 call sites where we don't need to free the array, we do a regular for loop calling json_variant_unref() instead.
* network/json: introduce PreferredLifetimeUSec and ValidLifetimeUSecYu Watanabe2023-07-061-2/+4
|
* network: introduce link_get_captive_portal()Yu Watanabe2023-07-061-20/+5
| | | | | Then, downgrade log level of the message about mis-match of captive portals in different protocols.
* networkd: include captive portal information in link json descriptionRonan Pigott2023-07-021-0/+45
|
* networkd/dhcpserver: Save and expose the client hostname sent when ↵Rene Hollander2023-05-311-0/+1
| | | | | | | | | | requesting a DHCP lease. DHCP clients often send their own hostname in option 12. It can be useful to store it with the lease so it can be shown to a human to easily identify which lease belongs to which device. RFC: https://www.rfc-editor.org/rfc/rfc2132#section-3.14
* Add DHCPServer information to JSON output.Rene Hollander2023-05-271-0/+133
| | | | | | | | Adds a new JSON object called DHCPServer for each interface that has a DHCPServer configured. It has the following attributes: - PoolSize and PoolOffset from the configuration - List of offered leases - List of static leases from the configuration
* network: Show network and link file dropins in networkctl statusDaan De Meyer2023-01-121-1/+12
| | | | Fixes #24428
* network: rename Link.sd_device -> Link.devYu Watanabe2022-07-231-2/+2
|
* strv: make iterator in STRV_FOREACH() declaread in the loopYu Watanabe2022-03-191-2/+1
| | | | This also avoids multiple evaluations in STRV_FOREACH_BACKWARDS()
* network: rename SetupState to AdministrativeStateLaserEyess2021-12-101-1/+1
| | | | | | This is more consistent with the terminology used elsewhere. In particular it is consistent with the name of the property exposed over dbus for the link state.
* network: json: add src address when its prefix length is non-zeroYu Watanabe2021-12-081-3/+3
| | | | | | This should not change anything. Just for consistency with route_set_netlink_message(), which sets RTA_SRC attribute when prefix length is non-zero.
* network: json: add missing initializationYu Watanabe2021-11-301-1/+1
| | | | Fixes CID#1466513.
* network: json: append DNS misc settingsYu Watanabe2021-11-261-0/+107
|
* network: json: append DNSSEC negative trust anchorsYu Watanabe2021-11-261-0/+62
|
* network: json: append domainsYu Watanabe2021-11-261-0/+160
|
* network: json: append SIP server informationYu Watanabe2021-11-261-0/+59
|
* network: json: append NTP server informationYu Watanabe2021-11-261-0/+164
|
* network: json: append DNS server informationYu Watanabe2021-11-261-0/+170
|
* network: json: add several entries for wait-onlineYu Watanabe2021-11-261-1/+9
|
* network: json: add more link informationYu Watanabe2021-11-251-1/+29
|
* network: json: append routing policy rule informationYu Watanabe2021-11-251-0/+108
|
* network: json: append neighbor informationYu Watanabe2021-11-251-0/+68
|
* network: json: append nexthop informationYu Watanabe2021-11-251-0/+133
|
* network: json: append route informationYu Watanabe2021-11-251-1/+129
|
* network: json: append address informationYu Watanabe2021-11-251-0/+87
|
* network: json: split manager_build_json() into twoYu Watanabe2021-11-251-1/+5
|
* network: json: make {network,device}_build_json() accept NULLYu Watanabe2021-11-251-22/+24
|
* network: json: use new building json macrosYu Watanabe2021-11-251-17/+17
|
* shared/json: use int64_t instead of intmax_tZbigniew Jędrzejewski-Szmek2021-11-181-1/+1
| | | | | | | | | | | We were already asserting that the intmax_t and uintmax_t types are the same as int64_t and uint64_t. Pretty much everywhere in the code base we use the latter types. In principle intmax_t could be something different on some new architecture, and then the code would fail to compile or behave differently. We actually do not want the code to behave differently on those architectures, because that'd break interoperability. So let's just use int64_t/uint64_t since that's what we indend to use.
* netif-util: rename link_get_type_string() -> net_get_type_string()Yu Watanabe2021-11-091-1/+1
|
* netif-util: move several functions from network-util.[ch] to ↵Yu Watanabe2021-11-091-1/+1
| | | | | | | shared/netif-util.[ch] These functions are not relevant to sd-network, and only used by networkd, networkctl, and udevd.
* network: rename Manager::links -> Manager::links_by_indexYu Watanabe2021-06-301-2/+2
| | | | This also renames link_get() -> link_get_by_index().
* network: add an online state for links and managerAlvin Šipraga2021-05-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new state of type LinkOnlineState which indicates whether a link is online or not. The state is also used by networkd's manager to expose the overall online state of the system. The possible states are: offline the link (or system) is offline partial at least one required link is online (see below) online all required links are online For links, a link is defined to be "online" if: - it is managed; and - its operational state is within the range defined by RequiredForOnline=; and - it has an IPv4 address if RequiredFamilyForOnline=ipv4 or =both; and - it has an IPv6 address if RequiredFamilyForOnline=ipv6 or =both. A link is defined to be "offline" if: - it is managed; and - it is not online, i.e. its operational state is not within the range defined by RequiredForOnline=, and/or it is missing an IP address in a required address family. Otherwise, the link online state is undefined (represented internally as _LINK_ONLINE_STATUS_INVALID or -EINVAL). Put another way, networkd will only offer a meaningful online state for managed links where RequiredForOnline=yes. For the manager, the online state is a function of the online state of all links which are requried for online, i.e. RequiredForOnline=yes. If all required links are online, then the manager online state is defined to be "online". If at least one of the required links is online, then the manager online state is defined to be "partial". If none of the required links are online, then the manager online state is defined to be "offline". If there are no managed links, or RequiredForOnline=no for all managed links, then the manager online state is undefined as above. The purpose of the "partial" state is analogous to the --any switch in systemd-networkd-wait-online.service(8). For example, a required link which lacks a carrier on boot will not force the overall (manager) online state to "offline" if there is an alternative link available.
* network: introduce Describe() method for manager and linksYu Watanabe2021-05-141-0/+135
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-30 00:58:36 +0100