For me (21.02.1), I get a new WAN IP with either a reboot, or running ifup wan.
On 19.0x (before a reboot alone would get a new WAN IP) I ran this...
killall -SIGUSR2 udhcpc
reboot
Ironic that some have been complaining about getting a new WAN IP on reboot with 21.02.1.
Doing that does not result in what one needs.
Clicking the WAN restart button in the interfaces screen does force a DHCP release and DHCP request.
Here is the log (started immediately before hitting that button):
root@OpenWrt:~# logread -f
Tue Jan 11 16:16:40 2022 daemon.notice netifd: wan (1768): udhcpc: received SIGTERM
Tue Jan 11 16:16:40 2022 daemon.notice netifd: wan (1768): udhcpc: unicasting a release of 10.0.1.226 to 10.0.1.1
Tue Jan 11 16:16:40 2022 daemon.notice netifd: wan (1768): udhcpc: sending release
Tue Jan 11 16:16:40 2022 daemon.notice netifd: wan (1768): udhcpc: entering released state
Tue Jan 11 16:16:40 2022 daemon.notice netifd: wan (1768): Command failed: Permission denied
Tue Jan 11 16:16:40 2022 daemon.notice netifd: Interface 'wan' is now down
Tue Jan 11 16:16:40 2022 daemon.notice netifd: Interface 'wan' is setting up now
Tue Jan 11 16:16:40 2022 daemon.warn dnsmasq[2211]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Tue Jan 11 16:16:41 2022 daemon.notice netifd: wan (2745): udhcpc: started, v1.33.1
Tue Jan 11 16:16:41 2022 daemon.notice netifd: wan (2745): udhcpc: sending discover
Tue Jan 11 16:16:42 2022 daemon.notice netifd: wan (2745): udhcpc: sending select for 10.0.1.226
Tue Jan 11 16:16:42 2022 daemon.notice netifd: wan (2745): udhcpc: lease of 10.0.1.226 obtained, lease time 86400
Tue Jan 11 16:16:43 2022 daemon.notice netifd: Interface 'wan' is now up
Tue Jan 11 16:16:43 2022 daemon.info dnsmasq[2211]: reading /tmp/resolv.conf.d/resolv.conf.auto
Tue Jan 11 16:16:43 2022 daemon.info dnsmasq[2211]: using only locally-known addresses for domain test
Tue Jan 11 16:16:43 2022 daemon.info dnsmasq[2211]: using only locally-known addresses for domain onion
Tue Jan 11 16:16:43 2022 daemon.info dnsmasq[2211]: using only locally-known addresses for domain localhost
Tue Jan 11 16:16:43 2022 daemon.info dnsmasq[2211]: using only locally-known addresses for domain local
Tue Jan 11 16:16:43 2022 daemon.info dnsmasq[2211]: using only locally-known addresses for domain invalid
Tue Jan 11 16:16:43 2022 daemon.info dnsmasq[2211]: using only locally-known addresses for domain bind
Tue Jan 11 16:16:43 2022 daemon.info dnsmasq[2211]: using only locally-known addresses for domain lan
Tue Jan 11 16:16:43 2022 daemon.info dnsmasq[2211]: using nameserver 10.0.1.1#53
Tue Jan 11 16:16:43 2022 user.notice firewall: Reloading firewall due to ifup of wan (eth0.1)
It is worth noting that the DHCP server will very likely issue the same IP again, but that is a function of how that DHCP server is configured and operating.
It doesn't work for me to do that. In the TP-link firmware, the IP can be rejected and it is renewed by pressing the corresponding button. In OpenWrt just restart the interface. I doubt it is a problem from the ISP's DHCP server.
Let’s see the logs as they appear when you hit the restart interface button in openwrt.
Tue Jan 11 16:35:47 2022 daemon.notice netifd: wan (2908): udhcpc: received SIGTERM
Tue Jan 11 16:35:47 2022 daemon.notice netifd: wan (2908): udhcpc: unicasting a release of 24.232.82.67 to 172.20.2.226
Tue Jan 11 16:35:47 2022 daemon.notice netifd: wan (2908): udhcpc: sending release
Tue Jan 11 16:35:47 2022 daemon.notice netifd: wan (2908): udhcpc: entering released state
Tue Jan 11 16:35:48 2022 daemon.notice netifd: wan (2908): Command failed: Permission denied
Tue Jan 11 16:35:48 2022 daemon.notice netifd: Interface 'wan' is now down
Tue Jan 11 16:35:48 2022 daemon.info avahi-daemon[2192]: Withdrawing address record for 24.232.82.67 on eth1.
Tue Jan 11 16:35:48 2022 daemon.info avahi-daemon[2192]: Leaving mDNS multicast group on interface eth1.IPv4 with address 24.232.82.67.
Tue Jan 11 16:35:48 2022 daemon.info avahi-daemon[2192]: Interface eth1.IPv4 no longer relevant for mDNS.
Tue Jan 11 16:35:48 2022 kern.info kernel: [80314.669822] eth1: link down
Tue Jan 11 16:35:48 2022 daemon.notice netifd: Interface 'wan' is disabled
Tue Jan 11 16:35:48 2022 daemon.notice netifd: Interface 'wan' is enabled
Tue Jan 11 16:35:48 2022 daemon.notice netifd: Interface 'wan' is setting up now
Tue Jan 11 16:35:48 2022 daemon.warn dnsmasq[1]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Tue Jan 11 16:35:48 2022 daemon.notice netifd: Network device 'eth1' link is down
Tue Jan 11 16:35:48 2022 daemon.notice netifd: Interface 'wan' has link connectivity loss
Tue Jan 11 16:35:48 2022 daemon.notice netifd: Interface 'wan' is now down
Tue Jan 11 16:35:48 2022 daemon.notice netifd: Interface 'wan' is disabled
Tue Jan 11 16:35:48 2022 daemon.notice netifd: Interface 'wan' is enabled
Tue Jan 11 16:35:50 2022 daemon.notice netifd: Network device 'eth1' link is up
Tue Jan 11 16:35:50 2022 daemon.notice netifd: Interface 'wan' has link connectivity
Tue Jan 11 16:35:50 2022 daemon.notice netifd: Interface 'wan' is setting up now
Tue Jan 11 16:35:50 2022 kern.info kernel: [80316.993807] eth1: link up (100Mbps/Full duplex)
Tue Jan 11 16:35:50 2022 daemon.notice netifd: wan (8378): udhcpc: started, v1.34.1
Tue Jan 11 16:35:50 2022 daemon.notice netifd: wan (8378): udhcpc: broadcasting discover
Tue Jan 11 16:35:50 2022 daemon.notice netifd: wan (8378): udhcpc: broadcasting select for 24.232.82.67, server 172.20.2.226
Tue Jan 11 16:35:50 2022 daemon.notice netifd: wan (8378): udhcpc: lease of 24.232.82.67 obtained from 172.20.2.226, lease time 600
The system is doing exactly what it is supposed to do. It is releasing the DHCP lease, taking down the WAN, then bringing it back up again and requesting a DHCP lease again. I've highlighted the DHCP related log items.
Keep in mind that you don't have control over the DHCP server -- it will issue whatever address it decides. Your system can theoretically refuse to accept an offer, but I don't think that happens in most cases.
So why using the original firmware is the IP renewed with the same upstream connection?
I don't understand your question... what do you mean "IP renewed' in this case?
I mean to always get a new public IP when I press the button "Release" (or synonym because I don't remember) and then "Renew" (the same, I don't remember the exact word).
The only possible difference is how the DHCP client behaves with respect to one aspect of the release and request process, but I'd have to look into this to see if it is really a "thing" that can happen.
Here is what I am thinking...
In a DHCP lease renewal, the client asks the server if it can renew the existing lease (keeping the same IP). The server can then approve or decline that request.
In a normal initial DHCP lease acquisition, there is a DORA process (Discover, Offer, Request, Accept). If the client is saying "hey, can I have this specific address" it is possible that the server is allowing that to happen. But I don't recall if this is possible except during renewals.
What does it have to do? If I had a new MAC on every reboot, I would even more have to have a new IP. Still I have tried changing the MAC on eth1 so I can get a new IP.
To be honest, I have no idea.