Fred,

It seems like you'd like to be able to add something to the packet
that said "I have seen this" or "I generated this" so you know that
you can ignore the packet when it comes back again, correct?

The other option I can see here is that you'd like to inject a packet
into the "top half" of the IP packet processing, correct?

Darren

Fred Medlin wrote:

> Thanks Diego,
>
> I think what you are saying is that the return code from the 
> PHYSICAL_IN hook callback dictates whether or not the packet continues 
> to the ip layer (application) or is discarded. That would be a 
> synchronous way to handle each arriving packet.
>
> From my hook callback implementation, I have an async call that 
> effectively removes each arriving packet. After some 
> filtering/processing, valid packets are injected to QUEUE_IN.
>
> At that point, it will be hooked again by PHYSICAL_IN because the 
> network stack believes the packet is arriving from a network interface.
>
> Invoking net_inject eventually queues up the packet for ip_input so I 
> don't think that call would work for me either. That would be the BSD 
> way, but in this kernel it will again be hooked.
>
> Thanks,
> Fred
>
>
> On 9/6/07, *Diego B* < [EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>     Hi;
>     Why do you think the same packet will be hooked again (at the same
>     hook)
>     when you return from your hook-implementation function ?
>     The same packet maybe hooked at a later stage in the process until it
>     reach he application requiring it.
>     AFAIK net_inject is used to inject a *new* packet into the process, I
>     don't know if you can inject a live packet again.
>
>     Regards
>     Diego B
>
>     Fred Medlin wrote:
>> Hi All,
>>
>> Once an inbound packet is hooked by PHYSICAL_IN and determined
>     that it
>> can continue on to the kernel, how can it be injected so that it
>     won't
>> be hooked again? Is that a kernel service or will I need a way to
>     mark
>> the packet? I'm assuming here, that net_inject is the correct way to
>> handle this.
>>
>> I've  tried net_inject with QUEUE_IN, but  I really don't want the
>> PHYSICAL_IN hook to see it again.
>>
>> Thanks,
>> Fred
>> ------------------------------------------------------------------------
>
>>
>> _______________________________________________
>> networking-discuss mailing list
>> [email protected]
>     <mailto:[email protected]>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>networking-discuss mailing list
>[email protected]
>  
>

_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to