Live view filtering - Is this normal?

[verasense]

I am trying to remove a host from the Live View display. I have set host != IP but it is still showing up.

Is this a bug or am I doing something wrong?

[verasense]

Also... I captured packets for two VLANs and the WAN, and the one in the WAN is named incorrectly as:

packetcapture_igb0_vlan20.cap

This seems like a (minor) bug to me.

[gpb]

Looks like the filter bug is reported here.

https://github.com/opnsense/core/issues/4988

[Sheldon]

I am trying to remove a host from the Live View display. I have set host != IP but it is still showing up.

Is this a bug or am I doing something wrong?

This doesn't look like a software bug to me. Written in words, i see your configuration like this:

Display only packets which match rule 1.
Rule 1: Does {at least one of: src, dst} not contain {10.10.10.50}?

Your packets (with red underlined src) match rule 1, because their dst does not contain "10.10.10.50".

You might feel this software behavior doesn't make sense. But to me it makes sense, because the implementation of both filter aspects ("src,dst" and "does not contain") seems correct. You might feel the "src,dst" should be implemented as "and" and not "or". But i think the "or" is necessary to be able to filter packets which have a given host as dst or src.

If you want to see only packets which have a given host neither as src nor as dst, you probably need to create 2 rules, one for src and one for dst.

[Sheldon]

Also... I captured packets for two VLANs and the WAN, and the one in the WAN is named incorrectly as:

packetcapture_igb0_vlan20.cap

This seems like a (minor) bug to me.

If this is related to the live view filtering, i don't see how this is related. If this is not related, it would be "misleading" and deserves its own thread.

[verasense]

This doesn't look like a software bug to me. Written in words, i see your configuration like this:

Display only packets which match rule 1.
Rule 1: Does {at least one of: src, dst} not contain {10.10.10.50}?

Your packets (with red underlined src) match rule 1, because their dst does not contain "10.10.10.50".

You might feel this software behavior doesn't make sense. But to me it makes sense, because the implementation of both filter aspects ("src,dst" and "does not contain") seems correct. You might feel the "src,dst" should be implemented as "and" and not "or". But i think the "or" is necessary to be able to filter packets which have a given host as dst or src.

If you want to see only packets which have a given host neither as src nor as dst, you probably need to create 2 rules, one for src and one for dst.

I see... I think you are right. This sounds to me like the != behaviour on Wireshark. But in this case, it is very confusing to give the option "host does not contain X.X.X.X" because it will never do anything.

And you are right about your 2nd comment, it should have been in a new thread. Just seemed quite small to create a new thread and this thread was ignored for a long time, now it's not.

[Sheldon]

But in this case, it is very confusing to give the option "host does not contain X.X.X.X" because it will never do anything.

The option is not limited to "host does not contain X.X.X.X", but is more general "host does not contain <text>". That text doesn't have to be a complete IP address, it can be just a part of an address. Filtering "host does not contain X.X.X." can be useful to include or exclude communication within a /24 subnet.

These example packets

Code: [Select]

src=192.168.1.91 port=12345 ---> dst=192.168.1.1 port=80
src=192.168.1.92 port=12345 ---> dst=192.168.1.1 port=443
src=192.168.1.93 port=12345 ---> dst=192.168.1.2 port=53
src=192.168.1.94 port=12345 ---> dst=192.168.1.3 port=465
could be all matched by a single rule "host does not contain 192.168.1.". So i think this is a useful option.