El 02/06/14 10:58, Florian Westphal escribió:
Álvaro Neira Ayuso <alvaroneay@xxxxxxxxx> wrote:
Now, when we add a rule with DSCP, in the code generation step, nftables
compares 1 bytes but it should compare 6 bits. I think that the problem should
be in the code generation.
I don't really see how this patch changes this. The kernel operates in units
of bytes. For anything smaller nftables will have to generate appropriate
bitwise operations. Please explain in more detail how this patch changes this.
Now, nothing. For that it's stopped. I'm working for doing a patch
for operating in the kernel not only with units of bytes like you
say. In a couple of days, I'm going to send it to the list.
Are you sure this is the right approach?
It might be better to create appropriate masking instructions in
userspace, in most cases byte addressing is sufficient.
Something like this (warning: untested, misses 'reverse' mapping to
remove the implicit bitops when listing rules):
http://git.breakpoint.cc/cgit/fw/nftables.git/commit/?h=payload_offset_04&id=76ac27643400111785a8abb21fdd9e4311d9876e
I have explained very bad. I'm working in a patch like you but I have
done a different solution. I have done my solution in the evaluation. I
have added a bitwise node in the tree when we evaluate the relational if
we have a EXPR_PAYLOAD node in the left and when the size of this left
node is not a multiple of BITS_PER_BYTE. And I have used the function
mpz_prefixmask for doing the masks. The problem come when I have added a
rule like:
nft add rule ip filter input ip frag-off != 0
The mask that we need to use for take the 13 bits for frag-off is like this:
|00052|N-|00002| |len |flags| type|
|00008|--|00001| |len |flags| type|
| 00 00 00 01 | | data |
|00008|--|00002| |len |flags| type|
| 00 00 00 01 | | data |
|00008|--|00003| |len |flags| type|
| 00 00 00 02 | | data |
|00012|N-|00004| |len |flags| type|
|00006|--|00001| |len |flags| type|
| 1f ff 00 00 | | data |
The problem is when I have seen the mask of the bitwise in the kernel, I
have seen that the mask is 0xff1f. I'm working for trying to fix that. I
have thought that maybe was a problem that I have tried this rule
without my patch and we have the same problem:
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
