IP address spontaneous change

prpr · Feb 16, 2024

One of my boxes crashed yesterday afternoon (or so I thought) i.e. it dropped off network monitoring, so I rebooted it.
This morning it did the same thing but I hadn't rebooted it, and as I was investigating something else, I had cause to add the 192.0.2.0/24 subnet to my router.
I tried pinging and then telnetting to 192.0.2.100 (the default Humax IP address for our boxes) and was amazed to find I connected not to the thing I was trying to investigate but to my "crashed" box which wasn't crashed at all - it had just changed its IP address to the default.
After poking around various log files and my network monitoring & router logs, it seems that this was just spontaneous and nothing to do with DHCP lease renewal (which happened around 3 hours earlier) as I first suspected.
I'm at a bit of a loss as to how this can just happen, but at least I now have another thing to look for when it happens again (this machine seems to "crash" every few days for whatever reason).

@/df any thoughts?

Black Hole · Feb 16, 2024

Wired or wireless? We're aware of it happening on wireless.

prpr · Feb 16, 2024

Wired. Wireless is what I was trying to investigate!

/df · Feb 16, 2024

I think the Humax settop code will try to reset to its built-in default if it thinks the network settings aren't working. Maybe this is just checked at a certain point rather than continually. The assumption has always been that this is a get-out-of-jail feature used by the original devs.

prpr · Feb 19, 2024

Well, it happened again overnight. This time it seems to have rebooted at 3am (I don't know why, and shouldn't be anything to do with tunefix) and again I've found it on the default IP address. Investigation reveals that the udhcpc process isn't running, which would explain it. There isn't a .pid file in /var/lib/humaxtv/ either. Starting it manually immediately loses connection and then I can reconnect on the correct DHCP address.
Incidentally, does anyone know what the "-t 5 -T 10" options do? I can't find any documentation.

/df · Feb 19, 2024

udhcpc is the BusyBox DHCP client (as in "μ DHCP C" - there's a "... D" server too).

man busybox:

Code:

...
udhcpc

    udhcpc [-Cfbnqtvo] [-c CID] [-V VCLS] [-H HOSTNAME] [-i INTERFACE]
    	[-p pidfile] [-r IP] [-s script] [-O dhcp-option]...

            -V,--vendorclass=CLASSID        Vendor class identifier
            -i,--interface=INTERFACE        Interface to use (default eth0)
            -H,-h,--hostname=HOSTNAME       Client hostname
            -c,--clientid=CLIENTID  Client identifier
            -C,--clientid-none      Suppress default client identifier
            -p,--pidfile=file       Create pidfile
            -r,--request=IP         IP address to request
            -s,--script=file        Run file at DHCP events (default /usr/share/udhcpc/default.script)
            -t,--retries=N          Send up to N request packets
            -T,--timeout=N          Try to get a lease for N seconds (default 3)
            -A,--tryagain=N         Wait N seconds (default 20) after failure
            -O,--request-option=OPT Request DHCP option OPT (cumulative)
            -o,--no-default-options Do not request any options (unless -O is also given)
            -f,--foreground Run in foreground
            -b,--background Background if lease is not immediately obtained
            -S,--syslog     Log to syslog too
            -n,--now        Exit with failure if lease is not immediately obtained
            -q,--quit       Quit after obtaining lease
            -R,--release    Release IP on quit
            -a,--arping     Use arping to validate offered address
...

/df · Feb 19, 2024

In the wifi-up script that I massaged, I had this code after supposedly setting the wifi and network params:

Code:

...
# if manual config then
#     apply config
else
	# wait for PHY connection 
	while ! isConnected "$wif"; do
		sleep 2
	done
	eth_check
	echo "$(date -Iseconds -u) DHCP:"
	# file holds PID of $wif's udhcpc
	pidf="/var/lib/humaxtv/udhcpc.$wif.pid"
	# if udhcpc is running for $wif, renew the lease - or launch a new one
	[ -s "$pidf" ] && 
		pid=$(cat "$pidf") && 
		kill -USR1 "$pid" 2>/dev/null ||
		udhcpc -t 5 -T 10 -p "$pidf" -i "$wif" &
	# give some time for above to work before next init routine?
	sleep 7
fi
...

So

sleep loop until connected
get rid of any route via a disconnected Ethernet
ensure the DHCP client is running for the wi-fi interface $wif
let this all pan out ...

prpr · Feb 19, 2024

/df said:
udhcpc is the BusyBox DHCP client

The help screen you gave is the same as the one from the non-CF Humax firmware, which in their 1.03.13 version identifies itself as:
BusyBox v1.12.4 (2021-02-04 14:45:31 KST) multi-call binary

The one in our latest CF just says:

Code:

BusyBox v1.20.2 (2023-04-05 11:24:32 BST) multi-call binary.

Usage: udhcpc [-fbnqvoCRB] [-i IFACE] [-r IP] [-s PROG] [-p PIDFILE]
        [-V VENDOR] [-x OPT:VAL]... [-O OPT]...

and appears somewhat less featured. I wonder if this is a good idea and whether it was deliberate. On the face of it it seems wrong.

prpr · Feb 19, 2024

/df said:
In the wifi-up script that I massaged

Yeah, but this is on the wired box, so that doesn't apply, and even if it does get run it dips out right away with "No wireless dongle detected."

prpr · Feb 19, 2024

prpr said:
Well, it happened again overnight. This time it seems to have rebooted at 3am (I don't know why, and shouldn't be anything to do with tunefix) and again I've found it on the default IP address. Investigation reveals that the udhcpc process isn't running

Having investigated the on-screen menus, this is because it had spontaneously changed its network settings from DHCP to Manual.

MikeSh · Feb 19, 2024

prpr said:
Having investigated the on-screen menus, this is because it had spontaneously changed its network settings from DHCP to Manual.

That's different. Ours used to occasionally flip out from Manual to DHCP, so I left them in the latter and locked the address in at the router end.
(Though TBH I don't know if that only happened when they were on WiFi dongles - I kept them that way even after they went wired.)

/df · Feb 20, 2024

Ah yes, it can happen: who knows why?

It's possible that the help text in the CF BusyBox doesn't match the actual s/w. These strings that appear to include data for option parsing are together in the output of strings /bin/busybox :

Code:

udhcp 1.20.2
O::x::T+:t+:A+:vv
CV:H:h:F:i:np:qRr:s:T:t:SA:O:ox:fBbav
option -h NAME is deprecated, use -x hostname:NAME

/bin/busybox and /mod/bin/busybox/* appear to be different builds of the same BB version, with different build parameters. The 3.14 CF BB is another build but almost a decade newer.

I can't see why it wouldn't be good idea for the CF to bundle the latest BB (1.36.1), or the latest one that works without major issues (especially if the stat command was enabled). There were a lot of udhcpc fixes ca. 1.33/34, it seems. Certainly the installable package, or a parallel one, could be up-to-date. However, I recollect finding myself in a maze of twisty config options, all alike, when trying to do this with an on-box build.

prpr · Feb 20, 2024

/df said:
/bin/busybox and /mod/bin/busybox/* appear to be different builds of the same BB version, with different build parameters.

They are.

The 3.14 CF BB is another build but almost a decade newer.

It is. I added the stat command, as per your request. I think it's identical to the previous CF build apart from that.

I can't see why it wouldn't be good idea for the CF to bundle the latest BB (1.36.1), or the latest one that works without major issues (especially if the stat command was enabled).

Determining which would appear not to be a clear thing then.

There were a lot of udhcpc fixes ca. 1.33/34, it seems. Certainly the installable package, or a parallel one, could be up-to-date.

Sounds like a lot of work a) configuring it, b) building it, c) testing it to make sure nothing obvious gets broken.

However, I recollect finding myself in a maze of twisty config options, all alike, when trying to do this with an on-box build.

Plugh.

/df · Feb 20, 2024

But possibly the same config options that work for 1.20 might get a long way to building the current version. I think it was 1.29 when I last tried but 1.36.1 is the latest stable.

bottletop · Feb 21, 2024

prpr said:
Wired. Wireless is what I was trying to investigate!

I think the network behaviour has changed a little in the last 2 years or so. Not sure if this will help.

On my HDR I have eth0 and wlan0 on same subnet. They have static IP on WebIF network settings. wlan0 is always connected and I occasionally hotplug in eth0 when required (ie after boot up). They worked independently and reliably so I could use either or both IP. I think both showed up on ifconfig (eg even if eth0 wasn't connected). It looks like eth0 is now taken down when unconnected. This has the effect of losing it's static IP so that hotpluging eth0 no longer works. I think now it's defaulting eth0 rather than using the set/configured IP.

Black Hole · Feb 21, 2024

That's curious, because I thought Ethernet took priority over WiFi.

IP address spontaneous change

prpr

Well-Known Member

Black Hole

May contain traces of nut

prpr

Well-Known Member

/df

Well-Known Member

prpr

Well-Known Member

/df

Well-Known Member

/df

Well-Known Member

prpr

Well-Known Member

prpr

Well-Known Member

prpr

Well-Known Member

MikeSh

Well-Known Member

/df

Well-Known Member

prpr

Well-Known Member

/df

Well-Known Member

bottletop

Active Member

Black Hole

May contain traces of nut