Good day.
Sun, Mar 18, 2007 at 08:17:09AM +0300, Eygene Ryabinkin wrote:
You're right, thanks for spotting the error. The corrected patch
is attached.
After some iterations with rik@ we came to a next version of an
if_bridge.4 patch. Comments are welcome.
--
Eygene
--- if_bridge.4.origSun
Eygene Ryabinkin wrote:
Good day.
Sun, Mar 18, 2007 at 08:17:09AM +0300, Eygene Ryabinkin wrote:
You're right, thanks for spotting the error. The corrected patch
is attached.
After some iterations with rik@ we came to a next version of an
if_bridge.4 patch. Comments are welcome.
Tue, Mar 27, 2007 at 10:20:40PM +0400, Roman Kurakin wrote:
Eygene what about the next patch for physically input filtration?
I guess we need a separate PR and a thread here for it.
Yes, I will port it to the new if_bridge.c. The end of this week is
a good estimate for the patching and testing
Good day.
Tue, Mar 13, 2007 at 08:50:29AM +0300, Eygene Ryabinkin wrote:
Sure. And that is why all switches that can bear the IP on their
interfaces have distinct MACs for each interface or/and the only
one interface can have the IP. And that is why I am going to
add the paragraph to the
Julian, good day.
+.Pp
+The packets destined to the bridging host will be seen by the filter
+on the interface with the MAC address equal to the packet's destination
+MAC. Be prepated to the situation when some of the bridge members are
sharing
prepated to ?
prepared for? ???
You're
Here it is. I'll check it for compilation this evening and I hope Eygene will
be able to put it in a production for testings.
The system with 6.2 and this patch is living since yesterday. No problems
were spotted. I will try to put this patch into another, busier system,
but this will not be
Eygene Ryabinkin wrote:
I tried to understand this, because Bruce already gave me a patch,
but I am a bit stupid: I do not see how M_PROMISC that is cleared
unconditionally before BRIDGE_INPUT will help us to identify the
right interface. As I see now, the BRIDGE_INPUT is called once from
Bruce,
Tue, Mar 13, 2007 at 11:36:54AM +, Bruce M. Simpson wrote:
In short: M_PROMISC exists to easily identify frames which were received
promiscuously, to prevent infinite recursion, and to simplify code which needs
to re-enter ether_input().
M_PROMISC is a flag introduced by NetBSD
Bruce, good day!
Tue, Mar 06, 2007 at 04:00:10PM +, Bruce M. Simpson wrote:
Eygene Ryabinkin wrote:
I am awfully sorry, but you're seem to be mistaken:
Thanks for clarifying this. That'll be because I didn't read if_bridge that
far. ;^) In my original message I was just looking at
Hi,
Eygene Ryabinkin wrote:
Speaking about vlan problems: the original problem is to do something
with VLAN interfaces only because they are sharing the MAC of their
physical parent. The problem itself is not VLAN-specific -- if there
will be two physical interfaces with the same MACs and they
On Mon, Mar 12, 2007 at 09:36:43AM +, Bruce M. Simpson wrote:
Hi,
Eygene Ryabinkin wrote:
Speaking about vlan problems: the original problem is to do something
with VLAN interfaces only because they are sharing the MAC of their
physical parent. The problem itself is not VLAN-specific
Yar, good day.
Mon, Mar 12, 2007 at 02:20:56PM +0300, Yar Tikhiy wrote:
On Mon, Mar 12, 2007 at 09:36:43AM +, Bruce M. Simpson wrote:
Eygene Ryabinkin wrote:
Speaking about vlan problems: the original problem is to do something
with VLAN interfaces only because they are sharing the
Bruce,
Mon, Mar 12, 2007 at 09:36:43AM +, Bruce M. Simpson wrote:
Speaking about vlan problems: the original problem is to do something
with VLAN interfaces only because they are sharing the MAC of their
physical parent. The problem itself is not VLAN-specific -- if there
will be two
Eygene Ryabinkin wrote:
[...]
We're not checking if the interface member is a VLAN interface. We just
do the generic checks for the incoming interface. rik@ will send the
patch today, at least he just promised me ;))
Here it is. I'll check it for compilation this evening and I hope Eygene
Eygene Ryabinkin wrote:
This is a different point. The bridge wants to know about bridge
members MACs just because it should catch the packets that are
destined to the bridge members. It is the only way for an L2 thing
that is operating in the promiscious mode.
Correct.
For our case (when
Yar Tikhiy wrote:
Guys, excuse me, but I still fail to see how the case of VLANs'
sharing a single MAC differs from the case of several physical
interfaces with the same MAC from the POV of a bridge. A bridge
can have no own MAC addresses at all, it plays with foreign MAC
addresses only.
On Mon, Mar 12, 2007 at 01:26:13PM +, Bruce M. Simpson wrote:
Yar Tikhiy wrote:
Guys, excuse me, but I still fail to see how the case of VLANs'
sharing a single MAC differs from the case of several physical
interfaces with the same MAC from the POV of a bridge. A bridge
can have no own
Yar,
2. In the case where 802.3ad trunking is implemented, the same Ethernet
address may be used by multiple physical interfaces.
3. As Eygene explained well: there are a number of consumers of
Ethernet frames in the stack. As if_bridge may potentially be passed
mbuf chains
On Mon, Mar 12, 2007 at 05:38:11PM +0300, Eygene Ryabinkin wrote:
Yar,
2. In the case where 802.3ad trunking is implemented, the same Ethernet
address may be used by multiple physical interfaces.
3. As Eygene explained well: there are a number of consumers of
Ethernet frames
Yar Tikhiy wrote:
On Mon, Mar 12, 2007 at 05:38:11PM +0300, Eygene Ryabinkin wrote:
Yar,
2. In the case where 802.3ad trunking is implemented, the same Ethernet
address may be used by multiple physical interfaces.
3. As Eygene explained well: there are a number of consumers of
Yar, good day.
Probably because if_bridge is written for Ethernet, 802.11 and
may be some other 802 interfaces:
-
DESCRIPTION
The if_bridge driver creates a logical link between two or more IEEE
802
networks that use the same (or ``similar enough'') framing
Andrew Thompson wrote:
On Tue, Mar 06, 2007 at 08:22:16PM +0300, Roman Kurakin wrote:
Ok, since no one want to provide an explanation I'll to do it myself.
...
I suggest to fix this problem in the other way, by checking if the
physical interface
is the dst interface by MAC. Eq if
+/* Give a chance for ifp at first priority. This will help in case
we
+ * the packet comes through the interface with VLAN's and the same
+ * MACs on several interfaces in a bridge. Also will save some
circles
+ * in case dst interface is the
On Tue, Mar 06, 2007 at 08:22:16PM +0300, Roman Kurakin wrote:
Ok, since no one want to provide an explanation I'll to do it myself.
...
I suggest to fix this problem in the other way, by checking if the
physical interface
is the dst interface by MAC. Eq if we got packet from Ci, it will be
Eygene Ryabinkin wrote:
I am awfully sorry, but you're seem to be mistaken:
Thanks for clarifying this. That'll be because I didn't read if_bridge
that far. ;^) In my original message I was just looking at if_ethersubr.c.
I need to make sure any changes which are made to if_bridge to deal
Ok, since no one want to provide an explanation I'll to do it myself.
Lets assume that we have two interfaces that are joined to bridge.
I'll call them as A and B. Both has a distinct MACs.
Now we have two cases for behaviour of filtering. The first case that
we will behave like real hub
Roman, good day!
Lets assume that we have two interfaces that are joined to bridge.
I'll call them as A and B. Both has a distinct MACs.
Now we have two cases for behaviour of filtering. The first case that
we will behave like real hub between the physical interfaces and its
virtual
Eygene Ryabinkin wrote:
Will try to understand if it will cure my problem, thanks!
Attaching my patch, just in case if freebsd gnats will be down ;))
Thanks for this. It looks like Andrew may be in a better position to say
if this fix should go in or not.
It is possible that if bridge
Hi,
Eygene Ryabinkin wrote:
Sure, I can test it, but then I need to know what problems are cured
by your patch, or I just should watch if it will not break something.
My concern is that I want to make sure that all these changes to the
ether_input path work OK together.
The M_PROMISC
Bruce,
In my case if_bridge drops off the packet because firewall fails to
recognize the packet as good: the interface that is passed to a
pfil_hooks is bad (I mean not the one expected).
The ifp which your patch changes is that of the mbuf chain when bridge_input
determines it is not for
Good day, the freebsd-net readers.
Perhaps someone can look at the kern/109815 and provide some
feedback. Citing my PR:
When if_bridge is used to gather multiple vlan interfaces that have
the same physical parent (I will call such vlan interfaces the 'vlan
group') the interface identifier
Hi,
I haven't seen your patch, can you point me at it off-list? Thanks.
Eygene Ryabinkin wrote:
I traced the current if_bridge.c behaviour to the NetBSD's if_bridge.c
1.9. This was the first version in that the firewall hooks were
introduced. And the assumtion that the MAC identifies the
32 matches
Mail list logo
