All of lore.kernel.org
 help / color / mirror / Atom feed
From: k8 s <uint32@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: IPSec Inbound Processing Basic Doubt
Date: Thu, 23 Jun 2005 23:25:34 +0530	[thread overview]
Message-ID: <699a19ea050623105516cd5eb8@mail.gmail.com> (raw)

Hello,

I have a basic doubt regarding ipsec inbound packet processing.
I have idea about the stackable destination.If I am not wrong it is like this.
 /* Output packet to network from transport.  */
static inline int dst_output(struct sk_buff *skb)
{
        int err;

        for (;;) {
                err = skb->dst->output(skb);

                if (likely(err == 0))
                        return err;
                if (unlikely(err != NET_XMIT_BYPASS))
                        return err;
        }
}

here skb->dst->oututput(skb)
               xfrm4_output(skb) 
                     {
                                x->type->output(skb)
                                skb->dst = dst_pop(skb);
                      }
                                            
And x->type->output(skb) calls ah_output | esp_output and the skb->dst
value is reset during dst_pop(skb)

All methods return non zero for the dst_output for loop to continue
except ip_queue_xmit   (I Think) which returns 0 and the for loop
exits. Error reporting by any member in the chain is through returning
XMIT_BYPASS or similar

I hope Its the way

My doubt regarding Inbound processing is
 dst_input()
{
    for(;;)
   {
        err = skb->dst->input()
   }
}
hope that it calls rxfrm4_rcv (ipv4)  calls
                                xfrm4_rcv_encap()
                                   {
                                        x->type->input()
                                        dst_release(skb->dst);

                                          //also there is a
netif_rx(skb) in the same method
                                    }
 and  x->type->input() calling ah_input | esp_input()

Now is it that 
a) inbound is similar to outbound stackable destination calls except
that the calls are in                                              
reverse direction
b)Does netif_rx call in xfrm4_rcv_encap mean one of the many xfrms of
ipsec gets processed first and the packet is fed back to the ipstack
through netif_rx() and the whole game starts again with ip_rcv
checking protocol finding 50 0r 51 and calling xfrm4_rcv

So is it a call chain 
or 
packet looping between ipsec and ip continuosly using  netif_rx and
ip_rcv and xfrm4_rcv




S Kartikeyan

             reply	other threads:[~2005-06-23 17:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-23 17:55 k8 s [this message]
2005-06-27 16:24 ` IPSec Inbound Processing Basic Doubt Michael Becker
2005-06-28 17:08   ` k8 s
2005-06-28 17:31     ` k8 s
2005-06-28 21:53       ` Re[2]: " Michael Becker
2005-06-28 21:41     ` Michael Becker

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=699a19ea050623105516cd5eb8@mail.gmail.com \
    --to=uint32@gmail.com \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.