Re: [Bridge] [RFC PATCH net-next] bridge: Implement MLD Querier wake-up calls / Android bug workaround

[Linus Lüssing]

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 tempting. However as far as I know
OpenWrt's firewall has no easy layer 2 netfilter integration yet.
So it has default layer 3 netfilter rules, but not for layer 2.

Ideally I'd want to work towards a solution where things "just
work as expected" when a user enables "IGMP Snooping" in the UI.
I could hack the netfilter rules into netifd, the OpenWrt network
manager, when it configures the bridge. But not sure if the
OpenWrt maintainers would like that...

Any preferences from the OpenWrt maintainers side?

Regards, Linus


PS: With BPF I don't have that much experience yet. I would need
to write a daemon which would parse the MLD packets and would
fetch the FDB via netlink, right? If so, sounds like that would
need way more than 300 lines of code. And that would need to be
maintained within OpenWrt, right?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[RFC PATCH net-next] bridge: Implement MLD Querier wake-up calls / Android bug workaround

[Linus Lüssing]

Implement a configurable MLD Querier wake-up calls "feature" which
works around a widely spread Android bug in connection with IGMP/MLD
snooping.

Currently there are mobile devices (e.g. Android) which are not able
to receive and respond to MLD Queries reliably because the Wifi driver
filters a lot of ICMPv6 when the device is asleep - including
MLD. This in turn breaks IPv6 communication when MLD Snooping is
enabled. However there is one ICMPv6 type which is allowed to pass and
which can be used to wake up the mobile device: ICMPv6 Echo Requests.

If this bridge is the selected MLD Querier then setting
"multicast_wakeupcall" to a number n greater than 0 will send n
ICMPv6 Echo Requests to each host behind this port to wake
them up with each MLD Query. Upon receiving a matching ICMPv6 Echo
Reply an MLD Query with a unicast ethernet destination will be sent
to 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 that this is quite a hack, so I'm unsure if this is suitable
for upstream. On the other hand, the Android ticket isn't moving
anywhere and even if it were fixed in Android, I'd expect it to take
years until that fix would propagate or unpatched Android devices to
vanish. So I'm wondering if it should be treated like a hardware bug
workaround and by that should be suitable for applying it upstream in
the Linux kernel?

I've also raised this issue on the mcast-w...@ietf.org and p...@ietf.org
mailing list earlier this year but the amount of feedback was a bit
sparse.

CC'ing the OpenWrt mailing list, too, as I expect there to be most users
affected by this issue, if they enabled IGMP/MLD snooping.

Let me know what you think about this.

 include/linux/if_bridge.h|   1 +
 include/uapi/linux/if_link.h |   1 +
 net/bridge/Kconfig   |  26 
 net/bridge/br_fdb.c  |  10 ++
 net/bridge/br_input.c|   4 +-
 net/bridge/br_multicast.c| 284 ++-
 net/bridge/br_netlink.c  |  19 +++
 net/bridge/br_private.h  |  19 +++
 net/bridge/br_sysfs_if.c |  18 +++
 9 files changed, 374 insertions(+), 8 deletions(-)

diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 6479a38e52fa..73bc692e1ae6 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -50,6 +50,7 @@ struct br_ip_list {
 #define BR_MRP_AWARE   BIT(17)
 #define BR_MRP_LOST_CONT   BIT(18)
 #define BR_MRP_LOST_IN_CONTBIT(19)
+#define BR_MULTICAST_WAKEUPCALLBIT(20)
 
 #define BR_DEFAULT_AGEING_TIME (300 * HZ)
 
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 7fba4de511de..5015f8ce1ad7 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -355,6 +355,7 @@ enum {
IFLA_BRPORT_BACKUP_PORT,
IFLA_BRPORT_MRP_RING_OPEN,
IFLA_BRPORT_MRP_IN_OPEN,
+   IFLA_BRPORT_MCAST_WAKEUPCALL,
__IFLA_BRPORT_MAX
 };
 #define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
diff --git a/net/bridge/Kconfig b/net/bridge/Kconfig
index 80879196560c..056e80bf00c4 100644
--- a/net/bridge/Kconfig
+++ b/net/bridge/Kconfig
@@ -48,6 +48,32 @@ config BRIDGE_IGMP_SNOOPING
 
  If unsure, say Y.
 
+config BRIDGE_IGMP_SNOOPING_WAKEUPCALLS
+   bool "MLD Querier wake-up calls"
+   depends on BRIDGE_IGMP_SNOOPING
+   depends on IPV6
+   help
+ If you say Y here, then the MLD Snooping Querier will be built
+ with a per bridge port wake-up call "feature"/workaround.
+
+ Currently there are mobile devices (e.g. Android) which are not able
+ to receive and respond to MLD Queries reliably because the Wifi driver
+ filters a lot of ICMPv6 when the device is asleep - including MLD.
+ This in turn breaks IPv6 communication when MLD Snooping is enabled.
+ However there is one ICMPv6 type which is allowed to pass and
+ which can be used to wake up the mobile device: ICMPv6 Echo Requests.
+
+ If this bridge is the selected MLD Querier then setting
+ "multicast_wakeupcall" to a number n greater than 0 will send n
+ ICMPv6 Echo Requests to each host behind this port to wake them up
+ with each MLD Query. Upon receiving a matching ICMPv6 Echo Reply
+ an MLD Query with a unicast ethernet destination will be sent to the
+ specific host(s).
+
+ Say N to exclude this support and reduce the binary size.
+
+ If unsure, say N.
+
 config BRIDGE_VLAN_FILTERING
bool "VLAN filtering"
depends on BRIDGE
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 9db504baa094..f63f85c5007c 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c

Re: [OpenWrt-Devel] [PATCH] layerscape: kernel: cma: increase CMA buffer size from 16 to 32MB

[Linus Lüssing]

On 25/05/2020 11:25, m...@adrianschmutzler.de wrote:
[...]

Despite, armv7 uses 64 MB ?


Hm, you're right. Not sure, I wouldn't increase the CMA buffer more as 
needed though, as any unused CMA space is basically wasted, it can't be 
used for caches etc right now.


But I can increase it to 64 MB to not divert from armv7 if that's 
preferred. As all layerscape boards usually come with a large amount of 
RAM, I assume?


Regards, Linus

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] layerscape: kernel: cma: increase CMA buffer size from 16 to 32MB

[Linus Lüssing]

From: Linus Lüssing 

16MB are not enough for ath10k to initialize three 4x4 AC Wave 2
PCIe cards
(168c:0046: Qualcomm Atheros QCA9984 802.11ac Wave 2 Wireless Network Adapter).
This leads to the following error when trying to initialize the third
one:

[   16.742475] ath10k_pci 0002:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 
reset_mode 0
[   16.874024] ath10k_pci 0002:01:00.0: Direct firmware load for 
ath10k/pre-cal-pci-0002:01:00.0.bin failed with error -2
[   16.884784] ath10k_pci 0002:01:00.0: Direct firmware load for 
ath10k/cal-pci-0002:01:00.0.bin failed with error -2
[   16.895224] ath10k_pci 0002:01:00.0: Direct firmware load for 
ath10k/QCA9984/hw1.0/firmware-6.bin failed with error -2
[   16.905956] ath10k_pci 0002:01:00.0: qca9984/qca9994 hw1.0 target 0x0100 
chip_id 0x sub 168c:cafe
[   16.915881] ath10k_pci 0002:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 
1 testmode 1
[   16.925422] ath10k_pci 0002:01:00.0: firmware ver 10.4-3.9.0.2-00021 api 5 
features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 
9626782c
[   18.169022] ath10k_pci 0002:01:00.0: board_file api 2 bmi_id 0:31 crc32 
cf58c3bc
[   20.692482] cma: cma_alloc: alloc failed, req-size: 200 pages, ret: -12
[   25.882670] ath10k_pci 0002:01:00.0: wmi service ready event not received
[   25.943121] ath10k_pci 0002:01:00.0: could not init core (-110)
[   25.949048] ath10k_pci 0002:01:00.0: could not probe fw (-110)

Fixing this issue by doubling the CMA buffer size from 16 to 32MB.
New values in /proc/meminfo, with three such cards connected:

root@OpenWrt:/# cat /proc/meminfo | grep -i "cma"
CmaTotal:  32768 kB
CmaFree:   19268 kB

Interestingly, older Qualcomm AC cards
(Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter)
don't seem to use the Contiguous Memory Allocator and therefore
don't suffer from this issue.

Signed-off-by: Linus Lüssing 
---
 target/linux/layerscape/armv8_64b/config-4.14 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/layerscape/armv8_64b/config-4.14 
b/target/linux/layerscape/armv8_64b/config-4.14
index c1bd718366..ef1bbadd2b 100644
--- a/target/linux/layerscape/armv8_64b/config-4.14
+++ b/target/linux/layerscape/armv8_64b/config-4.14
@@ -140,7 +140,7 @@ CONFIG_CMA_ALIGNMENT=8
 CONFIG_CMA_AREAS=7
 # CONFIG_CMA_DEBUG is not set
 # CONFIG_CMA_DEBUGFS is not set
-CONFIG_CMA_SIZE_MBYTES=16
+CONFIG_CMA_SIZE_MBYTES=32
 # CONFIG_CMA_SIZE_SEL_MAX is not set
 CONFIG_CMA_SIZE_SEL_MBYTES=y
 # CONFIG_CMA_SIZE_SEL_MIN is not set
-- 
2.27.0.rc0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] imx6: Adding Ka-Ro electronics TX6U-8033 Module on MB7 baseboard support

[Linus Lüssing]

From: Linus Lüssing 

This adds support for the Ka-Ro MB7 board with a TX6U-8033 module.

Specification, according to Linux DTS commit:

TX6U-8033:
ProcessorFreescale i.MX 6 Dual Lite, 800MHz
RAM  1GiB DDR3 SDRAM
ROM  4GiB eMMC
Power supply Single 3.1V to 5.5V
Size 31mm SO-DIMM
Temp. Range  industrial grade (-40°C/-25°C to 105°C Tj)

The u-boot shipped by the vendor by default expects the following partition
layout:

MBR/MSDOS, disk-id '0cc66cc0' {
0cc66cc0-01 => ext2, /vmlinuz
0cc66cc0-02 => ext4, rootfs
}

TX6DL U-Boot > env print
append_bootargs=rootfstype=ext4
[...]
bootcmd_mmc=setenv autostart no;run bootargs_mmc;ext2load mmc 0 ${kerneladdr} 
vmlinuz
[...]
rootpart_uuid=0cc66cc0-02
[...]

This is also one of the reasons, why only ext4 rootfs support was added
and tested so far. No squashfs support yet.

Other than that, nothing fancy needs to be added or preserved on the
eMMC.

Cc: Simon Wunderlich 
Signed-off-by: Linus Lüssing 
---

Changelog v2:
* removed wildcard board names

 target/linux/imx6/Makefile|   2 +-
 .../imx6/base-files/etc/board.d/02_network|   3 +-
 target/linux/imx6/base-files/lib/imx6.sh  |   4 +
 .../base-files/lib/preinit/79_move_config |   9 ++
 .../imx6/base-files/lib/upgrade/platform.sh   | 108 +-
 target/linux/imx6/image/Makefile  |  34 ++
 .../linux/imx6/image/gen_karo_sdcard_img.sh   |  26 +
 .../imx6/patches-4.14/100-bootargs.patch  |  13 +++
 tools/Makefile|   1 +
 9 files changed, 197 insertions(+), 3 deletions(-)
 create mode 100755 target/linux/imx6/image/gen_karo_sdcard_img.sh

diff --git a/target/linux/imx6/Makefile b/target/linux/imx6/Makefile
index ac4300f7eb..8083a54e16 100644
--- a/target/linux/imx6/Makefile
+++ b/target/linux/imx6/Makefile
@@ -20,6 +20,6 @@ include $(INCLUDE_DIR)/target.mk
 
 KERNELNAME:=zImage dtbs
 
-DEFAULT_PACKAGES += uboot-envtools mkf2fs e2fsprogs blkid
+DEFAULT_PACKAGES += uboot-envtools mkf2fs e2fsprogs blkid partx-utils
 
 $(eval $(call BuildTarget))
diff --git a/target/linux/imx6/base-files/etc/board.d/02_network 
b/target/linux/imx6/base-files/etc/board.d/02_network
index 6ec667346d..c662be72b7 100755
--- a/target/linux/imx6/base-files/etc/board.d/02_network
+++ b/target/linux/imx6/base-files/etc/board.d/02_network
@@ -21,7 +21,8 @@ cubox-i |\
 *gw552x)
ucidef_set_interfaces_lan_wan 'eth0' 'eth1'
;;
-*wandboard)
+*wandboard |\
+tx6u-8033)
ucidef_set_interface_wan 'eth0'
;;
 esac
diff --git a/target/linux/imx6/base-files/lib/imx6.sh 
b/target/linux/imx6/base-files/lib/imx6.sh
index 68caaff15f..c4b87d1c21 100755
--- a/target/linux/imx6/base-files/lib/imx6.sh
+++ b/target/linux/imx6/base-files/lib/imx6.sh
@@ -99,6 +99,10 @@ imx6_board_detect() {
name="wandboard"
;;
 
+   "Ka-Ro electronics TX6U-8033 Module on MB7 baseboard")
+   name="tx6u-8033"
+   ;;
+
*)
name="generic"
;;
diff --git a/target/linux/imx6/base-files/lib/preinit/79_move_config 
b/target/linux/imx6/base-files/lib/preinit/79_move_config
index bdf397c4fc..de7196c7a1 100644
--- a/target/linux/imx6/base-files/lib/preinit/79_move_config
+++ b/target/linux/imx6/base-files/lib/preinit/79_move_config
@@ -15,6 +15,15 @@ move_config() {
umount /boot
fi
;;
+   tx6u-8033)
+   local bootpart=/dev/mmcblk2p1
+
+   if [ -b $bootpart ]; then
+   mkdir -p /boot
+   mount -t ext2 -o rw,noatime $bootpart /boot
+   [ -f /boot/sysupgrade.tgz ] && mv -f 
/boot/sysupgrade.tgz /
+   fi
+   ;;
esac
 }
 
diff --git a/target/linux/imx6/base-files/lib/upgrade/platform.sh 
b/target/linux/imx6/base-files/lib/upgrade/platform.sh
index a090cc080b..9c9bed96fe 100755
--- a/target/linux/imx6/base-files/lib/upgrade/platform.sh
+++ b/target/linux/imx6/base-files/lib/upgrade/platform.sh
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2010-2015 OpenWrt.org
+# Copyright (C) 2010-2019 OpenWrt.org
 #
 
 . /lib/imx6.sh
@@ -30,6 +30,102 @@ apalis_do_upgrade() {
umount /boot
 }
 
+# (mostly) copied from brcm2708 platform.sh (which was copied from x86?)
+tx6u_8033_check_image() {
+   local diskdev partdev diff
+
+   [ "$#" -gt 1 ] && return 1
+
+   export_bootdevice && export_partdevice diskdev 0 || {
+   echo "Unable to determine upgrade device"
+   return 1
+   }
+
+   get_partitions "/dev/$diskdev" bootdisk
+
+   #extract the boot sector from the image
+   get_image "$@" | dd of=/tmp/image.bs count=1 bs=512b 2>/dev/null
+
+   get_partitions /tmp/image.bs image
+
+   #comp

[OpenWrt-Devel] [PATCH] imx6: Adding Ka-Ro electronics TX6U-8033 Module on MB7 baseboard support

[Linus Lüssing]

From: Linus Lüssing 

This adds support for the Ka-Ro MB7 board with a TX6U-8033 module.

Specification, according to Linux DTS commit:

TX6U-8033:
ProcessorFreescale i.MX 6 Dual Lite, 800MHz
RAM  1GiB DDR3 SDRAM
ROM  4GiB eMMC
Power supply Single 3.1V to 5.5V
Size 31mm SO-DIMM
Temp. Range  industrial grade (-40°C/-25°C to 105°C Tj)

The u-boot shipped by the vendor by default expects the following partition
layout:

MBR/MSDOS, disk-id '0cc66cc0' {
0cc66cc0-01 => ext2, /vmlinuz
0cc66cc0-02 => ext4, rootfs
}

TX6DL U-Boot > env print
append_bootargs=rootfstype=ext4
[...]
bootcmd_mmc=setenv autostart no;run bootargs_mmc;ext2load mmc 0 ${kerneladdr} 
vmlinuz
[...]
rootpart_uuid=0cc66cc0-02
[...]

This is also one of the reasons, why only ext4 rootfs support was added
and tested so far. No squashfs support yet.

Other than that, nothing fancy needs to be added or preserved on the
eMMC.

Cc: Simon Wunderlich 
Signed-off-by: Linus Lüssing 
---
 target/linux/imx6/Makefile|   2 +-
 .../imx6/base-files/etc/board.d/02_network|   3 +-
 target/linux/imx6/base-files/lib/imx6.sh  |   4 +
 .../base-files/lib/preinit/79_move_config |   9 ++
 .../imx6/base-files/lib/upgrade/platform.sh   | 108 +-
 target/linux/imx6/image/Makefile  |  34 ++
 .../linux/imx6/image/gen_karo_sdcard_img.sh   |  26 +
 .../imx6/patches-4.14/100-bootargs.patch  |  13 +++
 tools/Makefile|   1 +
 9 files changed, 197 insertions(+), 3 deletions(-)
 create mode 100755 target/linux/imx6/image/gen_karo_sdcard_img.sh

diff --git a/target/linux/imx6/Makefile b/target/linux/imx6/Makefile
index ac4300f7eb..8083a54e16 100644
--- a/target/linux/imx6/Makefile
+++ b/target/linux/imx6/Makefile
@@ -20,6 +20,6 @@ include $(INCLUDE_DIR)/target.mk
 
 KERNELNAME:=zImage dtbs
 
-DEFAULT_PACKAGES += uboot-envtools mkf2fs e2fsprogs blkid
+DEFAULT_PACKAGES += uboot-envtools mkf2fs e2fsprogs blkid partx-utils
 
 $(eval $(call BuildTarget))
diff --git a/target/linux/imx6/base-files/etc/board.d/02_network 
b/target/linux/imx6/base-files/etc/board.d/02_network
index 6ec667346d..9f93d5b17e 100755
--- a/target/linux/imx6/base-files/etc/board.d/02_network
+++ b/target/linux/imx6/base-files/etc/board.d/02_network
@@ -21,7 +21,8 @@ cubox-i |\
 *gw552x)
ucidef_set_interfaces_lan_wan 'eth0' 'eth1'
;;
-*wandboard)
+*wandboard |\
+*tx6u-8033)
ucidef_set_interface_wan 'eth0'
;;
 esac
diff --git a/target/linux/imx6/base-files/lib/imx6.sh 
b/target/linux/imx6/base-files/lib/imx6.sh
index 68caaff15f..c4b87d1c21 100755
--- a/target/linux/imx6/base-files/lib/imx6.sh
+++ b/target/linux/imx6/base-files/lib/imx6.sh
@@ -99,6 +99,10 @@ imx6_board_detect() {
name="wandboard"
;;
 
+   "Ka-Ro electronics TX6U-8033 Module on MB7 baseboard")
+   name="tx6u-8033"
+   ;;
+
*)
name="generic"
;;
diff --git a/target/linux/imx6/base-files/lib/preinit/79_move_config 
b/target/linux/imx6/base-files/lib/preinit/79_move_config
index bdf397c4fc..00e3570d1d 100644
--- a/target/linux/imx6/base-files/lib/preinit/79_move_config
+++ b/target/linux/imx6/base-files/lib/preinit/79_move_config
@@ -15,6 +15,15 @@ move_config() {
umount /boot
fi
;;
+   *tx6u-8033*)
+   local bootpart=/dev/mmcblk2p1
+
+   if [ -b $bootpart ]; then
+   mkdir -p /boot
+   mount -t ext2 -o rw,noatime $bootpart /boot
+   [ -f /boot/sysupgrade.tgz ] && mv -f 
/boot/sysupgrade.tgz /
+   fi
+   ;;
esac
 }
 
diff --git a/target/linux/imx6/base-files/lib/upgrade/platform.sh 
b/target/linux/imx6/base-files/lib/upgrade/platform.sh
index a090cc080b..d6eef0c3eb 100755
--- a/target/linux/imx6/base-files/lib/upgrade/platform.sh
+++ b/target/linux/imx6/base-files/lib/upgrade/platform.sh
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2010-2015 OpenWrt.org
+# Copyright (C) 2010-2019 OpenWrt.org
 #
 
 . /lib/imx6.sh
@@ -30,6 +30,102 @@ apalis_do_upgrade() {
umount /boot
 }
 
+# (mostly) copied from brcm2708 platform.sh (which was copied from x86?)
+tx6u_8033_check_image() {
+   local diskdev partdev diff
+
+   [ "$#" -gt 1 ] && return 1
+
+   export_bootdevice && export_partdevice diskdev 0 || {
+   echo "Unable to determine upgrade device"
+   return 1
+   }
+
+   get_partitions "/dev/$diskdev" bootdisk
+
+   #extract the boot sector from the image
+   get_image "$@" | dd of=/tmp/image.bs count=1 bs=512b 2>/dev/null
+
+   get_partitions /tmp/image.bs image
+
+   #compare tables
+   diff="$(grep -F -

Re: [OpenWrt-Devel] [LEDE-DEV] NETSHe mac80211 GPL sources

[Linus Lüssing]

On Fri, Feb 03, 2017 at 09:35:30AM +0300, Stanislav V. Korsakov wrote:
> Please check this article http://netshe.ru/wirelessstack to understand
> layering of our modifications in Linux wireless stack. 

"this module is a proprietary module broker"

Wow, that's a fancy name for it :D.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH netifd] bridge: make learning and unicast-flood configurable per bridge port

[Linus Lüssing]

Tuning these two options allows a more fine grained configuration of the
forwarding database (fdb) of a bridge.

The former allows to enable or disable the learning of the presence of
MAC addresses behind a bridge port. (default: enabled on all ports)

The latter allows to tune the behaviour in case a destination MAC address
of a frame is unknown to the fdb, like only flooding on specific ports or
not flooding on any port. (default: flood on all ports, except incoming)

This can be useful to create a dumb hub, for instance for monitoring
purposes. Or in larger layer 2 mesh networks to avoid keeping redundant
databases (e.g. with the batman-adv translation table).

Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
 device.c   |   18 ++
 device.h   |6 ++
 system-linux.c |   18 ++
 3 files changed, 42 insertions(+)

diff --git a/device.c b/device.c
index 9344e1b..0e07615 100644
--- a/device.c
+++ b/device.c
@@ -51,6 +51,8 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = "multicast_to_unicast", 
.type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_MULTICAST_ROUTER] = { .name = "multicast_router", .type = 
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_MULTICAST] = { .name ="multicast", .type = BLOBMSG_TYPE_BOOL 
},
+   [DEV_ATTR_LEARNING] = { .name ="learning", .type = BLOBMSG_TYPE_BOOL },
+   [DEV_ATTR_UNICAST_FLOOD] = { .name ="unicast_flood", .type = 
BLOBMSG_TYPE_BOOL },
 };
 
 const struct uci_blob_param_list device_attr_list = {
@@ -177,6 +179,8 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
s->multicast : os->multicast;
n->multicast_to_unicast = s->multicast_to_unicast;
n->multicast_router = s->multicast_router;
+   n->learning = s->learning;
+   n->unicast_flood = s->unicast_flood;
n->flags = s->flags | os->flags | os->valid_flags;
 }
 
@@ -295,6 +299,16 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
s->flags |= DEV_OPT_MULTICAST;
}
 
+   if ((cur = tb[DEV_ATTR_LEARNING])) {
+   s->learning = blobmsg_get_bool(cur);
+   s->flags |= DEV_OPT_LEARNING;
+   }
+
+   if ((cur = tb[DEV_ATTR_UNICAST_FLOOD])) {
+   s->unicast_flood = blobmsg_get_bool(cur);
+   s->flags |= DEV_OPT_UNICAST_FLOOD;
+   }
+
device_set_disabled(dev, disabled);
 }
 
@@ -939,6 +953,10 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u32(b, "multicast_router", 
st.multicast_router);
if (st.flags & DEV_OPT_MULTICAST)
blobmsg_add_u8(b, "multicast", st.multicast);
+   if (st.flags & DEV_OPT_LEARNING)
+   blobmsg_add_u8(b, "learning", st.learning);
+   if (st.flags & DEV_OPT_UNICAST_FLOOD)
+   blobmsg_add_u8(b, "unicast_flood", st.unicast_flood);
}
 
s = blobmsg_open_table(b, "statistics");
diff --git a/device.h b/device.h
index ac77cfb..4a88c05 100644
--- a/device.h
+++ b/device.h
@@ -45,6 +45,8 @@ enum {
DEV_ATTR_MULTICAST_TO_UNICAST,
DEV_ATTR_MULTICAST_ROUTER,
DEV_ATTR_MULTICAST,
+   DEV_ATTR_LEARNING,
+   DEV_ATTR_UNICAST_FLOOD,
__DEV_ATTR_MAX,
 };
 
@@ -88,6 +90,8 @@ enum {
DEV_OPT_MULTICAST_TO_UNICAST= (1 << 14),
DEV_OPT_MULTICAST_ROUTER= (1 << 15),
DEV_OPT_MULTICAST   = (1 << 16),
+   DEV_OPT_LEARNING= (1 << 17),
+   DEV_OPT_UNICAST_FLOOD   = (1 << 18),
 };
 
 /* events broadcasted to all users of a device */
@@ -149,6 +153,8 @@ struct device_settings {
bool multicast_to_unicast;
unsigned int multicast_router;
bool multicast;
+   bool learning;
+   bool unicast_flood;
 };
 
 /*
diff --git a/system-linux.c b/system-linux.c
index 351a994..621f99b 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -372,6 +372,16 @@ static void 
system_bridge_set_startup_query_interval(struct device *dev, const c
  dev->ifname, val);
 }
 
+static void system_bridge_set_learning(struct device *dev, const char *val)
+{
+   system_set_dev_sysctl("/sys/class/net/%s/brport/learning", dev->ifname, 
val);
+}
+
+static void system_bridge_set_unicast_flood(struct device *dev, const char 
*val)
+{
+   system_set_dev_sysctl("/sys/class/net/%s/brport/unicast_flood", 
dev->ifname, val);
+}
+
 static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
 {
int fd = -1, ret = -1;
@@ -648,6 +658,14 @@ int system_bridge_addif(struct device *bridge, struc

[OpenWrt-Devel] [PATCH netifd] bridge: multicast: Export some parameters RFCs suggest to be tunable

[Linus Lüssing]

RFCs suggest some parameters of IGMP and MLD to be configurable by
the administrator. With this patch the following parameters are
configurable:

* robustness (default: 2)
* query_interval (default: 12500 [125s])
* query_response_interval (default: 1000 [10s])
* last_member_interval (default: 100 [1s])

Depending on the size and nature of the network topology administrators
might want to increase or decrease these parameters.

netifd will take care of configuring any other parameters which are
dependant on the ones above and set them according to the formulas
provided in the RFCs. These parameters of the bridge are
membership_interval, querier_interval, startup_query_interval,
startup_query_count and last_member_count.

RFCs allow setting three more parameters to be configurable:
startup_query_interval, startup_query_count and last_member_count.
However this patch does not export them, as they can be indirectly
tuned via the given, exported four parameters, too.

Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
 bridge.c   |   32 ++
 system-linux.c |  131 ++--
 system.h   |   16 +--
 3 files changed, 163 insertions(+), 16 deletions(-)

diff --git a/bridge.c b/bridge.c
index 4a0cbe9..1c163cd 100644
--- a/bridge.c
+++ b/bridge.c
@@ -34,6 +34,10 @@ enum {
BRIDGE_ATTR_BRIDGE_EMPTY,
BRIDGE_ATTR_MULTICAST_QUERIER,
BRIDGE_ATTR_HASH_MAX,
+   BRIDGE_ATTR_ROBUSTNESS,
+   BRIDGE_ATTR_QUERY_INTERVAL,
+   BRIDGE_ATTR_QUERY_RESPONSE_INTERVAL,
+   BRIDGE_ATTR_LAST_MEMBER_INTERVAL,
__BRIDGE_ATTR_MAX
 };
 
@@ -49,6 +53,10 @@ static const struct blobmsg_policy 
bridge_attrs[__BRIDGE_ATTR_MAX] = {
[BRIDGE_ATTR_BRIDGE_EMPTY] = { "bridge_empty", BLOBMSG_TYPE_BOOL },
[BRIDGE_ATTR_MULTICAST_QUERIER] = { "multicast_querier", 
BLOBMSG_TYPE_BOOL },
[BRIDGE_ATTR_HASH_MAX] = { "hash_max", BLOBMSG_TYPE_INT32 },
+   [BRIDGE_ATTR_ROBUSTNESS] = { "robustness", BLOBMSG_TYPE_INT32 },
+   [BRIDGE_ATTR_QUERY_INTERVAL] = { "query_interval", BLOBMSG_TYPE_INT32 },
+   [BRIDGE_ATTR_QUERY_RESPONSE_INTERVAL] = { "query_response_interval", 
BLOBMSG_TYPE_INT32 },
+   [BRIDGE_ATTR_LAST_MEMBER_INTERVAL] = { "last_member_interval", 
BLOBMSG_TYPE_INT32 },
 };
 
 static const struct uci_blob_param_info bridge_attr_info[__BRIDGE_ATTR_MAX] = {
@@ -553,6 +561,10 @@ bridge_apply_settings(struct bridge_state *bst, struct 
blob_attr **tb)
cfg->forward_delay = 2;
cfg->igmp_snoop = true;
cfg->multicast_querier = true;
+   cfg->robustness = 2;
+   cfg->query_interval = 12500;
+   cfg->query_response_interval = 1000;
+   cfg->last_member_interval = 100;
cfg->hash_max = 512;
cfg->bridge_empty = false;
cfg->priority = 0x7FFF;
@@ -575,6 +587,26 @@ bridge_apply_settings(struct bridge_state *bst, struct 
blob_attr **tb)
if ((cur = tb[BRIDGE_ATTR_HASH_MAX]))
cfg->hash_max = blobmsg_get_u32(cur);
 
+   if ((cur = tb[BRIDGE_ATTR_ROBUSTNESS])) {
+   cfg->robustness = blobmsg_get_u32(cur);
+   cfg->flags |= BRIDGE_OPT_ROBUSTNESS;
+   }
+
+   if ((cur = tb[BRIDGE_ATTR_QUERY_INTERVAL])) {
+   cfg->query_interval = blobmsg_get_u32(cur);
+   cfg->flags |= BRIDGE_OPT_QUERY_INTERVAL;
+   }
+
+   if ((cur = tb[BRIDGE_ATTR_QUERY_RESPONSE_INTERVAL])) {
+   cfg->query_response_interval = blobmsg_get_u32(cur);
+   cfg->flags |= BRIDGE_OPT_QUERY_RESPONSE_INTERVAL;
+   }
+
+   if ((cur = tb[BRIDGE_ATTR_LAST_MEMBER_INTERVAL])) {
+   cfg->last_member_interval = blobmsg_get_u32(cur);
+   cfg->flags |= BRIDGE_OPT_LAST_MEMBER_INTERVAL;
+   }
+
if ((cur = tb[BRIDGE_ATTR_AGEING_TIME])) {
cfg->ageing_time = blobmsg_get_u32(cur);
cfg->flags |= BRIDGE_OPT_AGEING_TIME;
diff --git a/system-linux.c b/system-linux.c
index 052bc94..7638086 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -332,6 +332,50 @@ static void system_bridge_set_multicast_router(struct 
device *dev, const char *v
  dev->ifname, val);
 }
 
+static void system_bridge_set_robustness(struct device *dev, const char *val)
+{
+   
system_set_dev_sysctl("/sys/devices/virtual/net/%s/bridge/multicast_startup_query_count",
+ dev->ifname, val);
+   
system_set_dev_sysctl("/sys/devices/virtual/net/%s/bridge/multicast_last_member_count",
+ dev->ifname, val);
+}
+
+static void system_bridge_set_query_interval(struct device *dev, const char 
*val)
+{
+   
system_set_dev_sysctl("/sys/devices/virtual/net/%s/bridge/multicast_query_interval",
+   

Re: [OpenWrt-Devel] Request for Feedback - prplwrt Software Support Program - initial draft

[Linus Lüssing]

On Thu, Mar 03, 2016 at 03:07:22PM -0600, Eric Schultz wrote:
> * prpl and its members, as funders, would set initial themes that all
> projects would be expected to fit into.

Could you clarify what you mean with "initial themes", maybe some
examples?

What would happen if the OpenWRT community were unhappy with what
prpl members set as "initial themes"?


What would happen if an "initial theme" decided by
"the industry(TM)" through prpl membership were contrary to some
non-profit projects/organisations (for instance Freifunk) ideas on
"initial themes"?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Battlemesh] the cerowrt project's letter to the fcc about the wifi lockdown is nearly final

[Linus Lüssing]

On Tue, Oct 06, 2015 at 04:21:38PM +0200, Benjamin Henrion wrote:
> On Tue, Oct 6, 2015 at 3:49 PM, Linus Lüssing <linus.luess...@c0d3.blue> 
> wrote:
> > On Tue, Oct 06, 2015 at 02:13:36AM +0200, Dave Taht wrote:
> >> Comment away!
> >
> > There are many good points made in this text.
> >
> > I like the Volkswagen example and the suggestion to require
> > opening up the firmware.
> >
> > For the latter, had been thinking about that before briefly,
> > but kind of dismissed it early, basically because the reasoning in
> > my head was that FCC shouldn't make any requirements regarding
> > the form of the software at all. They should only regulate the
> > result.
> 
> Blobs cannot be trusted to do the right thing.

I know (and I guess we all do here?). I don't get the purpose of
this comment, sorry :(.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] the cerowrt project's letter to the fcc about the wifi lockdown is nearly final

[Linus Lüssing]

On Tue, Oct 06, 2015 at 02:13:36AM +0200, Dave Taht wrote:
> Comment away!

There are many good points made in this text.

I like the Volkswagen example and the suggestion to require
opening up the firmware.

For the latter, had been thinking about that before briefly,
but kind of dismissed it early, basically because the reasoning in
my head was that FCC shouldn't make any requirements regarding
the form of the software at all. They should only regulate the
result.

Actually this text and the VW example convinced me :). And yes,
now I think with that we can push even further, suggesting to
require open and modifiable source code (for the wifi part at
least). The VW example gives us the opportunity and strategic
advantage to be able to demandn more without sounding
unreasonable.

~

Some quotations and remarks:

"'It is our view that the rules appear to regulate the "means" not
the "ends"'"
-> So does the alternate approach in the end, but in the opposite
   "extreme"

"This software contains built-in configurations to ensure that
radios are used in compliance with the local laws and
regulations."
-> "ensure" seems to be a too strong word to me

"is a natural target for both criminal exploitation and
cyberwarfare"
-> Just my personal taste, but I don't like using the word "war"
   for mere economical power play between nations as it seems
   to soften the original meaning of "war", meaning to kill people
   (don't like the term "cryptowars" either - maybe that taste
   might have cultural roots; the word "war" is never used in
   German language in contexts like these while it seems more
   common in the US and probably other countries too?)
   
"It is currently limiting our attempts to fix the ath9k and mt76
devices"
-> What is meant by that exactly? ath9k is open source, binary
   firmwares can't be the issue you mean here... - with "it
   is limiting", do you mean "new, emerging devices with locked
   firmwares are limiting..."? Maybe clarify the "it"?

"If the Commission does not intend to prohibit the upgrade or
replacement of firmware in Wi-Fi devices, rules would be welcomed
that actually encouraged non-destructive interpretations by
equipment vendors."
-> That one might need explanations too. Actually, I think it is
   explained later, with citatitons of vendors. But ending the
   paragraph there leaves a questions mark for quite a while.

~

Not sure how much time is left to work on the text - content wise
everything seems to be in there. Structually maybe a guiding
thread could be worked out a little more. The beginning is good
and mentions and summarizes the main points well. Some points and
explanations seem to be repeated several times after that though.
Maybe things could be "unbloated" a little here and there ;).

Also the recommendations are not quite clear at some points to me.
The "Alternate Approach" and "Recommendations" sections are clear
by mandating open and modifiable firmwares for the wifi parts at
least. But some other parts seem to allude to different
suggestions. For instance as of writing this email, the draft also
contains:

"The portion of the source code that controls the radio is very
small compared to the entirety of the underlying operating system,
Graphical User Interface, routing and switching code, and all the
other functions that make up a modern Wi-Fi router. As such,
restricting the entire firmware to carries with it a lot of
collateral damage by also preventing improvements to these other
parts."

Which seems to reverse the recommendation.


Thanks for this great draft and the work you guys have put into it
so far!

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH][netifd] Bridge hairpin mode must be off by default

[Linus Lüssing]

Hi Dmitry,

On Thu, Sep 10, 2015 at 04:00:39PM +0300, Dmitry Ivanov wrote:
> [...] Enabling this mode leads to broadcast frames such as ARP and DHCP
> being retransmitted back to AP in WDS configurations.

Could you eloborate a little more on this? For a normal
bridge-on-AP setting this should be fine together with the
ap-isolation. But I'm not that familiar with WDS, I have to admit.

Do you see duplicate broadcast packets or echoes on the
transmitter? Or what is the issue?

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] kernel: bridge, multicast-to-unicast: fix echoes on STA

[Linus Lüssing]

Currently, multicast packets from an STA are sent to any according
multicast listener directly through the bridge multicast-to-unicast
feature. Unfortunately, so far this includes the originating STA, too,
resulting in multicast packets being echo'ed back to the originating STA
if it itself is a multicast listener for that group.

This behaviour breaks IPv6 duplicate address detection: An IPv6 Neighbor
Solicitation for IPv6 Duplicate Address Detection is being echo'ed back,
resulting in the host falsely detecting an address collision, which
makes the node unable to claim an IPv6 address and use IPv6 in general.

Mac80211 unfortunately only prevents the echoes for us for multicast
frames. For the multicast frames cast to a unicast destination we'll
need to take care of excluding the originator ourselves.

Signed-off-by: Linus Lüssing <linus.luess...@c0d3.blue>
---
 .../645-bridge_multicast_to_unicast.patch  |   35 +++-
 .../645-bridge_multicast_to_unicast.patch  |   11 --
 2 files changed, 28 insertions(+), 18 deletions(-)

diff --git 
a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch 
b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
index 1e070d9..a40abb5 100644
--- a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
+++ b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
@@ -133,7 +133,7 @@
if (err)
break;
}
-@@ -1407,7 +1433,8 @@ br_multicast_leave_group(struct net_brid
+@@ -1406,7 +1432,8 @@ br_multicast_leave_group(struct net_brid
 struct net_bridge_port *port,
 struct br_ip *group,
 struct bridge_mcast_other_query *other_query,
@@ -143,7 +143,7 @@
  {
struct net_bridge_mdb_htable *mdb;
struct net_bridge_mdb_entry *mp;
-@@ -1457,7 +1484,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1456,7 +1483,7 @@ br_multicast_leave_group(struct net_brid
for (pp = >ports;
 (p = mlock_dereference(*pp, br)) != NULL;
 pp = >next) {
@@ -152,7 +152,7 @@
continue;
  
rcu_assign_pointer(*pp, p->next);
-@@ -1491,7 +1518,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1490,7 +1517,7 @@ br_multicast_leave_group(struct net_brid
for (p = mlock_dereference(mp->ports, br);
 p != NULL;
 p = mlock_dereference(p->next, br)) {
@@ -161,7 +161,7 @@
continue;
  
if (!hlist_unhashed(>mglist) &&
-@@ -1509,8 +1536,8 @@ out:
+@@ -1508,8 +1535,8 @@ out:
  
  static void br_ip4_multicast_leave_group(struct net_bridge *br,
 struct net_bridge_port *port,
@@ -172,7 +172,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1525,14 +1552,14 @@ static void br_ip4_multicast_leave_group
+@@ -1524,14 +1551,14 @@ static void br_ip4_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, _group, >ip4_other_query,
@@ -189,7 +189,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1547,7 +1574,7 @@ static void br_ip6_multicast_leave_group
+@@ -1546,7 +1573,7 @@ static void br_ip6_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, _group, >ip6_other_query,
@@ -198,7 +198,7 @@
  }
  #endif
  
-@@ -1556,6 +1583,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1555,6 +1582,7 @@ static int br_multicast_ipv4_rcv(struct
 struct sk_buff *skb,
 u16 vid)
  {
@@ -206,7 +206,7 @@
struct sk_buff *skb2 = skb;
const struct iphdr *iph;
struct igmphdr *ih;
-@@ -1629,7 +1657,8 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1628,7 +1656,8 @@ static int br_multicast_ipv4_rcv(struct
case IGMP_HOST_MEMBERSHIP_REPORT:
case IGMPV2_HOST_MEMBERSHIP_REPORT:
BR_INPUT_SKB_CB(skb)->mrouters_only = 1;
@@ -216,7 +216,7 @@
break;
case IGMPV3_HOST_MEMBERSHIP_REPORT:
err = br_ip4_multicast_igmp3_report(br, port, skb2, vid);
-@@ -1638,7 +1667,8 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1637,7 +1666,8 @@ static int br_multicast_ipv4_rcv(struct
err = br_ip4_multicast_query(br, port, skb2, vid);
break;
case IGMP_HOST_LEAVE_MESSAGE:
@@ -226,7 +226,7 @@
break;
}
  
-@@ -1656,6 +1686,7 @@ static int br_multicast_ipv6_rcv(struct
+@@ -1655,6 +1685,7 @@ static int br_multicast_ipv6_rcv(struct
 struct sk_buff *skb,
 u16 vid)
  {
@@ -234,7 +234,7 @@
struct sk_buff *skb2;
const struct ipv6hdr *ip6h;
 

Re: [OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert "kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)"

[Linus Lüssing]

On Mon, Aug 31, 2015 at 11:29:45AM +0200, Steven Barth wrote:
> 
> 
> 
> >Ok, I was able to easily reproduce the issue here. Looking at the
> >tcpdump the wifi client receives its own Neighbor Solicitation
> >again, reflected through the bridge-hairpin option.
> 
> Why are we reflecting packets back to the originator anyway? Could it not be 
> excluded?

Currently the multicast-to-unicast patch reflects it back as it
detected that the originator itself is a listener of the multicast
group of the Neighbor Solicitation.

I had somehow expected that mac80211 would exclude it. But looks like it
doesn't. And yes, we can exclude/drop that unicast'ed multicast
packet with src==dst on the bridge side already like I said
before for a suggested fix. But it's not 100% sufficient yet, we'd
have issues again once a multicast router/querier is on an STA.

Cheers, Linus

> 
> Btw. once we are bit more stable i will try to test how the igmpv3/mldv2 
> querier / proxy I wrote interacts here (disabling kernel querier).

I'd be interested to hear about that :).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert "kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)"

[Linus Lüssing]

On Mon, Aug 31, 2015 at 12:19:44PM +0200, Linus Lüssing wrote:
> I had somehow expected that mac80211 would exclude it. But looks like it
> doesn't.

Looks like mac80211 on an STA does that for frames with a
multicast destination (to prevent getting the own multicast
packets echo'd back once the AP rebroadcasts them, I guess). E.g.
ap-isolation + bridge-hairpin without multicast-to-unicast works
fine. So maybe the simple fix for the multicast-to-unicast patch
is sufficient.

The unicast-to-multicast patch mangled the destination to a
unicast one and mac80211 does not seem to consider their source
address.

Going to make and try a patch for the bridge now.

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)

[Linus Lüssing]

Hi Steven,

Thanks for the feedback.

On Sat, Aug 29, 2015 at 04:21:50PM +0200, Steven Barth wrote:
 Let me know if you need more info.

Could you make a tcpdump for ICMPv6 on the wifi of the client?
Please start it before connecting and let it run for about three
minutes after connecting to the wifi.

On the router side, what's the output of:

* /sys/class/net/$bridged-wifi/brport/hairpin
* /sys/class/net/$bridged-wifi/brport/multicast_to_unicast
* /tmp/run/hostapd-*, ap-isolate=...

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)

[Linus Lüssing]

On Sun, Aug 30, 2015 at 03:49:50PM +0200, Linus Lüssing wrote:
 Hi Steven,
 
 Thanks for the feedback.
 
 On Sat, Aug 29, 2015 at 04:21:50PM +0200, Steven Barth wrote:
  Let me know if you need more info.
 
 Could you make a tcpdump for ICMPv6 on the wifi of the client?
 Please start it before connecting and let it run for about three
 minutes after connecting to the wifi.

Ok, I was able to easily reproduce the issue here. Looking at the
tcpdump the wifi client receives its own Neighbor Solicitation
again, reflected through the bridge-hairpin option.

The Linux IPv6 stack seems to interpret the reflected NS as an
address collision with another host. It seems a little weird that
the Linux kernel does that for NS - I think an IPv6 implementation
should only interpret Neighbor Advertisements as address conflicts
if I remember the RFCs correctly.


My current thought to fix this issue is to patch the
multicast-to-unicast patch in the following way:

Only transmit multicast-to-unicast'ed packets if the mangled,
now unicast MAC destination address differs from the MAC source.


We need to think about what'd happen for non-multicast-to-unicast'ed
multicast packets which get reflected back to the wifi interface
though. This should only happen if a multicast router is on one of
the wifi clients / STAs, I think. Will need to check whether the
Linux kernel interprets multicast packets without a mangled
MAC destination as duplicates, too.

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)

[Linus Lüssing]

PS: Out of curiousity, can someone with deeper knowledge into 802.11
tell me, when an STA sends a multicast packet to its master which
then rebroadcasts it at e.g. 1MBit/s, how does the originating STA
know that its a rebroadcast of its own frame and refrain from
forwarding it internally?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCHv3 openwrt 2/2] kernel: bridge, multicast-to-unicast: assign src after pskb_may_pull()

[Linus Lüssing]

A call to pskb_may_pull() might reallocate skb-data. Therefore we
should only assign the src-pointer after any potential reallocations.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 .../645-bridge_multicast_to_unicast.patch  |   45 +++-
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git 
a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch 
b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
index e8be1fd..83f2475 100644
--- a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
+++ b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
@@ -100,37 +100,40 @@
 struct sk_buff *skb,
 u16 vid)
  {
-+  const unsigned char *src = eth_hdr(skb)-h_source;
++  unsigned char *src;
struct igmpv3_report *ih;
struct igmpv3_grec *grec;
int i;
-@@ -1008,7 +1031,7 @@ static int br_ip4_multicast_igmp3_report
+@@ -1008,7 +1031,8 @@ static int br_ip4_multicast_igmp3_report
continue;
}
  
 -  err = br_ip4_multicast_add_group(br, port, group, vid);
++  src = eth_hdr(skb)-h_source;
 +  err = br_ip4_multicast_add_group(br, port, group, vid, src);
if (err)
break;
}
-@@ -1022,6 +1045,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1022,6 +1046,7 @@ static int br_ip6_multicast_mld2_report(
struct sk_buff *skb,
u16 vid)
  {
-+  const unsigned char *src = eth_hdr(skb)-h_source;
++  unsigned char *src;
struct icmp6hdr *icmp6h;
struct mld2_grec *grec;
int i;
-@@ -1070,7 +1094,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1069,8 +1094,9 @@ static int br_ip6_multicast_mld2_report(
+   continue;
}
  
++  src = eth_hdr(skb)-h_source;
err = br_ip6_multicast_add_group(br, port, grec-grec_mca,
 -   vid);
 +   vid, src);
if (err)
break;
}
-@@ -1407,7 +1431,8 @@ br_multicast_leave_group(struct net_brid
+@@ -1407,7 +1433,8 @@ br_multicast_leave_group(struct net_brid
 struct net_bridge_port *port,
 struct br_ip *group,
 struct bridge_mcast_other_query *other_query,
@@ -140,7 +143,7 @@
  {
struct net_bridge_mdb_htable *mdb;
struct net_bridge_mdb_entry *mp;
-@@ -1457,7 +1482,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1457,7 +1484,7 @@ br_multicast_leave_group(struct net_brid
for (pp = mp-ports;
 (p = mlock_dereference(*pp, br)) != NULL;
 pp = p-next) {
@@ -149,7 +152,7 @@
continue;
  
rcu_assign_pointer(*pp, p-next);
-@@ -1491,7 +1516,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1491,7 +1518,7 @@ br_multicast_leave_group(struct net_brid
for (p = mlock_dereference(mp-ports, br);
 p != NULL;
 p = mlock_dereference(p-next, br)) {
@@ -158,7 +161,7 @@
continue;
  
if (!hlist_unhashed(p-mglist) 
-@@ -1509,8 +1534,8 @@ out:
+@@ -1509,8 +1536,8 @@ out:
  
  static void br_ip4_multicast_leave_group(struct net_bridge *br,
 struct net_bridge_port *port,
@@ -169,7 +172,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1525,14 +1550,14 @@ static void br_ip4_multicast_leave_group
+@@ -1525,14 +1552,14 @@ static void br_ip4_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, br_group, br-ip4_other_query,
@@ -186,7 +189,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1547,7 +1572,7 @@ static void br_ip6_multicast_leave_group
+@@ -1547,7 +1574,7 @@ static void br_ip6_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, br_group, br-ip6_other_query,
@@ -195,55 +198,59 @@
  }
  #endif
  
-@@ -1556,6 +1581,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1556,6 +1583,7 @@ static int br_multicast_ipv4_rcv(struct
 struct sk_buff *skb,
 u16 vid)
  {
-+  const unsigned char *src = eth_hdr(skb)-h_source;
++  unsigned char *src;
struct sk_buff *skb2 = skb;
const struct iphdr *iph;
struct igmphdr *ih;
-@@ -1629,7 +1655,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1629,7 +1657,8 @@ static int br_multicast_ipv4_rcv(struct
case IGMP_HOST_MEMBERSHIP_REPORT:
case IGMPV2_HOST_MEMBERSHIP_REPORT

[OpenWrt-Devel] [PATCHv3 netifd 1/3] bridge: Fix multicast_to_unicast feature by hairpin+isolate

[Linus Lüssing]

All IGMP and MLD versions suffer from a specific limitation (from a
snooping switch perspective): Report suppression.

Once a listener hears an IGMPv2/3 or MLDv1 report for the same group
itself participates in then it might (if this listener is an IGMPv3 or
MLDv2 listener) or will (if this is an IGMPv1/2 or MLDv1 listener)
refrain from sending its own report.

Therefore we might currently miss such surpressing listeners as they
won't receive the multicast packet with the mangled, unicasted
destination.

Fixing this by first isolating the STAs and giving the bridge more
control over traffic forwarding. E.g. refraining to forward listener
reports to other STAs.

For broadcast and unicast traffic to an STA on the same AP, the hairpin
feature of the bridge will reflect such traffic back to the AP
interface. However, if the AP interface is actually configured to
isolate STAs, then hairpin is kept disabled.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 device.h   |1 +
 scripts/netifd-wireless.sh |   15 +++
 system-linux.c |   26 --
 wireless.c |   12 +++-
 wireless.h |1 +
 5 files changed, 48 insertions(+), 7 deletions(-)

diff --git a/device.h b/device.h
index ce135ba..373445c 100644
--- a/device.h
+++ b/device.h
@@ -173,6 +173,7 @@ struct device {
bool iface_config;
bool default_config;
bool wireless;
+   bool wireless_isolate;
 
struct interface *config_iface;
 
diff --git a/scripts/netifd-wireless.sh b/scripts/netifd-wireless.sh
index c5d8a96..f981f1b 100644
--- a/scripts/netifd-wireless.sh
+++ b/scripts/netifd-wireless.sh
@@ -248,12 +248,26 @@ wireless_vif_parse_encryption() {
esac
 }
 
+_wireless_set_brsnoop_isolation() {
+   local multicast_to_unicast=$1
+   local isolate
+
+   json_get_var isolate isolate
+
+   [ $isolate -gt 0 -o -z $network_bridge ]  return
+
+   [ -z $multicast_to_unicast ]  multicast_to_unicast=1
+   [ $multicast_to_unicast -gt 0 ]  json_add_boolean isolate 1
+}
+
 for_each_interface() {
local _w_types=$1; shift
local _w_ifaces _w_iface
local _w_type
local _w_found
 
+   local multicast_to_unicast
+
json_get_keys _w_ifaces interfaces
json_select interfaces
for _w_iface in $_w_ifaces; do
@@ -261,6 +275,7 @@ for_each_interface() {
if [ -n $_w_types ]; then
json_get_var network_bridge bridge
json_select config
+   _wireless_set_brsnoop_isolation $multicast_to_unicast
json_get_var _w_type mode
json_select ..
_w_types= $_w_types 
diff --git a/system-linux.c b/system-linux.c
index 9ba13fd..9c4bea6 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -315,6 +315,16 @@ static void system_set_dadtransmits(struct device *dev, 
const char *val)
system_set_dev_sysctl(/proc/sys/net/ipv6/conf/%s/dad_transmits, 
dev-ifname, val);
 }
 
+static void system_bridge_set_multicast_to_unicast(struct device *dev, const 
char *val)
+{
+   system_set_dev_sysctl(/sys/class/net/%s/brport/multicast_to_unicast, 
dev-ifname, val);
+}
+
+static void system_bridge_set_hairpin_mode(struct device *dev, const char *val)
+{
+   system_set_dev_sysctl(/sys/class/net/%s/brport/hairpin_mode, 
dev-ifname, val);
+}
+
 static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
 {
int fd = -1, ret = -1;
@@ -556,12 +566,16 @@ static char *system_get_bridge(const char *name, char 
*buf, int buflen)
return path + 1;
 }
 
-static void system_bridge_set_wireless(const char *bridge, const char *dev)
+static void
+system_bridge_set_wireless(struct device *dev)
 {
-   snprintf(dev_buf, sizeof(dev_buf),
-/sys/devices/virtual/net/%s/brif/%s/multicast_to_unicast,
-bridge, dev);
-   system_set_sysctl(dev_buf, 1);
+   bool hairpin = true;
+
+   if (dev-wireless_isolate)
+   hairpin = false;
+
+   system_bridge_set_multicast_to_unicast(dev, 1);
+   system_bridge_set_hairpin_mode(dev, hairpin ? 1 : 0);
 }
 
 int system_bridge_addif(struct device *bridge, struct device *dev)
@@ -574,7 +588,7 @@ int system_bridge_addif(struct device *bridge, struct 
device *dev)
ret = system_bridge_if(bridge-ifname, dev, SIOCBRADDIF, NULL);
 
if (dev-wireless)
-   system_bridge_set_wireless(bridge-ifname, dev-ifname);
+   system_bridge_set_wireless(dev);
 
return ret;
 }
diff --git a/wireless.c b/wireless.c
index fbd6191..337f563 100644
--- a/wireless.c
+++ b/wireless.c
@@ -35,12 +35,14 @@ static const struct uci_blob_param_list wdev_param = {
 enum {
VIF_ATTR_DISABLED,
VIF_ATTR_NETWORK,
+   VIF_ATTR_ISOLATE,
__VIF_ATTR_MAX,
 };
 
 static const struct

[OpenWrt-Devel] [PATCHv3 netifd 2/3] bridge: Allow setting multicast_to_unicast option

[Linus Lüssing]

With this patch the multicast_to_unicast feature can be disabled for all
wireless interfaces via an according option on the uci bridge interface.

This patch also exports the setting information to wireless handler
scripts. The hostapd script will need that information to determine
whether to enable or disable ap-isolation, for instance.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 device.c   |9 +
 device.h   |3 +++
 scripts/netifd-wireless.sh |1 +
 system-linux.c |   13 +
 wireless.c |4 
 5 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/device.c b/device.c
index b5bee11..b44ccb8 100644
--- a/device.c
+++ b/device.c
@@ -48,6 +48,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_RPS] = { .name = rps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_XPS] = { .name = xps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_DADTRANSMITS] = { .name = dadtransmits, .type = 
BLOBMSG_TYPE_INT32 },
+   [DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = multicast_to_unicast, 
.type = BLOBMSG_TYPE_BOOL },
 };
 
 const struct uci_blob_param_list device_attr_list = {
@@ -174,6 +175,7 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
s-neigh6reachabletime : os-neigh6reachabletime;
n-dadtransmits = s-flags  DEV_OPT_DADTRANSMITS ?
s-dadtransmits : os-dadtransmits;
+   n-multicast_to_unicast = s-multicast_to_unicast;
n-flags = s-flags | os-flags;
 }
 
@@ -274,6 +276,11 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
s-flags |= DEV_OPT_DADTRANSMITS;
}
 
+   if ((cur = tb[DEV_ATTR_MULTICAST_TO_UNICAST])) {
+   s-multicast_to_unicast = blobmsg_get_bool(cur);
+   s-flags |= DEV_OPT_MULTICAST_TO_UNICAST;
+   }
+
device_set_disabled(dev, disabled);
 }
 
@@ -884,6 +891,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
}
if (st.flags  DEV_OPT_DADTRANSMITS)
blobmsg_add_u32(b, dadtransmits, st.dadtransmits);
+   if (st.flags  DEV_OPT_MULTICAST_TO_UNICAST)
+   blobmsg_add_u8(b, multicast_to_unicast, 
st.multicast_to_unicast);
}
 
s = blobmsg_open_table(b, statistics);
diff --git a/device.h b/device.h
index 373445c..4344d8a 100644
--- a/device.h
+++ b/device.h
@@ -42,6 +42,7 @@ enum {
DEV_ATTR_RPS,
DEV_ATTR_XPS,
DEV_ATTR_DADTRANSMITS,
+   DEV_ATTR_MULTICAST_TO_UNICAST,
__DEV_ATTR_MAX,
 };
 
@@ -84,6 +85,7 @@ enum {
DEV_OPT_XPS = (1  11),
DEV_OPT_MTU6= (1  12),
DEV_OPT_DADTRANSMITS= (1  13),
+   DEV_OPT_MULTICAST_TO_UNICAST= (1  14),
 };
 
 /* events broadcasted to all users of a device */
@@ -141,6 +143,7 @@ struct device_settings {
bool rps;
bool xps;
unsigned int dadtransmits;
+   bool multicast_to_unicast;
 };
 
 /*
diff --git a/scripts/netifd-wireless.sh b/scripts/netifd-wireless.sh
index f981f1b..83a8223 100644
--- a/scripts/netifd-wireless.sh
+++ b/scripts/netifd-wireless.sh
@@ -274,6 +274,7 @@ for_each_interface() {
json_select $_w_iface
if [ -n $_w_types ]; then
json_get_var network_bridge bridge
+   json_get_var multicast_to_unicast multicast_to_unicast
json_select config
_wireless_set_brsnoop_isolation $multicast_to_unicast
json_get_var _w_type mode
diff --git a/system-linux.c b/system-linux.c
index 9c4bea6..944245c 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -567,14 +567,19 @@ static char *system_get_bridge(const char *name, char 
*buf, int buflen)
 }
 
 static void
-system_bridge_set_wireless(struct device *dev)
+system_bridge_set_wireless(struct device *bridge, struct device *dev)
 {
+   bool mcast_to_ucast = true;
bool hairpin = true;
 
-   if (dev-wireless_isolate)
+   if (bridge-settings.flags  DEV_OPT_MULTICAST_TO_UNICAST 
+   !bridge-settings.multicast_to_unicast)
+   mcast_to_ucast = false;
+
+   if (!mcast_to_ucast || dev-wireless_isolate)
hairpin = false;
 
-   system_bridge_set_multicast_to_unicast(dev, 1);
+   system_bridge_set_multicast_to_unicast(dev, mcast_to_ucast ? 1 : 0);
system_bridge_set_hairpin_mode(dev, hairpin ? 1 : 0);
 }
 
@@ -588,7 +593,7 @@ int system_bridge_addif(struct device *bridge, struct 
device *dev)
ret = system_bridge_if(bridge-ifname, dev, SIOCBRADDIF, NULL);
 
if (dev-wireless)
-   system_bridge_set_wireless(dev);
+   system_bridge_set_wireless(bridge, dev);
 
return ret;
 }
diff --git a/wireless.c b/wireless.c
index 337f563

[OpenWrt-Devel] [PATCHv3 netifd 3/3] bridge: Allow setting multicast_router option

[Linus Lüssing]

The multicast_router option of a bridge allows to control the forwarding
behaviour of multicast packets independant of the listener state:

* 0: Only forward if specific listener is present
* 1 (default): Forward if specific listener or a multicast router
  was detected (currently only learned via query messages, no MRD
  support yet)
* 2: Always forward any multicast traffic on this port

Since MRD is not mandated you might end up with silent multicast routers
(e.g. if your link has more than one multicast router; only one can
become the selected, noisy querier). Here you might need a manual
configuration option like the multicast_router option.

Other scenarios where this can be useful are for instance:
* Segmentation of IGMP/MLD domains together with ebtables
* Dedicated bridge port for monitoring/debugging purposes

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 device.c   |   12 
 device.h   |3 +++
 system-linux.c |   18 ++
 3 files changed, 33 insertions(+)

diff --git a/device.c b/device.c
index b44ccb8..d6e288c 100644
--- a/device.c
+++ b/device.c
@@ -49,6 +49,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_XPS] = { .name = xps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_DADTRANSMITS] = { .name = dadtransmits, .type = 
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = multicast_to_unicast, 
.type = BLOBMSG_TYPE_BOOL },
+   [DEV_ATTR_MULTICAST_ROUTER] = { .name = multicast_router, .type = 
BLOBMSG_TYPE_INT32 },
 };
 
 const struct uci_blob_param_list device_attr_list = {
@@ -176,6 +177,7 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
n-dadtransmits = s-flags  DEV_OPT_DADTRANSMITS ?
s-dadtransmits : os-dadtransmits;
n-multicast_to_unicast = s-multicast_to_unicast;
+   n-multicast_router = s-multicast_router;
n-flags = s-flags | os-flags;
 }
 
@@ -281,6 +283,14 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
s-flags |= DEV_OPT_MULTICAST_TO_UNICAST;
}
 
+   if ((cur = tb[DEV_ATTR_MULTICAST_ROUTER])) {
+   s-multicast_router = blobmsg_get_u32(cur);
+   if (s-multicast_router = 0  s-multicast_router = 2)
+   s-flags |= DEV_OPT_MULTICAST_ROUTER;
+   else
+   DPRINTF(Invalid value: %d - (Use 0: never, 1: learn, 
2: always)\n, blobmsg_get_u32(cur));
+   }
+
device_set_disabled(dev, disabled);
 }
 
@@ -893,6 +903,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u32(b, dadtransmits, st.dadtransmits);
if (st.flags  DEV_OPT_MULTICAST_TO_UNICAST)
blobmsg_add_u8(b, multicast_to_unicast, 
st.multicast_to_unicast);
+   if (st.flags  DEV_OPT_MULTICAST_ROUTER)
+   blobmsg_add_u32(b, multicast_router, 
st.multicast_router);
}
 
s = blobmsg_open_table(b, statistics);
diff --git a/device.h b/device.h
index 4344d8a..86a1628 100644
--- a/device.h
+++ b/device.h
@@ -43,6 +43,7 @@ enum {
DEV_ATTR_XPS,
DEV_ATTR_DADTRANSMITS,
DEV_ATTR_MULTICAST_TO_UNICAST,
+   DEV_ATTR_MULTICAST_ROUTER,
__DEV_ATTR_MAX,
 };
 
@@ -86,6 +87,7 @@ enum {
DEV_OPT_MTU6= (1  12),
DEV_OPT_DADTRANSMITS= (1  13),
DEV_OPT_MULTICAST_TO_UNICAST= (1  14),
+   DEV_OPT_MULTICAST_ROUTER= (1  15),
 };
 
 /* events broadcasted to all users of a device */
@@ -144,6 +146,7 @@ struct device_settings {
bool xps;
unsigned int dadtransmits;
bool multicast_to_unicast;
+   unsigned int multicast_router;
 };
 
 /*
diff --git a/system-linux.c b/system-linux.c
index 944245c..01500a5 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -325,6 +325,13 @@ static void system_bridge_set_hairpin_mode(struct device 
*dev, const char *val)
system_set_dev_sysctl(/sys/class/net/%s/brport/hairpin_mode, 
dev-ifname, val);
 }
 
+static void system_bridge_set_multicast_router(struct device *dev, const char 
*val, bool bridge)
+{
+   system_set_dev_sysctl(bridge ? 
/sys/class/net/%s/bridge/multicast_router :
+  
/sys/class/net/%s/brport/multicast_router,
+ dev-ifname, val);
+}
+
 static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
 {
int fd = -1, ret = -1;
@@ -585,6 +592,7 @@ system_bridge_set_wireless(struct device *bridge, struct 
device *dev)
 
 int system_bridge_addif(struct device *bridge, struct device *dev)
 {
+   char buf[64];
char *oldbr;
int ret = 0;
 
@@ -595,6 +603,11 @@ int system_bridge_addif(struct device *bridge, struct 
device *dev)
if (dev-wireless)
system_bridge_set_wireless(bridge, dev);
 
+   if (dev-settings.flags

[OpenWrt-Devel] [PATCHv3 openwrt 1/2] Revert kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)

[Linus Lüssing]

This reverts commit a080e8e1943156168913d0353a2e99d1151102aa.

It did not fix the problem but just hid some symptom. The real issue was
that IGMP/MLD report suppression was not considered for the
multicast-to-unicast feature. A recent netifd which isolates IGMP/MLD
reports between STAs by utilizing AP-isolation and bridge-hairpinning
should have fixed this.

It is perfectly fine to apply multicast-to-unicast to IPv6 Neighbor
Solicitations, too (once that feature is configured correctly).

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 .../645-bridge_multicast_to_unicast.patch  |   37 +---
 1 file changed, 17 insertions(+), 20 deletions(-)

diff --git 
a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch 
b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
index 00ad14f..e8be1fd 100644
--- a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
+++ b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
@@ -87,19 +87,16 @@
  {
struct br_ip br_group;
  
-@@ -736,7 +758,10 @@ static int br_ip6_multicast_add_group(st
+@@ -736,7 +758,7 @@ static int br_ip6_multicast_add_group(st
br_group.proto = htons(ETH_P_IPV6);
br_group.vid = vid;
  
 -  return br_multicast_add_group(br, port, br_group);
-+  if (ipv6_addr_is_solict_mult(group))
-+  src = NULL;
-+
 +  return br_multicast_add_group(br, port, br_group, src);
  }
  #endif
  
-@@ -965,6 +990,7 @@ static int br_ip4_multicast_igmp3_report
+@@ -965,6 +987,7 @@ static int br_ip4_multicast_igmp3_report
 struct sk_buff *skb,
 u16 vid)
  {
@@ -107,7 +104,7 @@
struct igmpv3_report *ih;
struct igmpv3_grec *grec;
int i;
-@@ -1008,7 +1034,7 @@ static int br_ip4_multicast_igmp3_report
+@@ -1008,7 +1031,7 @@ static int br_ip4_multicast_igmp3_report
continue;
}
  
@@ -116,7 +113,7 @@
if (err)
break;
}
-@@ -1022,6 +1048,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1022,6 +1045,7 @@ static int br_ip6_multicast_mld2_report(
struct sk_buff *skb,
u16 vid)
  {
@@ -124,7 +121,7 @@
struct icmp6hdr *icmp6h;
struct mld2_grec *grec;
int i;
-@@ -1070,7 +1097,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1070,7 +1094,7 @@ static int br_ip6_multicast_mld2_report(
}
  
err = br_ip6_multicast_add_group(br, port, grec-grec_mca,
@@ -133,7 +130,7 @@
if (err)
break;
}
-@@ -1406,7 +1433,8 @@ br_multicast_leave_group(struct net_brid
+@@ -1407,7 +1431,8 @@ br_multicast_leave_group(struct net_brid
 struct net_bridge_port *port,
 struct br_ip *group,
 struct bridge_mcast_other_query *other_query,
@@ -143,7 +140,7 @@
  {
struct net_bridge_mdb_htable *mdb;
struct net_bridge_mdb_entry *mp;
-@@ -1456,7 +1484,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1457,7 +1482,7 @@ br_multicast_leave_group(struct net_brid
for (pp = mp-ports;
 (p = mlock_dereference(*pp, br)) != NULL;
 pp = p-next) {
@@ -152,7 +149,7 @@
continue;
  
rcu_assign_pointer(*pp, p-next);
-@@ -1490,7 +1518,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1491,7 +1516,7 @@ br_multicast_leave_group(struct net_brid
for (p = mlock_dereference(mp-ports, br);
 p != NULL;
 p = mlock_dereference(p-next, br)) {
@@ -161,7 +158,7 @@
continue;
  
if (!hlist_unhashed(p-mglist) 
-@@ -1508,8 +1536,8 @@ out:
+@@ -1509,8 +1534,8 @@ out:
  
  static void br_ip4_multicast_leave_group(struct net_bridge *br,
 struct net_bridge_port *port,
@@ -172,7 +169,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1524,14 +1552,14 @@ static void br_ip4_multicast_leave_group
+@@ -1525,14 +1550,14 @@ static void br_ip4_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, br_group, br-ip4_other_query,
@@ -189,7 +186,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1546,7 +1574,7 @@ static void br_ip6_multicast_leave_group
+@@ -1547,7 +1572,7 @@ static void br_ip6_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, br_group, br-ip6_other_query,
@@ -198,7 +195,7 @@
  }
  #endif
  
-@@ -1555,6 +1583,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1556,6 +1581,7 @@ static int br_multicast_ipv4_rcv(struct
 struct

[OpenWrt-Devel] [PATCHv3] Fixes regarding bridge multicast-to-unicast feature

[Linus Lüssing]

Hi,

Here are a few patches to fix the issues the multicast-to-unicast
feature of the bridge has: IGMP/MLD report suppression could lead
to multicast packet loss. Also see ticket #17625 [0].

As previously discussed on this mailing list, AP-isolation together
with bridge-hairpinning is a way to make the multicast-to-unicast
feature usable even if listeners potentially suppressing reports
are present: That way the bridge will get all reports and will have
full control on where to forward them. For instance *not* to other
STAs (unless there is a multicast router).

Furthermore [PATCH netifd 2/3] introduces a netifd option to disable
the multicast-to-unicast feature.

[PATCH netifd 3/3] is not related to this issue but introduces a
handy option (which I would like to make use of for IGMP/MLD domain
segmentation).


The OpenWRT specific patches should be applied after the netifd
patches arrived in OpenWRT.

Cheers, Linus

[0]: https://dev.openwrt.org/ticket/17625

~~~

Changelog v3:
* Removed [PATCH openwrt 1/3]:
  Now included in [PATCH netifd 1/3] through netifd-wireless.sh

Changelog v2:
* Separated introduction of multicast_to_unicast configuration option
  in separate patch
* passing multicast_to_unicast to netifd scripts via json from netifd
  instead of external uci command calls
* Moved multicast_to_unicast uci option to be a bridge instead of
  bridge member option
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv2 netifd 2/3] bridge: Allow setting multicast_to_unicast option

[Linus Lüssing]

On Thu, Aug 06, 2015 at 11:09:02PM +0200, Felix Fietkau wrote:
 On 2015-08-06 22:10, Linus Lüssing wrote:
  On Wed, Aug 05, 2015 at 01:38:28PM +0200, Felix Fietkau wrote:
  On 2015-08-05 01:00, Linus Lüssing wrote:
   With this patch the multicast_to_unicast feature can be disabled for all
   wireless interfaces via an according option on the uci bridge interface.
   
   This patch also exports the setting information to wireless handler
   scripts. The hostapd script will need that information to determine
   whether to enable or disable ap-isolation, for instance.
   
   Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
  I think it would be better to store these flags in the bridge config
  instead of the generic device config, and either add a blob_buf argument
  in struct device_hotplug_ops - prepare, or add a new callback get_info,
  which adds the bridge info for use in the wireless json.
  
  These would then be options per bridge, but not per bridge port,
  wouldn't they?
 Right.
 
  For the multicast_to_unicast feature, okay (currently this patch
  only allows setting it globally for a bridge but not on a bridge
  port basis - though I was thinking about maybe making it bridge
  port specific once someone needs that). For the multicast_router
  option I'd need that on a bridge port basis.
 OK, then leave it as device options for now until we have a better way
 of specifiying bridge port settings. Same for multicast_to_unicast.

Ok, thanks :). (we want to fix and use bridge snooping +
multicast-to-unicast here as soon as possible so I'm quite fond of
simple solutions for now :) )

 
  I would like to avoid polluting the generic device options with bridge
  specific stuff.
  
  This patch should probably be merged with the previous one afterwards,
  since the first one without any other changes will cause regressions.
  
  Regressions, where/why? If this patch were ommitted from this
  patchset then no harm should be done (unless I'm missing
  something?).
 The regression is: patch 1 enables hairpin mode for wireless interfaces,
 with the assumption that the wireless script enables isolate mode for
 multicast-to-unicast enable configurations.
 The wireless script can only do that if patch 2 is applies, because that
 one passes the required options.

Not passing the multicast_to_unicast option from netifd to
hostapd.sh is not a regression. Actually even with patch 2 there
are cases where no multicast_to_unicast json option is passed -
that's when no multicast_to_unicast option was set in uci.

With netifd patch 1, without netifd patch 2 and with openwrt patch
1 things will work fine without a regression because
multicast_to_unicast is then empty and hostapd.sh will assume the
default which is that multicast_to_unicast was enabled.


However, netifd patch 1 without openwrt patch 1 is a regression,
yes (which is independant of netifd patch 2). Which I couldn't do
with a single patch as it's in two packages. But I like your
suggestion for netifd patch 1 which will also get rid of an
intermediate regression :). So with that change I think I can
leave netifd patch 2 and netifd 3 as is, without any regressions.

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv2 netifd 2/3] bridge: Allow setting multicast_to_unicast option

[Linus Lüssing]

On Wed, Aug 05, 2015 at 01:38:28PM +0200, Felix Fietkau wrote:
 On 2015-08-05 01:00, Linus Lüssing wrote:
  With this patch the multicast_to_unicast feature can be disabled for all
  wireless interfaces via an according option on the uci bridge interface.
  
  This patch also exports the setting information to wireless handler
  scripts. The hostapd script will need that information to determine
  whether to enable or disable ap-isolation, for instance.
  
  Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
 I think it would be better to store these flags in the bridge config
 instead of the generic device config, and either add a blob_buf argument
 in struct device_hotplug_ops - prepare, or add a new callback get_info,
 which adds the bridge info for use in the wireless json.

These would then be options per bridge, but not per bridge port,
wouldn't they?

For the multicast_to_unicast feature, okay (currently this patch
only allows setting it globally for a bridge but not on a bridge
port basis - though I was thinking about maybe making it bridge
port specific once someone needs that). For the multicast_router
option I'd need that on a bridge port basis.

 
 I would like to avoid polluting the generic device options with bridge
 specific stuff.
 
 This patch should probably be merged with the previous one afterwards,
 since the first one without any other changes will cause regressions.

Regressions, where/why? If this patch were ommitted from this
patchset then no harm should be done (unless I'm missing
something?).

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCHv2 netifd 1/3] bridge: Fix multicast_to_unicast feature by hairpin+isolate

[Linus Lüssing]

On Wed, Aug 05, 2015 at 01:28:23PM +0200, Felix Fietkau wrote:
 This patch turns on hairpin mode and assumes that the driver script
 checks the multicast_to_unicast flag.
 This is somewhat broken, since you only consider the hostapd.sh script,
 but there are other driver implementations out there (including some
 out-of-tree ones).
 I think a better approach would be to check the conditions that are used
 to enable hairpin mode and use them to alter the vif isolate options in
 the json data.
 You could do this from within netifd-wireless.sh, and drop the hostapd
 change entirely.

Okay, sounds good, will do that!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCHv2 openwrt 1/3] hostapd: Always isolate if brport-multicast_to_unicast is enabled

[Linus Lüssing]

For the multicast-to-unicast feature of a bridge to function correctly,
it is necessary that all STAs are always isolated on the AP level. The
bridge will take care of reflecting packets back to the AP interface
if necessary and/or no STA isolation wanted by using the hairpin feature
of the bridge.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 package/network/services/hostapd/files/netifd.sh |9 +
 1 file changed, 9 insertions(+)

diff --git a/package/network/services/hostapd/files/netifd.sh 
b/package/network/services/hostapd/files/netifd.sh
index a3ffd93..b987a63 100644
--- a/package/network/services/hostapd/files/netifd.sh
+++ b/package/network/services/hostapd/files/netifd.sh
@@ -1,3 +1,6 @@
+. /lib/network/config.sh
+. /lib/config/uci.sh
+
 wpa_supplicant_add_rate() {
local var=$1
local val=$(($2 / 1000))
@@ -194,9 +197,15 @@ hostapd_set_bss_options() {
set_default uapsd 1
 
append bss_conf ctrl_interface=/var/run/hostapd
+
+   [ -n $multicast_to_unicast ] || multicast_to_unicast=1
+
if [ $isolate -gt 0 ]; then
append bss_conf ap_isolate=$isolate $N
+   elif [ -n $network_bridge -a $multicast_to_unicast -gt 0 ]; then
+   append bss_conf ap_isolate=1 $N
fi
+
if [ $maxassoc -gt 0 ]; then
append bss_conf max_num_sta=$maxassoc $N
fi
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCHv2 openwrt 3/3] kernel: bridge, multicast-to-unicast: assign src after pskb_may_pull()

[Linus Lüssing]

A call to pskb_may_pull() might reallocate skb-data. Therefore we
should only assign the src-pointer after any potential reallocations.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 .../645-bridge_multicast_to_unicast.patch  |   45 +++-
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git 
a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch 
b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
index e8be1fd..83f2475 100644
--- a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
+++ b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
@@ -100,37 +100,40 @@
 struct sk_buff *skb,
 u16 vid)
  {
-+  const unsigned char *src = eth_hdr(skb)-h_source;
++  unsigned char *src;
struct igmpv3_report *ih;
struct igmpv3_grec *grec;
int i;
-@@ -1008,7 +1031,7 @@ static int br_ip4_multicast_igmp3_report
+@@ -1008,7 +1031,8 @@ static int br_ip4_multicast_igmp3_report
continue;
}
  
 -  err = br_ip4_multicast_add_group(br, port, group, vid);
++  src = eth_hdr(skb)-h_source;
 +  err = br_ip4_multicast_add_group(br, port, group, vid, src);
if (err)
break;
}
-@@ -1022,6 +1045,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1022,6 +1046,7 @@ static int br_ip6_multicast_mld2_report(
struct sk_buff *skb,
u16 vid)
  {
-+  const unsigned char *src = eth_hdr(skb)-h_source;
++  unsigned char *src;
struct icmp6hdr *icmp6h;
struct mld2_grec *grec;
int i;
-@@ -1070,7 +1094,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1069,8 +1094,9 @@ static int br_ip6_multicast_mld2_report(
+   continue;
}
  
++  src = eth_hdr(skb)-h_source;
err = br_ip6_multicast_add_group(br, port, grec-grec_mca,
 -   vid);
 +   vid, src);
if (err)
break;
}
-@@ -1407,7 +1431,8 @@ br_multicast_leave_group(struct net_brid
+@@ -1407,7 +1433,8 @@ br_multicast_leave_group(struct net_brid
 struct net_bridge_port *port,
 struct br_ip *group,
 struct bridge_mcast_other_query *other_query,
@@ -140,7 +143,7 @@
  {
struct net_bridge_mdb_htable *mdb;
struct net_bridge_mdb_entry *mp;
-@@ -1457,7 +1482,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1457,7 +1484,7 @@ br_multicast_leave_group(struct net_brid
for (pp = mp-ports;
 (p = mlock_dereference(*pp, br)) != NULL;
 pp = p-next) {
@@ -149,7 +152,7 @@
continue;
  
rcu_assign_pointer(*pp, p-next);
-@@ -1491,7 +1516,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1491,7 +1518,7 @@ br_multicast_leave_group(struct net_brid
for (p = mlock_dereference(mp-ports, br);
 p != NULL;
 p = mlock_dereference(p-next, br)) {
@@ -158,7 +161,7 @@
continue;
  
if (!hlist_unhashed(p-mglist) 
-@@ -1509,8 +1534,8 @@ out:
+@@ -1509,8 +1536,8 @@ out:
  
  static void br_ip4_multicast_leave_group(struct net_bridge *br,
 struct net_bridge_port *port,
@@ -169,7 +172,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1525,14 +1550,14 @@ static void br_ip4_multicast_leave_group
+@@ -1525,14 +1552,14 @@ static void br_ip4_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, br_group, br-ip4_other_query,
@@ -186,7 +189,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1547,7 +1572,7 @@ static void br_ip6_multicast_leave_group
+@@ -1547,7 +1574,7 @@ static void br_ip6_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, br_group, br-ip6_other_query,
@@ -195,55 +198,59 @@
  }
  #endif
  
-@@ -1556,6 +1581,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1556,6 +1583,7 @@ static int br_multicast_ipv4_rcv(struct
 struct sk_buff *skb,
 u16 vid)
  {
-+  const unsigned char *src = eth_hdr(skb)-h_source;
++  unsigned char *src;
struct sk_buff *skb2 = skb;
const struct iphdr *iph;
struct igmphdr *ih;
-@@ -1629,7 +1655,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1629,7 +1657,8 @@ static int br_multicast_ipv4_rcv(struct
case IGMP_HOST_MEMBERSHIP_REPORT:
case IGMPV2_HOST_MEMBERSHIP_REPORT

[OpenWrt-Devel] [PATCHv2 netifd 3/3] bridge: Allow setting multicast_router option

[Linus Lüssing]

The multicast_router option of a bridge allows to control the forwarding
behaviour of multicast packets independant of the listener state:

* 0: Only forward if specific listener is present
* 1 (default): Forward if specific listener or a multicast router
  was detected (currently only learned via query messages, no MRD
  support yet)
* 2: Always forward any multicast traffic on this port

Since MRD is not mandated you might end up with silent multicast routers
(e.g. if your link has more than one multicast router; only one can
become the selected, noisy querier). Here you might need a manual
configuration option like the multicast_router option.

Other scenarios where this can be useful are for instance:
* Segmentation of IGMP/MLD domains together with ebtables
* Dedicated bridge port for monitoring/debugging purposes

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 device.c   |   12 
 device.h   |3 +++
 system-linux.c |   18 ++
 3 files changed, 33 insertions(+)

diff --git a/device.c b/device.c
index b44ccb8..d6e288c 100644
--- a/device.c
+++ b/device.c
@@ -49,6 +49,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_XPS] = { .name = xps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_DADTRANSMITS] = { .name = dadtransmits, .type = 
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = multicast_to_unicast, 
.type = BLOBMSG_TYPE_BOOL },
+   [DEV_ATTR_MULTICAST_ROUTER] = { .name = multicast_router, .type = 
BLOBMSG_TYPE_INT32 },
 };
 
 const struct uci_blob_param_list device_attr_list = {
@@ -176,6 +177,7 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
n-dadtransmits = s-flags  DEV_OPT_DADTRANSMITS ?
s-dadtransmits : os-dadtransmits;
n-multicast_to_unicast = s-multicast_to_unicast;
+   n-multicast_router = s-multicast_router;
n-flags = s-flags | os-flags;
 }
 
@@ -281,6 +283,14 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
s-flags |= DEV_OPT_MULTICAST_TO_UNICAST;
}
 
+   if ((cur = tb[DEV_ATTR_MULTICAST_ROUTER])) {
+   s-multicast_router = blobmsg_get_u32(cur);
+   if (s-multicast_router = 0  s-multicast_router = 2)
+   s-flags |= DEV_OPT_MULTICAST_ROUTER;
+   else
+   DPRINTF(Invalid value: %d - (Use 0: never, 1: learn, 
2: always)\n, blobmsg_get_u32(cur));
+   }
+
device_set_disabled(dev, disabled);
 }
 
@@ -893,6 +903,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u32(b, dadtransmits, st.dadtransmits);
if (st.flags  DEV_OPT_MULTICAST_TO_UNICAST)
blobmsg_add_u8(b, multicast_to_unicast, 
st.multicast_to_unicast);
+   if (st.flags  DEV_OPT_MULTICAST_ROUTER)
+   blobmsg_add_u32(b, multicast_router, 
st.multicast_router);
}
 
s = blobmsg_open_table(b, statistics);
diff --git a/device.h b/device.h
index 4344d8a..86a1628 100644
--- a/device.h
+++ b/device.h
@@ -43,6 +43,7 @@ enum {
DEV_ATTR_XPS,
DEV_ATTR_DADTRANSMITS,
DEV_ATTR_MULTICAST_TO_UNICAST,
+   DEV_ATTR_MULTICAST_ROUTER,
__DEV_ATTR_MAX,
 };
 
@@ -86,6 +87,7 @@ enum {
DEV_OPT_MTU6= (1  12),
DEV_OPT_DADTRANSMITS= (1  13),
DEV_OPT_MULTICAST_TO_UNICAST= (1  14),
+   DEV_OPT_MULTICAST_ROUTER= (1  15),
 };
 
 /* events broadcasted to all users of a device */
@@ -144,6 +146,7 @@ struct device_settings {
bool xps;
unsigned int dadtransmits;
bool multicast_to_unicast;
+   unsigned int multicast_router;
 };
 
 /*
diff --git a/system-linux.c b/system-linux.c
index 944245c..01500a5 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -325,6 +325,13 @@ static void system_bridge_set_hairpin_mode(struct device 
*dev, const char *val)
system_set_dev_sysctl(/sys/class/net/%s/brport/hairpin_mode, 
dev-ifname, val);
 }
 
+static void system_bridge_set_multicast_router(struct device *dev, const char 
*val, bool bridge)
+{
+   system_set_dev_sysctl(bridge ? 
/sys/class/net/%s/bridge/multicast_router :
+  
/sys/class/net/%s/brport/multicast_router,
+ dev-ifname, val);
+}
+
 static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
 {
int fd = -1, ret = -1;
@@ -585,6 +592,7 @@ system_bridge_set_wireless(struct device *bridge, struct 
device *dev)
 
 int system_bridge_addif(struct device *bridge, struct device *dev)
 {
+   char buf[64];
char *oldbr;
int ret = 0;
 
@@ -595,6 +603,11 @@ int system_bridge_addif(struct device *bridge, struct 
device *dev)
if (dev-wireless)
system_bridge_set_wireless(bridge, dev);
 
+   if (dev-settings.flags

[OpenWrt-Devel] [PATCHv2 openwrt 2/3] Revert kernel: disable multicast-to-unicast translation for ipv6 neighbor solicitation (#17625)

[Linus Lüssing]

This reverts commit a080e8e1943156168913d0353a2e99d1151102aa.

It did not fix the problem but just hid some symptom. The real issue was
that IGMP/MLD report suppression was not considered for the
multicast-to-unicast feature. A recent netifd which isolates IGMP/MLD
reports between STAs by utilizing AP-isolation and bridge-hairpinning
should have fixed this.

It is perfectly fine to apply multicast-to-unicast to IPv6 Neighbor
Solicitations, too (once that feature is configured correctly).

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 .../645-bridge_multicast_to_unicast.patch  |   37 +---
 1 file changed, 17 insertions(+), 20 deletions(-)

diff --git 
a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch 
b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
index 00ad14f..e8be1fd 100644
--- a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
+++ b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
@@ -87,19 +87,16 @@
  {
struct br_ip br_group;
  
-@@ -736,7 +758,10 @@ static int br_ip6_multicast_add_group(st
+@@ -736,7 +758,7 @@ static int br_ip6_multicast_add_group(st
br_group.proto = htons(ETH_P_IPV6);
br_group.vid = vid;
  
 -  return br_multicast_add_group(br, port, br_group);
-+  if (ipv6_addr_is_solict_mult(group))
-+  src = NULL;
-+
 +  return br_multicast_add_group(br, port, br_group, src);
  }
  #endif
  
-@@ -965,6 +990,7 @@ static int br_ip4_multicast_igmp3_report
+@@ -965,6 +987,7 @@ static int br_ip4_multicast_igmp3_report
 struct sk_buff *skb,
 u16 vid)
  {
@@ -107,7 +104,7 @@
struct igmpv3_report *ih;
struct igmpv3_grec *grec;
int i;
-@@ -1008,7 +1034,7 @@ static int br_ip4_multicast_igmp3_report
+@@ -1008,7 +1031,7 @@ static int br_ip4_multicast_igmp3_report
continue;
}
  
@@ -116,7 +113,7 @@
if (err)
break;
}
-@@ -1022,6 +1048,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1022,6 +1045,7 @@ static int br_ip6_multicast_mld2_report(
struct sk_buff *skb,
u16 vid)
  {
@@ -124,7 +121,7 @@
struct icmp6hdr *icmp6h;
struct mld2_grec *grec;
int i;
-@@ -1070,7 +1097,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1070,7 +1094,7 @@ static int br_ip6_multicast_mld2_report(
}
  
err = br_ip6_multicast_add_group(br, port, grec-grec_mca,
@@ -133,7 +130,7 @@
if (err)
break;
}
-@@ -1406,7 +1433,8 @@ br_multicast_leave_group(struct net_brid
+@@ -1407,7 +1431,8 @@ br_multicast_leave_group(struct net_brid
 struct net_bridge_port *port,
 struct br_ip *group,
 struct bridge_mcast_other_query *other_query,
@@ -143,7 +140,7 @@
  {
struct net_bridge_mdb_htable *mdb;
struct net_bridge_mdb_entry *mp;
-@@ -1456,7 +1484,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1457,7 +1482,7 @@ br_multicast_leave_group(struct net_brid
for (pp = mp-ports;
 (p = mlock_dereference(*pp, br)) != NULL;
 pp = p-next) {
@@ -152,7 +149,7 @@
continue;
  
rcu_assign_pointer(*pp, p-next);
-@@ -1490,7 +1518,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1491,7 +1516,7 @@ br_multicast_leave_group(struct net_brid
for (p = mlock_dereference(mp-ports, br);
 p != NULL;
 p = mlock_dereference(p-next, br)) {
@@ -161,7 +158,7 @@
continue;
  
if (!hlist_unhashed(p-mglist) 
-@@ -1508,8 +1536,8 @@ out:
+@@ -1509,8 +1534,8 @@ out:
  
  static void br_ip4_multicast_leave_group(struct net_bridge *br,
 struct net_bridge_port *port,
@@ -172,7 +169,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1524,14 +1552,14 @@ static void br_ip4_multicast_leave_group
+@@ -1525,14 +1550,14 @@ static void br_ip4_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, br_group, br-ip4_other_query,
@@ -189,7 +186,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1546,7 +1574,7 @@ static void br_ip6_multicast_leave_group
+@@ -1547,7 +1572,7 @@ static void br_ip6_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, br_group, br-ip6_other_query,
@@ -198,7 +195,7 @@
  }
  #endif
  
-@@ -1555,6 +1583,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1556,6 +1581,7 @@ static int br_multicast_ipv4_rcv(struct
 struct

[OpenWrt-Devel] [PATCHv2 netifd 1/3] bridge: Fix multicast_to_unicast feature by hairpin+isolate

[Linus Lüssing]

All IGMP and MLD versions suffer from a specific limitation (from a
snooping switch perspective): Report suppression.

Once a listener hears an IGMPv2/3 or MLDv1 report for the same group
itself participates in then it might (if this listener is an IGMPv3 or
MLDv2 listener) or will (if this is an IGMPv1/2 or MLDv1 listener)
refrain from sending its own report.

Therefore we might currently miss such surpressing listeners as they
won't receive the multicast packet with the mangled, unicasted
destination.

Fixing this by first isolating the STAs and giving the bridge more
control over traffic forwarding. E.g. refraining to forward listener
reports to other STAs.

For broadcast and unicast traffic to an STA on the same AP, the hairpin
feature of the bridge will reflect such traffic back to the AP
interface. However, if the AP interface is actually configured to
isolate STAs, then hairpin is kept disabled.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 device.h   |1 +
 system-linux.c |   26 --
 wireless.c |   12 +++-
 wireless.h |1 +
 4 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/device.h b/device.h
index ce135ba..373445c 100644
--- a/device.h
+++ b/device.h
@@ -173,6 +173,7 @@ struct device {
bool iface_config;
bool default_config;
bool wireless;
+   bool wireless_isolate;
 
struct interface *config_iface;
 
diff --git a/system-linux.c b/system-linux.c
index 9ba13fd..9c4bea6 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -315,6 +315,16 @@ static void system_set_dadtransmits(struct device *dev, 
const char *val)
system_set_dev_sysctl(/proc/sys/net/ipv6/conf/%s/dad_transmits, 
dev-ifname, val);
 }
 
+static void system_bridge_set_multicast_to_unicast(struct device *dev, const 
char *val)
+{
+   system_set_dev_sysctl(/sys/class/net/%s/brport/multicast_to_unicast, 
dev-ifname, val);
+}
+
+static void system_bridge_set_hairpin_mode(struct device *dev, const char *val)
+{
+   system_set_dev_sysctl(/sys/class/net/%s/brport/hairpin_mode, 
dev-ifname, val);
+}
+
 static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
 {
int fd = -1, ret = -1;
@@ -556,12 +566,16 @@ static char *system_get_bridge(const char *name, char 
*buf, int buflen)
return path + 1;
 }
 
-static void system_bridge_set_wireless(const char *bridge, const char *dev)
+static void
+system_bridge_set_wireless(struct device *dev)
 {
-   snprintf(dev_buf, sizeof(dev_buf),
-/sys/devices/virtual/net/%s/brif/%s/multicast_to_unicast,
-bridge, dev);
-   system_set_sysctl(dev_buf, 1);
+   bool hairpin = true;
+
+   if (dev-wireless_isolate)
+   hairpin = false;
+
+   system_bridge_set_multicast_to_unicast(dev, 1);
+   system_bridge_set_hairpin_mode(dev, hairpin ? 1 : 0);
 }
 
 int system_bridge_addif(struct device *bridge, struct device *dev)
@@ -574,7 +588,7 @@ int system_bridge_addif(struct device *bridge, struct 
device *dev)
ret = system_bridge_if(bridge-ifname, dev, SIOCBRADDIF, NULL);
 
if (dev-wireless)
-   system_bridge_set_wireless(bridge-ifname, dev-ifname);
+   system_bridge_set_wireless(dev);
 
return ret;
 }
diff --git a/wireless.c b/wireless.c
index fbd6191..337f563 100644
--- a/wireless.c
+++ b/wireless.c
@@ -35,12 +35,14 @@ static const struct uci_blob_param_list wdev_param = {
 enum {
VIF_ATTR_DISABLED,
VIF_ATTR_NETWORK,
+   VIF_ATTR_ISOLATE,
__VIF_ATTR_MAX,
 };
 
 static const struct blobmsg_policy vif_policy[__VIF_ATTR_MAX] = {
[VIF_ATTR_DISABLED] = { .name = disabled, .type = BLOBMSG_TYPE_BOOL },
[VIF_ATTR_NETWORK] = { .name = network, .type = BLOBMSG_TYPE_ARRAY },
+   [VIF_ATTR_ISOLATE] = { .name = isolate, .type = BLOBMSG_TYPE_BOOL },
 };
 
 static const struct uci_blob_param_list vif_param = {
@@ -204,8 +206,10 @@ static void wireless_interface_handle_link(struct 
wireless_interface *vif, bool
 
if (up) {
struct device *dev = device_get(vif-ifname, 2);
-   if (dev)
+   if (dev) {
+   dev-wireless_isolate = vif-isolate;
dev-wireless = true;
+   }
}
 
blobmsg_for_each_attr(cur, vif-network, rem) {
@@ -700,6 +704,12 @@ void wireless_interface_create(struct wireless_device 
*wdev, struct blob_attr *d
vif-wdev = wdev;
vif-config = data;
vif-section = section;
+   vif-isolate = false;
+
+   cur = tb[VIF_ATTR_ISOLATE];
+   if (cur  blobmsg_get_bool(cur))
+   vif-isolate = blobmsg_get_bool(cur);
+
vlist_add(wdev-interfaces, vif-node, vif-name);
 }
 
diff --git a/wireless.h b/wireless.h
index c5dbb88..476c63e 100644
--- a/wireless.h
+++ b/wireless.h
@@ -77,6 +77,7 @@ struct wireless_interface {
 
const char *ifname

[OpenWrt-Devel] [PATCHv2] Fixes regarding bridge multicast-to-unicast feature

[Linus Lüssing]

Hi,

Here are a few patches to fix the issues the multicast-to-unicast
feature of the bridge has: IGMP/MLD report suppression could lead
to multicast packet loss. Also see ticket #17625 [0].

As previously discussed on this mailing list, AP-isolation together
with bridge-hairpinning is a way to make the multicast-to-unicast
feature usable even if listeners potentially suppressing reports
are present: That way the bridge will get all reports and will have
full control on where to forward them. For instance *not* to other
STAs (unless there is a multicast router).

Furthermore [PATCH netifd 2/3] introduces a netifd option to disable
the multicast-to-unicast feature.

[PATCH netifd 3/3] is not related to this issue but introduces a
handy option (which I would like to make use of for IGMP/MLD domain
segmentation).


The OpenWRT specific patches should be applied after the netifd
patches arrived in OpenWRT.

Cheers, Linus

[0]: https://dev.openwrt.org/ticket/17625

~~~

Changelog v2:
* Separated introduction of multicast_to_unicast configuration option
  in separate patch
* passing multicast_to_unicast to netifd scripts via json from netifd
  instead of external uci command calls
* Moved multicast_to_unicast uci option to be a bridge instead of
  bridge member option
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCHv2 netifd 2/3] bridge: Allow setting multicast_to_unicast option

[Linus Lüssing]

With this patch the multicast_to_unicast feature can be disabled for all
wireless interfaces via an according option on the uci bridge interface.

This patch also exports the setting information to wireless handler
scripts. The hostapd script will need that information to determine
whether to enable or disable ap-isolation, for instance.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 device.c   |9 +
 device.h   |3 +++
 scripts/netifd-wireless.sh |1 +
 system-linux.c |   13 +
 wireless.c |4 
 5 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/device.c b/device.c
index b5bee11..b44ccb8 100644
--- a/device.c
+++ b/device.c
@@ -48,6 +48,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_RPS] = { .name = rps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_XPS] = { .name = xps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_DADTRANSMITS] = { .name = dadtransmits, .type = 
BLOBMSG_TYPE_INT32 },
+   [DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = multicast_to_unicast, 
.type = BLOBMSG_TYPE_BOOL },
 };
 
 const struct uci_blob_param_list device_attr_list = {
@@ -174,6 +175,7 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
s-neigh6reachabletime : os-neigh6reachabletime;
n-dadtransmits = s-flags  DEV_OPT_DADTRANSMITS ?
s-dadtransmits : os-dadtransmits;
+   n-multicast_to_unicast = s-multicast_to_unicast;
n-flags = s-flags | os-flags;
 }
 
@@ -274,6 +276,11 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
s-flags |= DEV_OPT_DADTRANSMITS;
}
 
+   if ((cur = tb[DEV_ATTR_MULTICAST_TO_UNICAST])) {
+   s-multicast_to_unicast = blobmsg_get_bool(cur);
+   s-flags |= DEV_OPT_MULTICAST_TO_UNICAST;
+   }
+
device_set_disabled(dev, disabled);
 }
 
@@ -884,6 +891,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
}
if (st.flags  DEV_OPT_DADTRANSMITS)
blobmsg_add_u32(b, dadtransmits, st.dadtransmits);
+   if (st.flags  DEV_OPT_MULTICAST_TO_UNICAST)
+   blobmsg_add_u8(b, multicast_to_unicast, 
st.multicast_to_unicast);
}
 
s = blobmsg_open_table(b, statistics);
diff --git a/device.h b/device.h
index 373445c..4344d8a 100644
--- a/device.h
+++ b/device.h
@@ -42,6 +42,7 @@ enum {
DEV_ATTR_RPS,
DEV_ATTR_XPS,
DEV_ATTR_DADTRANSMITS,
+   DEV_ATTR_MULTICAST_TO_UNICAST,
__DEV_ATTR_MAX,
 };
 
@@ -84,6 +85,7 @@ enum {
DEV_OPT_XPS = (1  11),
DEV_OPT_MTU6= (1  12),
DEV_OPT_DADTRANSMITS= (1  13),
+   DEV_OPT_MULTICAST_TO_UNICAST= (1  14),
 };
 
 /* events broadcasted to all users of a device */
@@ -141,6 +143,7 @@ struct device_settings {
bool rps;
bool xps;
unsigned int dadtransmits;
+   bool multicast_to_unicast;
 };
 
 /*
diff --git a/scripts/netifd-wireless.sh b/scripts/netifd-wireless.sh
index c5d8a96..4d81929 100644
--- a/scripts/netifd-wireless.sh
+++ b/scripts/netifd-wireless.sh
@@ -260,6 +260,7 @@ for_each_interface() {
json_select $_w_iface
if [ -n $_w_types ]; then
json_get_var network_bridge bridge
+   json_get_var multicast_to_unicast multicast_to_unicast
json_select config
json_get_var _w_type mode
json_select ..
diff --git a/system-linux.c b/system-linux.c
index 9c4bea6..944245c 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -567,14 +567,19 @@ static char *system_get_bridge(const char *name, char 
*buf, int buflen)
 }
 
 static void
-system_bridge_set_wireless(struct device *dev)
+system_bridge_set_wireless(struct device *bridge, struct device *dev)
 {
+   bool mcast_to_ucast = true;
bool hairpin = true;
 
-   if (dev-wireless_isolate)
+   if (bridge-settings.flags  DEV_OPT_MULTICAST_TO_UNICAST 
+   !bridge-settings.multicast_to_unicast)
+   mcast_to_ucast = false;
+
+   if (!mcast_to_ucast || dev-wireless_isolate)
hairpin = false;
 
-   system_bridge_set_multicast_to_unicast(dev, 1);
+   system_bridge_set_multicast_to_unicast(dev, mcast_to_ucast ? 1 : 0);
system_bridge_set_hairpin_mode(dev, hairpin ? 1 : 0);
 }
 
@@ -588,7 +593,7 @@ int system_bridge_addif(struct device *bridge, struct 
device *dev)
ret = system_bridge_if(bridge-ifname, dev, SIOCBRADDIF, NULL);
 
if (dev-wireless)
-   system_bridge_set_wireless(dev);
+   system_bridge_set_wireless(bridge, dev);
 
return ret;
 }
diff --git a/wireless.c b/wireless.c
index 337f563..d0d2942 100644
--- a/wireless.c
+++ b

Re: [OpenWrt-Devel] [PATCH openwrt 1/3] hostapd: Always isolate if brport-multicast_to_unicast is enabled

[Linus Lüssing]

On Wed, Jul 08, 2015 at 02:31:03PM +0200, Felix Fietkau wrote:
 I really don't like the use of uci here. I think the information of
 whether ap_isolate needs to be enabled should be passed from netifd to
 this script in the json data.

Could you give me some pointers where in the netifd code that'd need to
be placed?

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Fixes regarding bridge multicast-to-unicast feature

[Linus Lüssing]

On Thu, Jun 18, 2015 at 05:22:58PM +0200, Linus Lüssing wrote:
 Hi,
 
 Here are a few patches to fix the issues the multicast-to-unicast
 feature of the bridge has: IGMP/MLD report suppression could lead
 to multicast packet loss.
 [...]

Any news / thoughts on these patches?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Improve wifi speed up to 2 times in AP mode.

[Linus Lüssing]

On Sun, Jun 28, 2015 at 09:16:58PM +0300, N.Leiten wrote:
 As a result I got full 100Mbit/s on AR71XX platform and 70-80Mbit on
 Ralink. I think it is good performance improvement at this moment.

Interesting, thanks for sharing your results!

If these settings are generally diserable, maybe it might make
sense to patch hostapd to set them by default if they aren't set
explicitly, instead of through netifd? That way anyone, not only
OpenWRT users might benefit from it.

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH openwrt 3/3] kernel: bridge, multicast-to-unicast: assign src after pskb_may_pull()

[Linus Lüssing]

A call to pskb_may_pull() might reallocate skb-data. Therefore we
should only assign the src-pointer after any potential reallocations.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 .../645-bridge_multicast_to_unicast.patch  |   45 +++-
 .../645-bridge_multicast_to_unicast.patch  |   45 +++-
 2 files changed, 52 insertions(+), 38 deletions(-)

diff --git 
a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch 
b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
index e8be1fd..83f2475 100644
--- a/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
+++ b/target/linux/generic/patches-3.18/645-bridge_multicast_to_unicast.patch
@@ -100,37 +100,40 @@
 struct sk_buff *skb,
 u16 vid)
  {
-+  const unsigned char *src = eth_hdr(skb)-h_source;
++  unsigned char *src;
struct igmpv3_report *ih;
struct igmpv3_grec *grec;
int i;
-@@ -1008,7 +1031,7 @@ static int br_ip4_multicast_igmp3_report
+@@ -1008,7 +1031,8 @@ static int br_ip4_multicast_igmp3_report
continue;
}
  
 -  err = br_ip4_multicast_add_group(br, port, group, vid);
++  src = eth_hdr(skb)-h_source;
 +  err = br_ip4_multicast_add_group(br, port, group, vid, src);
if (err)
break;
}
-@@ -1022,6 +1045,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1022,6 +1046,7 @@ static int br_ip6_multicast_mld2_report(
struct sk_buff *skb,
u16 vid)
  {
-+  const unsigned char *src = eth_hdr(skb)-h_source;
++  unsigned char *src;
struct icmp6hdr *icmp6h;
struct mld2_grec *grec;
int i;
-@@ -1070,7 +1094,7 @@ static int br_ip6_multicast_mld2_report(
+@@ -1069,8 +1094,9 @@ static int br_ip6_multicast_mld2_report(
+   continue;
}
  
++  src = eth_hdr(skb)-h_source;
err = br_ip6_multicast_add_group(br, port, grec-grec_mca,
 -   vid);
 +   vid, src);
if (err)
break;
}
-@@ -1407,7 +1431,8 @@ br_multicast_leave_group(struct net_brid
+@@ -1407,7 +1433,8 @@ br_multicast_leave_group(struct net_brid
 struct net_bridge_port *port,
 struct br_ip *group,
 struct bridge_mcast_other_query *other_query,
@@ -140,7 +143,7 @@
  {
struct net_bridge_mdb_htable *mdb;
struct net_bridge_mdb_entry *mp;
-@@ -1457,7 +1482,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1457,7 +1484,7 @@ br_multicast_leave_group(struct net_brid
for (pp = mp-ports;
 (p = mlock_dereference(*pp, br)) != NULL;
 pp = p-next) {
@@ -149,7 +152,7 @@
continue;
  
rcu_assign_pointer(*pp, p-next);
-@@ -1491,7 +1516,7 @@ br_multicast_leave_group(struct net_brid
+@@ -1491,7 +1518,7 @@ br_multicast_leave_group(struct net_brid
for (p = mlock_dereference(mp-ports, br);
 p != NULL;
 p = mlock_dereference(p-next, br)) {
@@ -158,7 +161,7 @@
continue;
  
if (!hlist_unhashed(p-mglist) 
-@@ -1509,8 +1534,8 @@ out:
+@@ -1509,8 +1536,8 @@ out:
  
  static void br_ip4_multicast_leave_group(struct net_bridge *br,
 struct net_bridge_port *port,
@@ -169,7 +172,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1525,14 +1550,14 @@ static void br_ip4_multicast_leave_group
+@@ -1525,14 +1552,14 @@ static void br_ip4_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, br_group, br-ip4_other_query,
@@ -186,7 +189,7 @@
  {
struct br_ip br_group;
struct bridge_mcast_own_query *own_query;
-@@ -1547,7 +1572,7 @@ static void br_ip6_multicast_leave_group
+@@ -1547,7 +1574,7 @@ static void br_ip6_multicast_leave_group
br_group.vid = vid;
  
br_multicast_leave_group(br, port, br_group, br-ip6_other_query,
@@ -195,55 +198,59 @@
  }
  #endif
  
-@@ -1556,6 +1581,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1556,6 +1583,7 @@ static int br_multicast_ipv4_rcv(struct
 struct sk_buff *skb,
 u16 vid)
  {
-+  const unsigned char *src = eth_hdr(skb)-h_source;
++  unsigned char *src;
struct sk_buff *skb2 = skb;
const struct iphdr *iph;
struct igmphdr *ih;
-@@ -1629,7 +1655,7 @@ static int br_multicast_ipv4_rcv(struct
+@@ -1629,7 +1657,8 @@ static int br_multicast_ipv4_rcv(struct

[OpenWrt-Devel] [PATCH netifd 1/2] bridge: Fix multicast_to_unicast feature by hairpin+isolate

[Linus Lüssing]

All IGMP and MLD versions suffer from a specific limitation (from a
snooping switch perspective): Report suppression.

Once a listener hears an IGMPv2/3 or MLDv1 report for the same group
itself participates in then it might (if this listener is an IGMPv3 or
MLDv2 listener) or will (if this is an IGMPv1/2 or MLDv1 listener)
refrain from sending its own report.

Therefore we might currently miss such surpressing listeners as they
won't receive the multicast packet with the mangled, unicasted
destination.

Fixing this by first isolating the STAs and giving the bridge more
control over traffic forwarding. E.g. refraining to forward listener
reports to other STAs.

For broadcast and unicast traffic to an STA on the same AP, the hairpin
feature of the bridge will reflect such traffic back to the AP
interface. However, if the AP interface is actually configured to
isolate STAs, then hairpin is kept disabled.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 device.c   |9 +
 device.h   |4 
 system-linux.c |   31 +--
 wireless.c |   12 +++-
 wireless.h |1 +
 5 files changed, 50 insertions(+), 7 deletions(-)

diff --git a/device.c b/device.c
index dd2823d..776829d 100644
--- a/device.c
+++ b/device.c
@@ -46,6 +46,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_NEIGHREACHABLETIME] = { .name = neighreachabletime, .type = 
BLOBMSG_TYPE_INT32 },
[DEV_ATTR_RPS] = { .name = rps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_XPS] = { .name = xps, .type = BLOBMSG_TYPE_BOOL },
+   [DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = multicast_to_unicast, 
.type = BLOBMSG_TYPE_BOOL },
 };
 
 const struct uci_blob_param_list device_attr_list = {
@@ -169,6 +170,7 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
s-neigh4reachabletime : os-neigh4reachabletime;
n-neigh6reachabletime = s-flags  DEV_OPT_NEIGHREACHABLETIME ?
s-neigh6reachabletime : os-neigh6reachabletime;
+   n-multicast_to_unicast = s-multicast_to_unicast;
n-flags = s-flags | os-flags;
 }
 
@@ -259,6 +261,11 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
else
s-xps = default_ps;
 
+   if ((cur = tb[DEV_ATTR_MULTICAST_TO_UNICAST])) {
+   s-multicast_to_unicast = blobmsg_get_bool(cur);
+   s-flags |= DEV_OPT_MULTICAST_TO_UNICAST;
+   }
+
device_set_disabled(dev, disabled);
 }
 
@@ -863,6 +870,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u32(b, neigh4reachabletime, 
st.neigh4reachabletime);
blobmsg_add_u32(b, neigh6reachabletime, 
st.neigh6reachabletime);
}
+   if (st.flags  DEV_OPT_MULTICAST_TO_UNICAST)
+   blobmsg_add_u8(b, multicast_to_unicast, 
st.multicast_to_unicast);
}
 
s = blobmsg_open_table(b, statistics);
diff --git a/device.h b/device.h
index 3001f10..55ef1cf 100644
--- a/device.h
+++ b/device.h
@@ -40,6 +40,7 @@ enum {
DEV_ATTR_NEIGHREACHABLETIME,
DEV_ATTR_RPS,
DEV_ATTR_XPS,
+   DEV_ATTR_MULTICAST_TO_UNICAST,
__DEV_ATTR_MAX,
 };
 
@@ -80,6 +81,7 @@ enum {
DEV_OPT_NEIGHREACHABLETIME  = (1  9),
DEV_OPT_RPS = (1  10),
DEV_OPT_XPS = (1  11),
+   DEV_OPT_MULTICAST_TO_UNICAST= (1  12),
 };
 
 /* events broadcasted to all users of a device */
@@ -135,6 +137,7 @@ struct device_settings {
unsigned int neigh6reachabletime;
bool rps;
bool xps;
+   bool multicast_to_unicast;
 };
 
 /*
@@ -167,6 +170,7 @@ struct device {
bool iface_config;
bool default_config;
bool wireless;
+   bool wireless_isolate;
 
struct interface *config_iface;
 
diff --git a/system-linux.c b/system-linux.c
index 6dc9acd..9e21ab0 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -310,6 +310,16 @@ static void system_set_neigh6reachabletime(struct device 
*dev, const char *val)

system_set_dev_sysctl(/proc/sys/net/ipv6/neigh/%s/base_reachable_time_ms, 
dev-ifname, val);
 }
 
+static void system_bridge_set_multicast_to_unicast(struct device *dev, const 
char *val)
+{
+   system_set_dev_sysctl(/sys/class/net/%s/brport/multicast_to_unicast, 
dev-ifname, val);
+}
+
+static void system_bridge_set_hairpin_mode(struct device *dev, const char *val)
+{
+   system_set_dev_sysctl(/sys/class/net/%s/brport/hairpin_mode, 
dev-ifname, val);
+}
+
 static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
 {
int fd = -1, ret = -1;
@@ -545,16 +555,25 @@ static char *system_get_bridge(const char *name, char 
*buf, int buflen)
return path + 1;
 }
 
-static void system_bridge_set_wireless(const char *bridge, const char *dev)
+static void

[OpenWrt-Devel] [PATCH] Fixes regarding bridge multicast-to-unicast feature

[Linus Lüssing]

Hi,

Here are a few patches to fix the issues the multicast-to-unicast
feature of the bridge has: IGMP/MLD report suppression could lead
to multicast packet loss. Also see ticket #17625 [0].

As previously discussed on this mailing list, AP-isolation together
with bridge-hairpinning is a way to make the multicast-to-unicast
feature usable even if listeners potentially suppressing reports
are present: That way the bridge will get all reports and will have
full control on where to forward them. For instance *not* to other
STAs (unless there is a multicast router).

Furthermore [PATCH netifd 1/2] introduces a netifd option to disable
the multicast-to-unicast feature.

[PATCH netifd 2/2] is not related to this issue but introduces a
handy option (which I would like to make use of for IGMP/MLD domain
segmentation).


The OpenWRT specific patches should be applied after the netifd
patches arrived in OpenWRT.

Cheers, Linus


[0]: https://dev.openwrt.org/ticket/17625
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH netifd 2/2] bridge: Allow setting multicast_router option

[Linus Lüssing]

The multicast_router option of a bridge allows to control the forwarding
behaviour of multicast packets independant of the listener state:

* 0: Only forward if specific listener is present
* 1 (default): Forward if specific listener or a multicast router
  was detected (currently only learned via query messages, no MRD
  support yet)
* 2: Always forward any multicast traffic on this port

Since MRD is not mandated you might end up with silent multicast routers
(e.g. if your link has more than one multicast router; only one can
become the selected, noisy querier). Here you might need a manual
configuration option like the multicast_router option.

Other scenarios where this can be useful are for instance:
* Segmentation of IGMP/MLD domains together with ebtables
* Dedicated bridge port for monitoring/debugging purposes

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 device.c   |   12 
 device.h   |3 +++
 system-linux.c |   17 +
 3 files changed, 32 insertions(+)

diff --git a/device.c b/device.c
index 776829d..bf643ef 100644
--- a/device.c
+++ b/device.c
@@ -47,6 +47,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_RPS] = { .name = rps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_XPS] = { .name = xps, .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_MULTICAST_TO_UNICAST] = { .name = multicast_to_unicast, 
.type = BLOBMSG_TYPE_BOOL },
+   [DEV_ATTR_MULTICAST_ROUTER] = { .name = multicast_router, .type = 
BLOBMSG_TYPE_INT32 },
 };
 
 const struct uci_blob_param_list device_attr_list = {
@@ -171,6 +172,7 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
n-neigh6reachabletime = s-flags  DEV_OPT_NEIGHREACHABLETIME ?
s-neigh6reachabletime : os-neigh6reachabletime;
n-multicast_to_unicast = s-multicast_to_unicast;
+   n-multicast_router = s-multicast_router;
n-flags = s-flags | os-flags;
 }
 
@@ -266,6 +268,14 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
s-flags |= DEV_OPT_MULTICAST_TO_UNICAST;
}
 
+   if ((cur = tb[DEV_ATTR_MULTICAST_ROUTER])) {
+   s-multicast_router = blobmsg_get_u32(cur);
+   if (s-multicast_router = 0  s-multicast_router = 2)
+   s-flags |= DEV_OPT_MULTICAST_ROUTER;
+   else
+   DPRINTF(Invalid value: %d - (Use 0: never, 1: learn, 
2: always)\n, blobmsg_get_u32(cur));
+   }
+
device_set_disabled(dev, disabled);
 }
 
@@ -872,6 +882,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
}
if (st.flags  DEV_OPT_MULTICAST_TO_UNICAST)
blobmsg_add_u8(b, multicast_to_unicast, 
st.multicast_to_unicast);
+   if (st.flags  DEV_OPT_MULTICAST_ROUTER)
+   blobmsg_add_u32(b, multicast_router, 
st.multicast_router);
}
 
s = blobmsg_open_table(b, statistics);
diff --git a/device.h b/device.h
index 55ef1cf..a487466 100644
--- a/device.h
+++ b/device.h
@@ -41,6 +41,7 @@ enum {
DEV_ATTR_RPS,
DEV_ATTR_XPS,
DEV_ATTR_MULTICAST_TO_UNICAST,
+   DEV_ATTR_MULTICAST_ROUTER,
__DEV_ATTR_MAX,
 };
 
@@ -82,6 +83,7 @@ enum {
DEV_OPT_RPS = (1  10),
DEV_OPT_XPS = (1  11),
DEV_OPT_MULTICAST_TO_UNICAST= (1  12),
+   DEV_OPT_MULTICAST_ROUTER= (1  13),
 };
 
 /* events broadcasted to all users of a device */
@@ -138,6 +140,7 @@ struct device_settings {
bool rps;
bool xps;
bool multicast_to_unicast;
+   unsigned int multicast_router;
 };
 
 /*
diff --git a/system-linux.c b/system-linux.c
index 9e21ab0..eb4b682 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -320,6 +320,13 @@ static void system_bridge_set_hairpin_mode(struct device 
*dev, const char *val)
system_set_dev_sysctl(/sys/class/net/%s/brport/hairpin_mode, 
dev-ifname, val);
 }
 
+static void system_bridge_set_multicast_router(struct device *dev, const char 
*val, bool bridge)
+{
+   system_set_dev_sysctl(bridge ? 
/sys/class/net/%s/bridge/multicast_router :
+  
/sys/class/net/%s/brport/multicast_router,
+ dev-ifname, val);
+}
+
 static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
 {
int fd = -1, ret = -1;
@@ -584,6 +591,11 @@ int system_bridge_addif(struct device *bridge, struct 
device *dev)
if (dev-wireless)
system_bridge_set_wireless(dev);
 
+   if (dev-settings.flags  DEV_OPT_MULTICAST_ROUTER) {
+   snprintf(buf, sizeof(buf), %i, 
dev-settings.multicast_router);
+   system_bridge_set_multicast_router(dev, buf, false);
+   }
+
return ret;
 }
 
@@ -834,6 +846,11 @@ int system_bridge_addbr(struct device *bridge, struct 
bridge_config

[OpenWrt-Devel] [PATCH openwrt 1/3] hostapd: Always isolate if brport-multicast_to_unicast is enabled

[Linus Lüssing]

For the multicast-to-unicast feature of a bridge to function correctly,
it is necessary that all STAs are always isolated on the AP level. The
bridge will take care of reflecting packets back to the AP interface
if necessary and/or no STA isolation wanted by using the hairpin feature
of the bridge.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 package/network/services/hostapd/files/netifd.sh |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/package/network/services/hostapd/files/netifd.sh 
b/package/network/services/hostapd/files/netifd.sh
index 23d2e7e..74b2d02 100644
--- a/package/network/services/hostapd/files/netifd.sh
+++ b/package/network/services/hostapd/files/netifd.sh
@@ -1,3 +1,6 @@
+. /lib/network/config.sh
+. /lib/config/uci.sh
+
 wpa_supplicant_add_rate() {
local var=$1
local val=$(($2 / 1000))
@@ -176,6 +179,9 @@ hostapd_set_bss_options() {
local bss_conf
local wep_rekey wpa_group_rekey wpa_pair_rekey wpa_master_rekey 
wpa_key_mgmt
 
+   local bridge_section=
+   local mcast_to_ucast=1
+
json_get_vars \
wep_rekey wpa_group_rekey wpa_pair_rekey wpa_master_rekey \
maxassoc max_inactivity disassoc_low_ack isolate auth_cache \
@@ -193,9 +199,18 @@ hostapd_set_bss_options() {
set_default wmm 1
set_default uapsd 1
 
+   if [ -n $network_bridge ]; then
+   bridge_section=$(find_config $network_bridge)
+   fi
+   if [ -n $bridge_section ]; then
+   mcast_to_ucast=$(uci_get_state network $bridge_section 
mcast_to_ucast 1)
+   fi
+
append bss_conf ctrl_interface=/var/run/hostapd
if [ $isolate -gt 0 ]; then
append bss_conf ap_isolate=$isolate $N
+   elif [ -n $bridge_section -a $mcast_to_ucast -gt 0 ]; then
+   append bss_conf ap_isolate=1 $N
fi
if [ $maxassoc -gt 0 ]; then
append bss_conf max_num_sta=$maxassoc $N
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

On Wed, Jun 03, 2015 at 07:25:32PM +0200, Steven Barth wrote:
 
 
 
 Steven, could you elaborate a little more on the scenario and
 explain why it is a must to shut up automatically when having a
 local user-space querier? If people are able to manually install and
 configure a complex multicast router, aren't they capable of
 manually disabling the bridge querier, too (there's even a netifd
 option for that)?
 
 I'm not thinking about complex router setups but instead about simple SSM 
 capable proxies (i.e. mcproxy and the like). I think thats a valid point and 
 don't see why v6 behaves rather awkwardly compared to v4 which simply goes 
 silent.

Hm, actually I would have thought the simply going silent a little
awkward because it's not what the IGMP/MRD standards mandate. And
that could lead to some down time if for instance two bridges
decide to shut up because of bad timing. The lower address
requirement in the querier election was supposed to take care of
that awkwardness. On the other hand using zero-source addresses
basically breaks the election mechanism too, so I guess it's ok to
shut up in that case...

 If i run a userspace querier the kernel should shut up otherwise the 
 userspace querier might get utterly confused since its suddenly competing 
 against itself in the election.

Ah, right, they use the same source address, good point! And for
that case, if the source addresses are the same then the bridge
already does that, both for IPv4 and IPv6 :). If receiving the
same source address as the own one, then it will select that
entity (no matter if from above the bridge or any bridge port),
as the new querier and will shut up. (compare
br_ip{6,}_multicast_select_querier())

 
 I mean the kernel can still do the mc- uc translation but simply let 
 userspace do the querying. Though i guess if all else fails we need to do 
 this manually using /proc writes in the init script hmmm...

Keep in mind that if we disabled the bridge querier by default
and if there is no userspace querier then we won't be able to
do mc-uc translation (or any multicast snooping). People wouldn't
be able to use their multicast streaming app with the OpenWRT
default configuration.

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

On Wed, Jun 03, 2015 at 07:47:49AM +0200, Steven Barth wrote:
 Do you by chance remember what was the behavior of the Linux kernel's
 intenral querier was.
 
 I mean does it use the usual L3-address of the bridge as source?

For IPv4 it uses 0.0.0.0 by default and there's an option to use
the IPv4 address of the interface (multicast_query_use_ifaddr).
For IPv6 it always uses the link-local IPv6 address of the bridge.

 How does it behave in the presence of other queriers either on WiFi stas or
 other bridge ports?

For IPv4 if 0.0.0.0 is used and if it hears any other query it'll
become quiet (and will start querying again if that querier
vanished after a certain timeout).

For IPv6 and a non-zero IPv4 source address it'll use the normal
IGMP/MLD querier election mechanism, meaning the one with the
lowest IP address will become the selected querier and the only
one querying on the link.

If the selected querier is behind one of the bridge ports then
any multicast traffic is always forwarded to that port regardless
of the IGMP/MLD reports it got from there.

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

On Wed, Jun 03, 2015 at 09:56:41AM +0200, Hans Dedecker wrote:
 On Wed, Jun 3, 2015 at 8:50 AM, Steven Barth cy...@openwrt.org wrote:
  Thanks for the quick reply.
 
 
  On 03.06.2015 08:26, Linus Lüssing wrote:
  For IPv6 and a non-zero IPv4 source address it'll use the normal
  IGMP/MLD querier election mechanism, meaning the one with the lowest
  IP address will become the selected querier and the only one querying
  on the link.
  So especially for v6 - since the kernel doesn't do IGMPv3 / MLDv2 - this
  effectively downgrades all the bridge links to ASM then (at least with a
  50% chance, i.e. when the kernel wins due to lower MAC-address), which
  is a bit meh.

Right, that's currently a trade-off, if you don't have
source-specific-multicast or another MLD querier on the network,
it is nice to have it enabled by default. Otherwise there's a
disadvantage. Not sure how often source-specific-multicast is actually
used these days and what the philosophy and typical scenario for the
default values in OpenWRT is. If the defaults were optimized for the
average guys home router, who probably doesn't have an SSM multicast
router, but might have an app to do some multicast music/video/conference
streaming it should probably be enabled by default to avoid his
wifi becoming unusable/congested. Don't feel strongly about the default
for the querier though.

 
  Now remaining question is, does the kernel detect if there is a
  userspace-querier running on the same machine and silence itself then?
  If not we probably need to address this as well somehow.
 I can confirm the bridge querier silence itself when an
 userspace-querier is running at least for IGMP.
 Did not check the MLD behavior yet.

Yes, that's probably due to the bridge zero-source querier becoming
quiet when it hears another IGMP query. For MLD that should be different
yes.

Steven, could you elaborate a little more on the scenario and
explain why it is a must to shut up automatically when having a
local user-space querier? If people are able to manually install and
configure a complex multicast router, aren't they capable of
manually disabling the bridge querier, too (there's even a netifd
option for that)?

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

On Fri, Oct 24, 2014 at 06:35:27PM +0200, Felix Fietkau wrote:
 I'd like to get back to suppressing forwarding IGMPv2/MLDv1 reports:
 I just learned that we can avoid changing mac80211 at all for this.
 If we disable forwarding between stations in mac80211 and enable hairpin
 mode on the bridge interface, we have enough control over the data path
 to selectively suppress forwarding of reports to be able to deal with
 this issue.
 Do you have some ideas on how to detect if a report needs to be
 forwarded to a station (and if so, to which station)?

After rereading the bridge code once more I noticed that technically
nothing would break if the querier is behind a station. If the
querier is behind a station we will flood reports back on the
incoming wifi ap interface and to all stations, therefore causing
report suppression for other listeners on another station, yes.
But: If the querier is behind a station, the bridge will also
at least send one multicast frame back without changing the ethernet
destination, resulting in a wifi broadcast (check
br_multicast_flood() in br_forward.c: router ports will have
precedence over multicast port groups due to the lport  rport
check).

So the disadvantages with the current approach are just the
following two if a querier is behind an STA:
* Unnecessary broadcasts which could be forwarded to the STA with
  the querier by unicast, too
* If there are multiple STAs listening to the same multicast group,
  all but the first will get the multicast packets via unicast
  (while all, including the first, will (additionally) receive
  them via broadcast)

But since nothing breaks and the scenario of having a
querier/multicast router behind an STA is rather uncommon, I think
that could be optimized later when someone needs it.

So just the following changes would be needed to
OpenWRT/netifd/bridge-mcast-to-ucast-patch for now:

netifd:
* If multicast-to-unicast is enabled, then enable hairpinning and
  ap-isolation, too.
* Add one option to disable the
  multicast-to-unicast+hairpinning+ap-isolation combination
bridge-patch:
* Revert Changeset 43736
  (kernel: disable multicast-to-unicast translation for ipv6
  neighbor solicitation
* Do the src = eth_hdr(skb)-h_dest initializations later, after
  any pskb_may_pull()
* Submit to upstream :)

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH netifd] bridge: allow setting hash_max value

[Linus Lüssing]

If the number of entries in the MDB exceeds hash_max then the
multicast snooping capabilities of the bridge are disabled
automatically.

The default value for hash_max is 512 which is already exceeded by some
wireless community mesh networks. They need to be able to set a higher
value.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 bridge.c   |6 ++
 system-linux.c |5 +
 system.h   |1 +
 3 files changed, 12 insertions(+)

diff --git a/bridge.c b/bridge.c
index fd553dc..9da5314 100644
--- a/bridge.c
+++ b/bridge.c
@@ -33,6 +33,7 @@ enum {
BRIDGE_ATTR_MAX_AGE,
BRIDGE_ATTR_BRIDGE_EMPTY,
BRIDGE_ATTR_MULTICAST_QUERIER,
+   BRIDGE_ATTR_HASH_MAX,
__BRIDGE_ATTR_MAX
 };
 
@@ -47,6 +48,7 @@ static const struct blobmsg_policy 
bridge_attrs[__BRIDGE_ATTR_MAX] = {
[BRIDGE_ATTR_IGMP_SNOOP] = { igmp_snooping, BLOBMSG_TYPE_BOOL },
[BRIDGE_ATTR_BRIDGE_EMPTY] = { bridge_empty, BLOBMSG_TYPE_BOOL },
[BRIDGE_ATTR_MULTICAST_QUERIER] = { multicast_querier, 
BLOBMSG_TYPE_BOOL },
+   [BRIDGE_ATTR_HASH_MAX] = { hash_max, BLOBMSG_TYPE_INT32 },
 };
 
 static const struct uci_blob_param_info bridge_attr_info[__BRIDGE_ATTR_MAX] = {
@@ -551,6 +553,7 @@ bridge_apply_settings(struct bridge_state *bst, struct 
blob_attr **tb)
cfg-forward_delay = 2;
cfg-igmp_snoop = true;
cfg-multicast_querier = true;
+   cfg-hash_max = 512;
cfg-bridge_empty = false;
cfg-priority = 0x7FFF;
 
@@ -569,6 +572,9 @@ bridge_apply_settings(struct bridge_state *bst, struct 
blob_attr **tb)
if ((cur = tb[BRIDGE_ATTR_MULTICAST_QUERIER]))
cfg-multicast_querier = blobmsg_get_bool(cur);
 
+   if ((cur = tb[BRIDGE_ATTR_HASH_MAX]))
+   cfg-hash_max = blobmsg_get_u32(cur);
+
if ((cur = tb[BRIDGE_ATTR_AGEING_TIME])) {
cfg-ageing_time = blobmsg_get_u32(cur);
cfg-flags |= BRIDGE_OPT_AGEING_TIME;
diff --git a/system-linux.c b/system-linux.c
index 08b6757..061617d 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -785,6 +785,7 @@ sec_to_jiffies(int val)
 
 int system_bridge_addbr(struct device *bridge, struct bridge_config *cfg)
 {
+   char buf[64];
unsigned long args[4] = {};
 
if (ioctl(sock_ioctl, SIOCBRADDBR, bridge-ifname)  0)
@@ -804,6 +805,10 @@ int system_bridge_addbr(struct device *bridge, struct 
bridge_config *cfg)

system_set_dev_sysctl(/sys/devices/virtual/net/%s/bridge/multicast_querier,
bridge-ifname, cfg-multicast_querier ? 1 : 0);
 
+   snprintf(buf, sizeof(buf), %i, cfg-hash_max);
+   system_set_dev_sysctl(/sys/devices/virtual/net/%s/bridge/hash_max,
+   bridge-ifname, buf);
+
args[0] = BRCTL_SET_BRIDGE_PRIORITY;
args[1] = cfg-priority;
system_bridge_if(bridge-ifname, NULL, SIOCDEVPRIVATE, args);
diff --git a/system.h b/system.h
index 94e0dd9..0a8d644 100644
--- a/system.h
+++ b/system.h
@@ -58,6 +58,7 @@ struct bridge_config {
int ageing_time;
int hello_time;
int max_age;
+   int hash_max;
 };
 
 enum macvlan_opt {
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] kernel: bridge: backport two snooping related patches

[Linus Lüssing]

With this patch the following two patches are backported:

* bridge: fix parsing of MLDv2 reports
* bridge: allow setting hash_max + multicast_router if interface is down

The former one is an important fix which got just applied to the net-tree
and is queued for stable. The latter is a patch which is needed to make
the hash_max and multicast_router attributes configurable through
netifd.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 ...51-01-bridge-fix-parsing-of-MLDv2-reports.patch |   58 
 ...w-setting-hash_max-multicast_router-if-in.patch |   99 
 .../645-bridge_multicast_to_unicast.patch  |2 +-
 3 files changed, 158 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/generic/patches-3.18/051-01-bridge-fix-parsing-of-MLDv2-reports.patch
 create mode 100644 
target/linux/generic/patches-3.18/051-02-bridge-allow-setting-hash_max-multicast_router-if-in.patch

diff --git 
a/target/linux/generic/patches-3.18/051-01-bridge-fix-parsing-of-MLDv2-reports.patch
 
b/target/linux/generic/patches-3.18/051-01-bridge-fix-parsing-of-MLDv2-reports.patch
new file mode 100644
index 000..9fdaf17
--- /dev/null
+++ 
b/target/linux/generic/patches-3.18/051-01-bridge-fix-parsing-of-MLDv2-reports.patch
@@ -0,0 +1,58 @@
+From 1430a5975e1a5f249875faab7fd35b915a8d2397 Mon Sep 17 00:00:00 2001
+From: Thadeu Lima de Souza Cascardo casca...@redhat.com
+Date: Fri, 22 May 2015 12:18:59 -0300
+Subject: [PATCH] bridge: fix parsing of MLDv2 reports
+
+When more than a multicast address is present in a MLDv2 report, all but
+the first address is ignored, because the code breaks out of the loop if
+there has not been an error adding that address.
+
+This has caused failures when two guests connected through the bridge
+tried to communicate using IPv6. Neighbor discoveries would not be
+transmitted to the other guest when both used a link-local address and a
+static address.
+
+This only happens when there is a MLDv2 querier in the network.
+
+The fix will only break out of the loop when there is a failure adding a
+multicast address.
+
+The mdb before the patch:
+
+dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
+dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
+dev ovirtmgmt port bond0.86 grp ff02::2 temp
+
+After the patch:
+
+dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
+dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
+dev ovirtmgmt port bond0.86 grp ff02::fb temp
+dev ovirtmgmt port bond0.86 grp ff02::2 temp
+dev ovirtmgmt port bond0.86 grp ff02::d temp
+dev ovirtmgmt port vnet0 grp ff02::1:ff00:76 temp
+dev ovirtmgmt port bond0.86 grp ff02::16 temp
+dev ovirtmgmt port vnet1 grp ff02::1:ff00:77 temp
+dev ovirtmgmt port bond0.86 grp ff02::1:ff00:def temp
+dev ovirtmgmt port bond0.86 grp ff02::1:ffa1:40bf temp
+
+Fixes: 08b202b67264 (bridge br_multicast: IPv6 MLD support.)
+Reported-by: Rik Theys rik.th...@esat.kuleuven.be
+Signed-off-by: Thadeu Lima de Souza Cascardo casca...@redhat.com
+Tested-by: Rik Theys rik.th...@esat.kuleuven.be
+Signed-off-by: David S. Miller da...@davemloft.net
+---
+ net/bridge/br_multicast.c |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/bridge/br_multicast.c
 b/net/bridge/br_multicast.c
+@@ -1071,7 +1071,7 @@ static int br_ip6_multicast_mld2_report(
+ 
+   err = br_ip6_multicast_add_group(br, port, grec-grec_mca,
+vid);
+-  if (!err)
++  if (err)
+   break;
+   }
+ 
diff --git 
a/target/linux/generic/patches-3.18/051-02-bridge-allow-setting-hash_max-multicast_router-if-in.patch
 
b/target/linux/generic/patches-3.18/051-02-bridge-allow-setting-hash_max-multicast_router-if-in.patch
new file mode 100644
index 000..c899c10
--- /dev/null
+++ 
b/target/linux/generic/patches-3.18/051-02-bridge-allow-setting-hash_max-multicast_router-if-in.patch
@@ -0,0 +1,99 @@
+From 6ae4ae8e512bd229f806c22f8a2cd751e4f987c2 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Linus=20L=C3=BCssing?= linus.luess...@c0d3.blue
+Date: Sat, 23 May 2015 03:12:34 +0200
+Subject: [PATCH] bridge: allow setting hash_max + multicast_router if
+ interface is down
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Network managers like netifd (used in OpenWRT for instance) try to
+configure interface options after creation but before setting the
+interface up.
+
+Unfortunately the sysfs / bridge currently only allows to configure the
+hash_max and multicast_router options when the bridge interface is up.
+But 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 linus.luess...@c0d3.blue
+Signed-off-by: David S. Miller da...@davemloft.net
+---
+ net/bridge/br_multicast.c |   24

Re: [OpenWrt-Devel] [PATCH] firewall: Allow MLD input on WAN

[Linus Lüssing]

Hi Steven,

On Sun, May 03, 2015 at 04:43:24PM +0200, Steven Barth wrote:
 Hello Linus,
 
 thanks for the patch. I have two questions here.
 
 #1 Why should this be done for v6 but not for v4?

woops, sorry, had the IGMP part for v4 in my test setup but forgot
to add it to the patch. Going to do that.

 
 #2 If the intention is to respond to MLD queries why should the
 firewall allow reception of report messages?

Yes, responding to queries is the primary concern. Technically,
it doesn't make much of a difference to allow reception report
messages. The default in OpenWRT is to have the querier on the
bridge, so reports shouldn't arrive on the input chain of br-wan
anyways as the bridge won't forward them (see RFC4541,
Considerations for Internet Group Management Protocol (IGMP)
and Multicast Listener Discovery (MLD) Snooping Switches).

On the other hand, there's RFC4890, Recommendations for Filtering
ICMPv6 Messages in Firewalls which says in section 4.3.3, that
firewalls mustn't drop either queries nor reports. MLD/IGMP traffic
shouldn't do any harm as it's always link-scoped.

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] firewall: Allow IGMP and MLD input on WAN

[Linus Lüssing]

The WAN port should at least respond to IGMP and MLD queries as
otherwise a snooping bridge/switch might drop traffic.

RFC4890 recommends to leave IGMP and MLD unfiltered as they are always
link-scoped anyways.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
v2 of [PATCH] firewall: Allow MLD input on WAN:
* Allow IGMP too
* Added note about RFC4890

 .../network/config/firewall/files/firewall.config   |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/package/network/config/firewall/files/firewall.config 
b/package/network/config/firewall/files/firewall.config
index d149e77..1a20e39 100644
--- a/package/network/config/firewall/files/firewall.config
+++ b/package/network/config/firewall/files/firewall.config
@@ -46,6 +46,13 @@ config rule
option family   ipv4
option target   ACCEPT
 
+config rule
+   option name Allow-IGMP
+   option src  wan
+   option protoigmp
+   option family   ipv4
+   option target   ACCEPT
+
 # Allow DHCPv6 replies
 # see https://dev.openwrt.org/ticket/10381
 config rule
@@ -59,6 +66,18 @@ config rule
option family   ipv6
option target   ACCEPT
 
+config rule
+   option name Allow-MLD
+   option src  wan
+   option protoicmp
+   option src_ip   fe80::/10
+   list icmp_type  '130/0'
+   list icmp_type  '131/0'
+   list icmp_type  '132/0'
+   list icmp_type  '143/0'
+   option family   ipv6
+   option target   ACCEPT
+
 # Allow essential incoming IPv6 ICMP traffic
 config rule
option name Allow-ICMPv6-Input
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] firewall: Allow MLD input on WAN

[Linus Lüssing]

The WAN port should at least respond to MLD queries as otherwise
a snooping bridge/switch might drop traffic.

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 package/network/config/firewall/files/firewall.config |   12 
 1 file changed, 12 insertions(+)

diff --git a/package/network/config/firewall/files/firewall.config 
b/package/network/config/firewall/files/firewall.config
index d149e77..b9a48cd 100644
--- a/package/network/config/firewall/files/firewall.config
+++ b/package/network/config/firewall/files/firewall.config
@@ -59,6 +59,18 @@ config rule
option family   ipv6
option target   ACCEPT
 
+config rule
+   option name Allow-MLD
+   option src  wan
+   option protoicmp
+   option src_ip   fe80::/10
+   list icmp_type  '130/0'
+   list icmp_type  '131/0'
+   list icmp_type  '132/0'
+   list icmp_type  '143/0'
+   option family   ipv6
+   option target   ACCEPT
+
 # Allow essential incoming IPv6 ICMP traffic
 config rule
option name Allow-ICMPv6-Input
-- 
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kernel: bridge: multicast: backport a few more fixes for 3.10

[Linus Lüssing]

On Wed, Jan 14, 2015 at 12:12:33AM +0100, Linus Lüssing wrote:
 On Tue, Dec 30, 2014 at 04:10:56AM +0100, Linus Lüssing wrote:
  The following patches unfortunately didn't hit the kernel stable
  branches yet, therefore cherrypicking them for OpenWRT here:
  
  * bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries
  * bridge: multicast: enable snooping on general queries only
  * bridge: multicast: add sanity check for general query destination
  
  Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
  ---
   .../patches-3.10/070-net_bridge_backports.patch|  193 
  
   .../644-bridge_optimize_netfilter_hooks.patch  |6 +-
   2 files changed, 162 insertions(+), 37 deletions(-)
  
 
 Bump

Didn't notice that this patch got applied to trunk already, just
saw it while browsing the dev.openwrt.org. Thanks!

Would it be possible to apply it to Barrier Breaker, too? The
patch only contains fixes and the issues are still present in BB,
too.

Thanks!

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] kernel: bridge: multicast: backport a few more fixes for 3.10

[Linus Lüssing]

On Tue, Dec 30, 2014 at 04:10:56AM +0100, Linus Lüssing wrote:
 The following patches unfortunately didn't hit the kernel stable
 branches yet, therefore cherrypicking them for OpenWRT here:
 
 * bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries
 * bridge: multicast: enable snooping on general queries only
 * bridge: multicast: add sanity check for general query destination
 
 Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
 ---
  .../patches-3.10/070-net_bridge_backports.patch|  193 
 
  .../644-bridge_optimize_netfilter_hooks.patch  |6 +-
  2 files changed, 162 insertions(+), 37 deletions(-)
 

Bump
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] kernel: bridge: multicast: backport a few more fixes for 3.10

[Linus Lüssing]

The following patches unfortunately didn't hit the kernel stable
branches yet, therefore cherrypicking them for OpenWRT here:

* bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries
* bridge: multicast: enable snooping on general queries only
* bridge: multicast: add sanity check for general query destination

Signed-off-by: Linus Lüssing linus.luess...@c0d3.blue
---
 .../patches-3.10/070-net_bridge_backports.patch|  193 
 .../644-bridge_optimize_netfilter_hooks.patch  |6 +-
 2 files changed, 162 insertions(+), 37 deletions(-)

diff --git a/target/linux/generic/patches-3.10/070-net_bridge_backports.patch 
b/target/linux/generic/patches-3.10/070-net_bridge_backports.patch
index f303c3a..48d6eda 100644
--- a/target/linux/generic/patches-3.10/070-net_bridge_backports.patch
+++ b/target/linux/generic/patches-3.10/070-net_bridge_backports.patch
@@ -1,3 +1,88 @@
+commit f0b4eeced518c632210ef2aea44fc92cc9e86cce
+Author: Linus Lüssing linus.luess...@web.de
+Date:   Mon Nov 17 12:20:28 2014 +0100
+
+bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries
+
+Ebtables on the OUTPUT chain (NF_BR_LOCAL_OUT) would not work as expected
+for both locally generated IGMP and MLD queries. The IP header specific
+filter options are off by 14 Bytes for netfilter (actual output on
+interfaces is fine).
+
+NF_HOOK() expects the skb-data to point to the IP header, not the
+ethernet one (while dev_queue_xmit() does not). Luckily there is an
+br_dev_queue_push_xmit() helper function already - let's just use that.
+
+Introduced by eb1d16414339a6e113d89e2cca2556005d7ce919
+(bridge: Add core IGMP snooping support)
+
+Ebtables example:
+
+$ ebtables -I OUTPUT -p IPv6 -o eth1 --logical-out br0 \
+--log --log-level 6 --log-ip6 --log-prefix=~EBT:  -j DROP
+
+before (broken):
+
+~EBT:  IN= OUT=eth1 MAC source = 02:04:64:a4:39:c2 \
+MAC dest = 33:33:00:00:00:01 proto = 0x86dd IPv6 \
+SRC=64a4:39c2:86dd:6000::0020:0001:fe80 IPv6 \
+DST=:::0004:64ff:fea4:39c2:ff02, \
+IPv6 priority=0x3, Next Header=2
+
+after (working):
+
+~EBT:  IN= OUT=eth1 MAC source = 02:04:64:a4:39:c2 \
+   MAC dest = 33:33:00:00:00:01 proto = 0x86dd IPv6 \
+SRC=fe80::::0004:64ff:fea4:39c2 IPv6 \
+DST=ff02:::::::0001, \
+IPv6 priority=0x0, Next Header=0
+
+Signed-off-by: Linus Lüssing linus.luess...@web.de
+Acked-by: Herbert Xu herb...@gondor.apana.org.au
+Signed-off-by: Pablo Neira Ayuso pa...@netfilter.org
+
+commit 20a599bec95a52fa72432b2376a2ce47c5bb68fb
+Author: Linus Lüssing linus.luess...@web.de
+Date:   Mon Mar 10 22:25:25 2014 +0100
+
+bridge: multicast: enable snooping on general queries only
+
+Without this check someone could easily create a denial of service
+by injecting multicast-specific queries to enable the bridge
+snooping part if no real querier issuing periodic general queries
+is present on the link which would result in the bridge wrongly
+shutting down ports for multicast traffic as the bridge did not learn
+about these listeners.
+
+With this patch the snooping code is enabled upon receiving valid,
+general queries only.
+
+Signed-off-by: Linus Lüssing linus.luess...@web.de
+Signed-off-by: David S. Miller da...@davemloft.net
+
+commit 9ed973cc40c588abeaa58aea0683ea665132d11d
+Author: Linus Lüssing linus.luess...@web.de
+Date:   Mon Mar 10 22:25:24 2014 +0100
+
+bridge: multicast: add sanity check for general query destination
+
+General IGMP and MLD queries are supposed to have the multicast
+link-local all-nodes address as their destination according to RFC2236
+section 9, RFC3376 section 4.1.12/9.1, RFC2710 section 8 and RFC3810
+section 5.1.15.
+
+Without this check, such malformed IGMP/MLD queries can result in a
+denial of service: The queries are ignored by most IGMP/MLD listeners
+therefore they will not respond with an IGMP/MLD report. However,
+without this patch these malformed MLD queries would enable the
+snooping part in the bridge code, potentially shutting down the
+according ports towards these hosts for multicast traffic as the
+bridge did not learn about these listeners.
+
+Reported-by: Jan Stancek jstan...@redhat.com
+Signed-off-by: Linus Lüssing linus.luess...@web.de
+Signed-off-by: David S. Miller da...@davemloft.net
+
 commit 3c3769e63301fd92fcaf51870c371583dd0282ce
 Author: Linus Lüssing linus.luess...@web.de
 Date:   Wed Sep 4 02:13:39 2013 +0200
@@ -229,7 +314,17 @@ Date:   Tue May 21 21:52:54 2013 +
  static void __br_multicast_send_query(struct net_bridge *br,
  struct net_bridge_port *port,
  struct br_ip *ip)
-@@ -790,37 +809,45 @@ static void __br_multicast_send_query(st

Re: [OpenWrt-Devel] Multicast packets being lost (3.10 stable)

[Linus Lüssing]

Hi David,

did you have a chance to look into backporting these fixes for
stable yet? (if I read the docs correctly, I should query you for
suggestions for stable kernels, right?)

Also, an eighth patch I'd suggest for stable now:

8) bridge: fix netfilter/NF_BR_LOCAL_OUT for own, locally generated queries
   - f0b4eeced (since 3.18)


If there's anything unclear, just let me know. Thanks :)!

Cheers, Linus


On Wed, Sep 10, 2014 at 03:33:41PM +0200, Linus Lüssing wrote:
 I just got a complaint about bridges, multicast and a
 3.10 kernel again. Seems like nobody had any objections about
 queueing these two patches for stable ( 2)+3) )?
 
 Also I'm still missing some more fixes in the stable branches.
 Especially 5), 6) and 7) are of high priority (next to 2) and 3) )
 in my opinion as otherwise IPv6 in general could be broken for people
 using 3.12 or 3.13 (as 3.12 contains a patch which activates
 multicast snooping for link-local addresses, too: 3c3769e63).
 
 Here is a more ordered list of patches I'd suggest to be queued for
 stable:
 
 1) bridge: fix switched interval for MLD Query types
- 32de868cb (present since 3.10)
 2) bridge: disable snooping if there is no querier
- b00589af3 (present since 3.11)
 3) bridge: don't try to update timers in case of broken MLD queries
- 248ba8ec0 (present since 3.11)
 4) Revert bridge: only expire the mdb entry when query is received
- 454594f3b (present since 3.12)
 5) bridge: multicast: add sanity check for query source addresses
- 6565b9eee (present since 3.14)
 6) bridge: multicast: add sanity check for general query destination
- 9ed973cc4 (present since 3.14)
 7) bridge: multicast: enable snooping on general queries only
- 20a599bec (present since 3.14)
 
 Let me know what you'd think about that or if there's any trouble
 applying them to older kernels.
 
 Cheers, Linus
 
 
 On Tue, Mar 25, 2014 at 02:06:07PM +0100, Linus Lüssing wrote:
  That commit is supposed to be a fix and seems to be a easily
  cherry-pickable on top of 3.10. So I think it's suitable for
  stable
  
  There are two follow-up commit for this particular patch that I'm aware
  of: bridge: separate querier and query timer into IGMP/IPv4
  and MLD/IPv6 ones (cc0fdd80). That's just an optimization
  and can be ignored for stable.
  
  The second one is bridge: don't try to update timers in case of
  broken MLD queries (248ba8ec0). Which is a direct fix for
  b00589af3 and should therefore go into stable, too, if b00589af3
  goes into stable.
  
  Cheers, Linus
  
  
  On Mon, Mar 24, 2014 at 09:41:07AM -0700, Stephen Hemminger wrote:
   We are seeing multicast snooping related issues.
   Is there some reason this commit never went into stable (3.10)
   
   commit b00589af3b04736376f24625ab0b394642e89e29
   Author: Linus Lüssing linus.luess...@web.de
   Date:   Thu Aug 1 01:06:20 2013 +0200
   
   bridge: disable snooping if there is no querier
   
   If there is no querier on a link then we won't get periodic reports 
   and
   therefore won't be able to learn about multicast listeners behind 
   ports,
   potentially leading to lost multicast packets, especially for 
   multicast
   listeners that joined before the creation of the bridge.
   
   These lost multicast packets can appear since c5c23260594
   (bridge: Add multicast_querier toggle and disable queries by 
   default)
   in particular.
   
   With this patch we are flooding multicast packets if our querier is
   disabled and if we didn't detect any other querier.
   
   A grace period of the Maximum Response Delay of the querier is added 
   to
   give multicast responses enough time to arrive and to be learned from
   before disabling the flooding behaviour again.
   
   Signed-off-by: Linus Lüssing linus.luess...@web.de
   Signed-off-by: David S. Miller da...@davemloft.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

PS: Also found another, small potential bug in your unicasting
patch: The 'src = eth_hdr(skb)-h_source's you added can break because
after this assignment but before the usage of 'src' there are calls to
pskb_may_pull(skb). pskb_may_pull(skb) can reallocate the skb-data,
potentially leading to the dereference of a dangling pointer for 'src'.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

On Fri, Oct 24, 2014 at 06:35:27PM +0200, Felix Fietkau wrote:
 On 2014-09-11 16:28, Linus Lüssing wrote:
  On Wed, Sep 10, 2014 at 04:31:37PM +0200, Linus Lüssing wrote:
  Another approach would be
  to add a feature to mac80211 to disable the forwarding of
  IGMPv2/MLDv1 reports to other STAs, only forwarding it on the own
  AP interface so that the bridge would see all reports.
  
  Hrm, on the other hand, if a querier is actually on one of the
  other STAs then mac80211 would have to forward the report there.
  Which would mean either needing query-snooping in mac80211 (or
  netdev in general) or interaction between mac80211 and the
  bridge-snooping code.
  
  I really hate this IGMPv2/MLDv1 report suppression...
  (that's where all the complexity in the batman-adv multicast
  optimizations came from, too)
 I'd like to get back to suppressing forwarding IGMPv2/MLDv1 reports:
 I just learned that we can avoid changing mac80211 at all for this.
 If we disable forwarding between stations in mac80211 and enable hairpin
 mode on the bridge interface, we have enough control over the data path
 to selectively suppress forwarding of reports to be able to deal with
 this issue.

Ah, I get it, you want to apply the same MAC-destination change
trick to the reports from the bridge, too. That should work,
hairpin is a neat idea :).

 Do you have some ideas on how to detect if a report needs to be
 forwarded to a station (and if so, to which station)?

Yep, it needs to be forwarded to the station with the selected
querier. Which is either a single one or none, so the
unicasting-trick would work.

Port and at least the IP address of the selected querier are tracked
in br-ip{4,6}_querier and get set in
br_ip{4,6}_multicast_select_querier().

 
 - Felix

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

On Wed, Sep 10, 2014 at 05:02:04PM +0200, Felix Fietkau wrote:
 I intentionally wanted to keep the implementation outside of mac80211,
 because there are other scenarios where this could be useful.
 I might have a dumb AP with no IGMP snooping capabilities connected to
 an Ethernet interface, and with this implementation I can simply enable
 multicast-unicast translation on the Ethernet device.

Ah! Right, that's a good use-case and reason to do it like that for
now, agreed. Thanks for clarifying :).

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

On Wed, Sep 10, 2014 at 04:31:37PM +0200, Linus Lüssing wrote:
 Another approach would be
 to add a feature to mac80211 to disable the forwarding of
 IGMPv2/MLDv1 reports to other STAs, only forwarding it on the own
 AP interface so that the bridge would see all reports.

Hrm, on the other hand, if a querier is actually on one of the
other STAs then mac80211 would have to forward the report there.
Which would mean either needing query-snooping in mac80211 (or
netdev in general) or interaction between mac80211 and the
bridge-snooping code.

I really hate this IGMPv2/MLDv1 report suppression...
(that's where all the complexity in the batman-adv multicast
optimizations came from, too)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

On Thu, Sep 11, 2014 at 04:51:41PM +0200, Felix Fietkau wrote:
 On 2014-09-11 16:28, Linus Lüssing wrote:
  On Wed, Sep 10, 2014 at 04:31:37PM +0200, Linus Lüssing wrote:
  Another approach would be
  to add a feature to mac80211 to disable the forwarding of
  IGMPv2/MLDv1 reports to other STAs, only forwarding it on the own
  AP interface so that the bridge would see all reports.
  
  Hrm, on the other hand, if a querier is actually on one of the
  other STAs then mac80211 would have to forward the report there.
  Which would mean either needing query-snooping in mac80211 (or
  netdev in general) or interaction between mac80211 and the
  bridge-snooping code.
  
  I really hate this IGMPv2/MLDv1 report suppression...
  (that's where all the complexity in the batman-adv multicast
  optimizations came from, too)
 How widely used is IGMPv2/MLDv1 compared to the newer version?

According to Wikipedia, MLDv2 is present in operating systems
since:

* Windows Vista
* FreeBSD 8.0
* Linux 2.5.68

However, unfortunately, MLDv2 has a lot of MLDv1-compatibility
sections: A single MLDv1 listener/report can cause report
suppresion for MLDv2 listeners, too. An MLDv1 router/query leads
to MLDv2 listeners to switch to MLDv1 compatibility mode. The
querier code in the Linux bridge sends MLDv1 queries which is even
enabled by default in widely used kernels like 3.2 (and which you
enabled by default in OpenWRT Barrier Breaker, too).

In the Freifunk mesh networks in Hamburg and Lübeck we do have
MLDv1 reports, though it's hard to tell how many MLDv1-only
devices there are due to the suppressions and
MLDv1-compatibility-mode on MLDv2 hosts.

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

On Thu, Sep 11, 2014 at 05:42:18PM +0200, Steven Barth wrote:
 Well it seems to be still somewhat used in embedded stuff, e.g. my
 5-year old HP ethernet/802.11g printer/scanner/whatever still uses
 MLDv1 / IGMPv2 to do its MDNS / SSDP business.

Yeah, that's probably because IGMPv2/MLDv1 is way easier to implement
than MLDv2, so as long as IGMPv2/MLDv1 aren't obsoleted by the
IETF, especially budget vendors will probably keep implementing it
even today.

 
 Another idea would maybe be to translate MLDv1 / IGMPv2 reports into
 appropriate MLDv2/IGMPv3 equivalents before sharing them on the
 bridge to prevent the suppression.

Hm, IGMPv2/MLDv1 to IGMPv3/MLDv2 should be relatively easy. But
I'm currently not sure whether a router/querier will make and take
some wrong assumptions and actions by thinking there is no
IGMPv2/MLDv1 listener. What if there is one MLDv2 listener which
included source specific state messages in its state change report?
The querier would respond with a Multicast Address and Source
Specific Query to learn whether there are listeners left for
this multicast and source addresses. Would the MLDv1 listener
interpret this query and process this message as a Multicast Address
Specific Query or would it ignore it?

What about the many MLDv1 queriers we have right now through the
bridge code? What if someone sneaks in an MLDv1 listener somewhere
in your bridged network over an ethernet cable? (You'd need
report translation both on the AP and on bridges and maybe query
translation, too)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Multicast packets being lost (3.10 stable)

[Linus Lüssing]

I just got a complaint about bridges, multicast and a
3.10 kernel again. Seems like nobody had any objections about
queueing these two patches for stable ( 2)+3) )?

Also I'm still missing some more fixes in the stable branches.
Especially 5), 6) and 7) are of high priority (next to 2) and 3) )
in my opinion as otherwise IPv6 in general could be broken for people
using 3.12 or 3.13 (as 3.12 contains a patch which activates
multicast snooping for link-local addresses, too: 3c3769e63).

Here is a more ordered list of patches I'd suggest to be queued for
stable:

1) bridge: fix switched interval for MLD Query types
   - 32de868cb (present since 3.10)
2) bridge: disable snooping if there is no querier
   - b00589af3 (present since 3.11)
3) bridge: don't try to update timers in case of broken MLD queries
   - 248ba8ec0 (present since 3.11)
4) Revert bridge: only expire the mdb entry when query is received
   - 454594f3b (present since 3.12)
5) bridge: multicast: add sanity check for query source addresses
   - 6565b9eee (present since 3.14)
6) bridge: multicast: add sanity check for general query destination
   - 9ed973cc4 (present since 3.14)
7) bridge: multicast: enable snooping on general queries only
   - 20a599bec (present since 3.14)

Let me know what you'd think about that or if there's any trouble
applying them to older kernels.

Cheers, Linus


On Tue, Mar 25, 2014 at 02:06:07PM +0100, Linus Lüssing wrote:
 That commit is supposed to be a fix and seems to be a easily
 cherry-pickable on top of 3.10. So I think it's suitable for
 stable
 
 There are two follow-up commit for this particular patch that I'm aware
 of: bridge: separate querier and query timer into IGMP/IPv4
 and MLD/IPv6 ones (cc0fdd80). That's just an optimization
 and can be ignored for stable.
 
 The second one is bridge: don't try to update timers in case of
 broken MLD queries (248ba8ec0). Which is a direct fix for
 b00589af3 and should therefore go into stable, too, if b00589af3
 goes into stable.
 
 Cheers, Linus
 
 
 On Mon, Mar 24, 2014 at 09:41:07AM -0700, Stephen Hemminger wrote:
  We are seeing multicast snooping related issues.
  Is there some reason this commit never went into stable (3.10)
  
  commit b00589af3b04736376f24625ab0b394642e89e29
  Author: Linus Lüssing linus.luess...@web.de
  Date:   Thu Aug 1 01:06:20 2013 +0200
  
  bridge: disable snooping if there is no querier
  
  If there is no querier on a link then we won't get periodic reports and
  therefore won't be able to learn about multicast listeners behind ports,
  potentially leading to lost multicast packets, especially for multicast
  listeners that joined before the creation of the bridge.
  
  These lost multicast packets can appear since c5c23260594
  (bridge: Add multicast_querier toggle and disable queries by default)
  in particular.
  
  With this patch we are flooding multicast packets if our querier is
  disabled and if we didn't detect any other querier.
  
  A grace period of the Maximum Response Delay of the querier is added to
  give multicast responses enough time to arrive and to be learned from
  before disabling the flooding behaviour again.
  
  Signed-off-by: Linus Lüssing linus.luess...@web.de
  Signed-off-by: David S. Miller da...@davemloft.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

On Wed, Sep 10, 2014 at 04:31:37PM +0200, Linus Lüssing wrote:
 One more thing/optimization I was thinking of is, instead
 of modifying the destination address of the frame whether the
 802.11 receiver address could be modified. For instance by letting
 the bridge forward the destinations to mac80211 as a list in the skb.
 
 Would seem a little cleaner to me and I think then this feature
 could even be enabled by default in upstream kernels for any mac80211
 based wifi interface. What do you think?

Also, another advantage of having the destinations on the mac80211 side
would be that it'd make further optimizations relatively easy. People
interested in that could make use of such a list together with the
information of the rate selection algorithm.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Regarding bridge multicast-to-unicast patch

[Linus Lüssing]

Hi Felix,

Matthias just told me about the work you have done on the bridge
code which can be found as 645-bridge_multicast_to_unicast.patch
in the OpenWRT repositord.

I really like the idea of unicasting multicast packets to STAs.
Especially as that would fit nicely with the work done on
batman-adv and multicast :P.

Currently, I think I'm seeing a conceptual issue with this
specific implementation though, leading to multicast packet
loss: It seems to me that IGMPv2/MLDv1 report suppression (as well
as IGMPv3/MLDv2 report suppresion in the presence of IGMPv2/MLDv1
listeners/reports) was not considered.

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] dnsmasq: direct address return option for uci config

[Linus Lüssing]

On Mon, May 09, 2011 at 10:51:50PM +0200, John Crispin wrote:
 On 09/04/11 07:00, Linus Lüssing wrote:
 
 hi,
 
 you should simply symlink /etc/resolv.conf to /tmp/resolv.conf.auto in
 this case
 
 thx,
 John

Hi John,

Ah, yes, you're right, that's easier, didn't think of that before. Sorry
didn't see your email back then. This patch is unnecessary then.

Cheers, Linus

PS: This is in reference to [PATCH 2/2] (not 1/2 as the
in-reply-to might suggest). I resubmitted [PATCH 1/2] unmodified
today.

 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] scripts: Add git submodule support for within env profiles

[Linus Lüssing]

If one or more directories of an env profile consist of a git submodule,
they will be checked out automatically now when switching to the according
profile with 'scripts/env switch'.

Signed-off-by: Linus Lüssing linus.luess...@web.de
---
 scripts/env |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/scripts/env b/scripts/env
index 80e08ec..ba7e30e 100755
--- a/scripts/env
+++ b/scripts/env
@@ -165,6 +165,7 @@ env_switch() {
env_init
env_ask_sync
git checkout $name || error environment '$name' not found
+   git submodule update --init --recursive
env_link_config
 }
 
-- 
1.7.7.3

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Add tinc init file and add conffiles

[Linus Lüssing]

Hi Manuel, hi list,

What do you think about maybe making it a little bit more uci-ish?
This should make it easier to integrate into LuCI later for instance.
And give the possibility to reconfigure things via the uci command line
tool and scripts, of course.

So, ehm, sorry for me throwing in this alternative, should have been
sending this patch way earlier to this mailing list...
If anyone feels offended/hijacked, please just ignore my email, first
come, first served.

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] tinc: Add uci config and init files

[Linus Lüssing]

With this commit configuration via uci, similiar to the one used for
OpenVPN, will be added to tinc.

Most of the parameters are working just as described in the official
manpages of tincd and tinc.conf as provided by its developer.

The only exceptions are 'enable' which if set to 0 or if not set
will make the tinc init script completely ignore this tinc network and
its according tinc host configurations (similiar to the one in the
OpenVPN config) and 'generate_keys' which if set to 1 will check whether
a key pair is already present for the given tinc network and if not will
generate them with the key size of key_size (default if not present:
2048) - this reduces the effort of setting up a tinc VPN on a router
to just providing the right uci config file with no need of creating
custom initialization scripts for for instance the key generation.

Furthermore, similiar to the OpenVPN configuration, also tinc configs
of its native format can be used. They just need to be placed in
/etc/tinc/NETNAME. The init scripts will always copy the content of
/etc/tinc/ to /tmp first and will append any parameters provided in
/etc/config/tinc afterwards (the user needs to take care to not specify
non-list parameters in both uci and native config).

Signed-off-by: Linus Lüssing linus.luess...@web.de
---
 net/tinc/Makefile   |7 ++
 net/tinc/files/tinc.config  |   54 ++
 net/tinc/files/tinc.init|  227 +++
 net/tinc/files/tinc.upgrade |1 +
 4 files changed, 289 insertions(+), 0 deletions(-)
 create mode 100644 net/tinc/files/tinc.config
 create mode 100755 net/tinc/files/tinc.init
 create mode 100644 net/tinc/files/tinc.upgrade

diff --git a/net/tinc/Makefile b/net/tinc/Makefile
index 05f9546..b8b09ec 100644
--- a/net/tinc/Makefile
+++ b/net/tinc/Makefile
@@ -45,6 +45,13 @@ CONFIGURE_ARGS += \
 define Package/tinc/install
$(INSTALL_DIR) $(1)/usr/sbin
$(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/tincd $(1)/usr/sbin/
+   $(INSTALL_DIR) $(1)/etc/init.d/
+   $(INSTALL_BIN) files/$(PKG_NAME).init $(1)/etc/init.d/$(PKG_NAME)
+   $(INSTALL_DIR) $(1)/etc/config
+   $(INSTALL_CONF) files/$(PKG_NAME).config $(1)/etc/config/$(PKG_NAME)
+   $(INSTALL_DIR) $(1)/etc/openvpn
+   $(INSTALL_DIR) $(1)/lib/upgrade/keep.d
+   $(INSTALL_DATA) files/tinc.upgrade $(1)/lib/upgrade/keep.d/tinc
 endef
 
 $(eval $(call BuildPackage,tinc))
diff --git a/net/tinc/files/tinc.config b/net/tinc/files/tinc.config
new file mode 100644
index 000..1ac1151
--- /dev/null
+++ b/net/tinc/files/tinc.config
@@ -0,0 +1,54 @@
+config tinc-net NETNAME
+   option enable 0
+
+   ## Daemon Configuration (cmd arguments)
+   #option generate_keys 0
+   #option key_size 2048
+   #option log /tmp/log/tinc.NETNAME.log
+   #option debug 3
+
+   ## Server Configuration (tinc.conf)
+   #option AddressFamily any
+   #option BindToAddress 127.0.0.1
+   #option BindToInterface lo
+
+   #list ConnectTo peer1
+
+   #option DirectOnly 0
+   #option Forwarding internal
+   #option GraphDumpFile /tmp/log/tinc.NETNAME.dot
+   #option Hostnames 0
+   #option IffOneQueue 0
+   #option Interface NETNAME
+   #option KeyExpire 3600
+   #option MACExpire 600
+   #option MaxTimeout 900
+   #option Mode router
+
+   option Name NODENAME
+
+   #option PingInterval 60
+   #option PingTimeout 5
+   #option PriorityInheritance 0
+   #option PrivateKeyFile /etc/tinc/NETNAME/rsa_key.priv
+   #option ProcessPriority normal
+   #option ReplayWindow 16
+   #option StrictSubnets 0
+   #option TunnelServer 0
+   #option UDPRcvBuf x
+   #option UDPSndBuf x
+
+config tinc-host NODENAME
+   option net NETNAME
+
+   #list Address example.com
+   #option Cipher blowfish
+   #option ClampMSS yes
+   #option Compression 0
+   #option Digest sha1
+   #option IndirectData 0
+   #option MACLength 4
+   #option PMTU 1514
+   #option PMTUDiscovery yes
+   #option Port 655
+   #option Subnet 192.168.1.0/24
diff --git a/net/tinc/files/tinc.init b/net/tinc/files/tinc.init
new file mode 100755
index 000..0ef51de
--- /dev/null
+++ b/net/tinc/files/tinc.init
@@ -0,0 +1,227 @@
+#!/bin/sh /etc/rc.common
+# Tinc init script
+# Copyright (C) 2011 Linus Lüssing
+#  Based on Jo-Philipp Wich's OpenVPN init script
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+
+START=42
+BIN=/usr/sbin/tincd
+SSD=start-stop-daemon
+EXTRA_COMMANDS=up down
+
+LIST_SEP=
+
+TMP_TINC=/tmp/tinc
+
+append_param() {
+   local v=$1
+   case $v in
+   *_*_*_*) v=${v%%_*}-${v#*_}; v=${v%%_*}-${v#*_}; 
v=${v%%_*}-${v#*_} ;;
+   *_*_*)   v=${v%%_*}-${v#*_}; v=${v%%_*}-${v#*_} ;;
+   *_*) v=${v%%_*}-${v#*_} ;;
+   esac
+   ARGS=$ARGS --$v
+   return

[OpenWrt-Devel] [PATCH 1/2] [package] uhttpd: Fix wrong certificate options with multiple words

[Linus Lüssing]

For instance two word city names will result in weird certificates.
Therefore adding the missing quotations.

Signed-off-by: Linus Lüssing linus.luess...@web.de
---
 package/uhttpd/files/uhttpd.init |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/package/uhttpd/files/uhttpd.init b/package/uhttpd/files/uhttpd.init
index 069e16f..1ec0096 100755
--- a/package/uhttpd/files/uhttpd.init
+++ b/package/uhttpd/files/uhttpd.init
@@ -44,7 +44,7 @@ generate_keys() {
[ -x $PX5G_BIN ]  {
$PX5G_BIN selfsigned -der \
-days ${days:-730} -newkey rsa:${bits:-1024} -keyout 
$UHTTPD_KEY -out $UHTTPD_CERT \
-   -subj 
/C=${country:-DE}/ST=${state:-Saxony}/L=${location:-Leipzig}/CN=${commonname:-OpenWrt}
+   -subj 
/C=${country:-DE}/ST=${state:-Saxony}/L=${location:-Leipzig}/CN=${commonname:-OpenWrt}
}
 }
 
-- 
1.7.7

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] dnsmasq: direct address return option for uci config

[Linus Lüssing]

With this commit the --address option of dnsmasq, directly returning ip
addresses for certain domains instead of querying the dns server, can be
configured in the dhcp uci configuration file. See the dnsmasq manpage
for further details of this option.

Signed-off-by: Linus Lüssing linus.luess...@web.de
---
 package/dnsmasq/files/dhcp.conf|1 +
 package/dnsmasq/files/dnsmasq.init |5 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/package/dnsmasq/files/dhcp.conf b/package/dnsmasq/files/dhcp.conf
index 660b06a..5ba772e 100644
--- a/package/dnsmasq/files/dhcp.conf
+++ b/package/dnsmasq/files/dhcp.conf
@@ -15,6 +15,7 @@ config dnsmasq
option leasefile'/tmp/dhcp.leases'
option resolvfile   '/tmp/resolv.conf.auto'
#list server'/mycompany.local/1.2.3.4'
+   #list address   '/whatever.domain/192.168.123.45'
#option nonwildcard 1
#list interface br-lan
#list notinterface  lo
diff --git a/package/dnsmasq/files/dnsmasq.init 
b/package/dnsmasq/files/dnsmasq.init
index a0e893c..9518df3 100644
--- a/package/dnsmasq/files/dnsmasq.init
+++ b/package/dnsmasq/files/dnsmasq.init
@@ -41,6 +41,10 @@ append_server() {
append args -S $1
 }
 
+append_address() {
+   append args -A $1
+}
+
 append_interface() {
local ifname=$(uci_get_state network $1 ifname $1)
append args -i $ifname
@@ -88,6 +92,7 @@ dnsmasq() {
append_parm $cfg domain -s
append_parm $cfg local -S
config_list_foreach $cfg server append_server
+   config_list_foreach $cfg address append_address
config_list_foreach $cfg interface append_interface
config_list_foreach $cfg notinterface append_notinterface
config_list_foreach $cfg addnhosts append_addnhosts
-- 
1.7.5.4

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] dnsmasq: add option to avoid modifying resolv.conf

[Linus Lüssing]

Currently, dnsmasq removes /tmp/resolv.conf (which is usually a symlink
to /tmp/resolv.conf.auto) and creates its own resolv.conf with at least
a nameserver pointing to 127.0.0.1.

However, in some cases it might not be desired that the router itself
queries its own dnsmasq dns-server but should query the upstream dns
server - possibly fetched via an additional, local dhcp client -
directly instead.

With this new uci configuration option it is possible to prohibit
dnsmasq to change /tmp/resolv.conf, leaving it as provided by the
udhcpd.

Signed-off-by: Linus Lüssing linus.luess...@web.de
---
* shortened the option name
* commented this option out in the default dhcp.conf to make clear
  that it's optional and should not break any old configs

 package/dnsmasq/files/dhcp.conf|1 +
 package/dnsmasq/files/dnsmasq.init |8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/package/dnsmasq/files/dhcp.conf b/package/dnsmasq/files/dhcp.conf
index 5ba772e..2d7f185 100644
--- a/package/dnsmasq/files/dhcp.conf
+++ b/package/dnsmasq/files/dhcp.conf
@@ -20,6 +20,7 @@ config dnsmasq
#list interface br-lan
#list notinterface  lo
#list bogusnxdomain '64.94.110.11'
+   #option keepresolvcf0
 
 config dhcp lan
option interfacelan
diff --git a/package/dnsmasq/files/dnsmasq.init 
b/package/dnsmasq/files/dnsmasq.init
index 9518df3..5570d35 100644
--- a/package/dnsmasq/files/dnsmasq.init
+++ b/package/dnsmasq/files/dnsmasq.init
@@ -114,6 +114,8 @@ dnsmasq() {
config_get hostsfile $cfg dhcphostsfile
[ -e $hostsfile ]  append args --dhcp-hostsfile=$hostsfile
 
+   config_get_bool keepresolvcf $cfg keepresolvcf
+
local rebind
config_get_bool rebind $cfg rebind_protection 1
[ $rebind -gt 0 ]  {
@@ -388,8 +390,9 @@ start() {
config_foreach dhcp_srv_add srvhost
config_foreach dhcp_add dhcp
 
-   /usr/sbin/dnsmasq $args  {
+   /usr/sbin/dnsmasq $args  [ ! $keepresolvcf = 1 ]  {
rm -f /tmp/resolv.conf
+   echo ### Created by dnsmasq.init ###  /tmp/resolv.conf
[ -n $DOMAIN ]  echo search $DOMAIN  /tmp/resolv.conf
DNS_SERVERS=$DNS_SERVERS 127.0.0.1
for DNS_SERVER in $DNS_SERVERS ; do
@@ -399,7 +402,8 @@ start() {
 }
 
 stop() {
-   [ -f /tmp/resolv.conf ]  {
+   [ -f /tmp/resolv.conf ]  \
+   [ `head -n1 /tmp/resolv.conf` = ### Created by dnsmasq.init ### ] 
 {
rm -f /tmp/resolv.conf
ln -s /tmp/resolv.conf.auto /tmp/resolv.conf
}
-- 
1.7.5.4

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] dnsmasq: direct address return option for uci config

[Linus Lüssing]

With this commit the --address option of dnsmasq, directly returning ip
addresses for certain domains instead of querying the dns server, can be
configured in the dhcp uci configuration file. See the dnsmasq manpage
for further details of this option.

Signed-off-by: Linus Lüssing linus.luess...@web.de
---
 package/dnsmasq/files/dhcp.conf|1 +
 package/dnsmasq/files/dnsmasq.init |5 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/package/dnsmasq/files/dhcp.conf b/package/dnsmasq/files/dhcp.conf
index 660b06a..5ba772e 100644
--- a/package/dnsmasq/files/dhcp.conf
+++ b/package/dnsmasq/files/dhcp.conf
@@ -15,6 +15,7 @@ config dnsmasq
option leasefile'/tmp/dhcp.leases'
option resolvfile   '/tmp/resolv.conf.auto'
#list server'/mycompany.local/1.2.3.4'
+   #list address   '/whatever.domain/192.168.123.45'
#option nonwildcard 1
#list interface br-lan
#list notinterface  lo
diff --git a/package/dnsmasq/files/dnsmasq.init 
b/package/dnsmasq/files/dnsmasq.init
index cd5a78a..8334b38 100644
--- a/package/dnsmasq/files/dnsmasq.init
+++ b/package/dnsmasq/files/dnsmasq.init
@@ -41,6 +41,10 @@ append_server() {
append args -S $1
 }
 
+append_address() {
+   append args -A $1
+}
+
 append_interface() {
local ifname=$(uci_get_state network $1 ifname $1)
append args -i $ifname
@@ -88,6 +92,7 @@ dnsmasq() {
append_parm $cfg domain -s
append_parm $cfg local -S
config_list_foreach $cfg server append_server
+   config_list_foreach $cfg address append_address
config_list_foreach $cfg interface append_interface
config_list_foreach $cfg notinterface append_notinterface
config_list_foreach $cfg addnhosts append_addnhosts
-- 
1.7.4.1

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] dnsmasq: add option to avoid modifying resolv.conf

[Linus Lüssing]

Currently, dnsmasq removes /tmp/resolv.conf (which is usually a symlink
to /tmp/resolv.conf.auto) and creates its own resolv.conf with at least
a nameserver pointing to 127.0.0.1.

However, in some cases it might not be desired that the router itself
queries its own dnsmasq dns-server but should query the upstream dns
server - possibly fetched via an additional, local dhcp client -
directly instead.

With this new uci configuration option it is possible to prohibit
dnsmasq to change /tmp/resolv.conf, leaving it as provided by the
udhcpd.

Signed-off-by: Linus Lüssing linus.luess...@web.de
---
 package/dnsmasq/files/dhcp.conf|1 +
 package/dnsmasq/files/dnsmasq.init |8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/package/dnsmasq/files/dhcp.conf b/package/dnsmasq/files/dhcp.conf
index 5ba772e..aa5f703 100644
--- a/package/dnsmasq/files/dhcp.conf
+++ b/package/dnsmasq/files/dhcp.conf
@@ -20,6 +20,7 @@ config dnsmasq
#list interface br-lan
#list notinterface  lo
#list bogusnxdomain '64.94.110.11'
+   option resolvconfuntouched 0
 
 config dhcp lan
option interfacelan
diff --git a/package/dnsmasq/files/dnsmasq.init 
b/package/dnsmasq/files/dnsmasq.init
index 8334b38..a578649 100644
--- a/package/dnsmasq/files/dnsmasq.init
+++ b/package/dnsmasq/files/dnsmasq.init
@@ -114,6 +114,8 @@ dnsmasq() {
config_get hostsfile $cfg dhcphostsfile
[ -e $hostsfile ]  append args --dhcp-hostsfile=$hostsfile
 
+   config_get_bool resolvconfuntouched $cfg resolvconfuntouched
+
local rebind
config_get_bool rebind $cfg rebind_protection 1
[ $rebind -gt 0 ]  {
@@ -389,8 +391,9 @@ start() {
config_foreach dhcp_srv_add srvhost
config_foreach dhcp_add dhcp
 
-   /usr/sbin/dnsmasq $args  {
+   /usr/sbin/dnsmasq $args  [ ! $resolvconfuntouched = 1 ]  {
rm -f /tmp/resolv.conf
+   echo ### Created by dnsmasq.init ###  /tmp/resolv.conf
[ -n $DOMAIN ]  echo search $DOMAIN  /tmp/resolv.conf
DNS_SERVERS=$DNS_SERVERS 127.0.0.1
for DNS_SERVER in $DNS_SERVERS ; do
@@ -400,7 +403,8 @@ start() {
 }
 
 stop() {
-   [ -f /tmp/resolv.conf ]  {
+   [ -f /tmp/resolv.conf ]  \
+   [ `head -n1 /tmp/resolv.conf` = ### Created by dnsmasq.init ### ] 
 {
rm -f /tmp/resolv.conf
ln -s /tmp/resolv.conf.auto /tmp/resolv.conf
}
-- 
1.7.4.1

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] dnsmasq: add option to avoid modifying resolv.conf

[Linus Lüssing]

PS: I'm not so happy with this long uci option name,
'resolvconfuntouched', but couldn't come up with anything better
yet. Something like 'upstreaminsteadoflocaldnsserver' would be
more descriptive but, well, even longer...
Suggestions (and feedback for this patch in general) welcome :).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] base-files: bridge config, avoid having a random ipv6 ll address

[Linus Lüssing]

So far, we are setting the bridge interface up before having added any
bridge interface ports. This results in the bridge assigning a random
mac address to its bridge interface and therefore IPv6 assigning a
matching link local address to the bridge interface as soon as the
bridge interface is up. After adding the first bridge port interface,
the bridge's mac address is reset correctly, however the IPv6 link
local address stays the same.

This commit ensures that we are at least having the IPv6 link local
address of the first interface added to the bridge instead of a random
one.

Signed-off-by: Linus Lüssing linus.luess...@web.de
---
 package/base-files/files/lib/network/config.sh |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/package/base-files/files/lib/network/config.sh 
b/package/base-files/files/lib/network/config.sh
index def1562..9489ccf 100755
--- a/package/base-files/files/lib/network/config.sh
+++ b/package/base-files/files/lib/network/config.sh
@@ -186,11 +186,11 @@ prepare_interface() {
config_get_bool stp $config stp 0
$DEBUG brctl addbr br-$config
$DEBUG brctl setfd br-$config 0
-   $DEBUG ifconfig br-$config up
$DEBUG ifconfig $iface 0.0.0.0
$DEBUG do_sysctl 
net.ipv6.conf.$iface.disable_ipv6 1
$DEBUG brctl addif br-$config $iface
$DEBUG brctl stp br-$config $stp
+   $DEBUG ifconfig br-$config up
# Creating the bridge here will have 
triggered a hotplug event, which will
# result in another setup_interface() 
call, so we simply stop processing
# the current event at this point.
-- 
1.7.4.1

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] mac80211 / ath9k / ibss / adhoc / probe-responses

[Linus Lüssing]

Hi Bastian,

Just for the record, had the same issue with madwifi a month ago.
In my case, there was even some rogue/broken other wifi device
which was sending probe requests every 5ms, resulting in a
congested medium due to my 4 devices in adhoc mode trying to
answer them all. A workaround for me so far was the madwifi specific
option probereq 0 (which of course does not work for ath9k
according to the wiki docs and is just a workaround anyway).

Cheers, Linus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [packages] tinc: update to 1.0.13

[Linus Lüssing]

Signed-off-by: Linus Lüssing linus.luess...@web.de
---
 net/tinc/Makefile |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/tinc/Makefile b/net/tinc/Makefile
index 290a8a1..efd6735 100644
--- a/net/tinc/Makefile
+++ b/net/tinc/Makefile
@@ -8,14 +8,14 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=tinc
-PKG_VERSION:=1.0.11
+PKG_VERSION:=1.0.13
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=http://www.tinc-vpn.org/packages \
http://ftp.yi.se/pub/tinc/ \
http://www.mirrors.wiretapped.net/security/network-security/tinc/
-PKG_MD5SUM:=ee0b1a3366c6e379cae34be6fa5dcb15
+PKG_MD5SUM:=86263994d38c750431efd17e9a91a248
 
 PKG_INSTALL:=1
 
-- 
1.7.1

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] including patches-folder in scripts/env

[Linus Lüssing]

This patch includes a patches folder in the base directoy to
scripts/env's version control. Such a folder will be treated the
same way as the files folder.

Signed-off-by: Linus Lüssing linus.luess...@web.de

Index: kamikaze/scripts/env
===
--- kamikaze/scripts/env(revision 18405)
+++ kamikaze/scripts/env(working copy)
@@ -62,6 +62,7 @@
git init 
touch .config 
mkdir files 
+   mkdir patches 
git add .  
git commit -q -m Initial import
} || {
@@ -87,6 +88,8 @@
ln -s env/.config $BASEDIR/.config
mkdir -p $ENVDIR/files
[ -L $BASEDIR/files ] || ln -s env/files $BASEDIR/files
+   mkdir -p $ENVDIR/patches
+   [ -L $BASEDIR/patches ] || ln -s env/patches $BASEDIR/patches
 }
 
 env_do_reset() {
@@ -134,14 +137,17 @@
env_init
[ -L $BASEDIR/.config ]  rm -f $BASEDIR/.config
[ -L $BASEDIR/files ]  rm -f $BASEDIR/files
+   [ -L $BASEDIR/patches ]  rm -f $BASEDIR/patches
[ -f $ENVDIR/.config ] || ( cd $ENVDIR/files  find | grep -vE 
'^\.$'  /dev/null )
env_sync_data
if ask_bool 1 Do you want to keep your current config and files; then
mkdir -p $BASEDIR/files
+   mkdir -p $BASEDIR/patches
cp -a $ENVDIR/files/* $BASEDIR/files 2/dev/null /dev/null
+   cp -a $ENVDIR/patches/* $BASEDIR/patches 2/dev/null 
/dev/nul
cp $ENVDIR/.config $BASEDIR/
else
-   rm -rf $BASEDIR/files $BASEDIR/.config
+   rm -rf $BASEDIR/files $BASEDIR/patches $BASEDIR/.config
fi
cd $BASEDIR
rm -rf $ENVDIR
@@ -186,18 +192,22 @@
if ask_bool 0 Do you want to clone the current environment?; 
then
from=$branch
fi
-   rm -f $BASEDIR/.config $BASEDIR/files
+   rm -f $BASEDIR/.config $BASEDIR/files $BASEDIR/patches
fi
git checkout -b $1 $from
-   if [ -f $BASEDIR/.config -o -d $BASEDIR/files ]; then
+   if [ -f $BASEDIR/.config -o -d $BASEDIR/files -o -d 
$BASEDIR/patches ]; then
if ask_bool 1 Do you want to keep your current config and 
files?; then
[ -d $BASEDIR/files -a \! -L $BASEDIR/files ]  {
mv $BASEDIR/files/* $ENVDIR/ 2/dev/null
rmdir $BASEDIR/files
}
+   [ -d $BASEDIR/patches -a \! -L $BASEDIR/patches ] 
 {
+   mv $BASEDIR/patches/* $ENVDIR/ 2/dev/null
+   rmdir $BASEDIR/patches
+   }
env_sync
else
-   rm -rf $BASEDIR/.config $BASEDIR/files
+   rm -rf $BASEDIR/.config $BASEDIR/files 
$BASEDIR/patches
fi
fi
env_link_config


signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] including patches-folder in scripts/env

[Linus Lüssing]

Argh, screw this, don't know why I was thinking that such a folder
might be parsed by the OpenWRT build environment... Sorry for the
inconvenience.


signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] fix madwifi crash in sc_cal_ch timer

[Linus Lüssing]

Yepp Felix, that one fixes ticket #5821 too, can't reproduce that
bug with this patch either. Thanks you two.

Cheers, Linus


signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] add ifplugd

[Linus Lüssing]

This patch adds ifplugd - a 'Network Interface Plug Detection Daemon' - to 
OpenWRT's repository. This lightweight daemon can execute scripts when a cable 
is plugged in or pulled out.

Signed-off-by: Linus Lüssing linus.luess...@web.de

Index: packages/net/ifplugd/Makefile
===
--- packages/net/ifplugd/Makefile   (revision 0)
+++ packages/net/ifplugd/Makefile   (revision 0)
@@ -0,0 +1,29 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ifplugd
+PKG_VERSION:=0.28
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=http://0pointer.de/lennart/projects/ifplugd
+PKG_MD5SUM:=df6f4bab52f46ffd6eb1f5912d4ccee3
+
+PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/ifplugd
+  SECTION:=net
+  CATEGORY:=Network
+  TITLE:=Network Interface Plug Detection Daemon
+  URL:=http://0pointer.de/lennart/projects/ifplugd/
+  DEPENDS:=+libdaemon
+endef
+
+define Package/ifplugd/install
+   install -m0755 -d $(1)/usr/sbin
+   install -m0755 $(PKG_BUILD_DIR)/src/ifplugd $(1)/usr/sbin/
+   install -m0755 $(PKG_BUILD_DIR)/src/ifplugstatus $(1)/usr/sbin/
+endef
+
+$(eval $(call BuildPackage,ifplugd))


signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] add ifplugd

[Linus Lüssing]

By the way, ifplugd compiles and runs fine for me, though the link
detection does not seem to fully work for my Dlink DIR-300
(atheros, ip175c switch chip) yet. The vlans are always shown as
link beat detected, but I don't know what would have to be
patched for that (ip175c driver? swconfig? ifplugd?
kernel-config?). But maybe it's the best to first add ifplugd
to the openwrt trunk and then I could fill out a new ticket
on trac? Or does somebody already have a quick fix :)?

Cheers, Linus


signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] fix madwifi crash in sc_cal_ch timer

[Linus Lüssing]

This patch fixes ticket #5821 for me (though I don't understand
why it does so). I've compiled the exact same firmware, except
one time with and one time without this patch - I'm not able to
reproduce the bug anymore with it.

Cheers, Linus


signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel