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> |
||
|---|---|---|
| .. | ||
| firewall | ||
| firewall4 | ||
| gre | ||
| ipip | ||
| ltq-adsl-app | ||
| ltq-vdsl-vr9-app | ||
| ltq-vdsl-vr11-app | ||
| netifd | ||
| qos-scripts | ||
| qosify | ||
| soloscli | ||
| swconfig | ||
| vti | ||
| vxlan | ||
| wifi-scripts | ||
| xfrm | ||