stangri/source.openwrt.melmac.net

[pbr] Issue: Routes are not re-added, after the interface's physical device being removed and re-added

imKnect opened this issue · 6 comments

Describe the bug
Routes are not re-added, after the interface's physical device is removed and re-added

My Environment

  1. Newly installed Openwrt 21.02.1 x86_64 official release
  2. Newly installed pbr and luci-app-pbr, Strict enforcement set false

To Reproduce
Steps to reproduce the behavior:

  1. Add a tun device (named utun), add a interface (name CLASH) binding that tun device (utun):

image

  1. Add policy in pbr, Strict enforcement set false and check the routes:

image
image

Routes (remember the red one):

image

  1. Run ip tuntap del utun mode tun to delete the utun, the iface CLASH down and pbr correctly change the the interface in policy to WAN

image
image

The route of utun disappeared

image

  1. Now run ip tuntap add utun mode tun to re-add utun, the iface CLASH up, and the pbr change the the interface in policy back to CLASH:

image

BUT the route of utun is still missing:

image

and the log can't provide any information.

Expected behavior
The routes should be added back after the tun dev being removed-and-re-add.

Now I am trying to modify the file /etc/hotplug.d/iface/70-pbr, changing the reload_interface to restart as a workaround, but the modify seams not work, the file:
image
the system log:
image

By the way, the buttons like Enable ,Start and Stop do not work at all, I have to enable and start pbr through cli.

h2qrv-kqcbu.gif

I hope this could be solved or is found to be my problem. Thanks for your attention.

Thank you for your feedback. While pbr has nothing to do with the interface's default routes (and this issue needs to be addressed elsewhere), I could reproduce WebUI buttons not working and I'll look into it.

Thank you for your feedback. While pbr has nothing to do with the interface's default routes (and this issue needs to be addressed elsewhere), I could reproduce WebUI buttons not working and I'll look into it.

I'm not good at networking, but the missing route is surely created by pbr cause it's in the table CLASH (which is also create by pbr).
Or there is something I don't understand happend?

Thank you for your feedback. While pbr has nothing to do with the interface's default routes (and this issue needs to be addressed elsewhere), I could reproduce WebUI buttons not working and I'll look into it.

I'm not good at networking, but the missing route is surely created by pbr cause it's in the table CLASH (which is also create by pbr). Or there is something I don't understand happend?

Oh, you're absolutely right. I'm not sure if there's a trigger in OpenWrt for adding a new device. I'll need to sleep on it to think how best to address this scenario.

Buttons have been fixed in 0.9.4.-10.

Buttons have been fixed in 0.9.4.-10.

Thanks for your work!

I'm not good at networking, but the missing route is surely created by pbr cause it's in the table CLASH (which is also create by pbr). Or there is something I don't understand happend?

Oh, you're absolutely right. I'm not sure if there's a trigger in OpenWrt for adding a new device. I'll need to sleep on it to think how best to address this scenario.

image
Actually in this situation (manully binded the tun device to a interface), the disappearance and addition of tun device is related to the trigger of the interface up&down. So I think a little improvement to the interface hotplug script might do the trick.

But in my reproduction process, the interface hotplug script seems not working (edited output but doesn't show up in syslog).

I believe a while ago I've changed the reload to restart as the pbr command in the hotplug script and this should be resolved then. If it isn't please reopen this, I'm sorry it took me so long to respond.