[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Broadcast traffic on vlans leaks into the parent interface on NetBSD-5.1
[Dennis, sorry for the off-list copy of a similar reply; my botch.]
>>> I believe every use of BPF by an application to send and receive
>>> protocol traffic is a signal that something is missing in the
>>> host's network implementation, [...]
>> ...in general, I agree, but in the case of DHCP, I'm not so sure.
> [...] the general argument I can find in there seems to be of the
> - The application has a legitimate need to do X.
> - The network stack has no way to do X for it.
> - Therefore, the answer is BPF (or some equally big hammer
Yes, that's about what was in what I actually wrote. I really should
have elaborated more.
For a more precise phrasing, see below.
> [...] you'd have three choices: (i) find a workaround a la BPF, (ii)
> find the minimal patch to the kernel networking which allows your
> particular application work, or (iii) figure out the fundamental,
> root cause of the kernel's inability to do what you need, and the
> classes of other applications which are going to have difficulty with
> this, and spend the effort developing a solution which resolves this
> for as many applications (including [yours]) as possible.
My position can more accurately be phrased as: my estimates are that
the set of relevant applications is small enough, the work involved for
(iii) or even (ii) is high enough, and the costs associated with (i)
are low enough, that BPF is a right answer.
This is not to say that reasonable disagreement on any - or even all -
of those points is impossible, nor that there are no other right
answers. However, since we've already got an implementation of (i),
the costs are heavily skewed in favour of retaining the status quo.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |