Subject: Re: dhcpd(8) _cannot_ be completely disabled on an interface
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Andrew Brown <firstname.lastname@example.org>
Date: 01/08/2002 02:55:58
>>>>> 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
>> 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
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
# 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. :)
|-----< "CODE WARRIOR" >-----|
email@example.com * "ah! i see you have the internet
firstname.lastname@example.org (Andrew Brown) that goes *ping*!"
email@example.com * "information is power -- share the wealth."