summaryrefslogtreecommitdiff
path: root/src/libsystemd-network/dhcp6-internal.h
Commit message (Collapse)AuthorAgeFilesLines
* send dhcpv6 release when stoppingchris2023-01-171-0/+1
|
* dhcp: use the attached sd_device object when generating IAIDYu Watanabe2022-10-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note, previously `use_mac` set with `test_mode`. As `dev`, which is set with `client->dev`, is not set when running test or fuzzer. Hence, the condition ``` if (udev_available() && !use_mac) ``` is effectively equivalent to ``` if (dev) ``` So, this commit mostly does not change behavior. Except for the following corner case. The sd_device object assigned from networkd (that is, Link.dev) never has ID_RENAMING udev property, as sd_device objects which has the property are filtered out at `link_check_initialized()` or `manager_udev_process_link()` in networkd-link.c. However, sd_device object created in `dhcp_identifier_set_iaid()` in the previous code may have it. Such situation may (at least, theoretically) happen when the network interface is renamed after initialized, e.g. by creating the following spurious .link file: ``` [Match] OriginalName=eno1 [Link] Name=lan ``` and then trigger uevent for the network interface while systemd-networkd calling `dhcp_identifier_set_iaid()`.
* sd-dhcp6-client: introduce sd_dhcp6_client_attach_device()Yu Watanabe2022-10-261-0/+2
| | | | It will be used later.
* sd-dhcp6-client: introduce sd_dhcp6_client_set_rapid_commit()Yu Watanabe2022-07-221-0/+1
|
* sd-dhcp6-client: rename req_opts_len -> n_req_optsYu Watanabe2022-04-031-1/+1
| | | | | As 'len' is confusing and we may misunderstand it as the size of the buffer instead of the number of options.
* fuzz-dhcp6-client: merge with fuzz-dhcp6-client-sendYu Watanabe2022-02-141-0/+1
|
* sd-dhcp6-client: split dhcp6-internal.h into twoYu Watanabe2022-02-141-119/+32
| | | | Also, this moves string tables to dhcp6-protocol.c.
* sd-dhcp6-client: do not expose set_transaction_id()Yu Watanabe2022-02-141-0/+1
| | | | | | | This is mostly for tests or fuzzers. Hence, this makes the function requires that the client is running in the test mode. Also, now the function mask the value for message type.
* sd-dhcp6-client: use OrderedSet for vendor optionYu Watanabe2022-02-141-2/+3
| | | | This also fixes memleak.
* sd-dhcp6-client: use struct hw_addr_dataYu Watanabe2022-02-141-2/+1
|
* sd-dhcp6-client: use proper type for string table lookup funcsYu Watanabe2022-02-141-4/+4
|
* sd-dhcp6-client: set lease expiration timer in client_enter_bound_state()Yu Watanabe2022-02-141-3/+3
| | | | | | The timer must be active until the client get re-enter bound state, and the timeout must be determined by the lease acquired when entering the bound state.
* sd-dhcp6-client: introduce dhcp6_lease_new_from_message()Yu Watanabe2022-02-141-7/+55
|
* sd-dhcp6-client: unify dhcp6_option_append_{ia,pd}()Yu Watanabe2022-02-141-1/+0
|
* sd-dhcp6-client: store PD prefix hint in ia_pdYu Watanabe2022-02-141-1/+1
| | | | And allows to specify multiple hints.
* sd-dhcp6-client: introduce dhcp6_ia_free()Yu Watanabe2022-02-141-1/+1
|
* sd-dhcp6-client: unify IA option headerYu Watanabe2022-02-141-19/+2
| | | | This also fixes possible unaligned read of message.
* sd-dhcp6-client: expose client_parse_message()Yu Watanabe2022-01-131-0/+7
| | | | To introduce tests for the function in later commits.
* sd-dhcp6-client: introduce dhcp6_option_can_request()Yu Watanabe2021-10-131-0/+1
|
* sd-dhcp6-client: slightly modernize ↵Yu Watanabe2021-09-291-3/+2
| | | | dhcp6_option_parse_domainname()/domainname_list()
* sd-dhcp6-client: fix buffer size calculation in dhcp6_option_parse_ip6addrs()Yu Watanabe2021-09-291-2/+5
| | | | | | | GREEDY_REALLOC() takes number of elements, not buffer size. This also rename dhcp6_option_parse_ip6addrs() to dhcp6_option_parse_addresses().
* sd-dhcp6-client: modernize dhcp6_option_parse_ia()Yu Watanabe2021-09-291-1/+7
| | | | | | | | This makes - the function not update the arguments for storing results on error, - use dhcp6_option_parse() to parse sub options, - ignore all errors, except for -ENOMEM, in parsing sub options, - update log messages.
* sd-dhcp6-client: make dhcp6_option_parse_status() also parse error messageYu Watanabe2021-09-291-1/+1
| | | | | | | This also introduce dhcp6_option_parse_ia_options(). Currently, it is assumed that each IA address or PD prefix may contain a status sub-option. But it is not prohibited that other sub-options or multiple status options are contained.
* sd-dhcp6-client: modernize dhcp6_option_parse()Yu Watanabe2021-09-291-2/+8
| | | | | | | - merge dhcp6_option_parse() with option_parse_hdr(). - do not assign/update any values on error. - use assert() instead of assert_return(), as the assertions cannot be triggered by a library user.
* sd-dhcp6-client: constify one argumentYu Watanabe2021-09-291-1/+1
|
* libsystemd-network: make sd_dhcp_client_get_ifname() or friends return ↵Yu Watanabe2021-09-291-3/+3
| | | | negative errno on error
* sd-dhcp6-client: ignore IAs whose IAID do not match client's IAIDYu Watanabe2021-09-221-1/+1
| | | | | | But do not refuse whole message. Fixes #20803.
* dhcp: do not use ifindex when generating iaid in testsYu Watanabe2021-06-121-0/+4
|
* alloc-util: simplify GREEDY_REALLOC() logic by relying on malloc_usable_size()Lennart Poettering2021-05-191-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | We recently started making more use of malloc_usable_size() and rely on it (see the string_erase() story). Given that we don't really support sytems where malloc_usable_size() cannot be trusted beyond statistics anyway, let's go fully in and rework GREEDY_REALLOC() on top of it: instead of passing around and maintaining the currenly allocated size everywhere, let's just derive it automatically from malloc_usable_size(). I am mostly after this for the simplicity this brings. It also brings minor efficiency improvements I guess, but things become so much nicer to look at if we can avoid these allocation size variables everywhere. Note that the malloc_usable_size() man page says relying on it wasn't "good programming practice", but I think it does this for reasons that don't apply here: the greedy realloc logic specifically doesn't rely on the returned extra size, beyond the fact that it is equal or larger than what was requested. (This commit was supposed to be a quick patch btw, but apparently we use the greedy realloc stuff quite a bit across the codebase, so this ends up touching *a*lot* of code.)
* libsystemd-network: check that errno==0 is not passed to log functionsZbigniew Jędrzejewski-Szmek2021-04-141-2/+5
|
* libsystemd-network: use macro for definitions of log_{lldp,dhcp,…}_errnoZbigniew Jędrzejewski-Szmek2021-04-141-11/+6
| | | | No functional change.
* Check that errno passed log_{interface,link}_*_errno() is non-zeroZbigniew Jędrzejewski-Szmek2021-04-141-1/+1
|
* libsystemd-network: make log_dhcp_client() or friends include interface nameYu Watanabe2021-03-041-9/+19
|
* dhcp6: do not set T1 and T2 by dhcp6_option_append_pd() in clientYu Watanabe2021-02-231-1/+1
| | | | Fixes #18090.
* dhcp6: refuse zero length vendor classYu Watanabe2021-01-131-1/+1
| | | | | Also, fixes the maximum length of the vendor class to UINT16_MAX. Moreover, a memory leak in sd_dhcp6_client_set_request_vendor_class().
* dhcp6: refuse zero length dhcp user classYu Watanabe2021-01-131-1/+1
| | | | | This also fixes a memory leak when sd_dhcp6_client_set_request_user_class() is called multiple times.
* license: LGPL-2.1+ -> LGPL-2.1-or-laterYu Watanabe2020-11-091-1/+1
|
* dhcp6: parse the FQDN optionBeniamino Galvani2020-08-031-2/+3
| | | | | Parse option 39 (Client Fully Qualified Domain Name, RFC 4704) from the DHCP reply, which specifies the FQDN assigned by the server to the client.
* libsystemd-network: rename index -> ifindexYu Watanabe2020-07-021-1/+1
|
* sd-dhcp6: Introduce vendor specific informationSusant Sahani2020-05-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC: 8415 21.17. Vendor-specific Information Option This option is used by clients and servers to exchange vendor- specific information. The format of the Vendor-specific Information option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_OPTS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . vendor-option-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 30: Vendor-specific Information Option Format option-code OPTION_VENDOR_OPTS (17). option-len 4 + length of vendor-option-data field. enterprise-number The vendor's registered Enterprise Number as maintained by IANA [IANA-PEN]. A 4-octet field containing an unsigned integer. vendor-option-data Vendor options, interpreted by vendor-specific code on the clients and servers. A variable-length field (4 octets less than the value in the option-len field). The definition of the information carried in this option is vendor specific. The vendor is indicated in the enterprise-number field. Use of vendor-specific information allows enhanced operation, utilizing additional features in a vendor's DHCP implementation. A DHCP client that does not receive requested vendor-specific information will still configure the node's IPv6 stack to be functional. The vendor-option-data field MUST be encoded as a sequence of code/length/value fields of format identical to the DHCP options (see Section 21.1). The sub-option codes are defined by the vendor identified in the enterprise-number field and are not managed by IANA. Each of the sub-options is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-opt-code | sub-option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-option-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 31: Vendor-specific Options Format sub-opt-code The code for the sub-option. A 2-octet field. sub-option-len An unsigned integer giving the length of the sub-option-data field in this sub-option in octets. A 2-octet field. sub-option-data The data area for the sub-option. The length, in octets, is specified by sub-option-len. Multiple instances of the Vendor-specific Information option may appear in a DHCP message. Each instance of the option is interpreted according to the option codes defined by the vendor identified by the Enterprise Number in that option. Servers and clients MUST NOT send more than one instance of the Vendor-specific Information option with the same Enterprise Number. Each instance of the Vendor-specific Information option MAY contain multiple sub-options. A client that is interested in receiving a Vendor-specific Information option: - MUST specify the Vendor-specific Information option in an Option Request option. - MAY specify an associated Vendor Class option (see Section 21.16). - MAY specify the Vendor-specific Information option with appropriate data. Servers only return the Vendor-specific Information options if specified in Option Request options from clients and: - MAY use the Enterprise Numbers in the associated Vendor Class options to restrict the set of Enterprise Numbers in the Vendor-specific Information options returned. - MAY return all configured Vendor-specific Information options. - MAY use other information in the packet or in its configuration to determine which set of Enterprise Numbers in the Vendor-specific Information options to return.
* sd-network: Rectify Advertise Message Processing by a ClientSusant Sahani2020-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to fix RCC 2215 behaviour with rfc7550 errata and https://tools.ietf.org/html/rfc8415. [RFC3315] specifies that a client must ignore an Advertise message if a server will not assign any addresses to a client, and [RFC3633] specifies that a client must ignore an Advertise message if a server returns the NoPrefixAvail status to a requesting router. Thus, a client requesting both IA_NA and IA_PD, with a server that only offers either addresses or delegated prefixes, is not supported by the current protocol specifications. Solution: a client SHOULD accept Advertise messages, even when not all IA option types are being offered. And, in this case, the client SHOULD include the not offered IA option types in its Request. A client SHOULD only ignore an Advertise message when none of the requested IA options include offered addresses or delegated prefixes. Note that ignored messages MUST still be processed for SOL_MAX_RT and INF_MAX_RT options as specified in [RFC7083]. Replace Section 17.1.3 of RFC 3315: (existing errata) The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message(s) to the user. With the following text (which addresses the existing erratum [Err2471] and includes the changes made by [RFC7083]): The client MUST ignore any Advertise message that contains no addresses (IAADDR options encapsulated in IA_NA or IA_TA options) and no delegated prefixes (IAPREFIX options encapsulated in IA_PD options; see RFC 3633) with the exception that the client: - MUST process an included SOL_MAX_RT option (RFC 7083) and - MUST process an included INF_MAX_RT option (RFC 7083). A client can display any associated status message(s) to the user or activity log. The client ignoring this Advertise message MUST NOT restart the Solicit retransmission timer.
* sd-network: DHCPv6 - Add support to send vendor class dataSusant Sahani2020-05-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ``` 21.16. Vendor Class Option This option is used by a client to identify the vendor that manufactured the hardware on which the client is running. The information contained in the data area of this option is contained in one or more opaque fields that identify details of the hardware configuration. The format of the Vendor Class option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_VENDOR_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | enterprise-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . vendor-class-data . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 28: Vendor Class Option Format option-code OPTION_VENDOR_CLASS (16). option-len 4 + length of vendor-class-data field. enterprise-number The vendor's registered Enterprise Number as maintained by IANA [IANA-PEN]. A 4-octet field containing an unsigned integer. vendor-class-data The hardware configuration of the node on which the client is running. A variable-length field (4 octets less than the value in the option-len field). The vendor-class-data field is composed of a series of separate items, each of which describes some characteristic of the client's hardware configuration. Examples of vendor-class-data instances might include the version of the operating system the client is running or the amount of memory installed on the client. Each instance of vendor-class-data is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | vendor-class-len | opaque-data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ Figure 29: Format of vendor-class-data Field The vendor-class-len field is 2 octets long and specifies the length of the opaque vendor-class-data in network byte order. Servers and clients MUST NOT include more than one instance of OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance of OPTION_VENDOR_CLASS can carry multiple vendor-class-data instances. ```
* sd-network: DHCPv6 - add support to send userclass optionSusant Sahani2020-05-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sd-network: DHCPv6 - add support to send userclass option 21.15. User Class Option The User Class option is used by a client to identify the type or category of users or applications it represents. The format of the User Class option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_USER_CLASS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . user-class-data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26: User Class Option Format option-code OPTION_USER_CLASS (15). option-len Length of user-class-data field. user-class-data The user classes carried by the client. The length, in octets, is specified by option-len. The information contained in the data area of this option is contained in one or more opaque fields that represent the user class or classes of which the client is a member. A server selects configuration information for the client based on the classes identified in this option. For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department. The user class information carried in this option MUST be configurable on the client. The data area of the User Class option MUST contain one or more instances of user-class-data information. Each instance of user-class-data is formatted as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ | user-class-len | opaque-data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ Figure 27: Format of user-class-data Field
* DHCP client: make SendOption work for DHCPv6 too.Andrew Doran2020-05-111-0/+10
|
* network: DHCPv6 client add support for prefix delegation hintSusant Sahani2019-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for prefix hint lenth and prefix hint address ``` Frame 43: 177 bytes on wire (1416 bits), 177 bytes captured (1416 bits) on interface 0 Ethernet II, Src: f6:c1:08:4d:45:f1 (f6:c1:08:4d:45:f1), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02) Internet Protocol Version 6, Src: fe80::d250:c82:7f6e:28d6, Dst: ff02::1:2 User Datagram Protocol, Src Port: 546, Dst Port: 547 DHCPv6 Message type: Solicit (1) Transaction ID: 0x5c7902 Rapid Commit Identity Association for Non-temporary Address Fully Qualified Domain Name Identity Association for Prefix Delegation Option: Identity Association for Prefix Delegation (25) Length: 41 Value: 1b97b1690000000000000000001a0019ffffffffffffffff… IAID: 1b97b169 T1: 0 T2: 0 IA Prefix Option: IA Prefix (26) Length: 25 Value: ffffffffffffffff3c000000000000000000000000000000… Preferred lifetime: infinity Valid lifetime: infinity Prefix length: 60 Prefix address: :: Option Request Client Identifier Elapsed time ```
* tree-wide: use PROJECT_FILE instead of __FILE__Zbigniew Jędrzejewski-Szmek2019-07-041-1/+1
| | | | This replaces the internal uses of __FILE__ with the new macro.
* dhcp6: constify things where we canLennart Poettering2018-10-251-2/+2
|
* dhcp6: check option length before reading valuesYu Watanabe2018-10-031-1/+1
| | | | | Fixes oss-fuzz#10746 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10746.
* dhcp6-client: Store lease timeouts T1 and T1 in client structPatrik Flykt2018-09-191-2/+0
| | | | | | | | | Since we now have the possibility to request prefixes to be delegated without corresponding IPv6 addresses, it does not make sense to store lease T1 and T2 timeouts in the otherwise unused IA_NA structure. Therefore lease timeouts T1 and T2 are moved to the DHCPv6 client structure, as there will be only one set of stateful timeouts required by RFC 7550, Section 4.3.
* tree-wide: use proper unicode © instead of (C) where we canLennart Poettering2018-06-141-1/+1
| | | | | | Let's use a proper unicode copyright symbol where we can, it's prettier. This important patch is very important.
View Lorry Controller Status