Re: struct dlil_if_flt_str
Re: struct dlil_if_flt_str
- Subject: Re: struct dlil_if_flt_str
- From: Justin Walker <email@hidden>
- Date: Tue, 15 Mar 2005 14:26:14 -0800
On Mar 15, 2005, at 14:16, 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.
That's just sick :-}
Now if someone or something is doing some kind of header
filtering or type checking and throwing away unknown packets types, I'm
screwed.
I don't expect any component of the system to throw away packets that
aren't known to it. Thumb's Rule in networking says to be conservative
in what you send and liberal in what you receive. A filter that
swallows what it doesn't understand probably won't last long as a
product.
If the later is the case then I need to be lower then a dlil interface
filter.
There is little that's lower than a DLIL interface filter.
[Politicians and lawyers spring to mind, but that's a subject of a
different thread]
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.
Another of Thumb's Rules says that you should *always* build one to
throw away...
Cheers,
Justin
--
/~\ The ASCII Justin C. Walker, Curmudgeon-at-Large
\ / Ribbon Campaign
X Help cure HTML Email
/ \
_______________________________________________
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