omr-bypass doesn't work in omr v0.60rc1 #3192
Comments
|
You have a problem in your configuration. Can you put the result of |
|
ok I found the bug. For now you can manually change the metric for each interface in Network->Interfaces and edit interfaces. |
Unfortunately not. Changing only metric for the interface doesn't work as restarting omr-bypass restores some how long metrics in /etc/config/network and long values for marks in /etc/config/firewall |
|
You need also to lower metric in LAN. |
|
Also I've found that /etc/firewall.omr-bypass file that script generates also looks strange. it puts the same 0x00004539 mark to traffic for all interfaces and does it twice. I think it is a mistake. Probably it should put different marks for ipv4 and ipv6 traffic specific for every interface |
|
Mark use the MTU value that is set automatically and should be different for each interface. Here it's like if MTU is empty. I think it's same problem as previous bug. |
You, probably, mean metric, not mtu? |
|
yes sorry, metric |
|
When are you plannig to make a commit with a fix of this bug? May be you can share the fix here in advance? |
|
It's already commited. |
|
Where can I find it? |
|
You need to put https://github.com/Ysurac/openmptcprouter-feeds/raw/develop/mptcp/files/etc/init.d/mptcp as /etc/init.d/mptcp and do a chmod u+x /etc/init.d/mptcp and "/etc/init.d/mptcp restart" |
|
It's getting better now, but still there is a problem with /etc/firewall.omr-bypass. After deleting it and rebooting the system it still looks like this: mark values are the same for all cases |
|
And not only this. After /etc/init.d/omr-bypass restart restart all rules with mark target in /etc/config/firewall are diasabled like this: I have to enable them manually. And netxt time omr-bypass is restared they are disabled again |
|
Rules are disabled when not used. |
|
Rebooted |
|
bypass rules are not working without manual intervention |
|
What do you have in |
|
Here it is: |
|
You should have rules |
|
in /etc/firewall.omr-bypass I need With this correction traffic from lan to 1.1.1.2 goes via right interface. However traffic from omr itself still doesn't go right way. For this some extra rules are required in /etc/firewall.omr-bypass Also adding other types of rules in omr-bypass, for example Ports source rules doesn't enable correspondent firewall rule in /etc/config/firewall. I have to put option enabled '1' for this rule manually |
|
I've just checked /etc/init.d/omr-bypass and found inconsistency in naming with /etc/config/firewall. In /etc/config/firewall there are separate rules for ipv4 and ipv6 For example there is such a rule: while in /etc/init.d/omr-bypass there is no such separation in correspendent code: this piece of code will try to setup and enable omr_dst_bypass_eth2_dstport_tcp rule which does't exist. To be consistent with firewall rules it should look like this (btw this specific example is messing up dest and src, which is, probably, copy/paste bug) : Or, we can go opposit direction and rules in /etc/config/firewall shouldn't be separated by ipv4 and ipv6 to be consistent with /etc/init.d/omr-bypass. This way, probably, is more easy to implement as omr-bypass luci interface doesn't have ipv4/ipv6 selectors in most bypass rules |
|
Where can I get the fix? |
|
Ok, I managed to build image from the developer branch with the latest commits and found out that you made substantial changes to omr-bypass logic. Now I see the correct rules in nft tables and bypassed traffic goes via right routes. Will see how it works in more complex configurations |
|
Still not all the problems are resolved. When I added another interfaces eth4 and eth5 for bypassing it got the same metric for them as for the previous one. And traffic rules messed up. now my rules look like this: omr-bypass config looks like this: As you can see there are many interfaces with id=1 in omr-bypass config file. And strange thing there is no reference to eth4 in ip rules |
|
What is the result of |
|
It's here: |
|
I would also need |
|
Here they are: |
|
I also noticed, that if I delete an interface, for example wan3 and then add a new one using settings wizard, the script will assign a next number to it. In my example it will be wan4. wan3 will never be assigned again. It would be better if the script fills the gaps in numbering |
|
I made omr configuration from the ground up. A new version of mptcp commited yesterday generates another, but still wrong id for the interfaces listed in omr-bypass: |
|
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days |
Expected Behavior
I expect that omr-bypass works
When I put anything in omr-bypass settings I expect the script to generate correct rules to bypass
Current Behavior
Script generates rules for the firewall that can not be executed
I see these messages in firewal log:
values generated for set_xmark and set_mark are too long
Possible Solution
Make shorter the values generated by scripts for expressions in firewall with set_xmark and set_mark statements
Steps to Reproduce the Problem
Context (Environment)
Different routes for different cases
Specifications
The text was updated successfully, but these errors were encountered: