Sunny73Cr <Sunny73Cr@xxxxxxxxxxxxxx> wrote: > I noticed there may be a floating point error or another miscellaneous approximation error when calculating the mask for raw payload expressions. It is somewhat related to this thread. There is no approximation. And no floating point math is involved. > using nft -d all (debug all); I found: > > inet filter output 5 4 > [ payload load 2b @ inner header + 6 => reg 1 ] > [ bitwise reg 1 = ( reg 1 & 0x0000c0ff ) ^ 0x00000000 ] > > After careful consideration, I realised that here; '2b' indicates two bytes, not two bits. I suggest it should read '2 Bytes'. Additionally, the "+ 6" section should really read as "+ 6 Bytes". "2B" or "6B" may get misread as 28, or 68; if the user makes a poor choice in font. Poor choice in font is not my concern, particularly; but fault-tolerant design is always nice. > > Anyhow, with the alterations to expression; I can then match it (2 bytes, offset of 6 bytes) to the 'mangled' input of @ih,48,16 > > > [ bitwise reg 1 = ( reg 1 & 0x0000c0ff ) ^ 0x00000000 ] > > Assuming that the mask is stored in a 32-bit integer field, the length of the string is fine. Otherwise, the mask of "0x0000c0ff" equates to 49,407 bits. 0x0c0ff in decimal notation is 49407. But I do not know how "0x0000c0ff" equates to "49407 bits". > Since raw payload expression includes the starting position in payload expressions; it is really 49,408 bits to match. I don't know what that is supposed to mean. > Via empirical calculation, the closest base 2 logarithm I can find for 49,407 (bits) is approximately ~15.5924570373. > If the mask is intended to cover 16 bits; should it not equate to 65,535 bits; or "0x0000ffff". > > Though, the intent was not to read and set the same value; rather, it was to redact 6 bits of data. Considering the intent of my input statement (@ih,58,6); I think the mask should be ((2^16) - (2^6)); or 65,472 in decimal; or 0xfff9 in hexadecimal. I have no idea what you mean. The mask cannot be computed by ((2^16) - (2^6)). The location (offset) matters, not just the amount of bits to retain/zero out. > This leaves us with an output statement of (little endian mask, as it seems is the case): > > @ih,48,16 set @ih,48,16 & 0xfff9 > > The statement: > > > [ bitwise reg 1 = ( reg 1 & 0x0000c0ff ) ^ 0x00000000 ] > > Should then read: > > > [ bitwise reg 1 = ( reg 1 & 0x0000fff9 ) ^ 0x00000000 ] That mask is 1111100111111111 which translates to '@ih,53,2 set ...' Please show a real bug, i.e.: 1. the rule you made 2. a text explaining what you wanted the rule to do 3. a packet capture showing packet after mangling 4. a text explaing what yhe packet capture SHOULD have shown instead else I will never be able to help.
