Age | Commit message (Collapse) | Author |
|
bridge_output() is used by the stack to duplicate a packet coming from a
bridge member to its other ports.
Confusion pointed by Momtchil Momtchev on misc@
ok reyk@
|
|
|
|
Splitting functions in if_bridge.c into if_bridge.c for the forwarding part
and bridgectl.c for the control part. It shouldn't have any functional change.
ok reyk@ mpi@ yasuoka@
|
|
ok reyk@ mpi@ yasuoka@
|
|
This allows more flexible configurations with vlan(4) and bridge(4) on
top of the same physical interface. In particular it allows to not feed
VLAN tagget packets into a bridge(4).
Fix regression reported by Armin Wolfermann on bugs@, ok dlg@
|
|
if_enqueue(). As pointed by dlg@, IF_QFULL on works in the priq
case.
Prompted by a diff from uebayasi@ to export ifi_oqdrops, ok dlg@
|
|
if_input() and to have a counterpart for bridge_ifenqueue() that helps
to understand the traffic/code flow in bridge better. The bridge
currently only puts a single packet on the input mbuf list, and
changing will need to undo part of this commit, but it still makes
sense to have a well-defined call for the ports receive path.
No functional change.
OK mpi@
|
|
(Especially adding IF_DROP() after IFQ_ENQUEUE() was completely wrong because
IFQ_ENQUEUE() already does it. Oops.)
After this revert, the situation becomes:
- if_snd.ifq_drops is incremented in either IFQ_ENQUEUE() or IF_DROP(), but
it is not shown to userland, and
- if_data.ifi_oqdrops is shown to userland, but it is not incremented by
anyone.
|
|
mpi@ plans to clean-up IF_DROP()'s, but fix consistent use of it for now.
OK dlg@
|
|
ok mpi
|
|
to pass additional context or transient data with the similar life
time.
ok mpi, suggestions, hand holding and ok from dlg
|
|
ok claudio@, dlg@
|
|
instead of having every driver that manipulates the ifih list
understand SRPLs, this moves that processing into if_ih_insert and
if_ih_remove functions.
we rely on the kernel lock to serialise the modifications to the
list.
tested by mpi@
ok mpi@ claudio@ mikeb@
|
|
We do not export those per-ifp statistics and they will soon all die.
"We're putting inet6 on a diet" claudio@
ok dlg@, mikeb@, claudio@
|
|
in bridge_localbroadcast() too.
This should fix another alignment issue kettenis@ is seeing.
ok dlg@
|
|
This fixes a crash during ifconfig bridge0 destroy.
OK mpi@
|
|
to defer the work currently done in bridge_input() and requiring the
KERNEL_LOCK to bridgeintr().
Tested by sthen@
ok rzalamena@, dlg@, bluhm@
|
|
if_input() has been designed to be able to safely handle a batch of
packets from physical drivers to the network stack. Most of these
drivers have an interrupt routine executed at IPL_NET and the check
made sense during the conversion. However we also want to re-enqueue
packets with if_input() from the network stack currently running at
IPL_SOFTNET.
ok claudio@
|
|
ok mpi@, claudio@.
|
|
The way gif(4) and bridge(4) are plugged together is disgusting but at
least this makes the layer violation obvious.
Fix a regression introduced by the M_PROTO1 loop prevention cleaning
because gif(4) was abusing this flag to figure out if the packet was
coming from a bridge(4).
Thanks to goda@ for finding this!
ok goda@, claudio@
|
|
This pseudo-option is a hack to support return-rst on bridge(4). It
passes Ethernet information via a "struct route" through ip_output().
"struct route" is slowly dying...
ok claudio@, benno@
|
|
ok stsp mpi
|
|
|
|
ifp in order to access its ifih handlers.
So get rid of if_get() in the various ifih handlers we know the ifp is
live at this point.
ok dlg@
|
|
talking about (*ifp->if_output)().
ok claudio@, dlg@
|
|
after the Ethernet header in its own function and use it in bridge_input().
This should fix alignment issues kettenis@ is seeing.
ok bluhm@, claudio@
|
|
In bridge(4) speak, broadcast-like packets are Ethernet Multicast
frames or Unicast for which the destination is unknown.
It makes sense to not retransmit broadcast-like packets on the interface
they were received but they still must be delivered to the network stack.
Problem reported by and ok jasper@
|
|
This fix some weird bridge(4) configurations involving pseudo-drivers
stacked on top of interfaces in a bridge.
Also simplifies the loop prevention logic to match bridge's input path.
Instead of using a tag per port/bridge simply flag output mbufs to make
sure only one copy per bridge go through bridge_output().
ok bluhm@, claudio@
|
|
Note that pseudo-drivers not using if_input() are not affected by this
conversion.
ok mikeb@, kettenis@, claudio@, dlg@
|
|
Move bridge_input() outside of ether_input() in order to duplicate packets
flowing through a bridge port before applying any transformation on mbufs.
This saves a various m_adj(9)/M_PREPEND(9) dances and remove the bridge(4)
hack from vlan(4).
Tested by mxb <mxb AT alumni DOT chalmers DOT se> and kettenis@
ok bluhm@
|
|
receiving interface in the packet header of every mbuf.
The interface pointer should now be retrieved when necessary with
if_get(). If a NULL pointer is returned by if_get(), the interface
has probably been destroy/removed and the mbuf should be freed.
Such mechanism will simplify garbage collection of mbufs and limit
problems with dangling ifp pointers.
Tested by jmatthew@ and krw@, discussed with many.
ok mikeb@, bluhm@, dlg@
|
|
ok lteo@
|
|
|
|
vlan_start().
ok sthen@, phessler@
|
|
ok jasper@, bluhm@
|
|
the handlers on the new interface won't be executed.
Tested by < mxb AT alumni.chalmers DOT se>
ok dlg@
|
|
a packet on the sending queue of an interface.
Tested by many, thanks a lot!
ok dlg@, claudio@
|
|
ok miod@
|
|
m_adj(9) to keep bridge(4) working while other pseudo-drivers are
converted to if_input().
Tested by mxb <mxb AT alumni DOT chalmers DOT se>, thanks!
ok henning@
|
|
No objection from reyk@, OK markus, hshoexer
|
|
to of vlan(4) from ether_input() to bridge_input().
One of the goal of the if_input() plumbing is to stop doing all possible
pseudo-drivers checks on every packets. There's no reason that even if
you're not running a bridge(4) you've to run this code.
This change also will also makes it easier to convert vlan(4) to if_input().
Reviewed by Rafael Zalamena and mikeb@, ok markus@
|
|
might be overwritten by pseudo-drivers.
ok dlg@, henning@
|
|
prio from the vlan header to our pf priority levels. This fixes the
mapping in the bridge code.
ok henning
|
|
|
|
long live the one true internet.
ok henning mikeb
|
|
Since bridge_output/bridge_ifenqueue replace ether_output that does
VLAN tagging and call into if_start directly we need to make sure
that tag has been set by the bridge.
XXX This abuses "if_output == vlan_output" check, but hopefully
XXX vlan(4) will use a distinct if_type someday and this code
XXX will be improved.
Discussed with henning and Rafael Zalamena, ok henning
|
|
to include that than rdnvar.h. ok deraadt dlg
|
|
ok miod@ mpi@
|
|
|
|
after discussions with beck deraadt kettenis.
|