Looking for small Confirmation about skb_pull & NF_ACCEPT !!!
SaNtosh kuLkarni
santosh.yesoptus at gmail.com
Thu Apr 5 05:00:53 EDT 2012
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 <vunnavafuture at gmail.com>wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120405/a896ddc5/attachment.html
More information about the Kernelnewbies
mailing list