site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Thread-index: AcUqAULwTND+D+BgSmOTT5EI+Sg08ABMnsgg Thread-topic: struct dlil_if_flt_str I was reading the Network Kernel Extensions Reference documentation and I read that dlil_inject_if_input and dlil_inject_if_output both behave the same as 'dlil_input' except preceding filters are not called, so I thought these would be good functions calls to use when re-injecting my manipulated packets. Yes/No? My other question or concern is, for testing and debugging, I will be sending these 'filtered' packets up to user land to be manipulated. To keep the stack going I am making a copy of the frame, passing it up to user land, and in the mean time releasing the original muff. My question is, how would I keep track of the queue of packets that might start building up in a back log and how would I know where to insert linked list connections of the 'altered' mbuf when I send it to either dlil_inject_if_input and dlil_inject_if_output? I was looking at the macros IF_ENQUEUE, IF_...., . Would any of these macros help me? Again thanks for your help Carl -----Original Message----- From: darwin-kernel-bounces+matthieu.kopp=centraliens.net@lists.apple.com [mailto:darwin-kernel-bounces+matthieu.kopp=centraliens.net@lists.apple. com] On Behalf Of Josh Graessley Sent: Tuesday, March 15, 2005 5:42 PM To: Carl Smith Cc: darwin-kernel@lists.apple.com Subject: Re: struct dlil_if_flt_str You may want to consider re-injecting the packet after making your modifications instead of making the modifications and returning. I can't remember the details, but there is a chance that the demux code that determines which protocol the packet belongs to may have already run. Changing the protocol in the header after that point will do no good. In addition, you can attach a protocol to the interface and specify demux descriptors that describe the ethertype you are interested in. In doing so, you will get all of those packets. You can then modify them to your hearts content and inject the modified packets using dlil_input. -josh On Mar 15, 2005, at 2:16 PM, Carl Smith wrote:

...

Do you really want to futz with the frame header on the input path? Actually Yes. It can be the header retained in the mbuf, but what I am doing is looking for a particular frame type, our registered type, extracting confidential information encrypted in the packet, setting the new/replaced frame type, i.e. 0x800 and so on, then passing it up the stack. Now if someone or something is doing some kind of header filtering or type checking and throwing away unknown packets types, I'm screwed.

If the later is the case then I need to be lower then a dlil interface filter.

If there is a problem with where I have my packet capture/filtering setup I would really appreciate any comments to eliminate some 'throw' away work.

Thanks Carl

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com