[How to] If your Yellow stops responding

[Viking]

How to force activate IPv4 binding to the HA Yellow Ethernet port
when “no IPv4 /no HA UI” is available/accessible and the Yellow does not respond to IPv4 ping.

Prerequisites

• Client: Windows 10/11

• Shell: Windows PowerShell (a.k.a. Terminal) — open via Start → “PowerShell”

• Windows PC is connected over Wi-Fi on the same LAN (not a guest/isolated SSID)

1. Prove the Yellow is up (IPv6 link-local ping from Windows)

• Find your Wi-Fi interface index:

netsh interface ipv6 show interfaces

Sample output:

Idx Met MTU State Name

11 45 1500 connected Wi-Fi

• Find the Yellow’s IPv6 link-local (fe80::…):
  • Option A: read it in your router’s device list (match the MAC on the Yellow).
  • Option B (discover from Windows):

ping -6 ff02::1%11

netsh interface ipv6 show neighbors interface=11

Sample line to match (same MAC as Yellow):

fe80::xxxx:yyyy:zzzz:aa40 e4-5f-zz-yy-zz-04 Reachable

• Ping the Yellow with zone index:

ping -6 fe80::xxxx:yyyy:zzzz:aa40%11

Sample success output:

Reply from fe80::xxxx:yyyy:zzzz:aa40%11: time=2ms

Why (objective): IPv4 is down; use IPv6 link-local as a side door to reach the OS so that IPv4 can be restored/forced.
Why (logic): Linux/HAOS automatically assigns an IPv6 link-local (fe80::/64) as soon as the NIC/driver are up-no router/DHCPv6 needed. This is generic Linux behavior (applies to HAOS), and not Yellow-specific. It does not require HA to be functional. A successful ICMPv6 (ping) reply proves the kernel, driver, and L2 link are alive even if IPv4/HA UI are not.
If you do not get an IPv6 reply at all, then either you made a typo somewhere in the address or the command syntax, or your Yellow isn’t attempting to load any core code at all.
But observe that browsers usually won’t open fe80::…%zone URLs; this step is for liveness and CLI access only.

Assuming you could successfully ping the IPv6 address on your Yellow box, then you are in a good position to continue from step #2. If the Ping failed, try to power cycle the Yellow again and make sure to observe the LED flash pattern according to the HA Yellow docs and give it a few minutes to get up and running.

Assuming you successfully could ping the IPv6 address, then:

2. Enable host-OS SSH (one-time) — get your id_rsa.pub, put it on a USB stick.

• Check if you already have id_rsa.pub on your Windows client:

If you see id_rsa.pub, print it (copy the entire single line):

type $HOME\\.ssh\\id\_rsa.pub

• If you don’t have a key yet, create one (RSA to produce id_rsa.pub):

ssh-keygen -t rsa -b 3072 -C "HA Yellow"

type $HOME\\.ssh\\id\_rsa.pub

(Alternatively, modern key: ssh-keygen -t ed25519 -C "HA Yellow" → then use id\_ed25519.pub instead.)

• Prepare the USB:
  • Format FAT32, label it CONFIG (all caps).
  • At the root, create a file named authorized_keys and paste the single-line public key into that file. OBS; no extra CR/LF or anything else.
  • Insert the USB stick into the Yellow, and power it on.

Why: This enables host SSH on IPv6 port 22222, giving console access without any UI.

3. SSH into HAOS (host) over IPv6

ssh -p 22222 root@\[fe80::xxxx:yyyy:zzzz:aa40%11\]

Why: Use the ha CLI to repair IPv4 even when the UI/IPv4 are down.

4. Inspect network state

ha network info

Sample (what you might see before fixing IPv4):

interfaces:
- connected: true
  enabled: true
  interface: end0
  ipv4:
    address: []
    gateway: null
    method: auto
    nameservers: []
    ready: false
  ipv6:
    address:
    - fe80::xxxx:yyyy:zzzz:aa40/64
    method: disabled
    ready: true

mac: E4:5F:XX:YY:ZZ:04

type: ethernet

Note the wired interface name (e.g., end0) and that IPv4 is not ready.
Why: Identifies the NIC to configure and confirms IPv4 isn’t active.

5. Set a static IPv4

ha network update end0 --ipv4-method static --ipv4-address 192.168.1.xx/24 --ipv4-gateway 192.168.1.1 --ipv4-nameserver 192.168.1.1

All on one line. Then verify:

ha network info

Why: Guarantees the Yellow always comes up at 192.168.1.XX (or whatever IPv4 address you prefer) on every boot, independent of DHCP.

6. Test from Windows (using your IP address)

ping 192.168.1.XX

Then try to open in your browser:

http://192.168.1.XX:8123

Why: Confirms IPv4 reachability and the HA UI can be accessed.

If ping succeeds but the HA UI still won’t load:

Check if port 8123 is listening:

powershell -NoProfile -Command "Test-NetConnection -ComputerName 192.168.1.XX -Port 8123"

Expected when OK:

TcpTestSucceeded : True

If TcpTestSucceeded = True (service listening, page still not loading), then try:

ssh -p 22222 root@\[fe80::xxxx:yyyy:zzzz:aa40%11\] "ha core logs --tail 100"

ssh -p 22222 root@\[fe80::xxxx:yyyy:zzzz:aa40%11\] "ha core restart"

ssh -p 22222 root@\[fe80::xxxx:yyyy:zzzz:aa40%11\] "ha supervisor logs --tail 100"

If TcpTestSucceeded = False (Core not listening) try:

ssh -p 22222 root@\[fe80::xxxx:yyyy:zzzz:aa40%11\] "ha core start"

ssh -p 22222 root@\[fe80::xxxx:yyyy:zzzz:aa40%11\] "ha core logs --tail 200"

Last resort (clean system reboot if all else fails and you still have SSH access):

ssh -p 22222 root@\[fe80::xxxx:yyyy:zzzz:aa40%11\] "ha host reboot"

Why: Ping proves host reachability; the port test shows if HA Core is accepting connections. Logs/restart recover Core; a clean host reboot is the safe final step (avoid power pulls).

7. Prevent future IP conflicts (router)

Do one:

• Move the DHCP pool start to e.g. .25 (or higher), or
• Add an exclusion/reservation for 192.168.1.XX

Why: Ensures the router never leases .20 to any other device.

Observe that your Yellow OS is now modified to ignore your DHCP server.
When we ran:

ha network update end0 --ipv4-method static --ipv4-address 192.168.1.XX/24 --ipv4-gateway 192.168.1.1 --ipv4-nameserver 192.168.1.1

we told HAOS/NetworkManager to stop running DHCPv4 on end0 and to always configure 192.168.1.XX with the specified gateway/DNS at boot. So:

• It does not contact your DHCP server for an address or options.
• It will still do normal ARP/ND on the LAN, but no DHCP negotiation.
• Your router’s DHCP pool/reservations won’t affect the Yellow’s IP anymore.
• Upside: deterministic address every time.
• Requirement: ensure the DHCP pool excludes .20 (or set a router reservation/exclusion) to avoid conflicts.

If you ever/later wish to reverse/undo everything, here’s the clean, reversible way to put IPv4 back on DHCP for your Yellow (HAOS), using only the host-SSH + ha CLI.

1. SSH to the Yellow (host SSH over IPv6)

ssh -p 22222 root@\[fe80::YOUR:LL:ADDR%IFINDEX\]

2. Switch the wired NIC back to DHCPv4

• Replace end0 with your interface name if different (check with ha network info).

ha network update end0 --ipv4-method auto

3. (Optional) Re-enable IPv6 auto if you had disabled it earlier

ha network update end0 --ipv6-method auto

4. Verify the change & confirm a lease arrived

ha network info

You should see, under end0 → ipv4:

• method: auto

• address: 192.168.1.x/24 (assigned by your router)

• ready: true

5. If no IPv4 shows up after ~60–90s, bounce the connection

ha network reload

ha network info

(If still no lease, check your router’s DHCP pool and any reservations/exclusions; ensure .20 (or whatever you use) isn’t reserved for someone else.)

6. Adjust your router so DHCP can assign an address

• If you previously shrank the DHCP pool or excluded .20, either:

  • Restore the original pool range, or
  • Keep a reservation for the Yellow’s MAC to a specific DHCP IP you want it to get every time.

7. (Optional) Clean reboot to confirm everything is persistent

ha host reboot

That’s it - after this, the Yellow will acquire IPv4 from DHCP automatically on every boot, as before.

This may of course fail if your original problem still exists.

[WallyR (Wally)]

I did not read the entire guide, but there are some issues in the beginning.
First is that most cheap consumer routers do not handle IPv6 that well in the GUI, so that option might be impossible by many.
The backup method have a interface id in the address and that is machine specific, so you need to explain how to find the correct interface id on another generic machine.
Using the network is, ie. ff02 or fe80 is not possible, because those networks IDs exist on all the interfaces even though they are not the same network.

[Viking]

Hi, and thanks for your comments and feedback.
You don’t need a “good IPv6 router GUI” to use the IPv6 method. It works fine on most networks because it relies on IPv6 link-local (fe80::/64), which is auto-assigned by every modern OS/NIC, and it needs no DHCPv6, no router config, no internet, and it stays entirely on the local L2 network (it never crosses subnets).
Link-local addresses are brought up by the host and NIC driver, not the router. Even if a cheap router has IPv6 disabled on the WAN or does a poor job in its GUI, hosts will still have fe80:: addresses on the LAN.
I only used the router as a convenient place to read the MAC→IPv6 mapping. If your router’s UI doesn’t show that, you can discover the Yellow from Windows directly (no router UI needed).

Regarding machine specific interface ID, this is local to the client you’re using, not the Yellow. So on any machine you use, you must find that machine’s LAN interface name/index and use it in the IPv6 link-local address.

Using the network ID is absolutely possible. This is exactly what the zone/scope ID (%…) is for. fe80::/64 (link-local) and ff02::/16 (link-local multicast) exist on every NIC. They’re meant to be reused per link because they’re link-scoped (not routed). You only have to say which link to use. The %<zone> suffix disambiguates. So it’s not “impossible” — you just have to include the zone.

[WallyR (Wally)]

I know IPv6.
The cheap routers delivered offered by many ISPs have GUIs that sadly do not.
They might work with IPv6, but no IPv6;settings and/or information are available in the GUI.

[WallyR (Wally)]

@Viking

Regarding machine specific interface ID, this is local to the client you’re using, not the Yellow. So on any machine you use, you must find that machine’s LAN interface name/index and use it in the IPv6 link-local address.

My point exactly.
You need to know explain that part in your guide.

[WallyR (Wally)]

@Viking

This is exactly what the zone/scope ID (%…)

That % indicate an interface id.
And if you have multiple NICs, then th y will all have a FE80 address and a different interface id.
The guide need to tell the user how to find the right one.

You are are thinking as a technical mind, but the people needing this guide is not at your level. They need things explained carefully.
The ones at your level can figure it out without the guide.

[Viking]

On Windows, when we talk about the %… part of a link-local IPv6 address, the “zone/scope ID” to be used is the interface index (the Idx you see in netsh). People casually say “ID,” but the precise thing Windows wants is the numeric interface index.
Using netsh interface ipv6 show gives you that index (ID is not the right term) no matter how many NICs you may have.

Please forgive me if I fail to understand the point you’re trying to make.

[LiQuid_cOOled]

@Viking

Please forgive me if I fail to understand the point you’re trying to make.

From your posted guide, I’d consider your level of understanding robust so Wally’s posts should be pretty clear.

The info you are providing appears to be well intended, but your guide is assuming that every HA user has an in-depth technical experience with networking, HA and Windows.

[Viking]

Yeah, I guess you’re right about that. Nobody’s perfect. I still decided to post - in case it would help some…

[LiQuid_cOOled]

It’s valuable info for sure!