On Fri, Jan 15, 2021 at 2:16 PM Eric Dumazet wrote:
[snip]
> > My wild guess is that as soon as socket got created:
> > socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
> > the packets were already queued to it.
> > So later setsockopt() is too late to filter.
> >
> > Eric, thoughts?
>
> Exactly,
On Fri, Jan 15, 2021 at 7:52 AM Alexei Starovoitov
wrote:
>
> Adding appropriate mailing list to cc...
>
> My wild guess is that as soon as socket got created:
> socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
> the packets were already queued to it.
> So later setsockopt() is too late to filter.
Adding appropriate mailing list to cc...
My wild guess is that as soon as socket got created:
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
the packets were already queued to it.
So later setsockopt() is too late to filter.
Eric, thoughts?
On Wed, Jan 6, 2021 at 6:55 AM Tom Cook wrote:
>
>
Another factoid to add to this: I captured all traffic on an
interface while the test program was running using
tcpdump -i wlo1 -w capture.pcap
observing that multiple packets got through the filter. I then built
the bpf_dbg program from the kernel source tree and ran the same
filter and
Just to note I have also reproduced this on a 5.10.0 kernel.
On Tue, Jan 5, 2021 at 1:42 PM Tom Cook wrote:
>
> In the course of tracking down a defect in some existing software,
> I've found the failure demonstrated by the short program below.
> Essentially, a cBPF program that just rejects
In the course of tracking down a defect in some existing software,
I've found the failure demonstrated by the short program below.
Essentially, a cBPF program that just rejects every frame (ie always
returns zero) and is attached to a socket using setsockopt(SOL_SOCKET,
SO_ATTACH_FILTER, ...)
6 matches
Mail list logo
