bridged, previously legitimate traffic was not passed as the bridge could not
tell that it was on a different Ethernet segment.
All non-tagged traffic is treated as vlan1 as per IEEE 802.1Q-2003
in case of multiple interfaces with the same MAC in the same bridge.
This commit do not solve the entire problem. Only case where packet
arrived from such interface.
PR: kern/109815
MFC after: 7 days
Submitted by: Eygene Ryabinkin and rik@
Discussed with: bms@, thompsa@, yar@
of the bridge port and path cost have been administratively set or
calculated automatically by RSTP.
Make sure to transition from non-edge to edge when the port goes down
and the edge flag was manually set before.
This is needed to comply with the condition
((!portEnabled && AdminEdge) || ....)
in the Bridge Detection State Machine (IEE802.1D-2004, p. 171).
Reviewed by: thompsa
Approved by: bz (mentor)
- use flags rather than sperate ioctls for edge, p2p
- implement p2p and autop2p flags
- define large pathcost constant as ULL
- show bridgeid and rootid in ifconfig
Obtained from: Reyk Floeter <reyk@openbsd.org>
address learned by the bridge is made permanent, the address will not age out
and most importantly will not migrate to another interface.
This can be used to stop mac address poisoning or clients roaming in much the
same way as static entries without the hassle of preloading the table.
specific privilege names to a broad range of privileges. These may
require some future tweaking.
Sponsored by: nCircle Network Security, Inc.
Obtained from: TrustedBSD Project
Discussed on: arch@
Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri,
Alex Lyashkov <umka at sevcity dot net>,
Skip Ford <skip dot ford at verizon dot net>,
Antoine Brodin <antoine dot brodin at laposte dot net>
to, previously it was always broadcast to all interfaces (a bug). This is
useful when the bridge is the default gateway and vlans are used to isolate
each client, the reply is now kept private to the vlan which the client
resides.
Reported by: Jon Otterholm
Tested by: Jon Otterholm
MFC after: 3 days
RSTP provides faster spanning tree convergence, the protocol will exchange
information with neighboring switches to quickly transition to forwarding
without creating loops. The code will default to RSTP mode but will downgrade
any port connected to a legacy STP network so is fully backward compatible.
Reviewed by: syrinx
Tested by: syrinx
packets. Reimplement this correctly and use a sysctl that defaults to off so
the user doesnt get any suprises if ipfw blocks the ARP packet.
MFC after: 3 days
parameter that can specify configuration parameters:
o rev cloner api's to add optional parameter block
o add SIOCCREATE2 that accepts parameter data
o rev vlan support to use new api (maintain old code)
Reviewed by: arch@
The packet filter may reassemble the ip fragments and return a packet that is
larger than the MTU of the sending interface. There is no check for DF or icmp
replies as we can only get a large packet to fragment by reassembling a
previous fragment, and this only happens after a call to pfil(9).
Obtained from: OpenBSD (mostly)
Glanced at by: mlaier
MFC after: 1 month
details see PR kern/94448.
PR: kern/94448
Original patch: Eygene A. Ryabinkin <rea-fbsd at rea dot mbslab dot kiae dot ru>Final patch: thompsa@
Tested by: thompsa@, Eygene A. Ryabinkin
MFC after: 7 days
that we might have address collisions, so make sure that this hardware address
isn't already in use on another bridge.
Submitted by: csjp
MFC after: 1 month
destination interface as a member of our bridge or this is a unicast packet,
push it through the bpf(4) machinery.
For broadcast or multicast packets, don't bother with the bpf(4) because it will
be re-injected into ether_input. We do this before we pass the packets through
the pfil(9) framework, as it is possible that pfil(9) will drop the packet or
possibly modify it, making it very difficult to debug firewall issues on the
bridge.
Further, implemented IFF_MONITOR for bridge interfaces. This does much the same
thing that it does for regular network interfaces: it pushes the packet to any
bpf(4) peers and then returns. This bypasses all of the bridge machinery,
saving mutex acquisitions, list traversals, and other operations performed by
the bridging code.
This change to the bridging code is useful in situations where individuals use a
bridge to multiplex RX/TX signals from two interfaces, as is required by some
network taps for de-multiplexing links and transmitting the RX/TX signals
out through two separate interfaces. This behaviour is quite common for network
taps monitoring links, especially for certain manufacturers.
Reviewed by: thompsa
MFC after: 1 month
Sponsored by: Seccuris Labs
- code expects memcmp() to return a signed value, our memcmp() returns 0 if
args are equal and > 0 if not.
- It's possible to hijack interface for static entry. If bridge recieves
packet from interface marked as learning it will replace the bridge_rtnode
entry for the source address even if such entry marked as static.
Submitted by: Gleb Kurtsov <k-gleb yandex.ru>
MFC after: 3 days
