Hi,
> 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), Best Regards, Vladislav Grishenko
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
