Re: NDRV sockets and Protocol Match error
Re: NDRV sockets and Protocol Match error
- Subject: Re: NDRV sockets and Protocol Match error
- From: Joshua Graessley <email@hidden>
- Date: Fri, 5 Dec 2003 13:16:04 -0800
Duane,
The desc.protocol_family should not be NDRV_DEMUXTYPE_SNAP.
desc.protocol_family should be something like PF_INET. It should
represent the protocol of the packets you are registering to receive.
The ndrv_demux_desc structure(s) define what type of packets you are
interested in receiving. In the case of Ethernet, the ndrv_demux_desc
specifies Ethernet Type 2 frames, SAP, or SNAP protocols. For example,
to receive IP related packets, two ndrv_demux_desc structures are used.
One of them for the IP packets (ETYPE2 0x0800) and one for ARP (ETYPE2
0x0806).
The ndrv_protocol_desc is basically a header that tells the kernel how
many demux descriptors are required and which protocol family these
demux descriptors will capture packets for. The primary purpose of the
protocol family is to allow protocol filters to filter packets between
the interface and that protocol.
In the case of some protocol that isn't listed in sys/socket.h, things
are a little messy. You need to pick a protocol family that is unlikely
to be used by anyone else. It may be possible to request a value from
DTS, but I'm not sure. An example of this might be 802.1x. 802.1x is a
protocol that isn't listed in sys/socket.h. It is possible that someone
may want to write an 802.1x client. They could use PF_NDRV to register
the demux descriptors to get the 802.1x packets. They would need to
pick some protocol family.
When picking a protocol family, don't use a value less than 255. Socket
addresses have an address family field that usually matches up with a
protocol family. For example, AF_INET == PF_INET. The socket address
family field is only 1 byte long. We'd like to preserve all protocol
family values <= 255 for future use in protocols implemented in the
kernel.
-josh
On Dec 5, 2003, at 12:41 PM, Duane Murphy wrote:
>
Thanks for the help Joshua,
>
>
--- At Fri, 5 Dec 2003 11:06:52 -0800, Joshua Graessley wrote:
>
>
> What are you passing for "prot_family"?
>
>
As the code shows, both are using NDRV_DEMUXTYPE_SNAP.
>
>
> When you attach a protocol to an interface, the code verifies that the
>
> protocol isn't already attached. The code responsible for doing this
>
> doesn't know much about the format of the demux descriptors (these
>
> could potentially contain interface specific types). Instead, it looks
>
> at the protocol family. If a protocol is already attached to the
>
> interface with that protocol family, you will get an EEXIST error.
>
>
Hmm, I thought it was something like that. So the socket is not
>
important
>
but rather the interface that the socket is attached to. The socket is
>
just a conduit to program the interface.
>
>
Hmm, this brings up some questions about how to approach this.
>
>
1. I expect that I can register more than one SNAP type for an
>
interface
>
then, that is an array of ndrv_demux_desc. They just have to be
>
registered together. ie it's "setting" not "adding".
>
>
Provided the above is true:
>
>
2. What is the affect on the sockets? If I have two sockets open on the
>
same interface and one of the sockets has two families, do both sockets
>
get the data or just the one? What is the relationship between
>
registering a protocol match and open NDRV sockets on that interface?
>
>
3. Is the value of the protocol family "important" or can I just make
>
them up to keep them seperate and non-colliding? Would this fix my
>
problem?
>
>
> On Dec 5, 2003, at 9:17 AM, Duane Murphy wrote:
>
>
>
>> We are using PFNDRV raw ethernet sockets in our product. We are
>
>> running
>
>> into a case where adding a protocol matching specification is failing
>
>> with -1 and errno is 17 (EEXIST -- File exists).
>
>>
>
>> All of the protocol specifications are for SNAP.
>
>>
>
>> We are using two sockets at the same time on the same physical port
>
>> with
>
>> different two different SNAP protocol specifications. The first one
>
>> works
>
>> just fine. The second one fails.
>
>>
>
>> The sockets are seperate, so we arent adding protocol specs to the
>
>> same
>
>> socket. If the error is ignored, the socket works fine for sending,
>
>> the
>
>> data goes out but nothing is accepted.
>
>>
>
>> What can cause this error from setsockopt? Are there limits that we
>
>> need
>
>> to be aware of?
>
>>
>
>> The SNAP codes we are registering are:
>
>>
>
>> { 0x00, 0x20, 0xEA, 0x02, 0x02 }
>
>> { 0x00, 0x20, 0xEA, 0x81, 0x4C }
>
>>
>
>> Here is the code we are using to register:
>
>>
>
>> int add_protocol_match(
>
>> int fd, u_int32_t prot_family, ndrv_demux_desc* in_demux )
>
>> {
>
>> ndrv_protocol_desc desc = {};
>
>>
>
>> desc.version = NDRV_PROTOCOL_DESC_VERS;
>
>> desc.protocol_family = prot_family;
>
>> desc.demux_count = 1;
>
>> desc.demux_list = in_demux;
>
>>
>
>> int result = setsockopt(
>
>> fd, SOL_NDRVPROTO, NDRV_SETDMXSPEC,
>
>> reinterpret_cast< caddr_t >( &desc ),
>
>> sizeof desc );
>
>> return result;
>
>> }
>
>>
>
>> int ENI::Socket::ethernet_socket::add_snap_protocol_match(
>
>> int in_socket,
>
>> const u_char* in_snap_address )
>
>> {
>
>> ndrv_demux_desc demux_desc = {};
>
>>
>
>> demux_desc.type = DLIL_DESC_SNAP;
>
>> demux_desc.length = sizeof demux_desc.data.snap;
>
>> demux_desc.data.snap[0] = in_snap_address[0];
>
>> demux_desc.data.snap[1] = in_snap_address[1];
>
>> demux_desc.data.snap[2] = in_snap_address[2];
>
>> demux_desc.data.snap[3] = in_snap_address[3];
>
>> demux_desc.data.snap[4] = in_snap_address[4];
>
>>
>
>> int result
>
>> = add_protocol_match( in_socket, NDRV_DEMUXTYPE_SNAP, &demux_desc
>
>> );
>
>> return result;
>
>> }
>
>
...Duane
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.