Re: ipq_set_verdict

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






hey  Jee and Sven

thanks both of u for that, yes i guess you are right that wont work,i
looked into the kernel source for the same, i can reinject just one packet
for the one i took from the kernel...and the id has to be the same, so i
cant use this.
can u give me some good libnet links.

thanks
Amit





"Jee J.Z." <jz105@xxxxxxxxxx>@lists.netfilter.org on 04/20/2004 07:19:12 PM

Sent by:    netfilter-admin@xxxxxxxxxxxxxxxxxxx


To:    Amit Kumar Singh/HSS@HSS
cc:    "Sven Schuster" <schuster.sven@xxxxxx>,
       <netfilter@xxxxxxxxxxxxxxxxxxx>

Subject:    Re: ipq_set_verdict


Hi again,


> hi
>
>   I thought of a way of reinjecting absolutely new packets into the
kernel
> .... suppose i call ip_set_verdict (this in turn calls nf_reinject) to
> inject packets into the kernel)for the new packets that a user space
> process generates. nf_reinject has a parameter nf_info which probably
tells

When you call ipq_set_verdict, there must be a packet waiting for userspace
processing in the kernel. You can reinject any packet content as you wish
by
setting NF_ACCEPT, however, you have to use the packet id of the packet
currently waiting in the kernel.

> the kernel from which hook was this packet captured and hence from where
to
> continue when this is reinjected(from the next hook onwards). Now,
suppose
> I have a PRE_ROUTING hook that captures the packets and sends it to my
user
> space process. This process might  return some packets to be reinjected
and
> might generate some of its own that it wants injected into the kernel
(from
> pre_routing stage but bypassing the netfilter PRE_ROUTING hook) .. for
> these newly generated packets I can use the same nf_info param i used for
> the packets that i captured from the kernel and that will make the kernel
> think that they were captured by the PRE_ROUTING hook and so after
> reinjection continue from after the PRE_ROUTING hook....so for these
> packets routing decision would be taken after injection and hence these
> newly packets cld either be outbound(going to the wore) or inbound (the
> ones that need to travel up the stack from ip).

Good idea. But keep in mind that one original packet only allow you to
generate and inject one new packet using libipq, IMO. However, if you use
libnet, I believe you can generate as many new packets as you wish and
inject them.

Not sure I get what you mean rightly. Let me know if I miss something.

Jee

> This sounds good to me but can this be done or am i thinking on wrong
lines
> here. Please suggest if im wrong.
>
> thanks
> Amit
>
> "DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited
> (HSS) and is intended solely for the use of the individual to whom it is
> addressed. It may contain  privileged or confidential information and
> should not be circulated or used for any purpose other than for what it
is
> intended. If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying, altering,
or
> disclosing the contents of this message. HSS accepts no responsibility
for
> loss or damage arising from the use of the information transmitted by
this
> email including damage from virus."
>
>
>






[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux