d47ce71a89
Using UUID-based client IDs for DHCPv4/DHCPv6 with no option of falling back to hardware IDs (ie. MAC-address or DUID-LL) resp. none at all (IPv4), is causing regressions in some setups. Introduce a new setting to override the preferred client ID to be used for DHCPv4/DHCPv6 on a per-interface basis: network.<ifname>.sendclientid='auto|global|hardware|none' - "auto" (default if empty or not present) uses any explicitly defined client ID, or falls back to the global DUID and finally to the DUID-LL resp. MAC address (ie. identical to before this commit). - "global" uses the global default DUID, if configured, for DHCPv4 and DHCPv6 requests, even if a client ID is explicitly specified for the i/f - "hardware" will not pass a client ID to udhcpc/odhcp6c, even if a global default DUID is configured or an explicit client ID specified, resulting in the i/f MAC address resp. type 3 DUID(-LL) to be used - "none" (IPv4 only) will not add an option tag 61 to DHCPv4 requests at all. Signed-off-by: Shine <4c.fce2@proton.me> Link: https://github.com/openwrt/openwrt/pull/24107 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> |
||
|---|---|---|
| .. | ||
| 6in4 | ||
| 6rd | ||
| 6to4 | ||
| 464xlat | ||
| ds-lite | ||
| map | ||
| odhcp6c | ||
| thc-ipv6 | ||