On 22/01/16(Fri) 08:42, Stefan Fritsch wrote:
> As there isn't any consensus for one of the other solutions, I am going to
> commit the patch that fixes this inside vio(4).
I think that you should commit the diff that does it unconditionally.
If people are concerned about the supplementary
As there isn't any consensus for one of the other solutions, I am going to
commit the patch that fixes this inside vio(4).
On Thu, 14 Jan 2016, Stefan Fritsch wrote:
> On Mon, 4 Jan 2016, Stefan Fritsch wrote:
> > On Sun, 3 Jan 2016, Theo de Raadt wrote:
> > > >> dlg writes:
> > > >> > should we
On Mon, 4 Jan 2016, Stefan Fritsch wrote:
> On Sun, 3 Jan 2016, Theo de Raadt wrote:
> > >> dlg writes:
> > >> > should we just do it unconditionally? is there a downside to that?
> > >
> > >It may decrease performance a tiny bit. Since such bits tend to add
> > >up, I would be hesitant to enable
On Sat, Jan 02, 2016 at 04:04:33PM +0100, Mark Kettenis wrote:
> > Date: Sat, 2 Jan 2016 10:57:41 +0100
> > From: Martin Pieuchot
> >
> > If it's acceptable performance-wise to do the check unconditionally I
> > believe that's the way to go. If not I'm a bit afraid of
On Sun, 3 Jan 2016, Theo de Raadt wrote:
> >On Friday 01 January 2016 16:25:59, Theo de Raadt wrote:
> >> dlg writes:
> >> > should we just do it unconditionally? is there a downside to that?
> >
> >It may decrease performance a tiny bit. Since such bits tend to add
> >up, I would be hesitant to
> Date: Mon, 4 Jan 2016 21:30:31 +0100
> From: Claudio Jeker
>
> On Sat, Jan 02, 2016 at 04:04:33PM +0100, Mark Kettenis wrote:
> > > Date: Sat, 2 Jan 2016 10:57:41 +0100
> > > From: Martin Pieuchot
> > >
> > > If it's acceptable performance-wise to
On Mon, 4 Jan 2016, Claudio Jeker wrote:
> On Sat, Jan 02, 2016 at 04:04:33PM +0100, Mark Kettenis wrote:
> > > Date: Sat, 2 Jan 2016 10:57:41 +0100
> > > From: Martin Pieuchot
> > >
> > > If it's acceptable performance-wise to do the check unconditionally I
> > > believe
On 01/01/16(Fri) 22:55, Stefan Fritsch wrote:
> Hi,
>
> by default, the ether_input() checks the destination MAC address of
> incoming unicast packets only if the interface is in promiscous mode. If
> not, it is assumed that the NIC filters unicast packets reliably.
> Unfortunately, for
On Friday 01 January 2016 16:25:59, Theo de Raadt wrote:
> dlg writes:
> > should we just do it unconditionally? is there a downside to that?
It may decrease performance a tiny bit. Since such bits tend to add
up, I would be hesitant to enable the check for drivers that don't
need it. OTOH,
> Date: Sat, 2 Jan 2016 10:57:41 +0100
> From: Martin Pieuchot
>
> If it's acceptable performance-wise to do the check unconditionally I
> believe that's the way to go. If not I'm a bit afraid of introducing
> a flag/capability for a single driver. Do you know if any other
dlg writes:
> should we just do it unconditionally? is there a downside to that?
That is a very good question. What are the downsides against having
the driver do this filtering itself, like all real hardware does?
Why risk sending packets of the wrong form further upwards into the
network
>This could be done with a new flag. There seem to be three possible places
>where this flag could be put:
>
>* ifnet.if_flags
> This is a short and there is no free bit. But the IFF_NOTRAILERS bit has
> become unused recently and could be recycled.
>
>* ifnet.if_xflags
> An int, lots of free
> On 2 Jan 2016, at 7:55 AM, Stefan Fritsch wrote:
>
> Hi,
>
> by default, the ether_input() checks the destination MAC address of
> incoming unicast packets only if the interface is in promiscous mode. If
> not, it is assumed that the NIC filters unicast packets reliably.
13 matches
Mail list logo