>> On a related topic, there appears to be a code error in the
>> IPSEC code.
>>
>> Specifically, the priv flag is set to 1 if the user is root
>> and the socket is non-null (this lets the code be called
>> from the bridging code as well, so ignore the first half of
>> the "if" test, and concent
On Mon, 8 Oct 2001, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Yar Tikhiy writes:
> : First, the current implementation of the utility function
> : ether_ioctl(), which can do good job common to ethernet drivers,
> : won't indicate the situation when an ioctl command is unsupported
> : b
On Sunday, October 07, 2001, Mike Barcroft wrote:
> for (i = 0; ip_whois[i] != NULL; i++) {
> - if (strstr(buf, ip_whois[i]) == NULL)
> + if (strnstr(buf, ip_whois[i], len) ==
> +
I haven't reviewed that particular piece of code for correctness, but
noticed that the caching of the privilege check there actually does cause
problems for a variety of reasons in my work. I'd much rather individual
uses of suser() appeared in the netinet6 tree, and that appropriate
context for
Why does vlans announce themselves as being 10 Mbits/s? I'm getting this
from snmp on vlans that are attached to 100 Mbits/s cards.
--
Daniel C. Sobral (8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
You cannot kill time without injuring eterni
< said:
> Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI.
> There is code obviously taken from if_loop.c and used in some
> drivers, which tries to do something with the third argument "data"
> of the if_ioctl() driver method if "data" isn't NULL.
The historic implementation pas
On Mon, Oct 08, 2001 at 09:03:54AM -0600, Warner Losh wrote:
> Actaully, it should return ENOTTY rather than EINVAL. ENOTTY means
> that the ioctl isn't understood. I've had to fix several drivers at
> work that didn't follow this convention due to ignorance on the part
> of the driver writer.
In message <[EMAIL PROTECTED]> Yar Tikhiy writes:
: First, the current implementation of the utility function
: ether_ioctl(), which can do good job common to ethernet drivers,
: won't indicate the situation when an ioctl command is unsupported
: by it. It will return 0 in this case. Wouldn't it b
Hi there,
I'd like to discuss the following issues prior to
modifying the kernel.
First, the current implementation of the utility function
ether_ioctl(), which can do good job common to ethernet drivers,
won't indicate the situation when an ioctl command is unsupported
by it. It will return 0 i
