Suggestion: Customizing the Bootloader IP config

[flowjob1]

Hey, first I want to thank you for committing yourself and your time to working on this, I really appreciate that!

I am using this Zigbee Gateway via a VPN-ed FritzBox via Zigbee2MQTT for a small Zigbee Network (4 devices). And it works!
But re-flashing is hard because of the hardcoded bootloader IP-Address. With the limited FritzBox subnet routing, just giving my linux machine an IP-Adress in the 192.168.1.0/24 subnet is not working unfortunately.

So I thought, we already build everything from scratch, so:

Would it be possible to make the bootloader IP configurable, maybe during the "build_fullflash" workflow?
And are there any other ways to make the bootloader netowrking more robust?

What do you think?

[jnilo1]

Hi @flowjob1 Glad the gateway is working for you over the FritzBox VPN!

Good idea — the bootloader's TFTP IP is hardcoded in two lines and making it configurable is genuinely easy. There are two ways to do it, but I don't have bandwidth to implement either right now, so let me give you enough detail to try option 1 yourself — it's a 5-line patch and you have everything you need locally.

Option 1 — change the bootloader IP (build-time, what I'd recommend you try)

The TFTP server / client IPs are set in one function:

3-Main-SoC-Realtek-RTL8196E/31-Bootloader/boot/net/tftpd.c, lines 664–665:

arptable_tftp[TFTP_SERVER].ipaddr.s_addr = IPTOUL(192, 168, 1, 6);
arptable_tftp[TFTP_CLIENT].ipaddr.s_addr = IPTOUL(192, 162, 1, 116);

(Yes, the second one is 192.162.x — long-standing typo in the original Realtek code, harmless because the client IP is overwritten from the ARP request anyway, but worth fixing while you're there.)

Pick a server IP for the gateway in bootloader mode and a client IP for your host PC, both in the same subnet that your VPN can route. Then:

1. Patch the two lines with your chosen IPs.
2. Build the bootloader:

   cd 3-Main-SoC-Realtek-RTL8196E/31-Bootloader
   ./build_bootloader.sh

   This produces boot.bin.
3. Build the fullflash image (or just rebuild the bootloader partition if you prefer):

   cd <repo-root>
   ./build_fullflash.sh

4. Flash via SSH (your existing Linux path — no TFTP involved at this step):

   ./flash_install_rtl8196e.sh -y <gateway-Linux-IP>

   This installs the new bootloader (along with kernel/rootfs/userdata if you used build_fullflash.sh) using the existing SSH + boothold flow, which doesn't depend on the bootloader IP at all.
5. From now on, when you need to TFTP-flash from the bootloader prompt, set your host PC's IP to the client IP you chose above, and the gateway will respond at the server IP. flash_install_rtl8196e.sh already accepts BOOT_IP=<your-server-ip> on the host side — no change needed there.

The one constraint: your host PC and the gateway-in-bootloader-mode have to be on the same L2 segment for ARP to resolve, since the bootloader has no DHCP and no routing. As long as your VPN gives you an IP in the chosen subnet, you're fine.

If it works for you, a PR turning the two literal IPs into env-var-driven -D defines on build_bootloader.sh would be very welcome — I'd ship that with the next release.

Option 2 — runtime IP via boothold (cleaner, future)

For reference, the cleaner long-term design is to extend boothold to write a small struct ({magic, server_ip, client_ip, netmask}) into the reserved-memory no-map page at 0x01FFE000 (4 KiB available, only 4 bytes used today), and have a V2.6+ bootloader read it at startup. You'd then pick the IP from Linux with boothold --ip 10.0.0.6 && reboot, no rebuild. Requires a bootloader version bump and backward-compat handling, so I'd only do it if a few more people hit this. Mentioning it for completeness — try option 1 first.

Let us know how it goes!

[flowjob1]

Thank you very much for that detailed walkthrough! I will try that next time I install a new release and will report back! Am Di., 5. Mai 2026 um 14:33 Uhr schrieb jnilo1 ***@***.***>:

…

Hi @flowjob1 <https://github.com/flowjob1> Glad the gateway is working for you over the FritzBox VPN! Good idea — the bootloader's TFTP IP is hardcoded in two lines and making it configurable is genuinely easy. There are two ways to do it, but I don't have bandwidth to implement either right now, so let me give you enough detail to try option 1 yourself — it's a 5-line patch and you have everything you need locally. Option 1 — change the bootloader IP (build-time, what I'd recommend you try) The TFTP server / client IPs are set in one function: 3-Main-SoC-Realtek-RTL8196E/31-Bootloader/boot/net/tftpd.c, lines 664–665: arptable_tftp[TFTP_SERVER].ipaddr.s_addr = IPTOUL(192, 168, 1, 6);arptable_tftp[TFTP_CLIENT].ipaddr.s_addr = IPTOUL(192, 162, 1, 116); (Yes, the second one is 192.162.x — long-standing typo in the original Realtek code, harmless because the client IP is overwritten from the ARP request anyway, but worth fixing while you're there.) Pick a server IP for the *gateway in bootloader mode* and a client IP for *your host PC*, both in the same subnet that your VPN can route. Then: 1. *Patch the two lines* with your chosen IPs. 2. *Build the bootloader*: cd 3-Main-SoC-Realtek-RTL8196E/31-Bootloader ./build_bootloader.sh This produces boot.bin. 3. *Build the fullflash image* (or just rebuild the bootloader partition if you prefer): cd <repo-root> ./build_fullflash.sh 4. *Flash via SSH* (your existing Linux path — no TFTP involved at this step): ./flash_install_rtl8196e.sh -y <gateway-Linux-IP> This installs the new bootloader (along with kernel/rootfs/userdata if you used build_fullflash.sh) using the existing SSH + boothold flow, which doesn't depend on the bootloader IP at all. 5. *From now on*, when you need to TFTP-flash from the bootloader prompt, set your host PC's IP to the *client* IP you chose above, and the gateway will respond at the *server* IP. flash_install_rtl8196e.sh already accepts BOOT_IP=<your-server-ip> on the host side — no change needed there. The one constraint: your host PC and the gateway-in-bootloader-mode have to be on the same L2 segment for ARP to resolve, since the bootloader has no DHCP and no routing. As long as your VPN gives you an IP in the chosen subnet, you're fine. If it works for you, a PR turning the two literal IPs into env-var-driven -D defines on build_bootloader.sh would be very welcome — I'd ship that with the next release. Option 2 — runtime IP via boothold (cleaner, future) For reference, the cleaner long-term design is to extend boothold to write a small struct ({magic, server_ip, client_ip, netmask}) into the reserved-memory no-map page at 0x01FFE000 (4 KiB available, only 4 bytes used today), and have a V2.6+ bootloader read it at startup. You'd then pick the IP from Linux with boothold --ip 10.0.0.6 && reboot, no rebuild. Requires a bootloader version bump and backward-compat handling, so I'd only do it if a few more people hit this. Mentioning it for completeness — try option 1 first. Let us know how it goes! — Reply to this email directly, view it on GitHub <#97 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDJDRSJX7DY5YROGDE5F6BT4ZHNQLAVCNFSM6AAAAACYQ2KC42VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMOBRGYYDKMY> . You are receiving this because you were mentioned.Message ID: <jnilo1/hacking-lidl-silvercrest-gateway/repo-discussions/97/comments/16816053 @github.com>