Re: NDRV sockets and Protocol Match error
Re: NDRV sockets and Protocol Match error
- Subject: Re: NDRV sockets and Protocol Match error
- From: "Duane Murphy" <email@hidden>
- Date: Fri, 5 Dec 2003 12:41:42 -0800
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
_______________________________________________
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.