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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
