Thomas Bastian writes:
> We consider two major modes: one that applies at the device level
> and one that applies at the stream level:
What is the motivation for having two separate ways to set this? Why
not have this new feature _only_ at the stream level? Are there usage
models that correspond to both levels? The only one I see is
DLT_LINUX_SLL, which seems to imply stream-level (though I'm not
positive).
How do these two mechanisms interact with each other? You say that
the device level "takes precedence," but what does that really mean?
If I set DL_PROMLOOP_DEV_ON at the device level, does this mean:
a. Current open streams are unaffected, but newly-opened ones will
default to having the flag turned "on."
b. All open streams at the point in time in which I send
DL_PROMLOOP_DEV_ON will be switched into loop-on mode, even
those that had previously set DL_PROMLOOP_STR_OFF.
c. All open streams are switched to loop-on mode, and, because this
takes precedence over the stream level control, subsequent use
of DL_PROMLOOP_STR_OFF does nothing.
Does the proposal distinguish between looped-back traffic that
originates with the stream user and traffic that originates with other
streams?
It seems to me that snoop(1M) relies on being able to catch packets
transmitted by all streams, but that since it never sends any packets,
it doesn't care about self-originated traffic. Further, raw DLPI
users simply never (as a matter of design) want to see their own
traffic looped back.
So, why not dispense with the knob entirely, and simply change the
definition? Fix it so that promiscuous mode in DLPI does not itself
loop back traffic to the same stream that generated it. I.e., only
cases that cause loopback in the non-promiscuous behavior would loop
back. This would simplify the driver changes, the documentation, the
user interface, and the porting work required for applications.
Is there any case in which seeing the unicast traffic that you
generated on your own promiscuous-mode stream is not a bug?
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
