Looking for small Confirmation about skb_pull & NF_ACCEPT !!!

Thanks Guys for the Reply. Yes., it's Tunneling . I will be getting a
Packet with an Extra IP+UDP Header Over the Original IP header. I need
to strip this Extra 28 bytes & Route the Packet based on the Original
Inner IP header. This became bit Confusing to me.

@Santosh: Well; I am successful while adding Extra Header & Routing
Packet. In that case; I have used below Mentioned  steps & it worked
Fine. After looking at the Part of TCP./IP Stack code for kernel
2.6.25.x; I see only some Functions are Exported &
__ip_route_output_key() is one important function who is giving me the
Cached Routing Table Entry if the Corresponding Flow Matches. But the
Problem was Inner IP header's Source IP was not my Machine IP & it is
some other Machine & Functions Returns NO Routing key for me. It seems
to be this Function to be best used only for the Packets Generated
(OUTPUT CHAIN ) by my Machine. What can be the best Function to play
in my use case ??? Many are NOT EXPORTED to test in my code ;( .

Friends,
 Any  Pointer/Document for me to play with the Exported Kernel
Functions ??? I am playing with many but always ending with Kernel
Panic.

#################################################
  fi.fl4_dst=iph->daddr;
  fi.fl4_src=iph->saddr;
  fi.oif=0;
  Var1 =  __ip_route_output_key(&init_net,&rt,&fi);
  dst_release (sock_buff->dst);
  sock_buff->dst = &rt->u.dst;
  Var2 =  dst_output(sock_buff);
##################################################

-Thanks in Advance,
VKS


On Fri, Apr 6, 2012 at 9:56 AM, SaNtosh kuLkarni
[off-list ref] wrote:

are u doin some sort of tunneling ?


On Fri, Apr 6, 2012 at 6:03 AM, Sri Ram Vemulpali [off-list ref]
wrote:

quoted

Whenever you manipulate the packet before PRE_ROUTING point in the
stack, the kernel will decide whether to route the packet to LOCAL or
FORWARD. If you have pointer pointing to right IP header kernel will
use it to route. You really do not have to write routing code.

Also, when you say inner and outer header what do you mean by it. I
did not encounter this.

Thanks,
Sri.

On Thu, Apr 5, 2012 at 5:00 AM, SaNtosh kuLkarni
[off-list ref] wrote:

quoted

i had a similar problem where in i was using SKB_PUSH to add extra
header,,,, i used this... structure called flowi....?which?can be used
to
define a sort of traffic class...based on some combination of fields


iph->daddr =htonl(xxxxxx);
{
struct rtable *rt;
struct flowi fl;
memset(&fl, 0x0, sizeof(struct flowi));
fl.fl4_dst ?= htonl(xxxxxxx);
fl.proto = IPPROTO_TCP;
if (!ip_route_output_key(&init_net, &rt, &fl))
{
iph->saddr= htonl(ntohl(rt->rt_src));

skb_dst_set(skb2, &rt->u.dst);

}

}


On Mon, Apr 2, 2012 at 2:12 PM, Kesava Srinivas
[off-list ref]
wrote:

quoted

HI Friends,
Looking for a Confirmation on my analysis.

Once after Capturing the Socket Buffer in PRE_ROUTING Hook; Manipulated
the Socket Buffer by using the "skb_pull" Kernel Function. Using
skb_pull;
stripped 28 bytes (IP+UDP) which are the Part of outer UDP/IP Header.
Now;
My intention was to route the skb based on the Inner IP Header which is
sitting after stripping 28 bytes. At the END; returned NF_ACCEPT.

Even though; skb_pull worked Fine., Kernel's Stack is still looking in
to
Outer Header only for Routing the Packet.I expected ;Kernel will look
the
Inner Header (As data Pointer was incremented by 28 bytes via skb_pull)
and
Take decision based on the Inner one. But; that didn't? happened. It
looks
to me like; we need to always use NF_STOLEN & should write our own code
to
route based on the INNER HEADER. Was my conclusion correct ??

-Thanks in Advance,
VKS



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

--
Regards,
Sri.

-- 
-VKS
Masters,Computer Science&Engineering.