2014-03-24 16:09 GMT+01:00 Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>: > On Mon, Mar 10, 2014 at 12:50:07PM +0200, Tomasz Bursztyka wrote: >> Hi Pablo and Giuseppe, >> >> >As you can see, a minor issue have to be fixed when printing rules. >> >I have no idea how to handle --logical-in/out interfaces currently, >> >so please let me know if you have an idea or an advice. >> >> As far as I know, there is nothing in nftables's side to differentiate >> between interfaces origin, right? (like a proper hw tight 'eth0' vs >> a bridge 'br0') >> Unless I miss something, it has no real meaning in nftables to >> support such differentiation, >> but for the sake of ebtables compat layer we might need a solution here. >> >> Any idea how this issue could be fixed? > > I think you have to extend nft_meta to support that. See > ebt_basic_match(), the net_bridge_port information is obtained via > br_port_get_rcu(dev) given that dev != NULL. > > Beware that you have to make sure that the new meta types IIFBRNAME > and OIFBRNAME can only be used from the bridge family. I think you > have to do something similar to what Patrick did with nft_reject, by > adding a specific flavour of nft_meta for the bridge family. > > Giuseppe, what other remaining issues you have with the ebtables > compat layer? Could you summarize them, please? Thanks. Hi Pablo, minor issues to fix: - when printing rules, the mask is printed when it shouldn't be, see below: Chain INPUT (policy ACCEPT) target prot opt source destination -s 11:22:33:44:55:66/0:0:0:0:0:0 -j ACCEPT - nft_bridge_is_same not works properly - a rule can be deleted only if the number is specified (caused by point above) There are no other issues currently -- 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
