From: Linus Lüssing
When trying to set the noise floor via debugfs, a "data bus error"
crash like the following can happen:
[ 88.433133] Data bus error, epc == 80221c28, ra == 83314e60
[ 88.438895] Oops[#1]:
[ 88.441246] CPU: 0 PID: 7263 Comm: sh Not tainted 4.14.195 #0
[
On Tue, Sep 22, 2020 at 07:51:19PM +0200, Linus Lüssing wrote:
> I don't see a "src" in br_ip in net-next/master at the moment. Or
> is that supposed to be added with your IGMPv3 implementation in
> the future?
Ah, sorry, found the according patch (*) it in my other inbox.
On Tue, Sep 22, 2020 at 10:30:17AM +0300, Nikolay Aleksandrov wrote:
> From: Nikolay Aleksandrov
>
> Since now we have src in br_ip, u no longer makes sense so rename
> it to dst. No functional changes.
>
> v2: fix build with CONFIG_BATMAN_ADV_MCAST
Hi Nikolay,
I don't see a "src" in br_ip in
On Sun, Aug 16, 2020 at 03:08:13PM -0700, Stephen Hemminger wrote:
> Rather than adding yet another feature to the bridge, could this hack be done
> by
> having a BPF hook? or netfilter module?
Hi Stephen,
Thanks for the constructive feedback and suggestions!
The netfilter approach sounds tempt
the specific host(s).
Link: https://issuetracker.google.com/issues/149630944
Link: https://github.com/freifunk-gluon/gluon/issues/1832
Signed-off-by: Linus Lüssing
---
A version of this patch rebased to Linux 4.14 is currently applied on a
400 nodes mesh network (Freifunk Vogtland).
I'm aware
On Sun, Jul 05, 2020 at 11:18:36PM +0300, Nikolay Aleksandrov wrote:
> > > By the way, I can't verify at the moment, but I think we can drop that
> > > whole
> > > hunk altogether since skb_header_pointer() is used and it will simply
> > > return
> > > an error if there isn't enough data for nsrc
On Sun, Jul 05, 2020 at 10:11:39PM +0300, Nikolay Aleksandrov wrote:
> On 7/5/20 10:08 PM, Linus Lüssing wrote:
> > On Sun, Jul 05, 2020 at 09:33:13PM +0300, Nikolay Aleksandrov wrote:
> > > On 05/07/2020 21:22, Linus Lüssing wrote:
> > > > Commit e57f61858b7c ("
mber of
Sources" field in the "Multicast Address Record" before reading it.
And not the size of a pointer to this field.
Fixes: e57f61858b7c ("net: bridge: mcast: fix stale nsrcs pointer in igmp3/mld2
report handling")
Acked-by: Nikolay Aleksandrov
Signed-off-by: Linus Lüs
On Sun, Jul 05, 2020 at 09:33:13PM +0300, Nikolay Aleksandrov wrote:
> On 05/07/2020 21:22, Linus Lüssing wrote:
> > Commit e57f61858b7c ("net: bridge: mcast: fix stale nsrcs pointer in
> > igmp3/mld2 report handling") introduced a small bug which would potentially
>
"Number of
Sources" field in the "Multicast Address Record" before reading it.
And not the size of a pointer to this field.
Fixes: e57f61858b7c ("net: bridge: mcast: fix stale nsrcs pointer in igmp3/mld2
report handling")
Signed-off-by: Linus Lüssing
---
net/bridge/
Acked-by: Linus Lüssing
On Wed, Aug 14, 2019 at 12:58:58PM -0400, David Miller wrote:
> From: Stefano Brivio
> Date: Tue, 13 Aug 2019 00:46:01 +0200
>
> > Commit ba5ea614622d ("bridge: simplify ip_mc_check_igmp() and
> > ipv6_mc_check_mld() calls") replaces direct calls to pskb_may_pull()
> > in br_ipv6_multicast_mld2_r
On Tue, Feb 19, 2019 at 03:31:42PM +0200, Nikolay Aleksandrov wrote:
> On 19/02/2019 11:21, Linus Lüssing wrote:
> > On Tue, Feb 19, 2019 at 09:57:16AM +0100, Linus Lüssing wrote:
> >> On Mon, Feb 18, 2019 at 02:21:07PM +0200, Nikolay Aleksandrov wrote:
> >>> This is
On Tue, Feb 19, 2019 at 09:57:16AM +0100, Linus Lüssing wrote:
> On Mon, Feb 18, 2019 at 02:21:07PM +0200, Nikolay Aleksandrov wrote:
> > This is v2 of the RFC patch which aims to forward packets to known
> > mdsts' ports only (the no querier case). After v1 I've kept
&
On Mon, Feb 18, 2019 at 02:21:07PM +0200, Nikolay Aleksandrov wrote:
> This is v2 of the RFC patch which aims to forward packets to known
> mdsts' ports only (the no querier case). After v1 I've kept
> the previous behaviour when it comes to unregistered traffic or when
> a querier is present. All
On Sat, Feb 16, 2019 at 09:27:26PM +0200, niko...@cumulusnetworks.com wrote:
> >>The no querier condition is not currently reflected via switchdev, so
> >>the behavior you're proposing in your patch is what actually happens
> >in
> >>the data plane.
> >>
> >>We already hit the problem Linus mention
Hi Nik, hi Ido,
By the way speaking about the IGMP/MLD querier mechanism. Not sure if
you are subscribed to the p...@ietf.org or mcast-w...@ietf.org mailing lists.
There was a call for volunteers to progress IGMP/MLD to standards
track not that long ago:
"[pim] Volunteers needed for work on prog
On Thu, Feb 14, 2019 at 03:04:54PM +0100, Sven Eckelmann wrote:
> On Thursday, 14 February 2019 14:44:52 CET Linus Lüssing wrote:
> [...]
> > > No new sysfs config files.
> >
> > Why? The bridge for instance does the same.
>
> https://patchwork.open-mesh.org/patc
On Fri, Feb 15, 2019 at 03:04:27PM +0200, Nikolay Aleksandrov wrote:
> Every user would expect to have traffic forwarded only to the configured
> mdb destination when snooping is enabled, instead now to get that one
> needs to enable both snooping and querier. Enabling querier on all
> switches cou
On Wed, Feb 06, 2019 at 07:20:25PM +0100, Sven Eckelmann wrote:
> On Tuesday, 5 February 2019 20.24.10 CET Linus Lüssing wrote:
> [...]
> > Another thought, if all this is too vague for now...
>
> Yes, it is to vague for the integration in netlink :D
>
> >
used to en‐
>able or disable multicast optimizations (i.e. disabling
>means always sending own multicast frames via classic
>flooding).
>
> * according to sysfs ABI:
>
>What: /sys/class/net//mesh/multicast_mode
>Date:
Otherwise other snooping switches might refrain from forwarding these
advertisements to us.
Signed-off-by: Linus Lüssing
---
include/uapi/linux/in.h | 9 +++---
net/bridge/br_multicast.c | 72 ++-
net/ipv6/mcast.c | 2 ++
3 files c
ify that length
checks are performed properly.
Signed-off-by: Linus Lüssing
---
net/ipv4/igmp.c| 51 ++---
net/ipv6/mcast_snoop.c | 62 --
2 files changed, 52 insertions(+), 61 deletions(-)
diff --git a/net/i
ssing adds such routers to the internal
multicast router list.
Signed-off-by: Linus Lüssing
---
include/linux/in.h | 5 +
include/net/addrconf.h | 15 +
include/uapi/linux/icmpv6.h | 2 ++
include/uapi/linux/igmp.h | 1 +
net/bridge/br_multicas
potentially trimmed skb to
verfiy. However, there is no need to propagate it to the caller.
For the second and third case explicit IP packet length checks were
added.
This hopefully makes ip_mc_check_igmp() and ipv6_mc_check_mld() easier
to read and verfiy, as well as easier to use.
Signed-off-by: Linus
Hi,
This patchset adds initial Multicast Router Discovery support to
the Linux bridge (RFC4286). With MRD it is possible to detect multicast
routers and mark bridge ports and forward multicast packets to such routers
accordingly.
So far, multicast routers are detected via IGMP/MLD queries and PIM
ify that length
checks are performed properly.
Signed-off-by: Linus Lüssing
---
net/ipv4/igmp.c| 51 ++---
net/ipv6/mcast_snoop.c | 62 --
2 files changed, 52 insertions(+), 61 deletions(-)
diff --git a/net/i
Hi,
This patchset adds initial Multicast Router Discovery support to
the Linux bridge (RFC4286). With MRD it is possible to detect multicast
routers and mark bridge ports and forward multicast packets to such routers
accordingly.
So far, multicast routers are detected via IGMP/MLD queries and PIM
potentially trimmed skb to
verfiy. However, there is no need to propagate it to the caller.
For the second and third case explicit IP packet length checks were
added.
This hopefully makes ip_mc_check_igmp() and ipv6_mc_check_mld() easier
to read and verfiy, as well as easier to use.
Signed-off-by: Linus
Otherwise other snooping switches might refrain from forwarding these
advertisements to us.
Signed-off-by: Linus Lüssing
---
include/uapi/linux/in.h | 9 +++---
net/bridge/br_multicast.c | 72 ++-
net/ipv6/mcast.c | 2 ++
3 files c
ssing adds such routers to the internal
multicast router list.
Signed-off-by: Linus Lüssing
---
include/linux/in.h | 5 +
include/net/addrconf.h | 15 +
include/uapi/linux/icmpv6.h | 2 ++
include/uapi/linux/igmp.h | 1 +
net/bridge/br_multicas
Hi and thanks for your reply!
On Fri, Dec 14, 2018 at 10:32:16AM +0800, Ying Xu wrote:
> I think the scenario mentioned above is abnormal.
Can we agree, that this scenario, if switch A and B were using the
current bridge code, has issues right now which it did
not have before that patch?
I also
Even though RFC4541 recommends this, I'm not quite sure whether
this works... even for IGMP.
I think this would lead to multicast packet loss in a scenario
like this:
--
[Switch A] -- [Switch B]
/ /
/ /
ehavior to "xtables-nft-multi ebtables" which uses
nft_limit instead of ebt_limit. In tests nft_limit did not suffer from
this issue and rate limited to 650 just fine.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Linus Lüssing
---
Changelog v2:
- Adjusted commit messa
On Sat, Oct 29, 2016 at 12:56:28PM +0200, Jiri Pirko wrote:
> >> I strongly believe it is a huge mistake to use sysfs for things like
> >> this. This should be done via generic netlink api.
> >
> >This doesn't change the problem that it is already that way. This patch
> >only adds the list of avail
On Mon, Mar 12, 2018 at 12:08:56PM +0100, Linus Lüssing wrote:
> On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote:
> > I've problem when using OpenWrt/LEDE on a home router with Broadcom's
> > FullMAC WiFi chipset.
>
> Hi Rafał,
>
> Thanks for
On Mon, Mar 12, 2018 at 10:46:45AM +0100, Rafał Miłecki wrote:
> On 27 February 2018 at 18:05, Stephen Hemminger
[...]
> > ebtables is your friend in dealing with weird and broken devices.
>
> It may be weird, not sure if actually broken. Anyway I'd like to have
> some generic solution instead of
On Tue, Feb 27, 2018 at 11:08:20AM +0100, Rafał Miłecki wrote:
> I've problem when using OpenWrt/LEDE on a home router with Broadcom's
> FullMAC WiFi chipset.
Hi Rafał,
Thanks for reporting this issue!
> Can you see any solution for this problem? Is that an option to stop
> multicast-to-unicast
On Fri, Dec 08, 2017 at 06:46:06AM +0100, Linus Lüssing wrote:
> Extending the usersize to include info->prev would probably be too
> hackish/ugly, right?
And wouldn't be enough anyway, since
info->{credit,credit_cap,cost} would still be zeroed... Hm.
On Thu, Dec 07, 2017 at 01:26:19AM +0100, Pablo Neira Ayuso wrote:
> > I also had a quick look at a 4.15-rc1 kernel in a VM now. I still
> > end up in ebt_limit_mt_check() with the variables being reset
> > when editing the table somewhere.
>
> My question is if your fix would work with 4.15-rc1.
On Mon, Dec 04, 2017 at 05:53:35AM +0100, Linus Lüssing wrote:
> And so, no I do not have this patch. I looked at it now, but it
> does not seem to have any relation with .matchinfo, does it?
Relation between .usersize and .checkentry I ment, not
.usersize and .matchinfo.
Hi Pablo,
Thanks for your reply!
On Tue, Nov 28, 2017 at 12:30:08AM +0100, Pablo Neira Ayuso wrote:
> [...]
> > diff --git a/net/bridge/netfilter/ebt_limit.c
> > b/net/bridge/netfilter/ebt_limit.c
> > index 61a9f1be1263..f74b48633feb 100644
> > --- a/net/bridge/netfilter/ebt_limit.c
> > +++ b/ne
sending packets every 250ms for 600s, with a
"--limit 1/sec --limit-burst 50" rule and a command like this
in the background:
$ ebtables -N VOIDCHAIN
$ while true; do ebtables -F VOIDCHAIN; sleep 30; done
The results are:
Before: ~1600 packets
After: 650 packets
Signed-off-by: Linus Lüssing
nning of ip_input.c/ip_rcv() as the dnat target left
the skb->pkt_type as PACKET_OTHERHOST.
Fixing this by resetting skb->pkt_type to an appropriate type after
dnat'ing.
Signed-off-by: Linus Lüssing
---
Changelog v3:
- moved pkt_type fixup into ebtable dnat code
-> v1/v
On Tue, Mar 21, 2017 at 04:32:45PM -0700, Stephen Hemminger wrote:
> On Tue, 21 Mar 2017 23:28:45 +0100
> Linus Lüssing wrote:
>
> > However, the IP code drops it in the beginning of ip_input.c/ip_rcv()
> > as the dnat target did not update the skb->pkt_type. If after
&g
PACKET_OTHERHOST to PACKET_HOST, too.
Signed-off-by: Linus Lüssing
---
Changelog v2:
* refrain from altering pkt_type for multicast packets
with a unicast destination MAC
---
net/bridge/br_input.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/bridge/br_inpu
On Sun, Mar 19, 2017 at 05:55:06PM +0100, Linus Lüssing wrote:
> On Fri, Mar 17, 2017 at 02:10:44PM +0100, Pablo Neira Ayuso wrote:
> > Wait.
> >
> > May this break local multicast listener that are bound to the bridge
> > interface? Assuming the bridge interface
On Fri, Mar 17, 2017 at 02:10:44PM +0100, Pablo Neira Ayuso wrote:
> Wait.
>
> May this break local multicast listener that are bound to the bridge
> interface? Assuming the bridge interface got an IP address, and that
> there is local multicast listener.
>
> Missing anything here?
Hm, for multi
On Wed, Mar 15, 2017 at 07:15:39PM +0100, Pablo Neira Ayuso wrote:
> Could you update ebtables dnat to check if the ethernet address
> matches the one of the input bridge interface, so we mangle the
> ->pkt_type accordingly from there, instead of doing this from the
> core?
Actually, that was the
On Wed, Mar 15, 2017 at 11:42:11AM +0100, Pablo Neira Ayuso wrote:
> I'm missing then why redirect is not then just enough for Linus usecase.
For my usecase, the MAC address is configured by the user from a
Web-UI. It may or may not be the one from the bridge device.
Besides, found it counter int
PACKET_OTHERHOST to PACKET_HOST, too.
Signed-off-by: Linus Lüssing
---
net/bridge/br_input.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 013f2290b..ec83175 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_i
tch fixes this by always resending MLD reports when an interface
change happens, for instance from NO-CARRIER to CARRIER state.
Signed-off-by: Linus Lüssing
---
Initial problem report was sent to the bridge mailing list a while ago:
- https://lists.linuxfoundation.org/pipermail/bridge/2015-Se
...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing
---
This feature is used and enabled by default in OpenWRT and LEDE for AP
interfaces for more than a year now to allow both a more robust multicast
delivery and multicast at higher rates (e.g. multicast streaming
...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing
---
This feature is used and enabled by default in OpenWRT and LEDE for AP
interfaces for more than a year now to allow both a more robust multicast
delivery and multicast at higher rates (e.g. multicast streaming
+ style fixes, commit message]
Signed-off-by: Linus Lüssing
---
This feature is used and enabled by default in OpenWRT and LEDE for AP
interfaces for more than a year now to allow both a more robust multicast
delivery and multicast at higher rates (e.g. multicast streaming).
In OpenWRT/LEDE the
...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing
---
This feature is used and enabled by default in OpenWRT and LEDE for AP
interfaces for more than a year now to allow both a more robust multicast
delivery and multicast at higher rates (e.g. multicast streaming
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> I wonder if MAC80211 should be doing IGMP snooping and not bridge
> in this environment.
In the long term, yes. For now, not quite sure.
I personally like to go for simple solutions first :).
On Mon, Jan 09, 2017 at 10:42:46PM +0100, Johannes Berg wrote:
> On Mon, 2017-01-09 at 22:33 +0100, Linus Lüssing wrote:
> > On Mon, Jan 09, 2017 at 01:44:03PM +0100, Johannes Berg wrote:
> > >
> > > > > A host SHOULD silently discard a datagr
On Mon, Jan 09, 2017 at 12:44:19PM +0100, M. Braun wrote:
> Am 09.01.2017 um 09:08 schrieb Johannes Berg:
> > Does it make sense to implement the two in separate layers though?
> >
> > Clearly, this part needs to be implemented in the bridge layer due to
> > the snooping knowledge, but the code is
On Mon, Jan 09, 2017 at 09:05:49AM +0100, Johannes Berg wrote:
> On Sat, 2017-01-07 at 16:15 +0100, Linus Lüssing wrote:
>
> > Actually, I do not quite understand that remark in the mac80211
> > multicast-to-unicast patch. IP should not care about the ethernet
> > heade
On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg wrote:
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
>
> I suppose that the f
On Fri, Jan 06, 2017 at 07:13:56PM -0800, Stephen Hemminger wrote:
> On Mon, 2 Jan 2017 20:32:14 +0100
> Linus Lüssing wrote:
>
> > This feature is intended for interface types which have a more reliable
> > and/or efficient way to deliver unicast packets than broadcas
On Sat, Jan 07, 2017 at 11:32:57AM +0100, M. Braun wrote:
> Am 06.01.2017 um 14:54 schrieb Johannes Berg:
> >
> >> The bridge layer can use IGMP snooping to ensure that the multicast
> >> stream is only transmitted to clients that are actually a member of
> >> the group. Can the mac80211 feature d
packets than broadcast ones
(e.g. wifi).
However, it should only be enabled on interfaces where no IGMPv2/MLDv1
report suppression takes place. This feature is disabled by default.
The initial patch and idea is from Felix Fietkau.
Cc: Felix Fietkau
Signed-off-by: Linus Lüssing
---
This feature
On Mon, Oct 17, 2016 at 11:39:04AM +0200, Johannes Berg wrote:
> On Mon, 2016-10-17 at 00:39 +0200, Linus Lüssing wrote:
> > For mac80211_hwsim interfaces, suggest to use wpa_supplicant with the
> > more modern, netlink based driver instead of wext.
>
> Makes sense, applie
For mac80211_hwsim interfaces, suggest to use wpa_supplicant with the more
modern, netlink based driver instead of wext.
Signed-off-by: Linus Lüssing
---
Actually, I wasn't even able to make a connection with the configuration
files and information provided in
Documentation/netwo
On Wed, Aug 31, 2016 at 08:02:22AM +0200, Nikolay Aleksandrov wrote:
> On 31/08/16 03:37, Linus Lüssing wrote:
> > On Tue, Aug 30, 2016 at 05:23:08PM +0200, Nikolay Aleksandrov via Bridge
> > wrote:
> >> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> >>
On Tue, Aug 30, 2016 at 05:23:08PM +0200, Nikolay Aleksandrov via Bridge wrote:
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index 1da3221845f1..ed0dd3340084 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -362,7 +362,7 @@ static struct net_bridge_port *new_nbp(struct
This allows modules using this function (currently: batman-adv) to
compile even if cfg80211 is not built at all, thus relaxing
dependencies.
Signed-off-by: Linus Lüssing
---
include/net/cfg80211.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net
On Tue, Jun 28, 2016 at 08:04:42AM -0400, David Miller wrote:
> From: Linus Lüssing
> [...]
> > Fixes: 1d81d4c3dd88 ("bridge: check return value of ipv6_dev_get_saddr()")
>
> You're missing an initial 'd' in that SHA1-ID.
>
> With that fixed, app
On Mon, Jun 27, 2016 at 08:10:48PM +0200, Nikolay Aleksandrov via Bridge wrote:
> These are invaluable when monitoring or debugging complex multicast setups
> with bridges.
Indeed! Great patch :). Especially if people are unable to provide
pcap files for debugging (due to whatever reason). Hopeful
On Fri, Jun 24, 2016 at 12:35:18PM +0200, Daniel Danzberger wrote:
> The bridge is falsly dropping ipv6 mulitcast packets if there is:
> 1. No ipv6 address assigned on the brigde.
> 2. No external mld querier present.
> 3. The internal querier enabled.
>
> When the bridge fails to build mld que
ssinged to the bridge
> and returns a false state for the local querier in
> __br_multicast_querier_exists().
Acked-by: Linus Lüssing
Hi Daniel,
Thanks for submitting this patch here :).
On Thu, Jun 23, 2016 at 11:28:55AM +0200, daniel wrote:
> The bridge is falsly dropping ipv6 mulitcast packets
> if there is no ipv6 address assigned on the brigde and no
> external mld querier is present.
and if the bridge internal querier i
this by taking the offset between IP and IGMP/MLD header into
account, too.
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Simon Wunderlich
Signed-off-by: Linus Lüssing
---
v2: changed "int" to "unsigned int"
net/bridge/br_multicast
On Tue, May 03, 2016 at 01:26:23PM -0700, Stephen Hemminger wrote:
> On Tue, 3 May 2016 22:18:54 +0200
> Linus Lüssing wrote:
>
> > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> > index 03661d9..7105cdf 100644
> > --- a/net/bridge/br_multi
this by taking the offset between IP and IGMP/MLD header into
account, too.
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Simon Wunderlich
Signed-off-by: Linus Lüssing
---
net/bridge/br_multicast.c | 12 +++-
1 file changed, 7 insertions(+), 5
lticast_rcv+0x5dc/0xd00)
[ 44.060077] [<803b2c98>] (br_multicast_rcv) from [<803aa510>]
(br_handle_frame_finish+0xac/0x51c)
[...]
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Álvaro Fernández Rojas
Signed-off-by: Linus Lüssing
---
v3:
*
lticast_rcv+0x5dc/0xd00)
[ 44.060077] [<803b2c98>] (br_multicast_rcv) from [<803aa510>]
(br_handle_frame_finish+0xac/0x51c)
[...]
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Álvaro Fernández Rojas
Signed-off-by: Linus Lüssing
-
On Thu, Feb 18, 2016 at 01:51:34PM +0100, Steinar H. Gunderson wrote:
> On Mon, Feb 15, 2016 at 03:07:06AM +0100, Linus Lüssing wrote:
> > Steinar, can you check whether this fixes the bridge issues you reported on
> > bugzilla #99081? Not quite sure whether it is the same as your
sh+0xac/0x51c)
[...]
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Álvaro Fernández Rojas
Signed-off-by: Linus Lüssing
---
Steinar, can you check whether this fixes the bridge issues you reported on
bugzilla #99081? Not quite sure whether it is the sa
Tested-by: Tobias Powalowski
Signed-off-by: Linus Lüssing
---
net/bridge/br_multicast.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 66efdc2..480b3de 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_m
ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to
additionally check whether the returned skb_trimmed is a clone.
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Brenden Blanco
Signed-off-by: Linus Lüssing
---
net/bridge/br_multicast.c |4 ++--
On Tue, Aug 11, 2015 at 10:51:40PM +0200, Linus Lüssing wrote:
> On Mon, Aug 10, 2015 at 02:56:12PM -0700, Brenden Blanco wrote:
> > Doing some code reading with Alexei, we found a suspect commit, which
> > introduces an skb_get and skb_may_pull of the same skb, which leads
On Mon, Aug 10, 2015 at 02:56:12PM -0700, Brenden Blanco wrote:
> Doing some code reading with Alexei, we found a suspect commit, which
> introduces an skb_get and skb_may_pull of the same skb, which leads to the BUG
> when skb->len == len.
Urgh, didn't know that pskb_may_pull() doesn't like an sk
Hi,
For an .ndo_start_xmit handler, can the callee rely on the caller
setting the skb network header?
Or should the callee set it before performing any
skb_network_header()/ip_hdr()/ipv6_hdr()/... calls?
Cheers, Linus
PS: Currently looking at batman-adv's ndo_start_xmit handler
"interface_tx()"
On Thu, May 28, 2015 at 04:42:54AM -0700, Eric Dumazet wrote:
> Intent of the code was to clear port field, not the pointer to querier.
Acked-by: Linus Lüssing
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.ke
since br_multicast_init() doesn't start any timers and only sets
default values and initializes timers it should be save to reconfigure
the default values after that, before things actually get active after
the bridge is set up.
Signed-off-by: Linus Lüssing
---
Changelog v3:
* Readded two b
since br_multicast_init() doesn't start any timers and only sets
default values and initializes timers it should be save to reconfigure
the default values after that, before things actually get active after
the bridge is set up.
Signed-off-by: Linus Lüssing
---
Changelog v2:
* remove anothe
anged even if the according bridge (port) is down, just like other
other bridge (port) attributes allow too.
Signed-off-by: Linus Lüssing
---
Changelog:
* [RFC PATCH net-next] -> [PATCH net-next]
net/bridge/br_multicast.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(
On Thu, May 21, 2015 at 11:49:21AM +0800, Herbert Xu wrote:
> The timer operations are all supposed to be idempotent. So enabling
> a port twice or stopping it twice should be OK.
Oki doki.
>
> > * Might calls to br_multicast_add_router() via br_multicast_enable_port()
> > cause unintended si
anged even if the according bridge (port) is down, just like other
other bridge (port) attributes allow too.
Signed-off-by: Linus Lüssing
---
I'm currently a little unsure about a few things (that's why I'm sending
this as an RFC):
* For i=br_multicast_init(), e=br_multic
92 matches
Mail list logo
