Date: Mon, 05 Mar 2007 01:40:26 +0000 From: Bruce M Simpson <bms@incunabulum.net> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Ethernet cleanup; 802.1p input and M_PROMISC Message-ID: <45EB750A.90105@incunabulum.net> In-Reply-To: <20070304070458.GG40430@comp.chem.msu.su> References: <45E8B964.2090200@incunabulum.net> <20070303215359.GB40430@comp.chem.msu.su> <45EA0756.2000107@incunabulum.net> <20070304070458.GG40430@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
Yar Tikhiy wrote: > > Now I see your point, thanks! Well, at least in theory, the driver > shouldn't call ether_input() if the interface isn't running. OTOH, > the interface shouldn't be getting traffic if it's !UP. However, > I suspect that not all drivers handle IFF_UP fully or even can do > it at all due to hardware limitations. As I understand it, in an > ideal world a !UP interface should be deaf and dumb and not interfering > in any way with the network still connected to it physically. > Therefore discarding inbound traffic from a !UP interface may be a > necessary workaround, but it may not be enough. All that boils > down to this: The IFF_UP check in ether_input() is more to a sanity > check than to the way for IFF_UP to work. Therefore we can add the > IFF_DRV_RUNNING sanity check there, too, for completeness. > Thanks for your explanation. I'm still not sure I understand why IFF_DRV_RUNNING should be checked for in ether_input(). There is a pretty clear reason for checking for IFF_UP in ether_input(); an interface which is configured administratively down should not be bringing traffic into the stack, regardless of whether it is a hardware device or a pseudo-device. IFF_UP has been in since 4.2BSD; it is more or less integral to how the BSD network stack operates. There are situations in which a pseudo-device or hardware device could incorrectly call ether_input() with such traffic. Reading <net/if.h>, IFF_DRV_RUNNING is documented as meaning 'resources are allocated for this device'. Surely such a check is redundant and not relevant to the operation of ether_input()? As far as I can tell it is similar to the old meaning of IFF_RUNNING, and there are legitimate situations in which the hardware or its queues may have stopped processing temporarily whilst the interface may be administratively up (and thus accepting traffic). Please correct me if I'm wrong or point out situations where it's important IFF_DRV_RUNNING state is checked outside of a driver. Sorry if I seem obtuse, but I'm sure I'm missing some detail here. Regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45EB750A.90105>