Skip to content

docs-pbr-1.2.2:Add warning for unknown gateway on device #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
egc112 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs-pbr-1.2.2:Add warning for unknown gateway on device #21

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions pbr/1.2.2/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,6 +103,7 @@
- [Warning: Please set 'dhcp.lan.force=1'](#warning-please-set-dhcplanforce1)
- [Warning: Internal Version Mismatch](#warning-internal-version-mismatch)
- [Warning: Incompatible DHCP Option 6](#warning-incompatible-dhcp-option-6)
- [Warning: Unknown Gateway for device 'XX'](#warning-unknown-gateway-for-device-xx)
- [Thanks](#thanks)


Expand Down Expand Up @@ -1179,6 +1180,12 @@ If you have the matching versions of the `pbr` and `luci-app-pbr` installed you

The `pbr` package now checks for incompatible DHCP Option 6 on start if resolver_set is used.

### Warning: Unknown Gateway for device 'XX'

This usually is a transient warning and related to `WARNING: Uplink/WAN interface is still down, going back to boot mode`.
When an interface is not up there is no gateway, normally PBR will restart if the interface is up and the warning should be gone.
So you can ignore this warning if PBR restarts afterwards and the warning is gone.

## Thanks

I'd like to thank everyone who helped by providing testing and feedback on this service. Without contributions from [@hnyman](https://github.com/hnyman), [@dibdot](https://github.com/dibdot), [@danrl](https://github.com/danrl), [@tohojo](https://github.com/tohojo), [@cybrnook](https://github.com/cybrnook), [@nidstigator](https://github.com/nidstigator), [@AndreBL](https://github.com/AndreBL), [@dz0ny](https://github.com/dz0ny), [@tew42](https://github.com/tew42), [bogorad](https://forum.openwrt.org/u/bogorad), rigorous testing/bugreporting by [@dziny](https://github.com/dziny), [@bluenote73](https://github.com/bluenote73), [@buckaroo](https://github.com/pgera), [@Alexander-r](https://github.com/Alexander-r), [@n8v8R](https://github.com/n8v8R), [psherman](https://forum.openwrt.org/u/psherman), [@Vale-max](https://github.com/Vale-max), [@aliicex](https://github.com/aliicex), [dscpl](https://forum.openwrt.org/u/dscpl), [pesa1234](https://forum.openwrt.org/u/pesa1234) and multiple contributions from [@egc112](https://github.com/egc112), [@bigsmile74](https://github.com/bigsmile74), [@dl12345](https://github.com/dl12345) and [trendy](https://forum.openwrt.org/u/trendy) and feedback from other OpenWrt users it wouldn't have been possible. WireGuard/IPv6 support is courtesy of [IVPN](https://www.ivpn.net/).
Expand Down