oce(4) promiscous mode bug(?)

[Sergey Akhmatov]

On 17/06/2015 18:04, elof2 at sentor.se wrote:
>
> It sounds like a promisc bug in the driver, just as you say, but just 
> to test it some more:
>
>
> I see that you are running both in PPROMISC and PROMISC.
>
> What happen if you remove the PPROMISC and only let tcpdump set it's own
> PROMISC?
I've tried both. Without monitor mode, and without ppromisc

>
> Running in monitor mode is the correct way to sniff traffic. But just 
> to rule out errors in the oce driver, what happen if you do not run in 
> monitor mode?
>
>
> Do 'netstat -in' show the same input errors as your sysctl counter?
>
> (I assume you're running tcpdump with no bpf filter at all)
No errors, Input packets counter counts only broadcast packets. As I 
wrote before, I see errors for unicast packets in sysctl counter:
dev.oce.0.stats.rx.err.address_match_errors: 124171960
>
> What do a couple of 'netstat -B' say while tcpdump is running?
>
# netstat -B
   Pid  Netif   Flags      Recv      Drop     Match Sblen Hblen Command
62679   oce0 p--s---         2         0         2     0     0 tcpdump

No drops. Doesn't seem the problem is BPF related.

I've tried investigating further: promisc mode is enabled by actually 
reconfiguring hardware filter via "oce_set_common_iface_rx_filter" 
function in the driver.
Maybe I'll be able to find difference with working Linux driver.