FW: dlil_attah_interface_filter
FW: dlil_attah_interface_filter
- Subject: FW: dlil_attah_interface_filter
- From: "Carl Smith" <email@hidden>
- Date: Wed, 6 Apr 2005 16:33:27 -0400
- Thread-topic: dlil_attah_interface_filter
> In my NKE I have attached some filtering using
> 'dlil_attach_interface_filter' and pointed my call back functions via
> this call.
>
> The filtering works find and in my call back function,
> My_if_input(caddr_t cookie, struct ifnet **ifnet_ptr, struct mbuf
> **mbuf_ptr), I want to get/look at the filter ID of the calling
filter.
> This is the value that was obtained in the previous calling to
> 'dlil_attach_interface_filter'.
>
Another question I have relating to the above statement, is that in
My_if_input I am trapping the mbuf, Ethernet frame, as it is coming in.
That is from the outside world into the stack/machine. Now if I want to
change this packet and send it along it's way and I want to use the
functions dlil_inject_if_input, dlil_inject_if_output, am I correct in
assuming that in my filtering function My_if_input, I would use
dlil_inject_if_input and in My_if_output filter function I would use
dlili_inject_if_output to send these 'altered' packets on there way? The
only reason I am asking that as I was looking at the sample SharedIP I
see that in the 'send' calls, i.e. si_send_eth_ipv4 the code is calling
dlil_inject_pr_input. I thought a send was a call to the outside world
so I would have thought the proper dlil call would have been
dlil_inject_pr_output. This last statement along with the fact that
every time I use dlil_inject_if_input in my My_if_input function I am
getting a kernel panic, I am wondering if my logic or thinking is wrong.
I would appreciate any feedback
Carl
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden