On Tue, 2008-05-27 at 18:33 -0400, Peter Memishian wrote:
> > > - 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?
Since the kernel already has all of the information needed to build a
link-layer header, the destination address passed down with
DL_UNITDATA_REQ is ignored. I can't think of a compelling reason to
require that the addressed passed down by the application be the same as
the destination address configured on the tunnel, as that just poses
unnecessary restrictions on applications (they need to first find out
what that address is, when there isn't really a need for them to know).
> Minimally, won't 6to4
> tunnels still require an explicit tunnel destination to be specified?
No, the idea behind automatic tunneling is that the outer destination
address is automatically generated for each outgoing packet based on the
inner packet contents (for 6to4, this is based on the inner IPv6
destination address). For any given IPv6 packet transmitted to a 6to4
tunnel link, there is only one correct outer IPv4 destination. The
destination passed down along with the message is therefore ignored.
>
> 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).
Sounds good.
>
> 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?
The above seems good to me.
-Seb
