keep forwarding during interface reload

[brauliobo]

Summary

This avoids disabling forwarding for on_interface_reload starts.

Full service starts, reloads, and restarts keep the existing stop_forward / enable_forward behavior. Only targeted interface reloads skip the forwarding toggle.

Motivation

On a router with several IPv6 WANs, normal RA/DHCPv6 refreshes can trigger frequent interface.* events. In my case, wan_str6 advertises short public IPv6 and prefix lifetimes of roughly 3-5 minutes, and wan_vivo6 has an RA default route lifetime around 3 minutes.

Those events cause repeated PBR on_interface_reload runs. Because the init wrapper disables forwarding before calling the ucode start logic, each targeted interface reload briefly interrupts LAN forwarding. The user-visible symptom was streaming traffic, especially YouTube, playing for a while, freezing for tens of seconds, then resuming, repeatedly.

The selected policy path was healthy: YouTube was routed through wan_tim, not the noisy wan_str6 path. The interruption correlated with repeated PBR interface reloads rather than WAN packet loss.

Router observations

Environment where reproduced:

• OpenWrt 25.12.x
• nft/fw4 mode
• PBR with IPv6 enabled
• Multiple WAN interfaces: wan_vivo, wan_tim, wan_str, plus IPv6 peers
• YouTube policy targets wan_tim
• Frequent Processing environment (on_interface_reload) logs from IPv6 RA/DHCPv6 refreshes

Examples from the router:

pbr ... Processing environment (on_interface_reload) ... wan_vivo6 ... wan_str6 ... wan_tim6 ...

ubus monitor showed network.interface notify_proto updates for IPv6 interfaces such as wan_vivo6 and wan_str6 shortly before PBR reloads.

wan_tim was stable during testing:

120 packets transmitted, 120 packets received, 0% packet loss
round-trip min/avg/max = 26.868/27.270/27.895 ms

Validation

I tested the same logic on the affected router before opening this PR.

Validation performed:

• Deployed equivalent runtime change to /etc/init.d/pbr
• Ran ash -n /etc/init.d/pbr
• Triggered /etc/init.d/pbr on_interface_reload wan_str6
• Confirmed /proc/sys/net/ipv4/ip_forward stayed 1
• Monitored natural IPv6-triggered PBR interface reloads for 90 seconds
• Confirmed ip_forward stayed 1 throughout repeated on_interface_reload events
• Verified YouTube policy routing still selected wan_tim for IPv4 and IPv6
• Verified a YouTube probe over tim-wan returned HTTP 204

Representative route checks after the change:

142.250.219.46 via 192.168.1.1 dev tim-wan table pbr_wan_tim src 192.168.1.2 mark 0x40000
2804:214:800f:68::9 via fe80::1 dev tim-wan table pbr_wan_tim

Notes

This is intentionally minimal. The init wrapper currently disables forwarding before the ucode start logic resolves whether a reload remains a targeted on_interface_reload or falls back to a full start. This patch uses the init command parameter as the guard, so the common targeted interface-reload path avoids the forwarding interruption while full reload/restart paths remain unchanged.

If you prefer the guard to use the resolved ucode service_start_trigger, I can follow up with a slightly larger refactor where ucode exposes that decision before the forwarding toggle.

[stangri]

Hello @brauliobo, thank you for contribution.

A few things I'd like to point out:

• you can disable forwarding manipulations thru a pbr option
• @egc112 has recently patched 1.2.2 tree to prevent ghost wan6 reloads, which is the source of the issue here

@egc112 -- let me know when you're done with 1.2.2 patches so I can task copilot/claude to reimplement them in the ucode (1.2.3) version. If the ghost wan6 reloads fix doesn't resolve the situation @brauliobo, we can revisit this PR.

[egc112]

Yes Stan, please go ahead

I know several people have tested 1.2.2-r18 which has these fixes and did not encounter problems.

So push the fixes to the Openwrt main repo for further testing.

[egc112]

@brauliobo thanks for your contribution

PBR acts on a procd trigger (e.g. up down, update etc .)
When an interface e.g goes down and you are using metrics a higher metric interface can take over resulting in a leak which you prevent with haven strict enforcement enabled.
So there is a real use case for disabling Forwarding to prevent leaks which should be kept intact.

Of course if you do not want it you can simply disable strict enforcement
See the read.me : https://docs.mossdef.org/pbr/1.2.2/#strict-enforcement

However we identified a case where the wan6 interface was triggered but a reloading was not necessary at all.

We already implemented fixes for that, you can test it see: see: https://forum.openwrt.org/t/policy-based-routing-pbr-package-discussion/140639/2850

Please test and let us know if that fixes your problem, please also report in the 9PBR discussion thread](https://forum.openwrt.org/t/policy-based-routing-pbr-package-discussion/140639/2850)