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 identifie
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 physi
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 cha
Bruce,
> >And a question: can anyone say if my patch will break some known
> >good behaviour and if the current behaviour of if_bridge is based
> >on some logic I am currently failing to understand.
> >
> I would greatly appreciate it if you could look at the combined M_PROMISC and
> 802.1p pat
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 flag
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 i
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 with
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 between
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 l
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 b
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 we
> >
> > +/* 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
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 if
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
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 s
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
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
wil
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 MA
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. Theref
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
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 c
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 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
Ethe
On Mon, Mar 12, 2007 at 11:51:02PM +0300, Roman Kurakin wrote:
> 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 p
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 ``simi
> 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
if_ethe
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 N
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? ??
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.origSu
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.
I
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
34 matches
Mail list logo