netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Abhinav Srivastava <abhinavs_iitkgp@yahoo.co.in>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: Implementation of Ebtables target similar to QUEUE
Date: Fri, 28 Sep 2007 23:42:08 +0200	[thread overview]
Message-ID: <46FD7530.6090506@trash.net> (raw)
In-Reply-To: <132825.81500.qm@web7901.mail.in.yahoo.com>

Abhinav Srivastava wrote:
> Hi Patrick,
>
> Thanks for your quick reply. I understood the first
> part but did not get the second harder part
> completely.
>
> Could you please shed some more light on that and also
> it would be great if you could give me some pointer
> for  target files that I may need to look into.
>   

The NF_HOOK part: the okfn functions given to NF_HOOK in the bridge
code don't actually continue the packet processing path as required
for packet reinjection. Normally you'd have:


static inline int finish_packet_processing(struct sk_buff *skb)
{
    <finish packet processing>
}

static int process_packet(struct sk_buff *skb)
{
    ...
    return NF_HOOK(...., finish_packet_processing);
}

Look at net/ipv4/ip_input.c for an example. The bridging code does
(in some spots at least) something like this:

static int br_handle_local_finish(struct sk_buff *skb)
{
        struct net_bridge_port *p = rcu_dereference(skb->dev->br_port);

        if (p)
                br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
        return 0;        /* process further */
}

struct sk_buff *br_handle_frame(struct net_bridge_port *p, struct 
sk_buff *skb)
{
    ...
                if (NF_HOOK(PF_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
                            NULL, br_handle_local_finish))
    ...
}

When the queue handler calls nf_reinject, the packet goes to the
okfn. In the case above that would be br_handle_local_finish(),
which will simply update the fdb and return to nf_reinject,
leaking the packet instead of continuing processing.

The code needs to be rearranged that in all NF_HOOK invocations
the okfn takes ownership of the skb and continues processing.
grep net/bridge for NF_HOOK for all spots to check (excluding
br_netfilter.c).

The second part is simpler, __nf_queue() and nf_reinject()
perform a lookup for afinfo of the packets protocol family
and drop the packet if that lookup is unsucessful. For bridging
there is no registered family, so the packet is always dropped.
So these functions (net/netfilter/nf_queue.c) needs to be changed
to handle the unsucessful lookup by avoiding rerouting.


  reply	other threads:[~2007-09-28 21:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-28 20:51 Implementation of Ebtables target similar to QUEUE Abhinav Srivastava
2007-09-28 21:14 ` Patrick McHardy
2007-09-28 21:26   ` Abhinav Srivastava
2007-09-28 21:42     ` Patrick McHardy [this message]
2007-10-18 20:29       ` Abhinav Srivastava
2007-10-19  8:24         ` Patrick McHardy
2007-10-23 23:12           ` Abhinav Srivastava

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46FD7530.6090506@trash.net \
    --to=kaber@trash.net \
    --cc=abhinavs_iitkgp@yahoo.co.in \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).