Hello!
So this whole idea to make run_filter() return signed integers
and fail on negative is entirely flawed, it simply cannot work
and retain the expected semantics which have been there forever.
Actually, it can. Return value was used only as sign of error,
so that the mistake was to
From: Alexey Kuznetsov [EMAIL PROTECTED]
Date: Thu, 25 Jan 2007 16:22:20 +0300
Actually, it can. Return value was used only as sign of error,
so that the mistake was to return original unsigned result casted to int.
Alternative fix is enclosed. To be honest, it is not better than
yours:
From: Raivis Bucis [EMAIL PROTECTED]
Date: Thu, 4 Jan 2007 17:47:46 +0200
I believe I have found a bug in PF_PACKET socket filtering
(introduced in linux-2.6.19). If BPF returns values larger than
0x8000u, run_filter in af_packet.c considers that as error
instead of simply accepting
Hello,
I believe I have found a bug in PF_PACKET socket filtering (introduced in
linux-2.6.19). If BPF returns values larger than 0x8000u, run_filter in
af_packet.c considers that as error instead of simply accepting packet in its
full length. sk_filter does not have this problem.
Raivis
