On Thu, 13 Apr 2006, Rao Shoaib wrote:
Debian:
http://manpages.debian.net/cgi-bin/display_man.cgi?id=719767c6f553f49d5b0ed43486cb0619&format=html
Seems to be the old man page.
Redhat:
http://www.penguin-soft.com/penguin/man/7/ip.html
Seems to be a newer version, with a documentation bugfix :), as from:
If you are interested in knowing how the Redhat page has evolved
please read the thread
http://www.uwsg.iu.edu/hypermail/linux/kernel/0302.2/0515.html
It seems.
I find the Redhat man page to be confusing and I do not understand what
'primary local address of the interface' means.
Typically, for a given subnet and a set of addresses on an interface
matching that subnet exactly, the oldest address. More precisely (but
less specifically) the address which source-address selection would pick
for packets out that interface to that subnet.
Further more on Redhat Linux when I tried to send a packet using
sendmsg and specified source address using IP_PKTINFO it went out with
source address being the address of the outgoing interface.
Hmm, havn't used outbound Linux IP_PKTINFO, but that sounds like you
specified an ifindex, in which case the documented behaviour:
"When ipi_ifindex is not zero the primary local address of
the interface specified by the index overwrites ipi_spec_dst for the
routing table lookup."
which probably is what you got?
I wouldn't disagree Jim that this is not particularly useful / elegant
(I've never used outbound PKTINFO).
IPV6. If you believe that semantics of RFC 3542 should not be applied
to IPV4 please speak up.
I still think some kind of compromise at least between the documented
behaviour of existing implementation and RFC3542 would be best for
users, the following external projects (from a quick googling) at least
seem to be using (or interested in using, given bug reports) IP_PKTINFO:
FreeRADIUS
Avahi
netcat
ISC NTP
OpenVPN
MIT Krb5
Quagga
E.g. the "One sockopt, IP_PKTINFO, with an argument to indicate whether
ancillary data should be sent by kernel to application or not" seems
reasonable - at the cost of setting sticky socket data (does anyone use
sticky sockopt data???).
The details of the ancillary data structure and its semantic meaning
then can /still/ follow RFC3542, which I wouldn't dispute as being the
more sane. ;)
That seems like it could both make life easier for external users of
IP_PKTINFO on both Linux and Solaris, while being useful/sane. Otherwise
RFC3542 exactly, in spirit - but as my second preference vote.
regards,
--
Paul Jakma,
Network Approachability, KISS. http://quagga.ireland.sun.com/
Sun Microsystems, Dublin, Ireland. tel: EMEA x19190 / +353 1 819 9190
_______________________________________________
networking-discuss mailing list
[email protected]
