Implementation of Ebtables target similar to QUEUE

Implementation of Ebtables target similar to QUEUE

[Abhinav Srivastava]

Hi there,

I have questions regarding the extension of ebtables
code to support target similar to QUEUE target. In my
project, I have a requirement of intercepting packets
inside ebtables and pass some information related to
packet to userspace tool. Ebtables code should wait to
receive reply from userspace tool and then drop or
accept packet. Since, ebtables code run in the context
of interrupt's bottom half, I cannot wait inside that
code path.

To avoid that problem, I would like to create queues
inside ebtables so that I could put that packet into
the queue and start processing the next packet. I can
have other design where I send packets to userspace
and let userspace tool handle the packets. But, I do
not want to cross the user-kernel boundary for each
packet.

I need help in order to achieve my first design:

1) Is my requirement very complex? Can it be achieved
easily?

2) What are the parts of ebtables code i should
change?

3) In case, userspace tool says accept the packet. How
I would implement the fucntionality of getting old
packets from queue and send them out of the network or
for incoming packets send to higher level protocols?

4) Is there any effective way for creating queues
inside ebtables?

I would really appreciate any help or suggestions in
this regard?

Thanks,
Abhinav



      5, 50, 500, 5000 - Store N number of mails in your inbox. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html

Re: Implementation of Ebtables target similar to QUEUE

[Patrick McHardy]

Abhinav Srivastava wrote:
> Hi there,
>
> I have questions regarding the extension of ebtables
> code to support target similar to QUEUE target. In my
> project, I have a requirement of intercepting packets
> inside ebtables and pass some information related to
> packet to userspace tool. Ebtables code should wait to
> receive reply from userspace tool and then drop or
> accept packet. Since, ebtables code run in the context
> of interrupt's bottom half, I cannot wait inside that
> code path.
>
> To avoid that problem, I would like to create queues
> inside ebtables so that I could put that packet into
> the queue and start processing the next packet. I can
> have other design where I send packets to userspace
> and let userspace tool handle the packets. But, I do
> not want to cross the user-kernel boundary for each
> packet.
>
> I need help in order to achieve my first design:
>
> 1) Is my requirement very complex? Can it be achieved
> easily?
>
> 2) What are the parts of ebtables code i should
> change?
>
> 3) In case, userspace tool says accept the packet. How
> I would implement the fucntionality of getting old
> packets from queue and send them out of the network or
> for incoming packets send to higher level protocols?
>
> 4) Is there any effective way for creating queues
> inside ebtables?
>
> I would really appreciate any help or suggestions in
> this regard?

The ebtables part is very easy, just add a target that returns
NF_QUEUE. For the actually queueing and reinjection use
nfnetlink_queue. The two slightly harder parts are:

- Fix the netfilter hooks in the briding code to handle
queued packets, which requires to provide proper okfns
to NF_HOOK that continue packet processing path after
reinjection.

- Fix __nf_queue to not fail when the afinfo lookup is
unsuccessful.

That should be all thats necessary.

Re: Implementation of Ebtables target similar to QUEUE

[Abhinav Srivastava]

--- Patrick McHardy <kaber@trash.net> wrote:

> Abhinav Srivastava wrote:
> > Hi there,
> >
> > I have questions regarding the extension of
> ebtables
> > code to support target similar to QUEUE target. In
> my
> > project, I have a requirement of intercepting
> packets
> > inside ebtables and pass some information related
> to
> > packet to userspace tool. Ebtables code should
> wait to
> > receive reply from userspace tool and then drop or
> > accept packet. Since, ebtables code run in the
> context
> > of interrupt's bottom half, I cannot wait inside
> that
> > code path.
> >
> > To avoid that problem, I would like to create
> queues
> > inside ebtables so that I could put that packet
> into
> > the queue and start processing the next packet. I
> can
> > have other design where I send packets to
> userspace
> > and let userspace tool handle the packets. But, I
> do
> > not want to cross the user-kernel boundary for
> each
> > packet.
> >
> > I need help in order to achieve my first design:
> >
> > 1) Is my requirement very complex? Can it be
> achieved
> > easily?
> >
> > 2) What are the parts of ebtables code i should
> > change?
> >
> > 3) In case, userspace tool says accept the packet.
> How
> > I would implement the fucntionality of getting old
> > packets from queue and send them out of the
> network or
> > for incoming packets send to higher level
> protocols?
> >
> > 4) Is there any effective way for creating queues
> > inside ebtables?
> >
> > I would really appreciate any help or suggestions
> in
> > this regard?
> 
> The ebtables part is very easy, just add a target
> that returns
> NF_QUEUE. For the actually queueing and reinjection
> use
> nfnetlink_queue. The two slightly harder parts are:
> 
> - Fix the netfilter hooks in the briding code to
> handle
> queued packets, which requires to provide proper
> okfns
> to NF_HOOK that continue packet processing path
> after
> reinjection.
> 
> - Fix __nf_queue to not fail when the afinfo lookup
> is
> unsuccessful.
> 
> That should be all thats necessary.
> 

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.

Thanks,
Abhinav




      Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html

Re: Implementation of Ebtables target similar to QUEUE

[Patrick McHardy]

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.

Re: Implementation of Ebtables target similar to QUEUE

[Abhinav Srivastava]

--- Patrick McHardy <kaber@trash.net> wrote:

> 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.
> 
> 


Hi Patrick,

I tried to do what you said but some how could not
achieve it and since project deadlines are so pressing
I would like to achieve the same thing but from the
user space.

Inside the ebtables code, I intercept packets and send
it to userspace application, which decides whether to
accept the packet or drop it and re-inject it to the
network. I heard it can be done for iptables but can
it be done for ebtables?

I saw libipq which provides you functionality of
reinjecting the packets into ipfilters ip queue.

I would like to reinject the packet to ebtable
filtering code or if not then directly out to the
interface if I decide packet is to be accepted. Please
let me know if this deisgn is possible. I also ok with
passing the packet using libipq to ipfilters as long
as they can send the packet out to network. I just
want to achieve the complete design with minimum
hassle because of deadline.

I would really appreciate your help.

Thanks,
Abhinav



      5, 50, 500, 5000 - Store N number of mails in your inbox. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html

Re: Implementation of Ebtables target similar to QUEUE

[Patrick McHardy]

Abhinav Srivastava wrote:
> Hi Patrick,
> 
> I tried to do what you said but some how could not
> achieve it and since project deadlines are so pressing
> I would like to achieve the same thing but from the
> user space.
> 
> Inside the ebtables code, I intercept packets and send
> it to userspace application, which decides whether to
> accept the packet or drop it and re-inject it to the
> network. I heard it can be done for iptables but can
> it be done for ebtables?
> 
> I saw libipq which provides you functionality of
> reinjecting the packets into ipfilters ip queue.
> 
> I would like to reinject the packet to ebtable
> filtering code or if not then directly out to the
> interface if I decide packet is to be accepted. Please
> let me know if this deisgn is possible. I also ok with
> passing the packet using libipq to ipfilters as long
> as they can send the packet out to network. I just
> want to achieve the complete design with minimum
> hassle because of deadline.
> 
> I would really appreciate your help.


Well, the iptables queuing depends on exactly the QUEUE
functionality I described, you'll need to add this to
the briding code, otherwise it won't work.

Re: Implementation of Ebtables target similar to QUEUE

[Abhinav Srivastava]

--- Patrick McHardy <kaber@trash.net> wrote:

> Abhinav Srivastava wrote:
> > Hi Patrick,
> > 
> > I tried to do what you said but some how could not
> > achieve it and since project deadlines are so
> pressing
> > I would like to achieve the same thing but from
> the
> > user space.
> > 
> > Inside the ebtables code, I intercept packets and
> send
> > it to userspace application, which decides whether
> to
> > accept the packet or drop it and re-inject it to
> the
> > network. I heard it can be done for iptables but
> can
> > it be done for ebtables?
> > 
> > I saw libipq which provides you functionality of
> > reinjecting the packets into ipfilters ip queue.
> > 
> > I would like to reinject the packet to ebtable
> > filtering code or if not then directly out to the
> > interface if I decide packet is to be accepted.
> Please
> > let me know if this deisgn is possible. I also ok
> with
> > passing the packet using libipq to ipfilters as
> long
> > as they can send the packet out to network. I just
> > want to achieve the complete design with minimum
> > hassle because of deadline.
> > 
> > I would really appreciate your help.
> 
> 
> Well, the iptables queuing depends on exactly the
> QUEUE
> functionality I described, you'll need to add this
> to
> the briding code, otherwise it won't work.
> 

> 


Hi Patrick,

Thanks for your reply. I have started looking into the
code of ebtables in order to implement the
functionality. However I got curious by reading
somewhere that iptables can be used to filter packets
at bridge level. Is this correct?

Since I am not doing any MAC level filtering, I am
getting hold of sk_buff reference from ebtables code
and then doing my own thing. Can I use iptables for
this purpose? If yes, then is it possible to use
iptables QUEUE and re-injection facilities here? OR
again it is the same problem that packets are passing
through bridge and iptables QUEUE and re-injection
code  will drop the packet when it sees bridge
protocol and other problems that you mentioned before.

Regards,
Abhinav





      Forgot the famous last words? Access your message archive online at http://in.messenger.yahoo.com/webmessengerpromo.php