Strange behavior. I have a FC12 OS installed on a Dell PE1850. I am setting up a snort/tcpdump sniffer interface on eth1. This is typically a very simple process - but I ran into something really funky.

When I a generic tcpdump or snort dump on eth1, I see all the traffic I expect to see. I see dst 80, dst 443, dst 445 etc. However, as soon as I specify any BPF filters, it only shows applicable "src" traffic. (Ie I see a.a.a.a -> b.b.b.b:80, but none of the return - only the outbound.) If I remove the filter, its there again, all the bidirectional traffic. The same things applies when running the snort command. I can see both directions on a basic snort dump - but once I apply any BPF filters, I see either only source or nothing at all. My BPF syntax is correct.

For example:

I run standard snort -v -i eth1 (no filters), I see tons of a.a.a.a b.b.b.b.80, bi directional.

But if I add a filter for destination port 80, I *should* see all of the outbound traffic, without the return. So if run tcpdump -nn -i eth1 dst port 80... I see nothing. Even though the generic command showed that plenty existed. Its not just port definitions that cause the problem. If I were to specify "src net a.a.a.0/24", I receive nothing. But without that filter - I can see for sure that traffic exists and should be captured in the filter. But here is where it gets strange. If I specify a "non-directional" type filter, such as "host a.a.a.a" (without any source or destination specifications) I *receive* results – but *only* in one direction (or not at all). Remove the filter and that host is there bi-directionally. Bah!

its almost as if the direction aspect of the NIC is not being understood by the kernel as the BPF filters would expect it?

Any ideas?

Thanks.
Matt

BTW - quick addition - the same bug does *not* exist on the management interface. Only the monitor interface, which I believe might be different onboard hardware.