Display will show a previous IPv4 address if an address was assigned from a previous connection

[apalrd]

Steps:

• Plug device into network which provides DHCPv4
• Wait for DHCPv4 to assign address and for it to display on screen
• Disconnect from network
• Plug device into a link which will not provide DHCPv4
• As Link is up, IP address page is shown, however, as IPv4 address is now blank, previous IPv4 address is shown when it is not actually assigned.

kvm/display.go

Line 37 in 6e2177e

updateLabelIfChanged("ui_Home_Content_Ip", networkState.IPv4)

seems to be the bug. IPv4 is a blank string, updateLabelIfChanged does not write new blank string, and string is not reset back to "..." after network connection is lost.

[Nevexo]

The bigger problem here is the system doesn't refresh it's IP addresses when the link comes back up.

udhcpc is always running, but doesn't refresh the lease when the interface state changes. I guess we could kill & invoke udhcpc -i eth0 when the linkstate changes? But that seems like a bit of a hack, it might be something @adamshiervani can alter in the Buildroot config to make DHCP refresh leases when the interface comes up.

My tree has a commit that has the KVM remove it's IPv4 addresses when the link goes down, but as they're not put back by DHCP, that just renders it inaccessible. Nevexo@5f093cb (hence why the commit has the IPv6 address removal commented out, so I could keep a shell open to it!)

[eric]

It doesn't seem required to kill and reinvoke udhcpc :

From the README:

signals accepted by udhcpc

udhcpc also responds to SIGUSR1 and SIGUSR2. SIGUSR1 will force a renew state,
and SIGUSR2 will force a release of the current lease, and cause udhcpc to
go into an inactive state (until it is killed, or receives a SIGUSR1). You do
not need to sleep between sending signals, as signals received are processed
sequencially in the order they are received.

[Nevexo]

It doesn't seem required to kill and reinvoke udhcpc :

From the README:

signals accepted by udhcpc

---

udhcpc also responds to SIGUSR1 and SIGUSR2. SIGUSR1 will force a renew state,

and SIGUSR2 will force a release of the current lease, and cause udhcpc to

go into an inactive state (until it is killed, or receives a SIGUSR1). You do

not need to sleep between sending signals, as signals received are processed

sequencially in the order they are received.

Oh interesting - thanks for pointing that out - I'll have a go at implementing that tomorrow and see if it helps any.

[Nevexo]

@apalrd I have a built binary on https://github.com/Nevexo/kvm/releases/tag/jetkvm-nevexo-ipv4-fix-test-1 that implements my potential fix for this issue, there's a bit of discussion going on around removing old IP addresses in #16 that I'd appreciate your input on if you get a moment.