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]> 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] >
_______________________________________________ networking-discuss mailing list [email protected]
