On 26.11, Florian Westphal wrote: > This is V2 of the nft trace patch set. > > See the individual patches for a change vs. v1 description. > > Patrick: I did a quick test w. your last public patches > (plus a few minor changes to make it build again) and things > seem to work fine. > > What does not work correctly is decoding of vlan header. > I think whats happening is that we cannot splice sub-byte > sized quantities from a larger chunk. I've managed to decode it properly, so the kernel part is fine: ether saddr 63:f6:4b:00:54:52 ether daddr c9:4b:a9:00:54:52 vlan pcp 0 vlan cfi 0 vlan id 1000 vlan type ip ip saddr 10.0.0.1 ip daddr 10.0.0.2 ip tos 0 ip ttl 64 ip id 61847 ip length 84 icmp type echo-request icmp code 0 icmp id 29049 icmp sequence 4267 icmp type 61 icmp code 177 icmp id 0 icmp sequence 0 icmp type 116 icmp code 211 There are a number of problems however. The easy one is wrong header definitions in nft, also my decoding is a bit hackish so far and occasionally causes endless loops, I'll fix that. The somewhat bigger problem are some inconsistencies. Usually we can see the original lower layer header on the receive path in the higher layers, f.i. the ethernet header. With VLAN offloading this doesn't work since we loose the meta data once the packet has been received through the VLAN code. This means we'll just see a regular ethernet header. This does not only affect tracing, but anything that wants to access that header. Its not a *huge* problem, but it is unexpected for the user, especially since he is able to treat the offloaded header like a regular VLAN header before "decapsulation". I have no good suggestion what to do about that. The information in the skb is gone. The only possibility I can think of is to reconstruct (most of) it based on the incoming device, the known upper protocol and skb->priority, but that's quite ugly. -- 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
