Subject: Re: dhcpd(8) _cannot_ be completely disabled on an interface
To: None <tech-net@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-net
Date: 01/09/2002 09:51:40
[Dropping tech-security, as this has nothing to do with security that I
can see any longer.]

>>>>>>>> [...IP_RECVIF...if_index...]
>> I think it would be easy to make IP_RECVIF - or something similar,
>> cloned from it, IP_RECVIFNAME maybe - give you the interface name
>> instead of the number.  Of course, it will be variable-size; this
>> may complicate your userland code somewhat.  Want me to try?
> what about having it simply fill in (and return) a struct
> sockaddr_storage?

Fill it in with what?  The interface name?  I'd rather use a fixed-size
(relatively large, like 16 or 32) array of char, if you want the name
in something fixed-size.

If you're thinking fill it in with the interface's address, I have two
questions: (1) which of the interface's addresses?, (2) what if
multiple interfaces have that address?

>> Oh, certainly.  Just remarking that I have had a great deal of
>> trouble codifying that the line between "that's a bug" and "so don't
>> do that".
> if you expect something of the kernel, and it doesn't live up to it
> (and no, dd'ing /dev/zero into /dev/mem is *not* something you can
> expect the kernel to live up to),

But why not?  The difficulty I've had lies in trying to be precise
about exactly why it's not reasonable to expect the kernel to survive
dd if=/dev/zero of=/dev/mem but it is reasonable to expect it to
survive, say, experiments with routing sockets.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B