udhcpc: dont use BPF filter, users report problems (bugs 4598, 6746), commit e4785ca653d0e219926692c229673b2c1b8d6ac4

[Denys Vlasenko]

On Fri, Feb 14, 2014 at 6:15 PM, Vladislav Grishenko <themiron at mail.ru> wrote:
>> At least for now, while we don't understand why filter breaks udhcpc for
>> some users.
>
> There was bug in 2.6.19 bpf result handling, when unsigned 32-bit result how
> much of packet to retain was treated as signed integer. So, values could be
> interpreted as negative and packet drop verdict.
>
> Bug introduced with fda9ef5d679b07c9d9097aaf6ef7f069d794a8f9 [NET]: Fix
> sk->sk_filter field access in 2.6.19
>
> Buf fixed with dbcb5855d108b7fa20ab42567a5412ce9dcd776a [AF_PACKET]: Fix BPF
> handling in 2.6.20
>
> Perhaps it's the root of #4598 and #6746.
>
> Fix is trivial, return maximum signed value, not unsigned. It's sill fine to
> return some sane large integer to accept and leave the whole packet
> unchanged.
>
> /* L3: accept packet */
>
> -BPF_STMT(BPF_RET|BPF_K, 0xffffffff),
>
> +BPF_STMT(BPF_RET|BPF_K, 0x7fffffff),

Many thanks for an excellent analysis, committed the fix to git.