Paul Jakma wrote:
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.
Maybe but I could not find the new one, do you have a pointer to the new
one.
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.
I find this confusing and difficult to explain to a user.
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 have made sure that the index is zero. My configuration is
eth1 Link encap:Ethernet HWaddr 00:09:3D:11:23:08
inet addr:192.168.192.156 Bcast:192.168.192.255
Mask:255.255.255.0
inet6 addr: fe80::209:3dff:fe11:2308/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:131 errors:0 dropped:0 overruns:0 frame:0
TX packets:152 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11780 (11.5 KiB) TX bytes:25179 (24.5 KiB)
Interrupt:193 Memory:fe030000-fe040000
eth1:1 Link encap:Ethernet HWaddr 00:09:3D:11:23:08
inet addr:192.168.192.160 Bcast:192.168.192.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:193 Memory:fe030000-fe040000
and If I specify 192.168.192.160 as the source address the Packet
always goes out with source address of 192.168.192.156.
Have you tried using this feature when no packet has been received on
the source address that is specified. All examples I have seen use this
feature only after they have received a packet.
I wouldn't disagree Jim that this is not particularly useful / elegant
(I've never used outbound PKTINFO).
Well try it. Inbound is simple and clear except I do not understand the
need for the matched address. Outbound is just to convoluted.
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
But they are not using this on Solaris so if we define IPV4_PKTINFO the
code should keep working and we have no need to be compatible and broken.
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. ;)
After the discussion on this list I am opting to be fully compatible
with RFC3542. We need to have symmetry in programming interfaces and
behavior between V4 and V6 and not necessarily with Linux.
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.
That is not my goal as Linux implementation seems broken and there is a
standard that we can follow. I have requested Erik to run this by the
folks who were actively involved in the IPV6 API specifiction and get
their input. If deemed necessary we may even put out an ID to describe
the behavior. Hey unlike Solaris, Linux has no backward compatibility
guarantee and can change it's behavior to conform to a standard. For
Solaris it's very important that we get this right the first time.
Rao.
regards,
_______________________________________________
networking-discuss mailing list
[email protected]
