Hi, I am not modifying the pkt in 'netfilter hook'. I am doing it in a dummy ethernet device xmit function. This dummy device is a virtual interface and attached to bridge. --- venu.m ----- Original Message ----- From: <aksingh@hss.hns.com> To: <aksingh@hss.hns.com> Cc: "Ravi Kumar" <ravivsn@rocsys.com>; "venum" <venum@intoto.com>; <kernelnewbies@nl.linux.org> Sent: Monday, July 05, 2004 4:37 PM Subject: Re: netif_rx dropping the packet > > > > > btw if you are using netfilter hook functions to capture packets and modify > them, then why dont you just return NF_ACCEPT, after the modification is > done instead of using netif_rx() ?, that shld work just fine. Once > NF_ACCEPT is returned, routing decision would be taken and the packet would > be routed correctly. > > regards > Amit > > > > > Amit Kumar Singh/HSS@HSS@nl.linux.org on 07/05/2004 03:16:17 PM > > Sent by: kernelnewbies-bounce@nl.linux.org > > > To: Ravi Kumar <ravivsn@rocsys.com> > cc: venum <venum@intoto.com>, kernelnewbies@nl.linux.org > > Subject: Re: netif_rx dropping the packet > > > > > > > Hi, > > If you check the return value, you might find that netif_rx returns > SUCCESS, the function always succeeds, the packet might be getting dropped > in ip_rcv() in all probability. One thing you can do to isolate the > problem, is set skb->nfmark when your PRE_ROUTING hook catches the packet > and you have to forward it by encapsulating the ip header, then in you > NF_IP_FORWARD hook or POST_ROUTING hook, you can check if you get the > packet. > Also, before you call netif_rx, it is important to set skb->mac.raw field > to the position where the packets ethernet header begins. You can try using > the function eth_type_trans. Try these things, and let us know how it goes. > > Amit > > > > > Ravi Kumar <ravivsn@rocsys.com>@nl.linux.org on 07/05/2004 09:52:42 AM > > Sent by: kernelnewbies-bounce@nl.linux.org > > > To: venum <venum@intoto.com> > cc: kernelnewbies@nl.linux.org > > Subject: Re: netif_rx dropping the packet > > > Hi Venu Maya, > There are numerous ways to take in packet. Apart from netfilter hooks, > dev_add_pack and ether hooks , packets can also taken by creating dummy > ethernet device. > As I understand, the problem is in encapsulation module. You would like > to see ipip.c/ip_gre.c as a proof of concept. After you attach the IP > header+ UDP Header + Your payload, and based on route look up , you get > device onto which the packet has to be sent to. use ip_send to send > packets to stack. (Refer to ipip.h, you can use IPTUNNEL_XMIT ) > > /* remember this to set in sk_buff */ > skb->dst = &rt->u.dst; > > Let me know how it goes, > -Ravi > ROCSYS Technologies Ltd > http://www.rocsys.com > > bhaskar wrote: > > > Hi, > > How did you capture the packet. I mean netfilter hooks, or using > > dev_add_pack or .... > > > > Regards > > bhaskar > > > > > > venum wrote: > > > >> Hi > >> > >> I am facing a problem with the part of kernel code that I am > >> developing for > >> a linux router. The objective is to encapsulate the received IP > >> packet with > >> a UDP header and an extra IP header and forward it to a different > >> destination. > >> I am encapsulating the original packet and passing it to the stack using > >> 'netif_rx'. I want the stack to forward the packet to changed > >> destination. > >> At the destination the packet will be decapsulated. > >> But once the packet is given to the 'netif_rx', stack is dropping the > >> packet > >> silently. > >> I don't know which part of the stack code is dropping the packet. > >> > >> I need help in debugging this problem.I am giving the following details > >> about the encapsulation: > >> > >> Dump of the ICMP ping packet received: > >> 0 0 24 c0 2d 63 0 80 48 18 9e 5a 8 0 45 0 > >> 0 3c 1 cb 0 0 80 1 dc 18 ac 10 2 5c ac 10 > >> 2 61 8 0 4a 5c 2 0 1 0 61 62 63 64 65 66 > >> 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 > >> 77 61 62 63 64 65 66 67 68 69 > >> > >> Packet Dump after Encapsulation: This packet is given to stack using > >> 'netif_rx' > >> 45 0 0 74 56 34 0 0 f0 11 ba 8b ac 10 16 1 > >> ac 10 16 3 d4 31 d4 31 0 8 0 0 1 1 1 11 > >> 22 33 44 55 66 0 0 0 0 0 0 0 24 c0 2d 63 > >> 0 80 48 18 9e 5a 8 0 45 0 0 3c 1 cb 0 0 > >> 80 1 dc 18 ac 10 2 5c ac 10 2 61 8 0 4a 5c > >> 2 0 1 0 61 62 63 64 65 66 67 68 69 6a 6b 6c > >> 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 > >> 66 67 68 69 > >> I want this packet to be routed to IP address 172.16.22.3. The required > >> route is configured. > >> Is any thing wrong in the above encapsulated packet ? > >> I am modifiying the follwing skb params: > >> > >> pSkb->ip_summed = CHECKSUM_UNNECESSARY; > >> /* I have tried others like NONE,HW with no improvements > >> */ > >> > >> pSkb->protocol = htons(ETH_P_IP); > >> /* Since it is always an IP packet */ > >> > >> Can anyone help me find out the problem. I will provide any other > >> details if > >> required. > >> > >> TIA, > >> venu maya > >> > >> > >> > >> -- > >> Kernelnewbies: Help each other learn about the Linux kernel. > >> Archive: http://mail.nl.linux.org/kernelnewbies/ > >> FAQ: http://kernelnewbies.org/faq/ > >> > >> > >> > > > > > > -- > > Kernelnewbies: Help each other learn about the Linux kernel. > > Archive: http://mail.nl.linux.org/kernelnewbies/ > > FAQ: http://kernelnewbies.org/faq/ > > > > > > > -- > Kernelnewbies: Help each other learn about the Linux kernel. > Archive: http://mail.nl.linux.org/kernelnewbies/ > FAQ: http://kernelnewbies.org/faq/ > > > > > -- > Kernelnewbies: Help each other learn about the Linux kernel. > Archive: http://mail.nl.linux.org/kernelnewbies/ > FAQ: http://kernelnewbies.org/faq/ > -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
