* Re: [Bridge] [PATCH] ipv6: correct the ipv6 option name - Pad0 to Pad1
From: Stephen Hemminger @ 2012-05-17 16:09 UTC (permalink / raw)
To: Eldad Zack
Cc: Hideaki YOSHIFUJI, netdev, bridge, Jamal Hadi Salim, James Morris,
David S. Miller, Alexey Kuznetsov, linux-kernel
In-Reply-To: <1337270425-21873-1-git-send-email-eldad@fogrefinery.com>
On Thu, 17 May 2012 18:00:25 +0200
Eldad Zack <eldad@fogrefinery.com> wrote:
> The padding destination or hop-by-hop option is called Pad1 and not Pad0.
>
> See RFC2460 (4.2) or the IANA ipv6-parameters registry:
> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
>
> Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
If standards bodies want to call a 0 a 1, then I guess we have to follow :-)
^ permalink raw reply
* Re: [Bridge] [PATCH] ipv6: correct the ipv6 option name - Pad0 to Pad1
From: Eldad Zack @ 2012-05-17 16:21 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Hideaki YOSHIFUJI, netdev, bridge, Jamal Hadi Salim, James Morris,
David S. Miller, Alexey Kuznetsov, linux-kernel
In-Reply-To: <20120517090923.0d0930e9@nehalam.linuxnetplumber.net>
On Thu, 17 May 2012, Stephen Hemminger wrote:
> On Thu, 17 May 2012 18:00:25 +0200
> Eldad Zack <eldad@fogrefinery.com> wrote:
>
> > The padding destination or hop-by-hop option is called Pad1 and not Pad0.
> >
> > See RFC2460 (4.2) or the IANA ipv6-parameters registry:
> > http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
> >
> > Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
>
> If standards bodies want to call a 0 a 1, then I guess we have to follow :-)
Yeah, Pad0 is a much better name for it. That's probably why it never
occured to any one for so long :-)
^ permalink raw reply
* Re: [Bridge] [PATCH] ipv6: correct the ipv6 option name - Pad0 to Pad1
From: David Miller @ 2012-05-17 19:50 UTC (permalink / raw)
To: eldad
Cc: yoshfuji, netdev, bridge, hadi, jmorris, linux-kernel, kuznet,
shemminger
In-Reply-To: <1337270425-21873-1-git-send-email-eldad@fogrefinery.com>
From: Eldad Zack <eldad@fogrefinery.com>
Date: Thu, 17 May 2012 18:00:25 +0200
> The padding destination or hop-by-hop option is called Pad1 and not Pad0.
>
> See RFC2460 (4.2) or the IANA ipv6-parameters registry:
> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml
>
> Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Applied to net-next.
^ permalink raw reply
* Re: [Bridge] wlan0 will not be automatically added to br0
From: Arun Khan @ 2012-06-07 16:40 UTC (permalink / raw)
To: Linux Bridge
In-Reply-To: <4F95550B.6010409@gmx.de>
On Mon, Apr 23, 2012 at 6:41 PM, Markus Feldmann <feldmann_markus@gmx.de> wrote:
> Hi All,
>
> i want my wlan0 added automatically to br0 on my Debian Squeeze Server. At
> the moment the ports eth[1-3] are running over br0. I am using kernel 3.2.9.
> The port eth0 is only for internet. eth[1-3] are for my local network at
> home. When i manually add wlan0 to br0 i can built up a communication
> between my laptop and my server. Therfore i execute the command <brctl addif
> br0 wlan0> on my server.
>
.... snip ...
For an ALIX box, I was looking at this link
<http://wiki.debian.org/BridgeNetworkConnections> under "Bridging
with a wireless NIC" and this
<http://www.linuxquestions.org/questions/linux-networking-3/wireless-wired-bridge-on-debian-squeeze-883201/>.
However, I switched to openWRT so I have no personal experience with
the implementation on Debian. I would suggest that you try Voyage
Linux (Debian based). It comes with a quite a few sample
configurations to setup an AP and you may be able to extend the
scripts to meet your requirements.
HTH
--
Arun Khan
^ permalink raw reply
* [Bridge] Query on Sapnning tree implementation from standard point of view
From: Sujata Verma @ 2012-06-14 12:23 UTC (permalink / raw)
To: bridge
[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]
Hi ,
I am going through spanning tree protocol and was testing it on Linux. My observation is there is no validation of timers for configuration BPDU. Lets say Root bridge received another BPDU from new bridge with invalid timer values but less priority, the existing bridge is becoming non-root bridge and is advertising the invalid timer values.
As i have gone through 802.1D-1998 standard, i understand that 2004 is current one but i was looking into STP not RSTP, i preferred to read this standard. I find these lines:
===============================================
9.3.3 Validation of received BPDUs
A Bridge Protocol Entity shall process a received BPDU as specified in 8.7 if and only if the BPDU contains at least four octets and the Protocol Identifier has the value specified for BPDUs (9.3.2), and
a) The BPDU Type denotes a Configuration BPDU and the BPDU contains at least 35 octets, and the
value of the BPDUs Message Age parameter is less than that of its Max Age parameter; or
b) The BPDU Type denotes a Topology Change Notification BPDU.
In case a), any octets that are present beyond Octet 35 are ignored, as far as processing according to this
standard is concerned. Similarly, in case b), any octets beyond Octet 4 are ignored.
============================================
Does this implies that any value timer values present within octet 35 is valid value and there is no validation done. Even if range for hello timer, max age and forward delay is defined and is limited. Is it an issue or fine within the standard?
Please help me understand this issue and thanks for any comments.
Regards,
Sujata
[-- Attachment #2: Type: text/html, Size: 1832 bytes --]
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Sasikanth babu @ 2012-06-14 12:39 UTC (permalink / raw)
To: Sujata Verma; +Cc: bridge
In-Reply-To: <1339676596.48814.YahooMailClassic@web121304.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]
On Thu, Jun 14, 2012 at 5:53 PM, Sujata Verma <sujataverma3@yahoo.com>wrote:
> Hi ,
>
> I am going through spanning tree protocol and was testing it on Linux. My
> observation is there is no validation of timers for configuration BPDU.
> Lets say Root bridge received another BPDU from new bridge with invalid
> timer values but less priority, the existing bridge is becoming non-root
> bridge and is advertising the invalid timer values.
>
> As i have gone through 802.1D-1998 standard, i understand that 2004 is
> current one but i was looking into STP not RSTP, i preferred to read this
> standard. I find these lines:
>
> ===============================================
> 9.3.3 Validation of received BPDUs
>
> A Bridge Protocol Entity shall process a received BPDU as specified in 8.7
> if and only if the BPDU contains at least four octets and the Protocol
> Identifier has the value specified for BPDUs (9.3.2), and
> a) The BPDU Type denotes a Configuration BPDU and the BPDU contains at
> least 35 octets, and the
> value of the BPDUs Message Age parameter is less than that of its Max Age
> parameter; or
>
> b) The BPDU Type denotes a Topology Change Notification BPDU.
> In case a), any octets that are present beyond Octet 35 are ignored, as
> far as processing according to this
> standard is concerned. Similarly, in case b), any octets beyond Octet 4
> are ignored.
>
> ============================================
>
> Does this implies that any value timer values present within octet 35 is
> valid value and there is no validation done. Even if range for hello timer,
> max age and forward delay is defined and is limited. Is it an issue or fine
> within the standard?
>
> Not all STP implementation do BPDU validations i.e validates all BPDU
parameters present within 35 octet. The validation checks for invalid
values present in the bpdu,
if the BPDU validation fails it drops the BPDU. The have seen this
validations in proprietary software.
> Please help me understand this issue and thanks for any comments.
>
> Regards,
> Sujata
>
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bridge
>
[-- Attachment #2: Type: text/html, Size: 3090 bytes --]
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Sujata Verma @ 2012-06-15 12:25 UTC (permalink / raw)
To: bridge
[-- Attachment #1.1: Type: text/plain, Size: 3410 bytes --]
Thanks. I was doing the same experiment on few switches, i could get hold of and this is the result:
Cisco Switch catalyst 2950 : Completely ignoring the packet, so validations are proper.
Netgear FSM726V3 : Hello timer is validated and is propagated as 10 instead of 255 ( which i sent) other max age and forward delay still it accepts as 255.
DLINK-DES-3026 : No validation done and accepts all as 255 ( max age, forward delay and hello timer)
In both Netgear and Dlink the message age is changed to 16, which i am not sure why it has happened ?
my setup is simple
PC1------Switch------PC2
From PC1 i am sending invalid timer values and observing on PC2.
I am attaching wireshark capture for Dlink and Netgear STP packets.
Please let me know if any one has any idea or comment on this.
Thanks,
Sujata
--- On Thu, 6/14/12, Sasikanth babu <sasikanth.v19@gmail.com> wrote:
From: Sasikanth babu <sasikanth.v19@gmail.com>
Subject: Re: [Bridge] Query on Sapnning tree implementation from standard point of view
To: "Sujata Verma" <sujataverma3@yahoo.com>
Cc: bridge@lists.linux-foundation.org
Date: Thursday, June 14, 2012, 6:09 PM
On Thu, Jun 14, 2012 at 5:53 PM, Sujata Verma <sujataverma3@yahoo.com> wrote:
Hi ,
I am going through spanning tree protocol and was testing it on Linux. My observation is there is no validation of timers for configuration BPDU. Lets say Root bridge received another BPDU from new bridge with invalid timer values but less priority, the existing bridge is becoming non-root bridge and is advertising the invalid timer values.
As i have gone through 802.1D-1998 standard, i understand that 2004 is current one but i was looking into STP not RSTP, i preferred to read this standard. I find these lines:
===============================================
9.3.3 Validation of received BPDUs
A Bridge Protocol Entity shall process a received BPDU as specified in 8.7 if and only if the BPDU contains at least four octets and the Protocol Identifier has the value specified for BPDUs (9.3.2), and
a) The BPDU Type
denotes a Configuration BPDU and the BPDU contains at least 35 octets, and the
value of the BPDUs Message Age parameter is less than that of its Max Age parameter; or
b) The BPDU Type denotes a Topology Change Notification BPDU.
In case a), any octets that are present beyond Octet 35 are ignored, as far as processing according to this
standard is concerned. Similarly, in case b), any octets beyond Octet 4 are ignored.
============================================
Does this implies that any value timer values present within octet 35 is valid value and there is no validation done. Even if range for hello timer, max age and forward delay is defined and is limited. Is it an issue or fine within the standard?
Not all STP implementation do BPDU validations i.e validates all BPDU parameters present within 35 octet. The validation checks for invalid values present in the bpdu,
if the BPDU validation fails it drops the BPDU. The have seen this validations in proprietary software.
Please help me understand this issue and thanks for any comments.
Regards,
Sujata
_______________________________________________
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bridge
[-- Attachment #1.2: Type: text/html, Size: 4874 bytes --]
[-- Attachment #2: STP_packet.pcap --]
[-- Type: application/cap, Size: 176 bytes --]
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Sasikanth babu @ 2012-06-15 13:55 UTC (permalink / raw)
To: Sujata Verma; +Cc: bridge
In-Reply-To: <1339763139.49767.YahooMailClassic@web121306.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 4226 bytes --]
On Fri, Jun 15, 2012 at 5:55 PM, Sujata Verma <sujataverma3@yahoo.com>wrote:
> Thanks. I was doing the same experiment on few switches, i could get hold
> of and this is the result:
>
> Cisco Switch catalyst 2950 : Completely ignoring the packet, so
> validations are proper.
>
> Netgear FSM726V3 : Hello timer is validated and is propagated as 10
> instead of 255 ( which i sent) other max age and forward delay still it
> accepts as 255.
>
> I don't think STP std has mentioned this propagation, As far as I know
this prorogation is wrong. I think this must be a bug in Netgear switch.
DLINK-DES-3026 : No validation done and accepts all as 255 ( max age,
> forward delay and hello timer)
>
> In both Netgear and Dlink the message age is changed to 16, which i am not
> sure why it has happened ?
>
> my setup is simple
>
> PC1------Switch------PC2
>
> From PC1 i am sending invalid timer values and observing on PC2.
>
Are you doing any port mirroring here to capture packets on PC2?. How
are you sending packets from PC1 (running linux bridge?)?
>
> I am attaching wireshark capture for Dlink and Netgear STP packets.
>
> Can you send out complete packet capture from start of your test to the
end to analyze
Thanks
Sasi
Please let me know if any one has any idea or comment on this.
>
> Thanks,
> Sujata
>
>
>
>
>
>
> --- On *Thu, 6/14/12, Sasikanth babu <sasikanth.v19@gmail.com>* wrote:
>
>
> From: Sasikanth babu <sasikanth.v19@gmail.com>
> Subject: Re: [Bridge] Query on Sapnning tree implementation from standard
> point of view
> To: "Sujata Verma" <sujataverma3@yahoo.com>
> Cc: bridge@lists.linux-foundation.org
> Date: Thursday, June 14, 2012, 6:09 PM
>
>
>
> On Thu, Jun 14, 2012 at 5:53 PM, Sujata Verma <sujataverma3@yahoo.com<http://mc/compose?to=sujataverma3@yahoo.com>
> > wrote:
>
> Hi ,
>
> I am going through spanning tree protocol and was testing it on Linux. My
> observation is there is no validation of timers for configuration BPDU.
> Lets say Root bridge received another BPDU from new bridge with invalid
> timer values but less priority, the existing bridge is becoming non-root
> bridge and is advertising the invalid timer values.
>
> As i have gone through 802.1D-1998 standard, i understand that 2004 is
> current one but i was looking into STP not RSTP, i preferred to read this
> standard. I find these lines:
>
> ===============================================
> 9.3.3 Validation of received BPDUs
>
> A Bridge Protocol Entity shall process a received BPDU as specified in 8.7
> if and only if the BPDU contains at least four octets and the Protocol
> Identifier has the value specified for BPDUs (9.3.2), and
> a) The BPDU Type denotes a Configuration BPDU and the BPDU contains at
> least 35 octets, and the
> value of the BPDUs Message Age parameter is less than that of its Max Age
> parameter; or
>
> b) The BPDU Type denotes a Topology Change Notification BPDU.
> In case a), any octets that are present beyond Octet 35 are ignored, as
> far as processing according to this
> standard is concerned. Similarly, in case b), any octets beyond Octet 4
> are ignored.
>
> ============================================
>
> Does this implies that any value timer values present within octet 35 is
> valid value and there is no validation done. Even if range for hello timer,
> max age and forward delay is defined and is limited. Is it an issue or fine
> within the standard?
>
> Not all STP implementation do BPDU validations i.e validates all BPDU
> parameters present within 35 octet. The validation checks for invalid
> values present in the bpdu,
> if the BPDU validation fails it drops the BPDU. The have seen this
> validations in proprietary software.
>
>
> Please help me understand this issue and thanks for any comments.
>
> Regards,
> Sujata
>
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org<http://mc/compose?to=Bridge@lists.linux-foundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bridge
>
>
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bridge
>
[-- Attachment #2: Type: text/html, Size: 7168 bytes --]
^ permalink raw reply
* [Bridge] Almost no traffic in br0 / tap0 combination
From: Bernhard Walle @ 2012-06-17 14:36 UTC (permalink / raw)
To: bridge
Hello,
probably the question is stupid, but I just don't get it.
I have a Linux host with a bridge that contain my normal eth interface
and a tap device. The br0 interface has the IP address, tap0 and eth0
are up and don't have any IP.
The tap0 interface is opened and read()s the frames coming in. On a
second console, tcpdump is monitoring the traffic. No traffic is
actually written to the tap0 interface.
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.a24ecad3959c no eth0
tap0
No iptables. I configured even hub-like behaviour:
# brctl setageingtime br0 0
# brctl setfd br0 0
Now my question: Why don't I see any traffic apart from broadcasts?
Shouldn't I see any traffic that is incoming? Because both eth0 and tap0
are in promisc mode?
Thanks for the advise!
Regards,
Bernhard
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Sujata Verma @ 2012-06-18 9:35 UTC (permalink / raw)
To: Sasikanth babu; +Cc: bridge
In-Reply-To: <CAOJFanVMn4Dx+Ue1-7yS8Lk_pkVP3ra8uZcV9MQbfqOKhHq1Ng@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9714 bytes --]
Ok.
I don't think STP std has mentioned this propagation, As far as I know
this prorogation is wrong. I think this must be a bug in Netgear
switch.
>>> My setup is
PC1( Windows PC) ----Switch------PC2 ( Windows PC)
Using Colasoft builder tool, i captured one STP packet modified the bridge priority such that it becomes root bridge , put all invalid values for timers as 255 and sent to the switch. My switch is linux PC, netgear switch and dlink switch for comparison purposes.
As switch receives the better BID packet it stop advertising it self as bridge and take values of timers from root bridge which is 255 for bridge, hello and forward delay in my case.
So the switch receives this packet and updates its cost, root information and sends out on another port on which PC2 is connected and where i am seeing it on wireshark with all timer values as received from root bridge. This is all fine, the only problem is, its not validating the timer values which seems a bug to me , as the timer values are defined within the limit in standard.
If Netgear is doing validation of the hello timer and is putting the maximum allowed value seems fine to me and not a bug. But still, i think forward delay and max age should also be validated before accepting new BPDU as root bridge.
As in linux/dlink it is not doing any validation and sending bpdu with 255 values, which is not correct as it could lead to delay of convergence time in case of root failure.
In netgear switch the command display before and after are as follows:
=========================================
(FSM726V3) #show spanning-tree
Bridge Priority................................ 32768
Bridge Identifier.............................. 80:00:00:26:F2:AF:93:A5
Time Since Topology Change..................... 0 day 0 hr 42 min 14 sec
Topology Change Count.......................... 1
Topology Change in progress.................... FALSE
Designated Root................................ 80:00:00:26:F2:AF:93:A5
Root Path Cost................................. 0
Root Port Identifier........................... 00:00
Bridge Max Age................................. 20
Bridge Max Hops................................ 20
Bridge Tx Hold Count........................... 6
Bridge Forwarding Delay........................ 15
Hello Time..................................... 2
Bridge Hold Time............................... 6
CST Regional Root.............................. 80:00:00:26:F2:AF:93:A5
Regional Root Path Cost........................ 0
--More-- or (q)uit
Associated FIDs Associated VLANs
--------------- ----------------
1 1
100 100
200 200
(FSM726V3) #show spanning-tree summary
Spanning Tree Adminmode........... Enabled
Spanning Tree Version............. IEEE 802.1d
BPDU Guard Mode................... Disabled
BPDU Filter Mode.................. Disabled
Configuration Name................ 00-26-F2-AF-93-A5
Configuration Revision Level...... 0
Configuration Digest Key.......... 0xac36177f50283cd4b83821d8ab26de62
Configuration Format Selector..... 0
No MST instances to display.
=======================================
After sending the invalid timer packet:
(FSM726V3) #
(FSM726V3) #
(FSM726V3) #show spanning-tree summary
Spanning Tree Adminmode........... Enabled
Spanning Tree Version............. IEEE 802.1d
BPDU Guard Mode................... Disabled
BPDU Filter Mode.................. Disabled
Configuration Name................ 00-26-F2-AF-93-A5
Configuration Revision Level...... 0
Configuration Digest Key.......... 0xac36177f50283cd4b83821d8ab26de62
Configuration Format Selector..... 0
No MST instances to display.
(FSM726V3) #show spanning-tree
Bridge Priority................................ 32768
Bridge Identifier.............................. 80:00:00:26:F2:AF:93:A5
Time Since Topology Change..................... 0 day 0 hr 0 min 12 sec
Topology Change Count.......................... 2
Topology Change in progress.................... TRUE
Designated Root................................ 10:00:00:20:A1:F0:88:50
Root Path Cost................................. 200004
Root Port Identifier........................... 80:01
Bridge Max Age................................. 255
Bridge Max Hops................................ 20
Bridge Tx Hold Count........................... 6
Bridge Forwarding Delay........................ 255
Hello Time..................................... 10
Bridge Hold Time............................... 6
CST Regional Root.............................. 80:00:00:26:F2:AF:93:A5
Regional Root Path Cost........................ 0
--More-- or (q)uit
Associated FIDs Associated VLANs
--------------- ----------------
1 1
100 100
200 200
(FSM726V3) #
=========================================
As Cisco doesnt accept this type of BPDU it means that it is a bug to be fixed on Linux, as i conclude.
Please let me know if you think otherwise.
Regards,
Sujata
--- On Fri, 6/15/12, Sasikanth babu <sasikanth.v19@gmail.com> wrote:
From: Sasikanth babu <sasikanth.v19@gmail.com>
Subject: Re: [Bridge] Query on Sapnning tree implementation from standard point of view
To: "Sujata Verma" <sujataverma3@yahoo.com>
Cc: bridge@lists.linux-foundation.org
Date: Friday, June 15, 2012, 7:25 PM
On Fri, Jun 15, 2012 at 5:55 PM, Sujata Verma <sujataverma3@yahoo.com> wrote:
Thanks. I was doing the same experiment on few switches, i could get hold of and this is the result:
Cisco Switch catalyst 2950 : Completely ignoring the packet, so validations are proper.
Netgear FSM726V3 : Hello timer is validated and is propagated as 10 instead of 255 ( which i sent) other max age and forward delay still it accepts as 255.
I don't think STP std has mentioned this propagation, As far as I know this prorogation is wrong. I think this must be a bug in Netgear switch.
DLINK-DES-3026 : No validation done and accepts all as 255 ( max age, forward delay and hello timer)
In both Netgear and Dlink the message age is changed to 16, which i am not sure why it has happened ?
my setup is simple
PC1------Switch------PC2
From PC1 i am sending invalid timer values and observing on PC2.
Are you doing any port mirroring here to capture packets on PC2?. How are you sending packets from PC1 (running linux bridge?)?
I am attaching wireshark capture for Dlink and Netgear STP packets.
Can you send out complete packet capture from start of your test to the end to analyze
Thanks
Sasi
Please let me know if any one has any idea or comment on
this.
Thanks,
Sujata
--- On Thu, 6/14/12, Sasikanth babu <sasikanth.v19@gmail.com> wrote:
From: Sasikanth babu <sasikanth.v19@gmail.com>
Subject: Re: [Bridge] Query on Sapnning tree implementation from standard point of view
To: "Sujata Verma" <sujataverma3@yahoo.com>
Cc: bridge@lists.linux-foundation.org
Date: Thursday, June 14, 2012, 6:09 PM
On Thu, Jun 14, 2012 at 5:53 PM, Sujata Verma <sujataverma3@yahoo.com> wrote:
Hi ,
I am going through spanning tree protocol and was testing it on Linux. My observation is there is no validation of timers for configuration BPDU. Lets say Root bridge received another BPDU from new bridge with invalid timer values but less priority, the existing bridge is becoming non-root bridge and is advertising the invalid timer values.
As i have gone through 802.1D-1998 standard, i understand that 2004 is current one but i was looking into STP not RSTP, i preferred to read this standard. I find these lines:
===============================================
9.3.3 Validation of received BPDUs
A Bridge Protocol Entity shall process a received BPDU as specified in 8.7 if and only if the BPDU contains at least four octets and the Protocol Identifier has the value specified for BPDUs (9.3.2), and
a) The BPDU Type
denotes a Configuration BPDU and the BPDU contains at least 35 octets, and the
value of the BPDUs Message Age parameter is less than that of its Max Age parameter; or
b) The BPDU Type denotes a Topology Change Notification BPDU.
In case a), any octets that are present beyond Octet 35 are ignored, as far as processing according to this
standard is concerned. Similarly, in case b), any octets beyond Octet 4 are ignored.
============================================
Does this implies that any value timer values present within octet 35 is valid value and there is no validation done. Even if range for hello timer, max age and forward delay is defined and is limited. Is it an issue or fine within the standard?
Not all STP implementation do BPDU validations i.e validates all BPDU parameters present within 35 octet. The validation checks for invalid values present in the bpdu,
if the BPDU validation fails it drops the BPDU. The have seen this validations in proprietary software.
Please help me understand this issue and thanks for any comments.
Regards,
Sujata
_______________________________________________
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bridge
_______________________________________________
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bridge
[-- Attachment #2: Type: text/html, Size: 15126 bytes --]
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Vitalii Demianets @ 2012-06-18 11:48 UTC (permalink / raw)
To: bridge
In-Reply-To: <1339763139.49767.YahooMailClassic@web121306.mail.ne1.yahoo.com>
On Friday 15 June 2012 15:25:39 Sujata Verma wrote:
> Thanks. I was doing the same experiment on few switches, i could get hold
> of and this is the result:
>
> Cisco Switch catalyst 2950 : Completely ignoring the packet, so validations
> are proper.
Hello, Sujata!
Would the result of the experiment differ if you set Message Age and Max Age
to the correct values while leaving Hello Time and Forward Delay incorrect:
Message Age = 19 (encoded as 0x13 0x00)
Max Age = 20 (encoded as 0x14 0x00)
Hello Time = 255 (encoded as 0xFF 0x00)
Forward Delay = 255 (encoded as 0xFF 0x00)
How would Cisco switch handle such BPDUs?
--
With Best Regards,
Vitalii Demianets
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Sasikanth babu @ 2012-06-18 15:55 UTC (permalink / raw)
To: Sujata Verma; +Cc: Stephen Hemminger, bridge
In-Reply-To: <1340012128.42375.YahooMailClassic@web121305.mail.ne1.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 10716 bytes --]
On Mon, Jun 18, 2012 at 3:05 PM, Sujata Verma <sujataverma3@yahoo.com>wrote:
> Ok.
>
> I don't think STP std has mentioned this propagation, As far as I know
> this prorogation is wrong. I think this must be a bug in Netgear switch.
>
> >>> My setup is
>
> PC1( Windows PC) ----Switch------PC2 ( Windows PC)
>
> Using Colasoft builder tool, i captured one STP packet modified the bridge
> priority such that it becomes root bridge , put all invalid values for
> timers as 255 and sent to the switch. My switch is linux PC, netgear switch
> and dlink switch for comparison purposes.
>
> As switch receives the better BID packet it stop advertising it self as
> bridge and take values of timers from root bridge which is 255 for bridge,
> hello and forward delay in my case.
>
> So the switch receives this packet and updates its cost, root information
> and sends out on another port on which PC2 is connected and where i am
> seeing it on wireshark with all timer values as received from root bridge.
> This is all fine, the only problem is, its not validating the timer values
> which seems a bug to me , as the timer values are defined within the limit
> in standard.
>
> If Netgear is doing validation of the hello timer and is putting the
> maximum allowed value seems fine to me and not a bug. But still, i think
> forward delay and max age should also be validated before accepting new
> BPDU as root bridge.
>
> As in linux/dlink it is not doing any validation and sending bpdu with
> 255 values, which is not correct as it could lead to delay of convergence
> time in case of root failure.
>
> In netgear switch the command display before and after are as follows:
>
> =========================================
> (FSM726V3) #show spanning-tree
>
> Bridge Priority................................ 32768
> Bridge Identifier.............................. 80:00:00:26:F2:AF:93:A5
> Time Since Topology Change..................... 0 day 0 hr 42 min 14 sec
> Topology Change Count.......................... 1
> Topology Change in progress.................... FALSE
> Designated Root................................ 80:00:00:26:F2:AF:93:A5
> Root Path Cost................................. 0
> Root Port Identifier........................... 00:00
> Bridge Max Age................................. 20
> Bridge Max Hops................................ 20
> Bridge Tx Hold Count........................... 6
> Bridge Forwarding Delay........................ 15
> Hello Time..................................... 2
> Bridge Hold Time............................... 6
> CST Regional Root.............................. 80:00:00:26:F2:AF:93:A5
> Regional Root Path Cost........................ 0
> --More-- or (q)uit
>
>
>
> Associated FIDs Associated VLANs
> --------------- ----------------
> 1 1
> 100 100
> 200 200
>
> (FSM726V3) #show spanning-tree summary
>
> Spanning Tree Adminmode........... Enabled
> Spanning Tree Version............. IEEE 802.1d
> BPDU Guard Mode................... Disabled
> BPDU Filter Mode.................. Disabled
> Configuration Name................ 00-26-F2-AF-93-A5
> Configuration Revision Level...... 0
> Configuration Digest Key.......... 0xac36177f50283cd4b83821d8ab26de62
> Configuration Format Selector..... 0
> No MST instances to display.
>
> =======================================
> After sending the invalid timer packet:
>
> (FSM726V3) #
> (FSM726V3) #
> (FSM726V3) #show spanning-tree summary
>
> Spanning Tree Adminmode........... Enabled
> Spanning Tree Version............. IEEE 802.1d
> BPDU Guard Mode................... Disabled
> BPDU Filter Mode.................. Disabled
> Configuration Name................ 00-26-F2-AF-93-A5
> Configuration Revision Level...... 0
> Configuration Digest Key.......... 0xac36177f50283cd4b83821d8ab26de62
> Configuration Format Selector..... 0
> No MST instances to display.
>
> (FSM726V3) #show spanning-tree
>
> Bridge Priority................................ 32768
> Bridge Identifier.............................. 80:00:00:26:F2:AF:93:A5
> Time Since Topology Change..................... 0 day 0 hr 0 min 12 sec
> Topology Change Count.......................... 2
> Topology Change in progress.................... TRUE
> Designated Root................................ 10:00:00:20:A1:F0:88:50
> Root Path Cost................................. 200004
> Root Port Identifier........................... 80:01
> Bridge Max Age................................. 255
> Bridge Max Hops................................ 20
> Bridge Tx Hold Count........................... 6
> Bridge Forwarding Delay........................ 255
> Hello Time..................................... 10
> Bridge Hold Time............................... 6
> CST Regional Root.............................. 80:00:00:26:F2:AF:93:A5
> Regional Root Path Cost........................ 0
> --More-- or (q)uit
>
>
>
> Associated FIDs Associated VLANs
> --------------- ----------------
> 1 1
> 100 100
> 200 200
>
> (FSM726V3) #
>
>
> =========================================
> As Cisco doesnt accept this type of BPDU it means that it is a bug to be
> fixed on Linux, as i conclude.
>
>
The Linux bridge does not do BPDU validations. And most of the
implementations don't do validations, since STD doesn't mentioned anything
about developers started ignoring it.
The way people use linux bridges are different from Cisco or Brocade or
Juniper routers. Bridge maintainer may have the right answer for this
(Adding him in CC)
> Please let me know if you think otherwise.
>
> Regards,
> Sujata
>
>
>
>
>
> --- On *Fri, 6/15/12, Sasikanth babu <sasikanth.v19@gmail.com>* wrote:
>
>
> From: Sasikanth babu <sasikanth.v19@gmail.com>
> Subject: Re: [Bridge] Query on Sapnning tree implementation from standard
> point of view
> To: "Sujata Verma" <sujataverma3@yahoo.com>
> Cc: bridge@lists.linux-foundation.org
> Date: Friday, June 15, 2012, 7:25 PM
>
>
>
> On Fri, Jun 15, 2012 at 5:55 PM, Sujata Verma <sujataverma3@yahoo.com<http://mc/compose?to=sujataverma3@yahoo.com>
> > wrote:
>
> Thanks. I was doing the same experiment on few switches, i could get hold
> of and this is the result:
>
> Cisco Switch catalyst 2950 : Completely ignoring the packet, so
> validations are proper.
>
> Netgear FSM726V3 : Hello timer is validated and is propagated as 10
> instead of 255 ( which i sent) other max age and forward delay still it
> accepts as 255.
>
> I don't think STP std has mentioned this propagation, As far as I know
> this prorogation is wrong. I think this must be a bug in Netgear switch.
>
> DLINK-DES-3026 : No validation done and accepts all as 255 ( max age,
> forward delay and hello timer)
>
> In both Netgear and Dlink the message age is changed to 16, which i am not
> sure why it has happened ?
>
> my setup is simple
>
> PC1------Switch------PC2
>
> From PC1 i am sending invalid timer values and observing on PC2.
>
>
> Are you doing any port mirroring here to capture packets on PC2?. How
> are you sending packets from PC1 (running linux bridge?)?
>
>
> I am attaching wireshark capture for Dlink and Netgear STP packets.
>
> Can you send out complete packet capture from start of your test to the
> end to analyze
>
> Thanks
> Sasi
>
> Please let me know if any one has any idea or comment on this.
>
> Thanks,
> Sujata
>
>
>
>
>
>
>
>
> --- On *Thu, 6/14/12, Sasikanth babu <sasikanth.v19@gmail.com<http://mc/compose?to=sasikanth.v19@gmail.com>
> >* wrote:
>
>
> From: Sasikanth babu <sasikanth.v19@gmail.com<http://mc/compose?to=sasikanth.v19@gmail.com>
> >
> Subject: Re: [Bridge] Query on Sapnning tree implementation from standard
> point of view
> To: "Sujata Verma" <sujataverma3@yahoo.com<http://mc/compose?to=sujataverma3@yahoo.com>
> >
> Cc: bridge@lists.linux-foundation.org<http://mc/compose?to=bridge@lists.linux-foundation.org>
> Date: Thursday, June 14, 2012, 6:09 PM
>
>
>
> On Thu, Jun 14, 2012 at 5:53 PM, Sujata Verma <sujataverma3@yahoo.com<http://mc/compose?to=sujataverma3@yahoo.com>
> > wrote:
>
> Hi ,
>
> I am going through spanning tree protocol and was testing it on Linux. My
> observation is there is no validation of timers for configuration BPDU.
> Lets say Root bridge received another BPDU from new bridge with invalid
> timer values but less priority, the existing bridge is becoming non-root
> bridge and is advertising the invalid timer values.
>
> As i have gone through 802.1D-1998 standard, i understand that 2004 is
> current one but i was looking into STP not RSTP, i preferred to read this
> standard. I find these lines:
>
> ===============================================
> 9.3.3 Validation of received BPDUs
>
> A Bridge Protocol Entity shall process a received BPDU as specified in 8.7
> if and only if the BPDU contains at least four octets and the Protocol
> Identifier has the value specified for BPDUs (9.3.2), and
> a) The BPDU Type denotes a Configuration BPDU and the BPDU contains at
> least 35 octets, and the
> value of the BPDUs Message Age parameter is less than that of its Max Age
> parameter; or
>
> b) The BPDU Type denotes a Topology Change Notification BPDU.
> In case a), any octets that are present beyond Octet 35 are ignored, as
> far as processing according to this
> standard is concerned. Similarly, in case b), any octets beyond Octet 4
> are ignored.
>
> ============================================
>
> Does this implies that any value timer values present within octet 35 is
> valid value and there is no validation done. Even if range for hello timer,
> max age and forward delay is defined and is limited. Is it an issue or fine
> within the standard?
>
> Not all STP implementation do BPDU validations i.e validates all BPDU
> parameters present within 35 octet. The validation checks for invalid
> values present in the bpdu,
> if the BPDU validation fails it drops the BPDU. The have seen this
> validations in proprietary software.
>
>
> Please help me understand this issue and thanks for any comments.
>
> Regards,
> Sujata
>
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org<http://mc/compose?to=Bridge@lists.linux-foundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bridge
>
>
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org<http://mc/compose?to=Bridge@lists.linux-foundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bridge
>
>
>
[-- Attachment #2: Type: text/html, Size: 14869 bytes --]
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Stephen Hemminger @ 2012-06-18 20:54 UTC (permalink / raw)
To: Sasikanth babu; +Cc: bridge
In-Reply-To: <CAOJFanURN8_LfYLWHFEtACc9_8mNb1vZ=mENnNR=0v6ZXTk=Tg@mail.gmail.com>
On Mon, 18 Jun 2012 21:25:26 +0530
Sasikanth babu <sasikanth.v19@gmail.com> wrote:
> >
> > Does this implies that any value timer values present within octet 35 is
> > valid value and there is no validation done. Even if range for hello timer,
> > max age and forward delay is defined and is limited. Is it an issue or fine
> > within the standard?
> >
> > Not all STP implementation do BPDU validations i.e validates all BPDU
> > parameters present within 35 octet. The validation checks for invalid
> > values present in the bpdu,
> > if the BPDU validation fails it drops the BPDU. The have seen this
> > validations in proprietary software.
> >
> >
> > Please help me understand this issue and thanks for any comments.
> >
> > Regards,
> > Sujata
> >
First off, STP is not a secure protocol. It assumes a trust in any bridge
it excepts PDU's from. That is why Cisco as bpdu guard to ignore stuff
from rogue endpoints. In Linux, you can do the same with netfilter but
most users dont.
Second, the standard (Linux is based on old 1998 version) allows any
value for forwarding delay (0 .. 255 seconds). The encoding of timer
value section implies that.
There is some checks about hello vs. max age.
Much of the code in Linux seems to have come from sample code in original
standard. The standard committee decided that was too convenient and dropped
it in later revisions.
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Vitalii Demianets @ 2012-06-19 7:48 UTC (permalink / raw)
To: bridge; +Cc: Stephen Hemminger
In-Reply-To: <20120618135450.27473585@nehalam.linuxnetplumber.net>
On Monday 18 June 2012 23:54:50 Stephen Hemminger wrote:
>
> First off, STP is not a secure protocol. It assumes a trust in any bridge
> it excepts PDU's from. That is why Cisco as bpdu guard to ignore stuff
> from rogue endpoints. In Linux, you can do the same with netfilter but
> most users dont.
>
> Second, the standard (Linux is based on old 1998 version) allows any
> value for forwarding delay (0 .. 255 seconds). The encoding of timer
> value section implies that.
>
Hello, Stephen!
Standards (both -1998 and -2004 revisions) do say nothing about validation of
timers (except one issue) and you gave a good point that encoding clearly
allows any timer value from 0.0 s to 255+255/256 s.
Now, to the exceptional issue:
9.3.3 a) of -1998 (9.3.4 a) of -2004)
===============================================
a) The BPDU Type denotes a Configuration BPDU and the BPDU contains at least
35 octets, and the value of the BPDUs Message Age parameter is less than that
of its Max Age parameter ... [skip]
===============================================
So, the standard clearly requires the BPDU where MessageAge < MaxAge to be
dropped.
Don't you think that including this check in Linux bridging code is
worthwhile?
--
With Best Regards,
Vitalii Demianets
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Sasikanth babu @ 2012-06-19 7:54 UTC (permalink / raw)
To: Vitalii Demianets; +Cc: Stephen Hemminger, bridge
In-Reply-To: <201206191048.10023.vitas@nppfactor.kiev.ua>
[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]
On Tue, Jun 19, 2012 at 1:18 PM, Vitalii Demianets
<vitas@nppfactor.kiev.ua>wrote:
> On Monday 18 June 2012 23:54:50 Stephen Hemminger wrote:
> >
> > First off, STP is not a secure protocol. It assumes a trust in any bridge
> > it excepts PDU's from. That is why Cisco as bpdu guard to ignore stuff
> > from rogue endpoints. In Linux, you can do the same with netfilter but
> > most users dont.
> >
> > Second, the standard (Linux is based on old 1998 version) allows any
> > value for forwarding delay (0 .. 255 seconds). The encoding of timer
> > value section implies that.
> >
>
> Hello, Stephen!
> Standards (both -1998 and -2004 revisions) do say nothing about validation
> of
> timers (except one issue) and you gave a good point that encoding clearly
> allows any timer value from 0.0 s to 255+255/256 s.
>
> Now, to the exceptional issue:
> 9.3.3 a) of -1998 (9.3.4 a) of -2004)
> ===============================================
> a) The BPDU Type denotes a Configuration BPDU and the BPDU contains at
> least
> 35 octets, and the value of the BPDUs Message Age parameter is less than
> that
> of its Max Age parameter ... [skip]
> ===============================================
>
> So, the standard clearly requires the BPDU where MessageAge < MaxAge to be
> dropped.
>
> Don't you think that including this check in Linux bridging code is
> worthwhile?
>
> Are you talking about this check (in function br_stp_rcv)?
if (bpdu.message_age > bpdu.max_age) {
if (net_ratelimit())
br_notice(p->br,
"port %u config from %pM"
" (message_age %ul > max_age
%ul)\n",
p->port_no,
eth_hdr(skb)->h_source,
bpdu.message_age, bpdu.max_age);
goto out;
}
> --
> With Best Regards,
> Vitalii Demianets
>
Thanks
Sasi
[-- Attachment #2: Type: text/html, Size: 2831 bytes --]
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Sujata Verma @ 2012-06-19 8:15 UTC (permalink / raw)
To: bridge, Vitalii Demianets
In-Reply-To: <201206181448.33159.vitas@nppfactor.kiev.ua>
[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]
With below setting I was able to run the test on all 4 devices
Message Age = 19 (encoded as 0x13 0x00)
Max Age = 20 (encoded as 0x14 0x00)
Hello Time = 255 (encoded as 0xFF 0xFF)
Forward Delay = 255 (encoded as 0xFF 0xFF)
The results are:
Linux bridge:
Accepting the new BPDU and accepting all fields as it is given above.
Netgear:
Not accepting the BPDU, advertising its own with values message age:0, max age: 20, hello time :2 and forward delay 15
Dlink:
Not accepting the BPDU , advertising its own with values message age:0, max age: 20,
hello time :2 and forward delay 15
Cisco:
Not accepting the BPDU, advertising its own with values message age:0, max age: 20,
hello time :2 and forward delay 15.
In Cisco the configuration is
2950#show spanning-tree summary
Root bridge for: VLAN0001.
Extended system ID is enabled.
PortFast BPDU Guard is disabled
EtherChannel misconfiguration guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Default pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001 0 0 0 2 2
---------------------- -------- --------- -------- ---------- ----------
1 vlan 0 0 0 2 2
======================================
So for the given values except linux all switches are dropping/ignoring the packet.
Regards,
Sujata
--- On Mon, 6/18/12, Vitalii Demianets <vitas@nppfactor.kiev.ua> wrote:
From: Vitalii Demianets <vitas@nppfactor.kiev.ua>
Subject: Re: [Bridge] Query on Sapnning tree implementation from standard point of view
To: bridge@lists.linux-foundation.org
Date: Monday, June 18, 2012, 5:18 PM
On Friday 15 June 2012 15:25:39 Sujata Verma wrote:
> Thanks. I was doing the same experiment on few switches, i could get hold
> of and this is the result:
>
> Cisco Switch catalyst 2950 : Completely ignoring the packet, so validations
> are proper.
Hello, Sujata!
Would the result of the experiment differ if you set Message Age and Max Age
to the correct values while leaving Hello Time and Forward Delay incorrect:
Message Age = 19 (encoded as 0x13 0x00)
Max Age = 20 (encoded as 0x14 0x00)
Hello Time = 255 (encoded as 0xFF 0x00)
Forward Delay = 255 (encoded as 0xFF 0x00)
How would Cisco switch handle such BPDUs?
--
With Best Regards,
Vitalii Demianets
_______________________________________________
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bridge
[-- Attachment #2: Type: text/html, Size: 3991 bytes --]
^ permalink raw reply
* Re: [Bridge] Query on Sapnning tree implementation from standard point of view
From: Vitalii Demianets @ 2012-06-19 8:16 UTC (permalink / raw)
To: Sasikanth babu; +Cc: Stephen Hemminger, bridge
In-Reply-To: <CAOJFanXztn4LMSLyqDH5zPBKXHKGztiSQPZmcSQ-4Px7zV54Bg@mail.gmail.com>
On Tuesday 19 June 2012 10:54:13 Sasikanth babu wrote:
> >
> > Don't you think that including this check in Linux bridging code is
> > worthwhile?
> >
> > Are you talking about this check (in function br_stp_rcv)?
>
> if (bpdu.message_age > bpdu.max_age) {
> if (net_ratelimit())
> br_notice(p->br,
> "port %u config from %pM"
> " (message_age %ul > max_age
> %ul)\n",
> p->port_no,
> eth_hdr(skb)->h_source,
> bpdu.message_age, bpdu.max_age);
> goto out;
> }
>
Oh, yes, thank you for pointing that out. I was clearly looking at the
outdated code.
--
With Best Regards,
Vitalii Demianets
^ permalink raw reply
* [Bridge] [patch -next] netfilter: use kfree_skb() not kfree()
From: Dan Carpenter @ 2012-06-30 11:48 UTC (permalink / raw)
To: Bart De Schuymer
Cc: coreteam, netdev, bridge, kernel-janitors, David S. Miller,
netfilter, netfilter-devel, Stephen Hemminger, Pablo Neira Ayuso
This was should be a kfree_skb() here to free the sk_buff pointer.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/bridge/netfilter/ebt_ulog.c b/net/bridge/netfilter/ebt_ulog.c
index 1bd1732..dfbb019 100644
--- a/net/bridge/netfilter/ebt_ulog.c
+++ b/net/bridge/netfilter/ebt_ulog.c
@@ -156,7 +156,7 @@ static void ebt_ulog_packet(unsigned int hooknr, const struct sk_buff *skb,
nlh = nlmsg_put(ub->skb, 0, ub->qlen, 0,
size - NLMSG_ALIGN(sizeof(*nlh)), 0);
if (!nlh) {
- kfree(ub->skb);
+ kfree_skb(ub->skb);
ub->skb = NULL;
goto unlock;
}
^ permalink raw reply related
* Re: [Bridge] [patch -next] netfilter: use kfree_skb() not kfree()
From: David Miller @ 2012-07-01 0:27 UTC (permalink / raw)
To: dan.carpenter
Cc: netfilter, coreteam, netdev, bridge, kernel-janitors,
bart.de.schuymer, netfilter-devel, shemminger, pablo
In-Reply-To: <20120630114853.GA22767@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Sat, 30 Jun 2012 14:48:53 +0300
> This was should be a kfree_skb() here to free the sk_buff pointer.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
My bad, applied, thanks Dan.
^ permalink raw reply
* [Bridge] how to disable multicast_router in bridge? and get rid of the LLDP messages
From: V Yegyanathan @ 2012-07-13 4:31 UTC (permalink / raw)
To: bridge
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
Hi All,
I created 3 bridges and inter-connected them with veth links. No external
nodes are connected to this n/w and STP is disabled and hence expected
links to be silent. [Yes, I dont want STP, even though this looped topo]
I got ipv6 multicast LLDPs and hence disabled ipv6 through sysfs for all
nodes.
After that I am getting
0.000000 86:79:7b:e4:8c:9f -> LLDP_Multicast LLDP 222 Chassis Id =
e8:03:9a:3b:1c:28 Port Id = 86:79:7b:e4:8c:9f TTL = 120
0.000031 2a:b3:bc:44:7a:44 -> LLDP_Multicast LLDP 221 Chassis Id =
e8:03:9a:3b:1c:28 Port Id = 2a:b3:bc:44:7a:44 TTL = 120
which are LLDP nearest messages which I want to get rid off.
I was suspecting it as due to multicast_router being enabled in bridge by
default and hence want to disable. I able to disable multicast_snooping
(file is written) but could not multicast_router. Manual write with vi
editor fails with sysfs sync failure.
Please let me know how I could stop these messages.
Reference:
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#Snooping
I am not able to set the value in "multicast_router" file to "0" while I
can do that for "multicast_snooping"
system details :
3.2.0-26-generic-pae #41-Ubuntu SMP Thu Jun 14 16:45:14 UTC 2012 i686 i686
i386 GNU/Linux
brctl -V
bridge-utils, 1.5
Please let me know if any more information is needed.
Thanks and regards,
vy
[-- Attachment #2: Type: text/html, Size: 1616 bytes --]
^ permalink raw reply
* [Bridge] [3.5 regression / bridge] constantly toggeling between disabled and forwarding
From: Michael Leun @ 2012-07-23 7:42 UTC (permalink / raw)
To: bridge, netdev; +Cc: shemminger, linux-kernel
Hi,
when I use my usb ethernet adapter
# > lsusb
[...]
Bus 002 Device 009: ID 9710:7830 MosChip Semiconductor MCS7830 10/100 Mbps Ethernet adapter
[...]
as port of an bridge
> # brctl addbr br0
> # brctl addif br0 eth0
> # brctl addif br0 ue5
> # ifconfig ue5 up
> # ifconfig br0 up
(Also does happen when eth0 is not part of the bridge, but the logs I
had available were from that situation...)
I constantly get messages showing the interface toggeling between
disabled and forwarding state:
Jul 23 07:40:50 elektra kernel: [ 1539.497337] br0: port 2(ue5) entered disabled state
Jul 23 07:40:50 elektra kernel: [ 1539.554992] br0: port 2(ue5) entered forwarding state
Jul 23 07:40:50 elektra kernel: [ 1539.555005] br0: port 2(ue5) entered forwarding state
Jul 23 07:40:51 elektra kernel: [ 1540.496242] br0: port 2(ue5) entered disabled state
Jul 23 07:40:51 elektra kernel: [ 1540.552534] br0: port 2(ue5) entered forwarding state
Jul 23 07:40:51 elektra kernel: [ 1540.552548] br0: port 2(ue5) entered forwarding state
Jul 23 07:40:52 elektra kernel: [ 1541.550413] br0: port 2(ue5) entered forwarding state
Jul 23 07:40:53 elektra kernel: [ 1542.529672] br0: port 2(ue5) entered disabled state
Jul 23 07:40:53 elektra kernel: [ 1542.587162] br0: port 2(ue5) entered forwarding state
Jul 23 07:40:53 elektra kernel: [ 1542.587175] br0: port 2(ue5) entered forwarding state
Jul 23 07:40:54 elektra kernel: [ 1543.585309] br0: port 2(ue5) entered forwarding state
Jul 23 07:41:00 elektra kernel: [ 1549.360600] br0: port 2(ue5) entered disabled state
Jul 23 07:41:00 elektra kernel: [ 1549.442998] br0: port 2(ue5) entered forwarding state
Jul 23 07:41:00 elektra kernel: [ 1549.443011] br0: port 2(ue5) entered forwarding state
Jul 23 07:41:01 elektra kernel: [ 1550.357686] br0: port 2(ue5) entered disabled state
Jul 23 07:41:01 elektra kernel: [ 1550.408208] br0: port 2(ue5) entered forwarding state
Jul 23 07:41:01 elektra kernel: [ 1550.408222] br0: port 2(ue5) entered forwarding state
Jul 23 07:41:02 elektra kernel: [ 1551.407656] br0: port 2(ue5) entered forwarding state
Jul 23 07:41:03 elektra kernel: [ 1552.401578] br0: port 2(ue5) entered disabled state
Jul 23 07:41:03 elektra kernel: [ 1552.474773] br0: port 2(ue5) entered forwarding state
Jul 23 07:41:03 elektra kernel: [ 1552.474786] br0: port 2(ue5) entered forwarding state
Jul 23 07:41:04 elektra kernel: [ 1553.472487] br0: port 2(ue5) entered forwarding state
Jul 23 07:41:05 elektra kernel: [ 1554.356138] br0: port 2(ue5) entered disabled state
[...]
This does (in the same situation, nothing else than the kernel changed)
not happen with 3.4.5.
Does anybody have an idea what the issue might be or do I need to bisect?
--
MfG,
Michael Leun
^ permalink raw reply
* Re: [Bridge] [3.5 regression / bridge] constantly toggeling between disabled and forwarding
From: Stephen Hemminger @ 2012-07-23 15:02 UTC (permalink / raw)
To: Michael Leun; +Cc: netdev, bridge, linux-kernel
In-Reply-To: <20120723091504.2d035d28@xenia.leun.net>
On Mon, 23 Jul 2012 09:15:04 +0200
Michael Leun <lkml20120218@newton.leun.net> wrote:
> Hi,
>
> when I use my usb ethernet adapter
>
> # > lsusb
> [...]
> Bus 002 Device 009: ID 9710:7830 MosChip Semiconductor MCS7830 10/100 Mbps Ethernet adapter
> [...]
>
> as port of an bridge
>
> > # brctl addbr br0
> > # brctl addif br0 eth0
> > # brctl addif br0 ue5
> > # ifconfig ue5 up
> > # ifconfig br0 up
>
> (Also does happen when eth0 is not part of the bridge, but the logs I
> had available were from that situation...)
>
> I constantly get messages showing the interface toggeling between
> disabled and forwarding state:
>
> Jul 23 07:40:50 elektra kernel: [ 1539.497337] br0: port 2(ue5) entered disabled state
> Jul 23 07:40:50 elektra kernel: [ 1539.554992] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:50 elektra kernel: [ 1539.555005] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:51 elektra kernel: [ 1540.496242] br0: port 2(ue5) entered disabled state
> Jul 23 07:40:51 elektra kernel: [ 1540.552534] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:51 elektra kernel: [ 1540.552548] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:52 elektra kernel: [ 1541.550413] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:53 elektra kernel: [ 1542.529672] br0: port 2(ue5) entered disabled state
> Jul 23 07:40:53 elektra kernel: [ 1542.587162] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:53 elektra kernel: [ 1542.587175] br0: port 2(ue5) entered forwarding state
> Jul 23 07:40:54 elektra kernel: [ 1543.585309] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:00 elektra kernel: [ 1549.360600] br0: port 2(ue5) entered disabled state
> Jul 23 07:41:00 elektra kernel: [ 1549.442998] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:00 elektra kernel: [ 1549.443011] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:01 elektra kernel: [ 1550.357686] br0: port 2(ue5) entered disabled state
> Jul 23 07:41:01 elektra kernel: [ 1550.408208] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:01 elektra kernel: [ 1550.408222] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:02 elektra kernel: [ 1551.407656] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:03 elektra kernel: [ 1552.401578] br0: port 2(ue5) entered disabled state
> Jul 23 07:41:03 elektra kernel: [ 1552.474773] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:03 elektra kernel: [ 1552.474786] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:04 elektra kernel: [ 1553.472487] br0: port 2(ue5) entered forwarding state
> Jul 23 07:41:05 elektra kernel: [ 1554.356138] br0: port 2(ue5) entered disabled state
> [...]
>
> This does (in the same situation, nothing else than the kernel changed)
> not happen with 3.4.5.
>
> Does anybody have an idea what the issue might be or do I need to bisect?
Probably not a bridge issue, but rather an issue with link status reporting
on the device. The bridge changes state when the attached ethernet
device raises/lowers carrier.
An independent way to observe link changes is to use a tool like:
ip monitor
which will show carrier up/down events.
^ permalink raw reply
* [Bridge] [PATCH 2/7] netpoll: make __netpoll_cleanup non-block
From: Cong Wang @ 2012-07-27 15:37 UTC (permalink / raw)
To: netdev
Cc: bridge, Jiri Pirko, Cong Wang, Neil Horman, Jay Vosburgh,
linux-kernel, David S. Miller, Eric Dumazet, Joe Perches,
Cong Wang, Stephen Hemminger
In-Reply-To: <1343403484-29347-1-git-send-email-amwang@redhat.com>
Like the previous patch, slave_disable_netpoll() and __netpoll_cleanup()
may be called with read_lock() held too, so we should make them
non-block, by moving the cleanup and kfree() to call_rcu_bh() callbacks.
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
drivers/net/bonding/bond_main.c | 4 +--
include/linux/netpoll.h | 3 ++
net/8021q/vlan_dev.c | 6 +----
net/bridge/br_device.c | 6 +----
net/core/netpoll.c | 42 +++++++++++++++++++++++++++++---------
5 files changed, 38 insertions(+), 23 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index ab773d4..9907889 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1257,9 +1257,7 @@ static inline void slave_disable_netpoll(struct slave *slave)
return;
slave->np = NULL;
- synchronize_rcu_bh();
- __netpoll_cleanup(np);
- kfree(np);
+ __netpoll_free_rcu(np);
}
static inline bool slave_dev_support_netpoll(struct net_device *slave_dev)
{
diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
index 28f5389..5011d74 100644
--- a/include/linux/netpoll.h
+++ b/include/linux/netpoll.h
@@ -23,6 +23,7 @@ struct netpoll {
u8 remote_mac[ETH_ALEN];
struct list_head rx; /* rx_np list element */
+ struct rcu_head rcu;
};
struct netpoll_info {
@@ -38,6 +39,7 @@ struct netpoll_info {
struct delayed_work tx_work;
struct netpoll *netpoll;
+ struct rcu_head rcu;
};
void netpoll_send_udp(struct netpoll *np, const char *msg, int len);
@@ -48,6 +50,7 @@ int netpoll_setup(struct netpoll *np);
int netpoll_trap(void);
void netpoll_set_trap(int trap);
void __netpoll_cleanup(struct netpoll *np);
+void __netpoll_free_rcu(struct netpoll *np);
void netpoll_cleanup(struct netpoll *np);
int __netpoll_rx(struct sk_buff *skb);
void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 73a2a83..43e14a2 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -703,11 +703,7 @@ static void vlan_dev_netpoll_cleanup(struct net_device *dev)
info->netpoll = NULL;
- /* Wait for transmitting packets to finish before freeing. */
- synchronize_rcu_bh();
-
- __netpoll_cleanup(netpoll);
- kfree(netpoll);
+ __netpoll_free_rcu(netpoll);
}
#endif /* CONFIG_NET_POLL_CONTROLLER */
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 3334845..bb6a5dd 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -267,11 +267,7 @@ void br_netpoll_disable(struct net_bridge_port *p)
p->np = NULL;
- /* Wait for transmitting packets to finish before freeing. */
- synchronize_rcu_bh();
-
- __netpoll_cleanup(np);
- kfree(np);
+ __netpoll_free_rcu(np);
}
#endif
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index c78a966..19dddef 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -878,6 +878,24 @@ static int __init netpoll_init(void)
}
core_initcall(netpoll_init);
+static void rcu_cleanup_netpoll_info(struct rcu_head *rcu_head)
+{
+ struct netpoll_info *npinfo =
+ container_of(rcu_head, struct netpoll_info, rcu);
+
+ skb_queue_purge(&npinfo->arp_tx);
+ skb_queue_purge(&npinfo->txq);
+
+ /* we can't call cancel_delayed_work_sync here, as we are in softirq*/
+ cancel_delayed_work(&npinfo->tx_work);
+
+ /* clean after last, unfinished work */
+ __skb_queue_purge(&npinfo->txq);
+ /* now cancel it again */
+ cancel_delayed_work(&npinfo->tx_work);
+ kfree(npinfo);
+}
+
void __netpoll_cleanup(struct netpoll *np)
{
struct netpoll_info *npinfo;
@@ -903,20 +921,24 @@ void __netpoll_cleanup(struct netpoll *np)
ops->ndo_netpoll_cleanup(np->dev);
RCU_INIT_POINTER(np->dev->npinfo, NULL);
+ call_rcu_bh(&npinfo->rcu, rcu_cleanup_netpoll_info);
+ }
+}
+EXPORT_SYMBOL_GPL(__netpoll_cleanup);
- /* avoid racing with NAPI reading npinfo */
- synchronize_rcu_bh();
+static void rcu_cleanup_netpoll(struct rcu_head *rcu_head)
+{
+ struct netpoll *np = container_of(rcu_head, struct netpoll, rcu);
- skb_queue_purge(&npinfo->arp_tx);
- skb_queue_purge(&npinfo->txq);
- cancel_delayed_work_sync(&npinfo->tx_work);
+ __netpoll_cleanup(np);
+ kfree(np);
+}
- /* clean after last, unfinished work */
- __skb_queue_purge(&npinfo->txq);
- kfree(npinfo);
- }
+void __netpoll_free_rcu(struct netpoll *np)
+{
+ call_rcu_bh(&np->rcu, rcu_cleanup_netpoll);
}
-EXPORT_SYMBOL_GPL(__netpoll_cleanup);
+EXPORT_SYMBOL_GPL(__netpoll_free_rcu);
void netpoll_cleanup(struct netpoll *np)
{
--
1.7.7.6
^ permalink raw reply related
* [Bridge] [PATCH 4/7] bridge: call NETDEV_RELEASE notifier in br_del_if()
From: Cong Wang @ 2012-07-27 15:38 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Stephen Hemminger, bridge, Cong Wang,
David S. Miller
In-Reply-To: <1343403484-29347-1-git-send-email-amwang@redhat.com>
When a bridge interface deletes its underlying ports, it should
notify netconsole too, like what bonding interface does.
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
net/bridge/br_if.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index e1144e1..d243914 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -427,6 +427,7 @@ int br_del_if(struct net_bridge *br, struct net_device *dev)
if (!p || p->br != br)
return -EINVAL;
+ call_netdevice_notifiers(NETDEV_RELEASE, br->dev);
del_nbp(p);
spin_lock_bh(&br->lock);
--
1.7.7.6
^ permalink raw reply related
* Re: [Bridge] [PATCH 4/7] bridge: call NETDEV_RELEASE notifier in br_del_if()
From: Stephen Hemminger @ 2012-07-27 15:50 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, bridge, David S. Miller, linux-kernel
In-Reply-To: <1343403484-29347-5-git-send-email-amwang@redhat.com>
On Fri, 27 Jul 2012 23:38:01 +0800
Cong Wang <amwang@redhat.com> wrote:
> When a bridge interface deletes its underlying ports, it should
> notify netconsole too, like what bonding interface does.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
> ---
> net/bridge/br_if.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index e1144e1..d243914 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -427,6 +427,7 @@ int br_del_if(struct net_bridge *br, struct net_device *dev)
> if (!p || p->br != br)
> return -EINVAL;
>
> + call_netdevice_notifiers(NETDEV_RELEASE, br->dev);
> del_nbp(p);
>
> spin_lock_bh(&br->lock);
Since you can have multiple ports attached to the bridge, this
doesn't seem correct. Don't you want the netconsole to keep going
on the other ports of the bridge?
What exactly is the problem with having netconsole persist?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox