Very Computer

Hello, all

I am building a streams module for solaris 8 that sits between IP and
the
ethernet header. By sending a NAK on the DL_IOC_HDR_INFO ioctl I have
forced
IP to disable the "fastpath" mechanism and use the standard DLPI
mechanism of DL_UNITDATA_REQ for outgoing traffic.

This does not seem to work for incoming traffic. The first data from a
'new'
source is received as a DL_UNITDATA_IND M_PROTO message (with chained
M_DATA mesgs). After that, all data is received as M_DATA messages !?

Am I doing something wrong? I want to use the M_PROTO data to retrieve
the source MAC address. Without this M_PROTO, there seems to be no
safe way to establish this address (except peeking 14 bytes before the
b_rptr).

Thanks in advance

Eric Weisink

Quote:> Hello, all

> I am building a streams module for solaris 8 that sits between IP and
> the
> ethernet header. By sending a NAK on the DL_IOC_HDR_INFO ioctl I have
> forced
> IP to disable the "fastpath" mechanism and use the standard DLPI
> mechanism of DL_UNITDATA_REQ for outgoing traffic.

> This does not seem to work for incoming traffic. The first data from a
> 'new'
> source is received as a DL_UNITDATA_IND M_PROTO message (with chained
> M_DATA mesgs). After that, all data is received as M_DATA messages !?

> Am I doing something wrong?

It looks right to me.
Which ethernet driver are you using?
Do you have another NIC you can try which uses a different driver?

--
Andrew Gabriel
Consultant Software Engineer

Quote:> Hello, all

> I am building a streams module for solaris 8 that sits between IP and
> the
> ethernet header. By sending a NAK on the DL_IOC_HDR_INFO ioctl I have
> forced
> IP to disable the "fastpath" mechanism and use the standard DLPI
> mechanism of DL_UNITDATA_REQ for outgoing traffic.

From my experience with DLPI on Solaris (and others platforms), on Solaris
you can bind to a network adapter and there is no need to disable fastpath
to receive packets.

Quote:

> This does not seem to work for incoming traffic. The first data from a
> 'new'
> source is received as a DL_UNITDATA_IND M_PROTO message (with chained
> M_DATA mesgs). After that, all data is received as M_DATA messages !?

You first need to attach to the proper interface (since Solaris is a
DLPI style 2 provider), then you need to DL_BIND_REQ preferably in
DL_CLDLS (connectionless) and probably also to dl_sap of ETHERTYPE_IP
(for others OS, for example HP-UX it's different).
After this usually every getmsg() will give you a M_PROTO and a M_DATA.

Quote:> Am I doing something wrong? I want to use the M_PROTO data to retrieve
> the source MAC address. Without this M_PROTO, there seems to be no
> safe way to establish this address (except peeking 14 bytes before the
> b_rptr).

To get your own MAC address, I'd recommend the DL_PHYS_ADDR_REQ with
dl_addr_type as DL_CURR_PHYS_ADDR. You will get the MAC in the ctlptr.
If you want to try to get your MAC from the network, you'd have trouble knowing
it if you're in promisc mode or if there is no one to send packets to you.

--
People are more *ly opposed to fur than to leather because it's
safer to harass rich women than motorcycle gangs.
http://www.veryComputer.com/;-  ICQ UIN: 2295979

I disabled fastpath to force Solaris to present incoming data as
separate M_PROTO and M_DATA

Quote:

> > This does not seem to work for incoming traffic. The first data from a
> > 'new'
> > Am I doing something wrong? I want to use the M_PROTO data to retrieve
> > the source MAC address. Without this M_PROTO, there seems to be no
> > safe way to establish this address (except peeking 14 bytes before the
> > b_rptr).
> To get your own MAC address, I'd recommend the DL_PHYS_ADDR_REQ with
> dl_addr_type as DL_CURR_PHYS_ADDR. You will get the MAC in the ctlptr.

As I wrote, output is OK, but incoming data is strange. With "source
address" I meant the MAC address of the remote computer. For my
streams module, I need to know that MAC address.

It seems that Solaris uses some performance optimasation by sending
the first message from a remote source as M_PROTO+M_DATA, and all
subsequent data as M_DATA messages.

Thanks for any help

Eric Weisink

Yes -- that's the undocumented fastpath mechanism.  It's enabled by
the DL_IOC_HDR_INFO ioctl (sys/dlpi.h), so if you intercept that ioctl
and M_IOCNAK it, that will disable the use of raw M_DATA on the
stream.

--

Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677