On Fri, Feb 14, 2014 at 6:15 PM, Vladislav Grishenko <themi...@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. _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
