Re: IP_PKTINFO, sendmsg(2) and routing.

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

I wrote:

> I plan to have running code some time during the coming weekend; I'm
> going to the cabin for a couple of days' relaxation, so this is perfect.

Well, that didn't work out the way I expected - the first thing that
happened after getting up there was that my home system crashed and
didn't reboot, so I was without my development environment, my email,
and my IRC client.  NetBSD-current with local modifications... :)

Anyway, I no longer think there's anything to really change in this
code.  You're just expecting a bit more from it than it offers.

Here's how it works:

Source address selection: if you supply a source address, it is used,
but it must be bindable, i.e. it must be either a unicast address
currently configured on some interface on the system, or a multicast
address.  If you do not supply a source address (that is, you supply
INADDR_ANY in the ipi_addr field), then the ipi_ifindex field is
checked, and the primary address configured on that interface is used.

Interface selection: if you supply an interface index, it will be used
for selecting the outgoing interface, but only if the packet being sent
doesn't require routing.  Specifically, you can send to multicast
addresses, or to INADDR_BROADCAST, and direct those packets to the
interface of your choice.  Unicast destinations will work if you happen
to point them at the interface they would've been routed out anyway, but
will otherwise fail.

Roy Marples wrote:

> But, in a nutshell, the most basic multi-homed implementation is the
> DHCP client.  IP_PKTINFO allows us NOT to need BPF.  We should be
> able to send from the unspecified address to the broadcast address
> on a specific interface using IP_PKTINFO for the DHCP_DISCOVER
> message.

So no, you can't do that.  If you want to send from INADDR_ANY, you have
to use BPF.  IP_PKTINFO will only work for sending from bindable
addresses on the sending host, as described above.  Raw sockets let you
do more fiddling, but even they won't allow you to send from INADDR_ANY.

> So what benefit does IP_PKTINFO bring us for sending exactly?

Its primary purpose is making it possible for connectionless services on
multi-homed systems to correctly respond to incoming packets from the
same address the incoming packet was sent to.

Additionally, IP_PKTINFO will let you transmit broadcast and multicast
packets over specifically chosen interfaces.

In FreeBSD, they solved the multi-homed system problem by adding the
IP_SENDSRCADDR option to complement the existing IP_RECVDSTADDR one,
whereas the Linux folks decided to create IP_PKTINFO modeled on the
standardized IPV6_PKTINFO, and botched it by gratuitously making the API
slightly different.  We now have both of these mechanisms, and are
source code compatible with both FreeBSD and Linux - while we also
maintain better orthogonality with IPv6.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay