>>>>> IP_RECVIF gets you the if_index value for the interface [...]
>>>> [...wishing for something "more useful" than that...]
>>> What would you consider "useful"?  The if_index values are the only
>>> unambiguous fixed-size names interfaces have, as far as I know.
>> if i receive a datagram on a socket, i (naively?) expect that the
>> interface will still be there by the time i construct a reply that i
>> wish to send out said interface,
>
>This will _probably_ be true, and if it isn't, it's probably no big
>deal as long as the failure mode is not too catastrophic.

probably not, no.  except that the time it takes me to map, from
userspace, the interface number to a name, widens the gap ever so
slightly.  :)

>> in which case the interface "name" and "address" (which have the same
>> lifetime issues as the number)
>
>I don't think so, not if numbers are assigned sequentually at boot and
>never repeated.  In practice today, a 32-bit serial number will never
>be repeated; a 64-bit probably will never be repeated for the
>foreseeable lifetime of NetBSD.  Interface name strings and addresses
>tend to repeat, and generally are not fixed-size anyway (though I'm not
>sure how much difference that last makes for IP_RECVIF).  I don't know
>offhand whether if_index numbers satisfy this criterion.

true, but i can much more easily open a bpf and "bind" it to an
interface than i can dig for the numbertoname mapping and then do the
binding.  if i can't find the number in such an instance...well, then
i guess i oughta just forget about it.  i just consider the name "more
useful" than the number.

>> are much more useful since i don't have to do dig in the kernel for
>> them.  dig here equates to something like SIOCGIFCONF.
>
>But how could you use either one?  What you really want is your
>application's internal name for an interface, and what's most useful
>for locating that depends on why you care about which interface is
>which.

sure, and how i actually map the "number" (or "name") to a descriptor
i have open (or need to open) is up to me.  however, telling me simply
the interface number when i ask to be told the receiving interface
strikes me as too little information.

>>>> i tried adding an arp entry via a routing socket once.  [...]
>>> [Routing messages] _are_ poorly documented.  [...]
>> not very well documented *or* implemented.  imho, me getting it wrong
>> as part of my learning process should not incur punishment in the
>> form of the kernel panicking.
>
>I'm inclined to agree with you in this case.  But when you're running
>as root, the "userland being able to panic the machine is always a bug"
>dictum is no longer really valid; consider dd if=/dev/zero of=/dev/mem.
>I've tried a few times to draw a line on the far side of which is stuff
>like that dd, for which it's unreasonable to expect that dictum to
>hold, and on the near side of which is stuff like ls, for which it's
>not.  So far I've not come up with anything even vaguely satisfactory.

yes, but there's a vast difference between "if i do this, i intend to
shoot myself in the foot" and "i will try this and expect the kernel
to protect my foot" expectations.  for example:

	# cat > /etc/ipf.conf << EOF
	pass in quick on lo0 out lo0
	EOF
	# ipf -Fa -f/etc/ipf.conf
	# ping 127.0.0.1

is a good way to shoot yourself in the foot.  "so don't do that."

>> hmm...i guess i oughta fix that a little.  :)
>
>:-)

:P

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."