Bug #9270
closed
"Remove all states to and from the filtered address" does not remove all states
Added by Yuri Weinstein almost 6 years ago. Updated over 3 years ago.
0%
Description
Simple use case:
Filter all states for an IP of any device (used my iPhone IP) in "Diagnostics"/"States"/"States"
Click on `Kill States` button
At this point it is expected that all states would be killed, but in fact not all states were killed.
Updated by Jim Pingle almost 6 years ago
- Target version set to 48
- Affected Version set to 2.4.x
- Affected Architecture All added
- Affected Architecture deleted (
)
There does seem to be an issue here, looks like it's in the pfSense module function pfSense_kill_states(). Sometimes it works, most of the time it doesn't.
Also if you enter an address or subnet in the filter box using a CIDR mask, such as 198.51.100.6/32, when you click the Kill button the / in the input field is replaced by an odd character of some kind (�, hex 0xFFFD, UTF-8 Hex EF BF BD). If I comment out the calls to pfSense_kill_states() that character remains correct.
Updated by Yuri Weinstein almost 5 years ago
Is this fix part of current development snapshot ?
Updated by Jim Pingle almost 5 years ago
It is still in a "new" state, so no, it has not yet been addressed.
Updated by Yuri Weinstein over 4 years ago
@jim This is very annoying bug and makes troubleshooting more difficult. Any chance to address it in the next point release?
Updated by Anonymous about 4 years ago
- Assignee changed from Jim Pingle to Luiz Souza
Updated by Anonymous about 4 years ago
- Assignee changed from Luiz Souza to Renato Botelho
Updated by Renato Botelho almost 4 years ago
Jim Pingle wrote:
There does seem to be an issue here, looks like it's in the pfSense module function
pfSense_kill_states(). Sometimes it works, most of the time it doesn't.Also if you enter an address or subnet in the filter box using a CIDR mask, such as
198.51.100.6/32, when you click the Kill button the/in the input field is replaced by an odd character of some kind (�, hex 0xFFFD, UTF-8 Hex EF BF BD). If I comment out the calls topfSense_kill_states()that character remains correct.
I've collected $_POST value before and after pfSense_kill_states() is called and it really modifies it. Still investigating why such thing could happen.
Array
(
[__csrf_magic] => sid:cdd036935bce2fdb1b1e5f7a290dabe4c18afb8a,1606411806
[interface] => all
[xfilter] => 172.21.4.175/32
[killfilter] => Kill States
)
Array
(
[__csrf_magic] => sid:cdd036935bce2fdb1b1e5f7a290dabe4c18afb8a,1606411806
[interface] => all
[xfilter] => 172.21.4.17532
[killfilter] => Kill States
)
Updated by Renato Botelho almost 4 years ago
- Status changed from New to In Progress
Updated by Renato Botelho almost 4 years ago
Just complementing the experiments I did today:
adding utf8_encode() to pfSense_kill_states() parameter fix the issue that affects $_POST. Now I'm concerned what else can be wrong on other calls to pfSense_* functions
Updated by Renato Botelho almost 4 years ago
- Status changed from In Progress to Feedback
Can you please give next round of snapshots a try and see if the workaround I committed help?
Updated by Jim Pingle almost 4 years ago
- Status changed from Feedback to Resolved
Looks OK now. I no longer get the unexpected character in the field, and the states are killed as expected.
Thanks!
Updated by Yuri Weinstein over 3 years ago
looks great in 2.5.0 thanks a million !
Updated by Yuri Weinstein over 3 years ago
Not sure if this should be added as a new issue
Assume you have an external IP XXX
And an OpenVPN net 192.168.200.0/0
After OpenVPN client connects it gets an IP 192.168.200.2
Now let's use States to see and kill all states for 192.168.200.2
There are lots of states look like this:
WAN tcp XXX:49313 (192.168.200.2:62472) -> <some_IP>:443 TIME_WAIT:TIME_WAIT 84 / 108 6 KiB / 129 KiB
And they don't get killed.
Expected - all states associated with 192.168.200.2 killed, or there is an option to select all and allow kill.
@Jim Pingle @Renato Botelho - what do you think ?
Updated by Jim Pingle over 3 years ago
That's a different problem since it's a NAT address and not the final source or destination. Unrelated to this. I'm not sure if pfctl supports killing states by that address.
Check for an existing issue, if there isn't one, open a new one for that.