On Mon, Apr 21, 2014 at 09:01:52PM +0200, Henning Brauer wrote:
> so while so many here were so busy bikeshedding, wasting everyone's
> time and hindering progress, reyk and I found that several people,
> including me, had flaws in their testing. unfortunately have to go the
> vlan_output route. ro
so while so many here were so busy bikeshedding, wasting everyone's
time and hindering progress, reyk and I found that several people,
including me, had flaws in their testing. unfortunately have to go the
vlan_output route. root cause "undo undo damage", don't make me explain
please...
new diff.
In list.openbsd.tech, you wrote:
> now it turns out it is trivial to have ether_output prepend the
> ether_vlan_header instead of the regular ethernet header, which makes
> the vlan tagging essentially free in most cases.
>
> you need a very current src tree to test this, relies on the code
> shuf
> Henning Brauer bsws.de> writes:
>
> > > And lot of (possible) encapsulation subsystems in the middle: vlan,
> > > vlan-in-vlan, ipsec, you name it.
> >
> > VLAN IS NOT AN ENCAPSULATION.
>
> Well, vlan(4) says:
>
> vlan, svlan - IEEE 802.1Q/1AD encapsulation/decapsulation pseudo-device
>
> >
this bikeshedding is annoying as hell and only makes sure we're not
proceeding. makes me almost want to reconsider the open development
process using tech@ instead of a private list.
and I want to proceed here, so I am looking for oks unless someone has
real, non-bikeshedding issues. and certainly
Henning Brauer bsws.de> writes:
> > And lot of (possible) encapsulation subsystems in the middle: vlan,
> > vlan-in-vlan, ipsec, you name it.
>
> VLAN IS NOT AN ENCAPSULATION.
Well, vlan(4) says:
vlan, svlan - IEEE 802.1Q/1AD encapsulation/decapsulation pseudo-device
> > Given a number of sub
* Alexey Suslikov [2014-04-21 13:56]:
> Henning Brauer bsws.de> writes:
>
> > I must admit I am getting tired of all these "good proposals/ideas".
> > don't you think we've gone thru this before?
>
> Look, I haven't called them good or bad.
>
> > what you propose would require a custom vlan_ou
Henning Brauer bsws.de> writes:
> I must admit I am getting tired of all these "good proposals/ideas".
> don't you think we've gone thru this before?
Look, I haven't called them good or bad.
> what you propose would require a custom vlan_output function which
> does nothing but setting the flag
On 21/04/14(Mon) 11:14, Claudio Jeker wrote:
> [...]
>
> Would it make sense to put this into a vlan_encap function so that we can
> reduce the amount of layer violation here?
I think it makes sense.
> #if NVLAN > 0
> if (ifp->if_type == IFT_L2VLAN)
> return vlan_encap(ifp, m
* Alexey Suslikov [2014-04-21 13:13]:
> Henning Brauer bsws.de> writes:
> > congratulations, that is close to unauditable.
> > i put the vlan and the !vlan case next to each other ON PURPOSE. both
> > cases add an ethernet header, one with a few extra fields, one
> > without. Having that next to
Henning Brauer bsws.de> writes:
> congratulations, that is close to unauditable.
>
> i put the vlan and the !vlan case next to each other ON PURPOSE. both
> cases add an ethernet header, one with a few extra fields, one
> without. Having that next to each other makes it f***ing obvious both
> ca
* Alexey Suslikov [2014-04-21 12:38]:
> Henning Brauer bsws.de> writes:
>
> > > #if NVLAN > 0
> > > if (ifp->if_type == IFT_L2VLAN)
> > > return vlan_encap(ifp, m);
> > > #endif
> >
> > I don't think so, really. We're talking about 25 lines of code, in a
> > function that either pre
Henning Brauer bsws.de> writes:
> > #if NVLAN > 0
> > if (ifp->if_type == IFT_L2VLAN)
> > return vlan_encap(ifp, m);
> > #endif
>
> I don't think so, really. We're talking about 25 lines of code, in a
> function that either prepends a regular ethernet header or a
> vlan-ethernet
* Claudio Jeker [2014-04-21 11:14]:
> __inline is dead long live inline.
oups, that crept back in.
> Would it make sense to put this into a vlan_encap function so that we can
> reduce the amount of layer violation here?
>
> #if NVLAN > 0
> if (ifp->if_type == IFT_L2VLAN)
> r
On Sun, Apr 20, 2014 at 06:45:46PM +0200, Henning Brauer wrote:
> so, on vlan, to insert the vlan tag, we right now:
> -copy (most of) the existing ethernet header into a ether_vlan_header
> on the stack
> -fill the extra fields (tag, inside ether type) in ether_vlan_header
> -set the ether type
>
so, on vlan, to insert the vlan tag, we right now:
-copy (most of) the existing ethernet header into a ether_vlan_header
on the stack
-fill the extra fields (tag, inside ether type) in ether_vlan_header
-set the ether type
-m_adj() to make room for the extra space ether_vlan_header needs
-m_copyba
16 matches
Mail list logo
