RE: struct dlil_if_flt_str
RE: struct dlil_if_flt_str
- Subject: RE: struct dlil_if_flt_str
- From: "Carl Smith" <email@hidden>
- Date: Tue, 15 Mar 2005 14:34:34 -0500
- Thread-topic: struct dlil_if_flt_str
Great stuff Josh the exact and clear information I was looking for.
OK so I know how I could handle the output packet manipulation but I
want to ask how I could manipulate the inbound packets and pass it on to
the stack correctly.
The return for the filter_if_input() function is a pointer to the
inbound parameter *m_orig. So say I wanted to change something in the
ethernet header, dest. Address, source address and/or type, then do
something to the data(expand it, compress it, ...), how would I pass
this correctly back in the m_orig?
Could I just deincrement the pointer on the mbuf, do all my stuff to the
header and packet data and pass the original incremented point of the
incoming mbuf or would I have to send the deincremented pointer as mbuf?
In short can I manipulate the ethernet header on the inbound call?
Also could someone point me to the spot in the source code that calls
this function, "int(*filter_if_input)(caddr_t cookie, struct ifnet
**infnet_ptr, stuct mbuf **mbuf_ptr, char **frame_ptr)"??
Am I making myself clear?
Carl
-----Original Message-----
From: Josh Graessley
Sent: Tuesday, March 15, 2005 1:53 PM
To: Carl Smith
Cc: email@hidden
Subject: Re: struct dlil_if_flt_str
*frame_ptr points to the frame header. The driver is responsible for
setting this pointer. For ethernet interfaces, this points to the
ethernet header. It is passed as a ** so the filter may change where
the value of the pointer. The header is usually set to point at the
start of the packet in the mbuf. The mbufs data pointer is then moved
to point to the data in the packet following the header.
On the output side, there is no frame_ptr because the the entire
packet including the frame header is in the mbuf.
Yes. The mbuf stores the meat of the packet. On the outbound path, it
stores the entire packet. On the inbound path, it store the entire
packet, but the data pointer has been incremented past the packet
header and the pointer to where the header starts is passed
separately as the frame_ptr. There are no guarantees that the
frame_ptr points to data in the mbuf, but that's how it's
implemented, and any other implementation would be problematic, so
that probably won't ever change.
-josh
On Mar 15, 2005, at 10:40 AM, Carl Smith wrote:
> I have a NKE which I got the callbacks working for packet capture
> using the functions in the Struct dlil_if_flt_str.
>
> What I am looking at is the filter_if_input and filter_if_output.
>
> I see that in the filter_if_input call back there is a param of
> char **frame_ptr. My questions are, is this param, frame_ptr, the
> complete Ethernet fram, and if so how could I look at the contents?
> If it is a buf of char, but it does not give a length, in the
> passed in values, it must be of some struct form, or there should
> be some way to cast it to some struct to be able to see it's
> contents. Does any one know what the structure is?
> Also in filter_if_output I also notice there is NO frame_ptr type
> parameter, can some explain why?
>
>
>
> And finally I guess I would be interested in the mbuf_ptr
> parameters of both functions if I what to trap and/or alter any of
> the packets coming or going from the stack, yes/no?
>
>
>
> Thanks for everyone's help and input
>
> Carl
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> 40apple.com
>
> This email sent to email@hidden
_______________________________________________
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