I used today Action Jump to a Chain. I had to put an second Return just beneath the Jump line to not process also the rest of the lines, when the custom Chain was filtered.
Feature request is like as in Connection Marking an Router Marking, to add a box in Action to stop processing of the rest of the filter lines. You can then tick the box Passthrough and processing is ready for that whole page if filtering of the lines below the jump is not necessary.
Re: [Feature request] Passthrough select box on Jump Action
Can you post an example, what didn't work for you as expected, and how the second return saved it? Maybe I'm little slow right now (well, it's quite late here), but I don't understand the description.
Re: [Feature request] Passthrough select box on Jump Action
Code: Select all
add action=jump chain=prerouting jump-target=UDP-target protocol=udp
add action=return chain=prerouting log-prefix=UDP-target protocol=udp
.
.
add action=accept chain=UDP-target comment=WireShark/Winpap disabled=yes dst-address=192.168.88.99 dst-port=37008 protocol=udp
.
.
add action=return chain=UDP-target protocol=udpThe last return makes no difference if it is present or not, I think because it is the last line in the /IP firewall RAW
You do not have the required permissions to view the files attached to this post.
Re: [Feature request] Passthrough select box on Jump Action [SOLVED]
Well, what you should note is that while it is called "jump" it really does a "call". When the jumped chain does a return, processing continues below the jump.
When you don't want that, you can make sure the jumped chain does not return but rather ends in a terminating action (Accept, Drop, Reject). Then it will not
come back below the jump action.
When you don't want that, you can make sure the jumped chain does not return but rather ends in a terminating action (Accept, Drop, Reject). Then it will not
come back below the jump action.
Re: [Feature request] Passthrough select box on Jump Action
Thanks pe1chl that was the solution to my problem to have an extra RETRUN needed to stop UDP traffic travelling on.
The traffic that was the most prominent was port 20561 so when I was using winbox in MAC config.
This still leaves the request for adding the Passthrough checkbox active because it could be useful if you want a not a watertight filtering because that is done in filter pages after that. MASQ/NAT/Filtering
The traffic that was the most prominent was port 20561 so when I was using winbox in MAC config.
This still leaves the request for adding the Passthrough checkbox active because it could be useful if you want a not a watertight filtering because that is done in filter pages after that. MASQ/NAT/Filtering
Re: [Feature request] Passthrough select box on Jump Action
I'm not convinced.
Return on end of subchain is useless, because it's already implicit action, it would happen anyway.
Return in top-level chain (prerouting, ...) is equivalent to accept.
If you don't want to return from subchain, just add accept/drop/reject as the last unconditional rule to subchain. And unlike your passthrough option, this gives you a choice, what should happen with packet.
Return on end of subchain is useless, because it's already implicit action, it would happen anyway.
Return in top-level chain (prerouting, ...) is equivalent to accept.
If you don't want to return from subchain, just add accept/drop/reject as the last unconditional rule to subchain. And unlike your passthrough option, this gives you a choice, what should happen with packet.
Re: [Feature request] Passthrough select box on Jump Action
That is right, this is how it works and it already has all capabilities. I normally end each subtable with a drop or accept rule so there
is no return, that is also more obvious for new admins as the "jump" name is counter to what really happens ("call")
is no return, that is also more obvious for new admins as the "jump" name is counter to what really happens ("call")
Re: [Feature request] Passthrough select box on Jump Action
It's obvious by itself:
Code: Select all
>---other_chain--- oops, end of chain!
| |
jump fall down
| |
---main_chain---^ >---main_chain_continues---Re: [Feature request] Passthrough select box on Jump Action
Maybe it is because I did programming long ago in assembler, where JUMP typically means "go to a different address in the program" and CALL means "save the current
address on the stack, go to a different address, run the program there until you hit a RETURN instruction, which means get the address off te stack and go there".
This CALL/RETURN is just like what the JUMP does in iptables ("call a subroutine")
Re: [Feature request] Passthrough select box on Jump Action
I think that I know the function of RETURN and to me it looked to have the same working of ACCEPT but that is not the case.
Maybe it is because I did programming long ago in assembler, where JUMP typically means "go to a different address in the program" and CALL means "save the current
address on the stack, go to a different address, run the program there until you hit a RETURN instruction, which means get the address off te stack and go there".
This CALL/RETURN is just like what the JUMP does in iptables ("call a subroutine")
RETURN can be use to steer inside a JUMP and stop processing the rest of the sub-CHAIN.
Code: Select all
.
JUMP to sub-CHAIN
.
RETURN specific match (further processing in MASQ/NAT/FILTER page) (same function here as ACCEPT)
.
sub-CHAIN
.
RETURN (return where the jump started and process the lines underneath the JUMP till reaching sub-CHAIN)
.
.
sub-CHAIN end - returns to the jump from which it was calledCode: Select all
.
.
JUMP to sub-CHAIN
.
.
sub-CHAIN
.
ACCEPT specific match (does not return where the jump started and goes to MASQ/NAT/FILTER page)
.
.
sub-CHAIN end - returns to the jump from which it was calledRe: [Feature request] Passthrough select box on Jump Action
I wrote above:
"ACCEPT specific match (does not return where the jump started and goes to MASQ/NAT/FILTER page)"
however after some more expediences it appears to be:
ACCEPT specific match (does not return where the jump started and goes NOT to MASQ/NAT/FILTER page)
Am I correct with this last experience?
"ACCEPT specific match (does not return where the jump started and goes to MASQ/NAT/FILTER page)"
however after some more expediences it appears to be:
ACCEPT specific match (does not return where the jump started and goes NOT to MASQ/NAT/FILTER page)
Am I correct with this last experience?
Re: [Feature request] Passthrough select box on Jump Action
The original wording seems correct to me.Am I correct with this last experience?
The scope of validity of the
Code: Select all
acceptCode: Select all
acceptCode: Select all
preroutingCode: Select all
mangleCode: Select all
preroutingCode: Select all
dstnatCode: Select all
natCode: Select all
dstnatCode: Select all
natCode: Select all
srcnatCode: Select all
natCode: Select all
dropLet me remind you this picture.