Error "XHR request timed out" when loading luci-app-pbr

It was working fine until I added a couple of more rules.
Now I have to reboot every time I want to load the page. Updates: reboots no longer work either. The issue is there after reboot.

Here is the content of /etc/config/pbr:


config pbr 'config'
	option verbosity '2'
	option strict_enforcement '1'
	option ipv6_enabled '0'
	list ignored_interface 'vpnserver'
	list ignored_interface 'wgserver'
	option boot_timeout '30'
	option rule_create_option 'add'
	option procd_reload_delay '1'
	option webui_show_ignore_target '0'
	list webui_supported_protocol 'all'
	list webui_supported_protocol 'tcp'
	list webui_supported_protocol 'udp'
	list webui_supported_protocol 'tcp udp'
	list webui_supported_protocol 'icmp'
	option enabled '1'
	list supported_interface 'ovpn'
	option resolver_set 'dnsmasq.ipset'

config include
	option path '/usr/share/pbr/pbr.user.aws'
	option enabled '0'

config include
	option path '/usr/share/pbr/pbr.user.netflix'
	option enabled '0'

config policy
	option name 'Plex/Emby Local Server'
	option interface 'wan'
	option src_port '8096 8920 32400'
	option enabled '0'

config policy
	option name 'Plex/Emby Remote Servers'
	option interface 'wan'
	option dest_addr 'plex.tv my.plexapp.com emby.media app.emby.media tv.emby.media'
	option enabled '0'

config policy
	option name 'telegram'
	option interface 'ovpn'
	option dest_addr '149.154.160.0/22 149.154.160.0/23  149.154.162.0/23 	 149.154.164.0/22 	 149.154.164.0/23 	 149.154.166.0/23 	 91.108.4.0/22 	 91.108.56.0/22 	 91.108.8.0/22 	 95.161.64.0/20 	 91.105.192.0/23 91.108.4.0/22 91.108.8.0/22 91.108.12.0/22 91.108.16.0/22 91.108.20.0/22 91.108.56.0/23 91.108.58.0/23 95.161.64.0/20 149.154.160.0/21 149.154.168.0/22 149.154.172.0/22 185.76.151.0/24 172.217.16.170 149.154.175.53 149.154.167.92 149.154.164.250 149.154.167.223 91.108.4.193 91.108.56.195 t.me telesco.pe tg.dev telegram.me telegram.org 149.154.167.99 91.105.192.0/23 91.108.4.0/22 91.108.8.0/21 91.108.16.0/21 91.108.56.0/22 '

config policy
	option name 'Reddit '
	option proto 'tcp'
	option dest_addr 'redd.it     redditblog.com     reddit.com     redditinc.com     redditmail.com     redditmedia.com        redditstatus.com'
	option interface 'ovpn'

config policy
	option name 'YouTube '
	option interface 'ovpn'
	option dest_addr '199.223.232.0/21 207.223.160.0/20 208.65.152.0/22 208.117.224.0/19 209.85.128.0/17 216.58.192.0/19 216.239.32.0/19 172.217.135.6 m.youtube.com i.ytimg.com redirector.googlevideo.com googlevideo.com youtu.be youtube-nocookie.com youtube.be youtube.co.uk youtube.com youtube.de youtube.fr youtube.googleapis.com youtube.nl youtube.pl youtubeeducation.com youtubegaming.com youtubei.googleapis.com youtubekids.com yt3.ggpht.com'

config policy
	option interface 'ovpn'
	option name 'fb'
	option dest_addr '163.70.128.174 54.83.80.98 31.13.85.52 157.240.14.63 157.240.208.174 163.70.128.174 54.83.80.98 31.13.85.52 157.240.14.63 157.240.208.174 31.13.24.0/21 31.13.64.0/18 45.64.40.0/22 57.144.0.0/14 66.111.48.0/22 66.220.144.0/20 69.63.176.0/20 69.171.224.0/19 74.119.76.0/22 102.132.96.0/19 102.221.188.0/22 103.4.96.0/22 129.134.0.0/16 147.75.208.0/20 157.240.0.0/16 163.70.128.0/17 163.77.128.0/17 163.114.128.0/20 164.163.191.64/26 173.252.64.0/18 179.60.192.0/22 185.60.216.0/22 185.89.216.0/22 199.201.64.0/22 204.15.20.0/22 157.240.201.34 mqtt-mini.facebook.com wa.me     whatsappbrand.com     whatsapp.cc     whatsapp.com     whatsapp.info     whatsapp.net       whatsapp-plus.info     whatsapp-plus.me     whatsapp-plus.net     whatsapp.tv 66.111.48.0/22 ig.me instagram.com i.instagram.com graph.instagram.com scontent-lga3-1.cdninstagram.com z-p42-chat-e2ee-ig.facebook.com i-fallback.instagram.com 
graph.facebook.com web.facebook.com gateway.instagram.com  whatsapp.com whatsapp.net api.facebook.com fb.com fb.me gateway.facebook.com lithium.facebook.com lookaside.facebook.com m.facebook.com facebook.com'

config policy
	option name 'wa'
	option interface 'ovpn'
	option dest_addr '157.240.0.63 157.240.14.53 e1.whatsapp.net whatsapp.net g.whatsapp.net'

config policy
	option dest_port '443'
	option proto 'tcp'
	option interface 'ovpn'
	option name 'sites'
	option dest_addr 'x.com twitter.com bbc.com bbcpersian.com bbc.co.uk ichef.bbci.co.uk bbci.co.uk emp.bbci.co.uk static.files.bbci.co.uk firebaseremoteconfig.googleapis.com'

config policy
	option name 'twitter'
	option interface 'ovpn'
	option dest_addr 'api.twitter.com abs.twimg.com pbs.twimg.com caps.twitter.com video.twimg.com  api-stream.twitter.com probe.twitter.com twimg.com 104.244.42.66 ads-twitter.com periscope.tv pscp.tv t.co tweetdeck.com twimg.com twitpic.com twitter.co twitter.com twitterinc.com twitteroauth.com twitterstat.us twttr.com 104.244.47.0/24 188.64.224.0/21 192.133.76.0/22 199.16.156.0/22 192.133.77.0/26 64.63.15.0/24 64.63.31.0/24 64.63.47.0/24 202.160.128.0/24 202.160.129.0/24'

config policy
	option name 'playstore'
	option dest_addr 'play-fe.googleapis.com play.googleapis.com play.google.com play-lh.googleusercontent.com'
	option interface 'ovpn'


Which device?
Which version ?
What does dmesg say ?

Hi it's a Xiaomi Mi Router 4A Gigabit Edition.
OpenWrt 22.03.5 r20134-5f15225c1e / LuCI openwrt-22.03 branch git-23.119.80898-65ef406
PBR v1.1.1-7

This is what I'm getting when running dmesg:

dmesg | grep pbr
[   84.484909] do_page_fault(): sending SIGSEGV to S94pbr for invalid read access from 77d6f1e6

@stangri Appreciate if you have a look.

This looks severe. The program in question is a shell script which should not produce invalid memory accesses like that. Is it possible that the hardware is faulty or the power supply unstable?

Whell I don't think so since everything is working. Even PBR policies are being enforces. I just can't load the luci page for this service. Other luci modules work with no issues.

Can you make RPCD calls from CLI? What's the output of:

ubus -v list luci.pbr
ubus -S call luci.pbr getInitList '{"name": "pbr" }'
ubus -S call luci.pbr getInitStatus '{"name": "pbr" }'
ubus -S call luci.pbr getPlatformSupport '{"name": "pbr" }'
ubus -S call luci.pbr getGateways '{"name": "pbr" }'
ubus -S call luci.pbr getInterfaces '{"name": "pbr" }'
root@OpenWrt:~# ubus -v list luci.pbr
'luci.pbr' @10e9bd4d
        "getGateways":{"name":"String"}
        "getInitList":{"name":"String"}
        "getInitStatus":{"name":"String"}
        "getInterfaces":{"name":"String"}
        "getPlatformSupport":{"name":"String"}
        "setInitAction":{"name":"String","action":"String"}

root@OpenWrt:~# ubus -S call luci.pbr getInitList '{"name": "pbr" }'
{"pbr":{"enabled":true,"running":true}}

root@OpenWrt:~# ubus -S call luci.pbr getInitStatus '{"name": "pbr" }'
root@OpenWrt:~# ubus -S call luci.pbr getPlatformSupport '{"name": "pbr" }'
{"pbr":{"ipset_installed":true,"nft_installed":true,"adguardhome_installed":false,"dnsmasq_installed":true,"unbound_installed":false,"adguardhome_ipset_support":false,"dnsmasq_ipset_support":true,"dnsmasq_nftset_support":false}}
root@OpenWrt:~# ubus -S call luci.pbr getGateways '{"name": "pbr" }'
{"pbr":{"gateways":[{"name":"wan","device_ipv4":"wan","gateway_ipv4":"192.168.0.254","device_ipv6":"wan","gateway_ipv6":"","default":false,"action":"create","table_id":"258","mark":"0x010000","priority":"30000"},{"name":"ovpn","device_ipv4":"tun0","gateway_ipv4":"10.8.0.2","device_ipv6":"tun0","gateway_ipv6":"fddd:1194:1194:1194::2/64","default":false,"action":"create","table_id":"259","mark":"0x020000","priority":"30001"}]}}
root@OpenWrt:~# ubus -S call luci.pbr getInterfaces '{"name": "pbr" }'
{"pbr":{"interfaces":["wan","ovpn"]}}

If rpcd calls fine I don't have an idea what might be causing the luci error.

Did you install pbr or pbr-iptables?

Only pbr.
pbr-iptables is not listalled

Also I see this in the logs:

daemon.notice procd: /etc/rc.d/S94pbr: # Warning: iptables-legacy tables present, use iptables-legacy to see them

Yeah, since 22.03 moved to fw4 which is based on nft, that's an expected warning.

I remember reading that there were two options for using iptables on 22.03, one translated iptables calls to nft and the other actually used iptables calls (as far as I recollect), but I don't remember which was called what and which one is better.

Maybe the dmesg error and the luci error are related to that.

1 Like

Ok when I disabled the "twitter" rule set it was fixed and the web ui was loaded.

I've added your twitter policy to my config (pbr 1.1.3-2 tho) and can't reproduce your luci error.

Not using the PBR package, but could the problem be some sites are listed in several policies ?