Am 30.10.2015 22:27, schrieb Florian Westphal:
Martin Gröger <mgroeger1@xxxxxx> wrote:
- NFQA_PAYLOAD maintains illusion of disabled/non-existant VLAN hw
offload, i.e. we insert it into NFQA_PAYLOAD between mac and network
header.
Sorry, I don't understand this. The VLAN header is (if exists) after
the source MAC. If a paket is bridged, I would expect, that the VLAN
header is kept unchanged. I would expect to find the VLAN header
exactly there! Is this wrong?
Yes, there is no VLAN header, its removed (usually by hardware offloads)
and stored in meta data only.
Thats why I think we should transparently re-insert when sending
the copy to userspace.
(I.e. undo what hardware offloads did).
Ok, now I understand.
So there are basically 2 options:
1.) reinsert the VLAN header
pro: looks like the wire
con: Is the insert measurable in terms of performance?
2.) pass der VLAN header also as meta data to the user.
pro: network header is always on the same offset, so it might be
easier for higher layer inspection
con: not like the wire
So, although I would have expected option 1, I think option 2 has
advantages too. So I think both shoud be ok.
- NFQA_HWADDR attribute is not present (redundant, we have this in
NFQA_PAYLOAD).
I still have the q&d hack that makes it work but no reroute (re-bridge,
cough) support, just dump-to-userspace.
As far as I understand this would be sufficient for my usecase,
since I want simply to inspect the packets and then decide to accept
or drop them.
Yes, in fact I think we should just ignore reroute (bad idea) or rebridge
(what would be the use case of this...?)
If someone really needs to be able to resend/relay packet they could do
this in userspace or just use PRE_ROUTING since thats before bridge
asks the FDB for the output port.
We could add bridge_me_harder to pick another output device for queueing
in BRIDGE OUTPUT but I have no idea why one would want such feature.
I'm currently trying to understand the structure.
So to add the missing parts:
- there is no change in the nftable kernel modules necessary?
Not to nftables but to nfnetlink_queue module (and to bridge netfilter
kernel part).
From the presentation Nftables-osd-2013-developer.pdf I understood,
that there is a generic instruction set part of the kernel. New
functionality will be added by new combination of this instruction set.
Additionally there must be some code for each hook, but I would expext,
that this code provides the packet and some metadata to the engine,
which process the instructions. Also for the interface from the main
engine to the nfnetlink_queue module I would expect the packet and a
metadata structure. Since the queueing for the IP hook works, I expected
that all generic instructions for this purpose are available and just
have to be used for the bridge hook.
So obviously somehow my expectation is wrong - but what's wrong?
- there are changes in the nftnl library necessary?
No, unless we add extra attribute e.g. for vlan header but I'd like
avoid it.
Ok, is this again an argument for Option 1 above?
Is this, because there is currently in the generic instructions no
option to add VLAN metadata somehow to the nfnetlink_queue?
- there are changes in nft necessary?
No, nft side should already work just fine.
Only Pablo_nftables-osd-userday-2013.pdf and
Nftables-osd-2013-developer.pdf.
Is there somethimg more to read to get an better understanding of nftables?
Sorry, not that I know of. Perhaps Patrick or Pablo have more
information available somewhere.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
