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 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
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
>
he "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/
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
and 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
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
and 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
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
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
e behavior 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 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 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 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.
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
> > +++
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
> > +++
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: Lin
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
Hi Ben,
On Tue, Nov 07, 2017 at 01:42:35PM +, Ben Hutchings wrote:
> That function didn't exist in 3.16 (at least not under that name).
Ah, you're right, back then the netlink interface did not
exist in batman-adv yet, only the debugfs one.
batadv_tt_global_print_entry would be the
Hi Ben,
On Tue, Nov 07, 2017 at 01:42:35PM +, Ben Hutchings wrote:
> That function didn't exist in 3.16 (at least not under that name).
Ah, you're right, back then the netlink interface did not
exist in batman-adv yet, only the debugfs one.
batadv_tt_global_print_entry would be the
Hi Ben!
On Mon, Nov 06, 2017 at 11:03:02PM +, Ben Hutchings wrote:
> 3.16.50-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Linus Lüssing <linus.luess...@c0d3.blue>
>
> commit 54e22f265e872ae140755b
Hi Ben!
On Mon, Nov 06, 2017 at 11:03:02PM +, Ben Hutchings wrote:
> 3.16.50-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Linus Lüssing
>
> commit 54e22f265e872ae140755b3318521d400a094605 upstream.
[...]
>
On Mon, Oct 23, 2017 at 09:47:21AM +0200, Linus Lüssing wrote:
> I'm currently continuing to bisect which difference in Emiliano's
> and my kernel image makes mine boot successfully but not
> Emiliano's. (And I'm continuing reading and testing with the
> filter-range option to bette
On Mon, Oct 23, 2017 at 09:47:21AM +0200, Linus Lüssing wrote:
> I'm currently continuing to bisect which difference in Emiliano's
> and my kernel image makes mine boot successfully but not
> Emiliano's. (And I'm continuing reading and testing with the
> filter-range option to bette
On Tue, Oct 17, 2017 at 10:07:40AM +0200, Neil Armstrong wrote:
> A PM Power Domain driver has been pushed at [1] to solve the main issue.
URL to [1] missing?
On Tue, Oct 17, 2017 at 10:07:40AM +0200, Neil Armstrong wrote:
> A PM Power Domain driver has been pushed at [1] to solve the main issue.
URL to [1] missing?
and if
configured would successfully trigger a reboot of the system.
Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
The following stress-ng command worked fine now:
$ stress-ng -v --sequential 0 -
and if
configured would successfully trigger a reboot of the system.
Fixes: 4a69fcd3a108 ("ARM: meson: Add DTS for Odroid-C1 and Tronfy MXQ boards")
Signed-off-by: Linus Lüssing
---
The following stress-ng command worked fine now:
$ stress-ng -v --sequential 0 -t 120s --exclude sysfs,opcode --
The Odroid U3 (Exynos 4412 based) for instance needs this driver,
otherwise its USB hub will not come up.
Also selecting it as built-in to allow booting from USB without
an initrd/initramfs. exynos_defconfig does the same already, too.
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.b
The Odroid U3 (Exynos 4412 based) for instance needs this driver,
otherwise its USB hub will not come up.
Also selecting it as built-in to allow booting from USB without
an initrd/initramfs. exynos_defconfig does the same already, too.
Signed-off-by: Linus Lüssing
---
arch/arm/configs
Hi Krzysztof,
Thanks for your quick reply!
On Thu, Sep 28, 2017 at 08:21:26AM +0200, Krzysztof Kozlowski wrote:
> [...]
> Anyway please define this as a module (unless it can't... but it
> worked in my case).
In that case you used an initrd, right? I see various cases of USB
built-ins, like
Hi Krzysztof,
Thanks for your quick reply!
On Thu, Sep 28, 2017 at 08:21:26AM +0200, Krzysztof Kozlowski wrote:
> [...]
> Anyway please define this as a module (unless it can't... but it
> worked in my case).
In that case you used an initrd, right? I see various cases of USB
built-ins, like
The Odroid U3 (Exynos 4412 based) for instance needs this driver,
otherwise its USB hub will not come up.
exynos_defconfig already has this enabled as built-in, too. So
just doing the same here in multi_v7_defconfig.
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
Thanks to
The Odroid U3 (Exynos 4412 based) for instance needs this driver,
otherwise its USB hub will not come up.
exynos_defconfig already has this enabled as built-in, too. So
just doing the same here in multi_v7_defconfig.
Signed-off-by: Linus Lüssing
---
Thanks to Tobias Jakobi, who indirectly made
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 <linus.luess...@c0d3.blue>
---
Changelog v3:
- moved pkt_type fixup into ebtable dnat cod
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/v2 o
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 <linus.luess...@c0d3.blue> wrote:
>
> > However, the IP code drops it in the beginning of ip_input.c/ip_rcv()
> > as the dnat target did not update
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
ERHOST to PACKET_HOST, too.
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
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
ERHOST 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_input.c b/net/
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
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
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
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
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 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
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
ERHOST to PACKET_HOST, too.
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
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
+++
ERHOST 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_input.c
@@
On Wed, Feb 22, 2017 at 10:03:02AM +0800, kernel test robot wrote:
>
> FYI, we noticed the following commit:
>
> commit: a088d1d73a4bcfd7bc482f8d08375b9b665dc3e5 ("ipv6: Fix IPv6 packet loss
> in scenarios involving roaming + snooping switches")
>
On Wed, Feb 22, 2017 at 10:03:02AM +0800, kernel test robot wrote:
>
> FYI, we noticed the following commit:
>
> commit: a088d1d73a4bcfd7bc482f8d08375b9b665dc3e5 ("ipv6: Fix IPv6 packet loss
> in scenarios involving roaming + snooping switches")
>
On Wed, Feb 15, 2017 at 10:41:34PM +, Ben Hutchings wrote:
> 3.2.85-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Linus Lüssing <linus.luess...@c0d3.blue>
>
> commit 9799c50372b23ed774791bdb87d700f
On Wed, Feb 15, 2017 at 10:41:34PM +, Ben Hutchings wrote:
> 3.2.85-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Linus Lüssing
>
> commit 9799c50372b23ed774791bdb87d700f1286ee8a9 upstream.
Hi Ben,
Thi
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 <linus.luess...@c0d3.blue>
---
Initial problem report was sent to the bridge mailing list a while ago:
- https://lists.linuxfounda
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/20
kau <n...@nbd.name>
[linus.luess...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
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
...@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
kau <n...@nbd.name>
[linus.luess...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
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
...@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 <linus.luess...@c0d3.blue>
---
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 highe
+ 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
kau <n...@nbd.name>
[linus.luess...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
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
...@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 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 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
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
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
> >
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
> >
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
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
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 <linus.luess...@c0d3.blue> wrote:
>
> > This feature is intended for interface types which have a more reliable
> > and/or efficient way to d
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
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
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 <n...@nbd.name>
Signed-off-by: Linus L
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
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 <linus.luess...@c0d3.blue>
---
Actually, I wasn't even able to make a connection with the configuration
files and information pr
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/networking
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 <linus.luess...@c0d3.blue>
---
include/net/cfg80211.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/inclu
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
For one thing, summarizes all non-umlaut versions into the umlaut one
(Linus Luessing -> Linus Lüssing).
For another, maps obosolete email addresses to the current @c0d3.blue
one.
Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
.mailmap | 2 ++
1 file changed, 2 insertions
For one thing, summarizes all non-umlaut versions into the umlaut one
(Linus Luessing -> Linus Lüssing).
For another, maps obosolete email addresses to the current @c0d3.blue
one.
Signed-off-by: Linus Lüssing
---
.mailmap | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.mailma
On Tue, Jun 28, 2016 at 08:04:42AM -0400, David Miller wrote:
> From: Linus Lüssing <linus.luess...@c0d3.blue>
> [...]
> > Fixes: 1d81d4c3dd88 ("bridge: check return value of ipv6_dev_get_saddr()")
>
> You're missing an initial 'd' in that SHA1-ID.
>
>
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, applied and queued
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
1 - 100 of 269 matches
Mail list logo
