| Message ID | 1410526023-4370-1-git-send-email-alvaroneay@gmail.com |
|---|---|
| State | Not Applicable |
| Delegated to: | Pablo Neira |
| Headers | show |
On Fri, Sep 12, 2014 at 02:47:03PM +0200, Alvaro Neira Ayuso wrote: > If we try to add a rule like: > > nft add rule filter input udp length {55-9999} > > nft shows: > > BUG: invalid byte order conversion 0 => 2 > nft: src/evaluate.c:153: byteorder_conversion_op: Assertion `0' failed. > > Some of the existing payload fields rely on BYTEORDER_INVALID. Therefore, if we > try to convert it in evaluation step, we hit this bug. > > The packets from the Internet are always in big endian. Therefore, we can create > all the payload expressions using big endian byteorder. No, that's not true for MAC addresses and also a bad assumption to make in general. What's wrong with the patch you sent previously? I think this is the correct way to fix it. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
IHello Patrick El 12/09/14 15:00, Patrick McHardy escribió: > On Fri, Sep 12, 2014 at 02:47:03PM +0200, Alvaro Neira Ayuso wrote: >> If we try to add a rule like: >> >> nft add rule filter input udp length {55-9999} >> >> nft shows: >> >> BUG: invalid byte order conversion 0 => 2 >> nft: src/evaluate.c:153: byteorder_conversion_op: Assertion `0' failed. >> >> Some of the existing payload fields rely on BYTEORDER_INVALID. Therefore, if we >> try to convert it in evaluation step, we hit this bug. >> >> The packets from the Internet are always in big endian. Therefore, we can create >> all the payload expressions using big endian byteorder. > > No, that's not true for MAC addresses and also a bad assumption to make > in general. You are right. I forgot that case. I supposed wrong. > > What's wrong with the patch you sent previously? I think this is the > correct way to fix it. Nothing. I'm going to follow the previous way for fixing this bug. Thanks Patrick. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/src/payload.c b/src/payload.c index 7297520..e705974 100644 --- a/src/payload.c +++ b/src/payload.c @@ -117,7 +117,7 @@ struct expr *payload_expr_alloc(const struct location *loc, } expr = expr_alloc(loc, &payload_expr_ops, tmpl->dtype, - tmpl->dtype->byteorder, tmpl->len); + BYTEORDER_BIG_ENDIAN, tmpl->len); expr->flags |= flags; expr->payload.desc = desc;
If we try to add a rule like: nft add rule filter input udp length {55-9999} nft shows: BUG: invalid byte order conversion 0 => 2 nft: src/evaluate.c:153: byteorder_conversion_op: Assertion `0' failed. Some of the existing payload fields rely on BYTEORDER_INVALID. Therefore, if we try to convert it in evaluation step, we hit this bug. The packets from the Internet are always in big endian. Therefore, we can create all the payload expressions using big endian byteorder. Signed-off-by: Alvaro Neira Ayuso <alvaroneay@gmail.com> --- This patch replaces the patch "src: add specific byteorder to the struct proto_hdr_template" [Tested with the rules] * nft add rule ip filter input ip length 10-55 counter * nft add rule ip filter input ip length 55-1000 counter * nft add rule ip filter input udp length {0-100} udp dport 9999 counter * nft add rule ip filter input udp length {100-9999} udp dport 9999 counter * Tested with Ana Rey's tests. src/payload.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)