> > - how to set daddrp in dlpi_send() ?
>
> This is the destination link-layer address you're sending to. Since
> this address is pre-configured as the "tunnel destination", you can send
> down 0.0.0.0, and it should work.
Is there a compelling reason to allow this, rather than require that the
destination address be the tunnel destination? Minimally, won't 6to4
tunnels still require an explicit tunnel destination to be specified?
Regarding the dlpi_send() manpage, how about:
The dlpi_send() function attempts to send the contents of _msgbuf_
over the DLPI link instance associated with DLPI handle _dh_ to the
destination address named by _daddrp_. The size of _msgbuf_ and
_daddrp_ are provided by the _msglen_ and _daddrlen_ arguments,
respectively. The attempt will fail if _dh_ is not in the DL_IDLE
DLPI state, the address named by _daddrp_ is invalid, _daddrlen_ is
larger than DLPI_PHYSADDR_MAX, or _msglen_ is outside the range
reported by dlpi_info(3DLPI).
There are some other wording improvements I'd like to make for the
remaining dlpi_send() text, resulting in the following additional
revisions:
If the _sendp_ argument is NULL, data is sent using the bound SAP
associated with _dh_ (see _dlpi_bind(3DLPI)_), and with the default
priority range. Otherwise, the _sendp_ argument must point to a
dlpi_sendinfo_t structure, defined in <libdlpi.h> as follows:
typedef struct {
uint_t dsi_sap;
dl_priority_t dsi_prio;
} dlpi_sendinfo_t;
The _dsi_sap_ value indicates the SAP to use for the message, and the
_dsi_prio_ indicates the priority. The priority range spans from 0
to 100, with zero being the highest priority. If one wishes to only
alter the SAP or priority (but not both), the current SAP can be
retrieved using dlpi_info(3DLPI), and the default priority can be
requested via the DL_QOS_DONT_CARE constant.
If the handle is in raw mode, as described in dlpi_open(3DLPI), the
msgbuf must start with the link-layer header; see dlpi(7P). In raw
mode, the contents of _daddrp_ and _sendp_ are ignored, as they are
already specified by the link-layer header in _msgbuf_.
If _msgbuf_ is accepted for delivery, no error is returned. A
successful return does not guarantee that data will be successfully
delivered to daddrp because only the unacknowledged connectionless
service (DL_CLDLS) is currently supported.
Comments?
--
meem
