On February 17, [email protected] wrote:
> On Fri, 2003-02-14 at 17:53, Neil Brown wrote:
> > No.
> > My application (which is just using standard rpc server libraries) is
> > saying
> > "This is in reply to a request that came in through a given
> > interface".
> >
> > It is not reasonable to treat that statement as equivalent to:
> > "This packet must go out that interface"
> >
> > which is what appears to be happening.
>
> You misunderstand what this control message knob means during
> a sendmsg() then, it means "send this over interface X"
>
> There is no other valid expectation.
>
> I'm curious where you read something that would suggest otherwise
> for sendmsg() behavior wrt. ip_pktinfo
man 7 ip
on debian (unstable).
I quote:
IP_PKTINFO
Pass an IP_PKTINFO ancillary message that contains a pktinfo
structure that supplies some information about the incoming
packet. This only works for datagram oriented sockets. The
argument is a flag that tells the socket whether the IP_PKTINFO
message should be passed or not. The message itself can only be
sent/retrieved as control message with a packet using recvmsg(2)
or sendmsg(2).
struct in_pktinfo {
unsigned int ipi_ifindex; /* Interface index */
struct in_addr ipi_spec_dst; /* Local address */
struct in_addr ipi_addr; /* Header Destination address */
};
ipi_ifindex is the unique index of the interface the packet was
received on. ipi_spec_dst is the local address of the packet
and ipi_addr is the destination address in the packet header.
If IP_PKTINFO is passed to sendmsg(2) then the outgoing packet
will be sent over the interface specified in ipi_ifindex with
the destination address set to ipi_spec_dst
Note that the in_pktinfo is described as "some information about the
incoming packet". In particular ipi_ifindex is "the unique index of
the interface the packets was received on".
i.e. it is more about the incoming than the outgoing packet.
It does go on to say that the outgoing packet will be sent over the
same interface, however I feel that is an illogical conclusion given
the description of the meaning of the field.
So yes, the current behaviour seems to match part of the
documentation. However I argue that the documented behaviour is
irrational.
A more rational behaviour is
"the outgoing packet will be sent over the interface specified in
ipi_ifindex if that interface has a valid route to the packets
destination. Otherwise normal rouing rules apply".
I further argue that this is not only more rational, but is actually
more useful (which is a more telling point).
NeilBrown
Hello!
> So yes, the current behaviour seems to match part of the
> documentation.
Good. :-)
> "the outgoing packet will be sent over the interface specified in
> ipi_ifindex if that interface has a valid route to the packets
> destination. Otherwise normal rouing rules apply".
>
> I further argue that this is not only more rational, but is actually
> more useful (which is a more telling point).
Either you rely on routing tables, or you do not, which is used
when routing tables are still not set up, or setup ambiguously,
or use of them just do not make sense which happens for multicasts/
limited/broadcasts/link local addresses. It is the thing which ifi_ifindex
does.
I do no see how it is possible to classify a middle way as "rational".
Well, and frankly speaking I do not see how it could be useful.
Alexey
From: Neil Brown <[email protected]>
Date: Tue, 18 Feb 2003 22:00:37 +1100
It does go on to say that the outgoing packet will be sent over the
same interface, however I feel that is an illogical conclusion given
the description of the meaning of the field.
So yes, the current behaviour seems to match part of the
documentation. However I argue that the documented behaviour is
irrational.
Alexey and myself totally disagree. We have described for you
the intended purpose of this feature. Please do not try to use
it in some other way, it may prove to be painful :-)