[OpenWrt-Devel] ath10k mesh + ap + encryption?
Hi, we have done some experiments last week on ath10k, trying to run mesh (802.11s) and access point at the same time, both encrypted. We have tested a recent LEDE (reboot-1519-g42f559e) but with firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave us a working encrypted 802.11s network. However, starting an AP at the same time didn't work (AP doesn't beacon). This wasn't a problem when 802.11s was running unencrypted. We also tested version 10.2.4.97 (from codeaurora), which is now default in LEDE. However, this version apparently doesn't support 11s mesh at all (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211 advertises support). So here are my questions: * Did anyone succesfully run AP and mesh, both encrypted at the same time? * Do you have any pointers how we could fix this? Could it be fixable in the driver (i.e. not in firmware)? * Does anyone have an idea if 11s will be supported in future versions? I didn't find any changelogs, but having 11s mode no longer in the service map does not make me optimistic. Thanks, Simon signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] UDP throughput problems with WDS and ath10k
Hello, On 23 March 2016 at 10:53, Xue Liu wrote: > Hello everyone, > > Now I am doing point to point throughput test using and ath10k. The > hardwares are clearfog A1 board with armada 388 and WLE900VX (QCA9880). The > OpenWRT trunk is running on it. Could you tell what is the OpenWrt Release and firmware used? I'm using trunk R49886 and tried several versions of firmware and stll can't send traffic trough the WDS link. The link is established, there is a wlan0.sta1, but there is no L3 traffic. Thanks, Bruno > > At first I did UDP throughput test ( WDS AP <---> WDS Client ) with iperf3 > server on the WDS AP. The throughput is approx 630 Mbps. But if the server > sends the data, the throughput will rise to 700 Mbps. I did the > bidirectional test for many times. The UDP data transferring from AP side > always has 70 - 80 Mbps more throughput. > > In the same situation, I did UDP throughput test between PC and WDS AP ( PC > <>WDS Client <> WDS AP ) . The PC is connected with the WDS client > via GbE port. I have found a more interesting result. The data throughput > is about 678 Mbps when the data is transmitted from AP to PC. There is > almost no performance loss. But the throughput is only about 425 Mpbs from > PC to AP. > > Can anyone give me some advises or some info about the reason and how to > improve the transmitting performance from PC to AP side. Thank you. > > Regards, > > Xue Liu > > ___ > ath10k mailing list > ath...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?
Simon Wunderlich writes: > we have done some experiments last week on ath10k, trying to run mesh > (802.11s) and access point at the same time, both encrypted. > > We have tested a recent LEDE (reboot-1519-g42f559e) but with > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave us > a > working encrypted 802.11s network. However, starting an AP at the same time > didn't work (AP doesn't beacon). This wasn't a problem when 802.11s was > running unencrypted. > > We also tested version 10.2.4.97 (from codeaurora), which is now default in > LEDE. However, this version apparently doesn't support 11s mesh at all > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211 > advertises support). > > So here are my questions: > > * Did anyone succesfully run AP and mesh, both encrypted at the same time? > * Do you have any pointers how we could fix this? Could it be fixable in the > driver (i.e. not in firmware)? > * Does anyone have an idea if 11s will be supported in future versions? I > didn't find any changelogs, but having 11s mode no longer in the service map > does not make me optimistic. Why is LEDE using 10.2.4.97? It seems to be a quite old release and I have no knowledge if anyone even tests that firmware branch with ath10k. I recommend to only use firmware releases from ath10k-firmware.git as we use those internally with ath10k. In any case, don't make any assumptions about future from that firmware branch as it's so old. -- Kalle Valo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: add support for Planex VR500.
VR500 is Wired Router. non Wireless.
- 256MiB RAM, 64MiB SPI Flash.
- USB 3.0 x1, USB 2.0 x1
Issue: soft reboot problem. SPI Flash donot exit 4byte address mode.
Signed-off-by: YuheiOKAWA
---
target/linux/ramips/base-files/etc/board.d/01_leds | 3 +-
.../linux/ramips/base-files/etc/board.d/02_network | 5 ++
target/linux/ramips/base-files/etc/diag.sh | 1 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/VR500.dts | 92 ++
target/linux/ramips/image/mt7621.mk| 8 ++
7 files changed, 112 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/VR500.dts
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 460253c..a96b0f0 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -133,7 +133,8 @@ mzk-ex300np)
;;
dir-810l|\
mzk-750dhp|\
-mzk-dp150n)
+mzk-dp150n|\
+vr500)
ucidef_set_led_default "power" "power" "$board:green:power" "1"
;;
ex2700)
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 6157d87..64082df 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -82,6 +82,7 @@ ramips_setup_interfaces()
psg1208|\
sap-g3200u3|\
sk-wb8|\
+ vr500|\
wf-2881|\
whr-300hp2|\
whr-600d|\
@@ -334,6 +335,10 @@ ramips_setup_macs()
lan_mac=$(mtd_get_mac_ascii u-boot-env LAN_MAC_ADDR)
wan_mac=$(mtd_get_mac_ascii u-boot-env WAN_MAC_ADDR)
;;
+ vr500)
+ lan_mac=$(mtd_get_mac_binary factory 57344)
+ wan_mac=$(mtd_get_mac_binary factory 57350)
+ ;;
w306r-v20)
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add "$lan_mac" 5)
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 0c5abb2..1eb726f 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -26,6 +26,7 @@ get_status_led() {
mzk-w300nh2|\
nbg-419n|\
pwh2004|\
+ vr500|\
wnce2001|\
wndr3700v5|\
x5|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 10139d7..cb4d6c8 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -415,6 +415,9 @@ ramips_board_detect() {
*"VoCore")
name="vocore"
;;
+ *"VR500")
+ name="vr500"
+ ;;
*"W150M")
name="w150m"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index e3bea00..9017342 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -122,6 +122,7 @@ platform_check_image() {
ur-336un|\
v22rw-2x2|\
vocore|\
+ vr500|\
w150m|\
w306r-v20|\
w502u|\
diff --git a/target/linux/ramips/dts/VR500.dts
b/target/linux/ramips/dts/VR500.dts
new file mode 100644
index 000..3cddce6
--- /dev/null
+++ b/target/linux/ramips/dts/VR500.dts
@@ -0,0 +1,92 @@
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+/ {
+ compatible = "ralink,mt7621-eval-board", "ralink,mt7621-soc";
+ model = "Planex VR500";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x1000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,57600";
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ power {
+ label = "vr500:green:power";
+ gpios = <&gpio1 13 1>;
+ };
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <20>;
+
+ reset {
+ label = "reset";
+ gpios = <&gpio1 15 1>;
+ linux,code = <0x198>;
+ };
+ };
+};
+
+&xhci {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+
+ m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ linux,modalias = "m25p80";
+ spi-max-frequency = <1000>;
+
+ partition@0 {
+ label = "u-boot";
Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?
On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote: > Simon Wunderlich writes: > > we have done some experiments last week on ath10k, trying to run mesh > > (802.11s) and access point at the same time, both encrypted. > > > > We have tested a recent LEDE (reboot-1519-g42f559e) but with > > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave > > us a working encrypted 802.11s network. However, starting an AP at the > > same time didn't work (AP doesn't beacon). This wasn't a problem when > > 802.11s was running unencrypted. > > > > We also tested version 10.2.4.97 (from codeaurora), which is now default > > in > > LEDE. However, this version apparently doesn't support 11s mesh at all > > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211 > > advertises support). > > > > So here are my questions: > > * Did anyone succesfully run AP and mesh, both encrypted at the same > > time? > > * Do you have any pointers how we could fix this? Could it be fixable in > > the> > > driver (i.e. not in firmware)? > > > > * Does anyone have an idea if 11s will be supported in future versions? I > > > > didn't find any changelogs, but having 11s mode no longer in the service > > map does not make me optimistic. > > Why is LEDE using 10.2.4.97? It seems to be a quite old release and I > have no knowledge if anyone even tests that firmware branch with ath10k. > I recommend to only use firmware releases from ath10k-firmware.git as we > use those internally with ath10k. In any case, don't make any > assumptions about future from that firmware branch as it's so old. This was introduced in December 25th, 2015 after some firmware-related problems. I'm CC'ing Martin Blumenstingl who suggested this change. Since then, ath10k is pulling firmware from here (unless ct firmware is used): https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ 10.2.4/firmware-5.bin_10.2.4.97-1 However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say 10.2.4.70.42-2 is more recent? I would have assumed otherwise from the numbers. However, 10.2.4.70 has much more sub-revisions. Is there any document describing the revisions? I don't understand it at least from this wiki page [1]. Thanks! Simon [1] https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/firmware signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?
Simon Wunderlich writes: > On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote: >> Simon Wunderlich writes: >> > we have done some experiments last week on ath10k, trying to run mesh >> > (802.11s) and access point at the same time, both encrypted. >> > >> > We have tested a recent LEDE (reboot-1519-g42f559e) but with >> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave >> > us a working encrypted 802.11s network. However, starting an AP at the >> > same time didn't work (AP doesn't beacon). This wasn't a problem when >> > 802.11s was running unencrypted. >> > >> > We also tested version 10.2.4.97 (from codeaurora), which is now default >> > in >> > LEDE. However, this version apparently doesn't support 11s mesh at all >> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211 >> > advertises support). >> > >> > So here are my questions: >> > * Did anyone succesfully run AP and mesh, both encrypted at the same >> > time? >> > * Do you have any pointers how we could fix this? Could it be fixable in >> > the> >> > driver (i.e. not in firmware)? >> > >> > * Does anyone have an idea if 11s will be supported in future versions? I >> > >> > didn't find any changelogs, but having 11s mode no longer in the service >> > map does not make me optimistic. >> >> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I >> have no knowledge if anyone even tests that firmware branch with ath10k. >> I recommend to only use firmware releases from ath10k-firmware.git as we >> use those internally with ath10k. In any case, don't make any >> assumptions about future from that firmware branch as it's so old. > > This was introduced in December 25th, 2015 after some firmware-related > problems. I'm CC'ing Martin Blumenstingl who suggested this change. > > Since then, ath10k is pulling firmware from here (unless ct firmware is used): > > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ > 10.2.4/firmware-5.bin_10.2.4.97-1 > > However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say > 10.2.4.70.42-2 is more recent? I would have assumed otherwise from the > numbers. However, 10.2.4.70 has much more sub-revisions. As I said before, I just deliver the firmware files to the community and the firmware team creates the actual releases. But my understanding is that these are from different branches which are built independently (and might have different features, like in this case the mesh support) so I would not make any conclusions if any firmware is "better" just from the numbers alone. -- Kalle Valo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?
On Tuesday, September 13, 2016 11:25:21 AM CEST Valo, Kalle wrote: > Simon Wunderlich writes: > > On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote: > >> Simon Wunderlich writes: > >> > we have done some experiments last week on ath10k, trying to run mesh > >> > (802.11s) and access point at the same time, both encrypted. > >> > > >> > We have tested a recent LEDE (reboot-1519-g42f559e) but with > >> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which > >> > gave > >> > us a working encrypted 802.11s network. However, starting an AP at the > >> > same time didn't work (AP doesn't beacon). This wasn't a problem when > >> > 802.11s was running unencrypted. > >> > > >> > We also tested version 10.2.4.97 (from codeaurora), which is now > >> > default > >> > in > >> > LEDE. However, this version apparently doesn't support 11s mesh at all > >> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211 > >> > advertises support). > >> > > >> > So here are my questions: > >> > * Did anyone succesfully run AP and mesh, both encrypted at the same > >> > time? > >> > * Do you have any pointers how we could fix this? Could it be fixable > >> > in > >> > the> > >> > > >> > driver (i.e. not in firmware)? > >> > > >> > * Does anyone have an idea if 11s will be supported in future > >> > versions? I > >> > > >> > didn't find any changelogs, but having 11s mode no longer in the > >> > service > >> > map does not make me optimistic. > >> > >> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I > >> have no knowledge if anyone even tests that firmware branch with ath10k. > >> I recommend to only use firmware releases from ath10k-firmware.git as we > >> use those internally with ath10k. In any case, don't make any > >> assumptions about future from that firmware branch as it's so old. > > > > This was introduced in December 25th, 2015 after some firmware-related > > problems. I'm CC'ing Martin Blumenstingl who suggested this change. > > > > Since then, ath10k is pulling firmware from here (unless ct firmware is > > used): > > > > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain > > / > > 10.2.4/firmware-5.bin_10.2.4.97-1 > > > > However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you > > say 10.2.4.70.42-2 is more recent? I would have assumed otherwise from > > the numbers. However, 10.2.4.70 has much more sub-revisions. > > As I said before, I just deliver the firmware files to the community and > the firmware team creates the actual releases. But my understanding is > that these are from different branches which are built independently > (and might have different features, like in this case the mesh support) > so I would not make any conclusions if any firmware is "better" just > from the numbers alone. you are right ... those numbers are not a good pointer. I found this repo, and from the checkin dates it looks like 10.2.4.97 is indeed way older (from September 2015) than 10.2.4.70.42 (April 2016): https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/log/10.2.4 I would agree that Changelogs would be helpful. Thanks for the clarification. We will then stick to the 70's branch then. Does anyone have pointers for the other questions? :) I would believe hat many people would be interested in running AP + Mesh encrypted at the same time (at least in the open source community ...). Thanks, Simon signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH netifd 2/3] interface-ip: DNS name server sorting support in resolv.conf.auto
Interface name servers when being written to resolv.conf.auto are sorted
based on the following parameters:
-Primary sorting key is interface dns_metric; name servers having lowest
interface dns_metric are listed first
-Secondary sorting key is interface metric; in case of equal interface
dns_metric name servers having lowest interface metric are listed first
-Finally alphabetical order of the interface names in case of equal
interface dns_metric and metric
In case the resolver queries the multiple servers in the order
listed; sorting is usefull in the following scenarios :
-Name resolving over a main and backup interface
-Assign priority to IPv6 name servers over IPv4 or vice versa
Signed-off-by: Hans Dedecker
---
interface-ip.c | 73 +++---
interface.c| 6 +
interface.h| 1 +
ubus.c | 1 +
4 files changed, 68 insertions(+), 13 deletions(-)
diff --git a/interface-ip.c b/interface-ip.c
index 26a2865..24ea054 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -1197,21 +1197,33 @@ write_resolv_conf_entries(FILE *f, struct
interface_ip_settings *ip, const char
}
}
-void
-interface_write_resolv_conf(void)
+/* Sorting of interface resolver entries : */
+/* Primary on interface dns_metric : lowest metric first */
+/* Secondary on interface metric : lowest metric first */
+/* Finally alphabetical order of interface names */
+static int resolv_conf_iface_cmp(const void *k1, const void *k2, void *ptr)
+{
+ const struct interface *iface1 = k1, *iface2 = k2;
+
+ if (iface1->dns_metric != iface2->dns_metric)
+ return iface1->dns_metric - iface2->dns_metric;
+
+ if (iface1->metric != iface2->metric)
+ return iface1->metric - iface2->metric;
+
+ return strcmp(iface1->name, iface2->name);
+}
+
+static void
+__interface_write_dns_entries(FILE *f)
{
struct interface *iface;
- char *path = alloca(strlen(resolv_conf) + 5);
- FILE *f;
- uint32_t crcold, crcnew;
+ struct {
+ struct avl_node node;
+ } *entry, *n_entry;
+ struct avl_tree resolv_conf_iface_entries;
- sprintf(path, "%s.tmp", resolv_conf);
- unlink(path);
- f = fopen(path, "w+");
- if (!f) {
- D(INTERFACE, "Failed to open %s for writing\n", path);
- return;
- }
+ avl_init(&resolv_conf_iface_entries, resolv_conf_iface_cmp, false,
NULL);
vlist_for_each_element(&interfaces, iface, node) {
if (iface->state != IFS_UP)
@@ -1219,15 +1231,50 @@ interface_write_resolv_conf(void)
if (vlist_simple_empty(&iface->proto_ip.dns_search) &&
vlist_simple_empty(&iface->proto_ip.dns_servers) &&
- vlist_simple_empty(&iface->config_ip.dns_search) &&
+ vlist_simple_empty(&iface->config_ip.dns_search) &&
vlist_simple_empty(&iface->config_ip.dns_servers))
continue;
+ entry = calloc(1, sizeof(*entry));
+ if (!entry)
+ continue;
+
+ entry->node.key = iface;
+ avl_insert(&resolv_conf_iface_entries, &entry->node);
+ }
+
+ avl_for_each_element(&resolv_conf_iface_entries, entry, node) {
+ iface = (struct interface *)entry->node.key;
+
fprintf(f, "# Interface %s\n", iface->name);
+
write_resolv_conf_entries(f, &iface->config_ip, iface->ifname);
+
if (!iface->proto_ip.no_dns)
write_resolv_conf_entries(f, &iface->proto_ip,
iface->ifname);
}
+
+ avl_remove_all_elements(&resolv_conf_iface_entries, entry, node,
n_entry)
+ free(entry);
+}
+
+void
+interface_write_resolv_conf(void)
+{
+ char *path = alloca(strlen(resolv_conf) + 5);
+ FILE *f;
+ uint32_t crcold, crcnew;
+
+ sprintf(path, "%s.tmp", resolv_conf);
+ unlink(path);
+ f = fopen(path, "w+");
+ if (!f) {
+ D(INTERFACE, "Failed to open %s for writing\n", path);
+ return;
+ }
+
+ __interface_write_dns_entries(f);
+
fflush(f);
rewind(f);
crcnew = crc32_file(f);
diff --git a/interface.c b/interface.c
index 71e2ecc..5870422 100644
--- a/interface.c
+++ b/interface.c
@@ -35,6 +35,7 @@ enum {
IFACE_ATTR_PEERDNS,
IFACE_ATTR_DNS,
IFACE_ATTR_DNS_SEARCH,
+ IFACE_ATTR_DNS_METRIC,
IFACE_ATTR_METRIC,
IFACE_ATTR_INTERFACE,
IFACE_ATTR_IP6ASSIGN,
@@ -57,6 +58,7 @@ static const struct blobmsg_policy
iface_attrs[IFACE_ATTR_MAX] = {
[IFACE_ATTR_METRIC] = { .name = "metric", .type = BLOBMSG_TYPE_INT32 },
[IFACE_ATTR_DNS] = { .name = "dns", .type = BLOBMSG_TYPE_ARRAY },
[IFACE_ATTR_DNS_SEARCH] = { .name = "dns_search", .type =
BLOBMSG_TYPE_ARRAY
[OpenWrt-Devel] [PATCH netifd 3/3] interface-event: Don't dequeue hotplug event in case of interface reload event
Dropping hotplug event in case of interface reload results into hotplug scripts not being being run for the interface and thus external actors not being informed about the actual state of the interface. This is clearly visible if the interface auto parameter is set to disabled for multiple interfaces resulting into no hotplug down event for all interfaces. Therefore don't flush the interface hotplug queue in case an interface reload event is observed. Signed-off-by: Hans Dedecker --- interface-event.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/interface-event.c b/interface-event.c index 93da22b..4976c2c 100644 --- a/interface-event.c +++ b/interface-event.c @@ -196,9 +196,10 @@ static void interface_event_cb(struct interface_user *dep, struct interface *ifa interface_queue_event(iface, ev); break; case IFEV_FREE: - case IFEV_RELOAD: interface_dequeue_event(iface); break; + default: + break; } } -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH netifd 1/3] bridge: Allow setting multicast_fast_leave_option
Setting the multicast_fast_leave option of a bridge allows to control
the forwarding of multicast traffic when an IGMP/MLD leave is received.
In case multicast_leave_option is enabled and a leave is received the
multicast membership will immediately be dropped on the bridge port while
in the other case the multicast membership will time out in the bridge.
This could be usefull in scenarios where explicit multicast membership
host tracking is not supported in the upstream network. In this case the
multicast stream is still flowing after a leave is received resulting into
possible bandwidth saturation on the lan if a new stream is joined as
multiple multicast streams are received.
Signed-off-by: Hans Dedecker
---
device.c | 9 +
device.h | 3 +++
system-linux.c | 9 +
3 files changed, 21 insertions(+)
diff --git a/device.c b/device.c
index fa3d00f..d45ce63 100644
--- a/device.c
+++ b/device.c
@@ -51,6 +51,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX]
= {
[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 },
+ [DEV_ATTR_MULTICAST_FAST_LEAVE] = { .name = "multicast_fast_leave", .
type = BLOBMSG_TYPE_BOOL },
[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 },
@@ -184,6 +185,7 @@ 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->multicast_fast_leave = s->multicast_fast_leave;
n->learning = s->learning;
n->unicast_flood = s->unicast_flood;
n->flags = s->flags | os->flags | os->valid_flags;
@@ -304,6 +306,11 @@ device_init_settings(struct device *dev, struct blob_attr
**tb)
DPRINTF("Invalid value: %d - (Use 0: never, 1: learn,
2: always)\n", blobmsg_get_u32(cur));
}
+ if ((cur = tb[DEV_ATTR_MULTICAST_FAST_LEAVE])) {
+ s->multicast_fast_leave = blobmsg_get_bool(cur);
+ s->flags |= DEV_OPT_MULTICAST_FAST_LEAVE;
+ }
+
if ((cur = tb[DEV_ATTR_MULTICAST])) {
s->multicast = blobmsg_get_bool(cur);
s->flags |= DEV_OPT_MULTICAST;
@@ -994,6 +1001,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
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);
+ if (st.flags & DEV_OPT_MULTICAST_FAST_LEAVE)
+ blobmsg_add_u8(b, "multicast_fast_leave",
st.multicast_fast_leave);
if (st.flags & DEV_OPT_MULTICAST)
blobmsg_add_u8(b, "multicast", st.multicast);
if (st.flags & DEV_OPT_LEARNING)
diff --git a/device.h b/device.h
index e13e435..032a8e9 100644
--- a/device.h
+++ b/device.h
@@ -44,6 +44,7 @@ enum {
DEV_ATTR_DADTRANSMITS,
DEV_ATTR_MULTICAST_TO_UNICAST,
DEV_ATTR_MULTICAST_ROUTER,
+ DEV_ATTR_MULTICAST_FAST_LEAVE,
DEV_ATTR_MULTICAST,
DEV_ATTR_LEARNING,
DEV_ATTR_UNICAST_FLOOD,
@@ -94,6 +95,7 @@ enum {
DEV_OPT_LEARNING= (1 << 17),
DEV_OPT_UNICAST_FLOOD = (1 << 18),
DEV_OPT_NEIGHGCSTALETIME= (1 << 19),
+ DEV_OPT_MULTICAST_FAST_LEAVE= (1 << 20),
};
/* events broadcasted to all users of a device */
@@ -156,6 +158,7 @@ struct device_settings {
unsigned int dadtransmits;
bool multicast_to_unicast;
unsigned int multicast_router;
+ bool multicast_fast_leave;
bool multicast;
bool learning;
bool unicast_flood;
diff --git a/system-linux.c b/system-linux.c
index d868c15..6e4a194 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -326,6 +326,11 @@ static void system_bridge_set_multicast_to_unicast(struct
device *dev, const cha
system_set_dev_sysctl("/sys/class/net/%s/brport/multicast_to_unicast",
dev->ifname, val);
}
+static void system_bridge_set_multicast_fast_leave(struct device *dev, const
char *val)
+{
+ system_set_dev_sysctl("/sys/class/net/%s/brport/multicast_fast_leave",
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);
@@ -680,6 +685,10 @@ int system_bridge_addif(struct device *bridge, struct
devic
Re: [OpenWrt-Devel] gen_initramfs_list.sh escaping problem or stale dependency file?
On 09/13/2016 12:24 AM, Michal Marek wrote:
> On Mon, Sep 12, 2016 at 05:12:15PM -0700, Florian Fainelli wrote:
>> Hi,
>>
>> I have a root filesystem embedding filenames that look like these:
>>
>> /lib/data/:
>>
>> these are essentially files that can be matched against an USB
>> vendor/product id in an easy way.
>>
>> Now, the fun part is that this is only a problem when doing the
>> following (using OpenWrt/LEDE as a build system):
>>
>> 1:
>> - set CONFIG_INITRAMFS_SOURCE=""
>> - build kernel modules
>> - build my user-space tools
>> - build the kernel image
>> - reconfigure the kernel to now use an initramfs
>> - build the kernel w/ initramfs
>>
>> and then back to step 1 with the kernel build, would I hit this error:
>>
>> usr/Makefile:64: *** multiple target patterns. Stop.
> [...]
>> Which sorts of make sense here because the file name contains a ":"
>> which is not escaped, so GNU Make tries to interpret it.
>>
>> Now the part that does not quite make sense to me is why this file is
>> even relevant here considering that the first thing we do is set
>> CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.
>
> It is possible that we read usr/Makefile twice for some reason. But the
> real problem is the lack of escaping. Can you try the following
> (untested) patch?
This patch works for me:
Tested-by: Florian Fainelli
Kind of surprising that this has not showed up before, but maybe people
don't really go through the same steps while re-configuring/re-building
their kernels
Thanks Michal!
>
>
> diff --git a/scripts/gen_initramfs_list.sh b/scripts/gen_initramfs_list.sh
> index 17fa901418ae..5d3188e74101 100755
> --- a/scripts/gen_initramfs_list.sh
> +++ b/scripts/gen_initramfs_list.sh
> @@ -97,7 +97,10 @@ print_mtime() {
> }
>
> list_parse() {
> - [ ! -L "$1" ] && echo "$1 \\" || :
> + if [ -L "$1" ]; then
> + return
> + fi
> + echo "$1" | sed 's/\([:%]\)/\\\1/g; s/$/ \\/'
> }
>
> # for each file print a line in following format
>
> Thanks,
> Michal
>
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k mesh + ap + encryption?
Hi Simon, On Tue, Sep 13, 2016 at 1:13 PM, Simon Wunderlich wrote: > On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote: >> Simon Wunderlich writes: >> > we have done some experiments last week on ath10k, trying to run mesh >> > (802.11s) and access point at the same time, both encrypted. >> > >> > We have tested a recent LEDE (reboot-1519-g42f559e) but with >> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave >> > us a working encrypted 802.11s network. However, starting an AP at the >> > same time didn't work (AP doesn't beacon). This wasn't a problem when >> > 802.11s was running unencrypted. >> > >> > We also tested version 10.2.4.97 (from codeaurora), which is now default >> > in >> > LEDE. However, this version apparently doesn't support 11s mesh at all >> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211 >> > advertises support). >> > >> > So here are my questions: >> > * Did anyone succesfully run AP and mesh, both encrypted at the same >> > time? >> > * Do you have any pointers how we could fix this? Could it be fixable in >> > the> >> > driver (i.e. not in firmware)? >> > >> > * Does anyone have an idea if 11s will be supported in future versions? I >> > >> > didn't find any changelogs, but having 11s mode no longer in the service >> > map does not make me optimistic. >> >> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I >> have no knowledge if anyone even tests that firmware branch with ath10k. >> I recommend to only use firmware releases from ath10k-firmware.git as we >> use those internally with ath10k. In any case, don't make any >> assumptions about future from that firmware branch as it's so old. Thanks for clarifying this. > This was introduced in December 25th, 2015 after some firmware-related > problems. I'm CC'ing Martin Blumenstingl who suggested this change. > > Since then, ath10k is pulling firmware from here (unless ct firmware is used): > > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ > 10.2.4/firmware-5.bin_10.2.4.97-1 I initially updated to version 10.2.4.70.13-2, but we decided to update to the "latest" firmware back then (see the thread at [0]) With the explanation from Kalle it makes sense to only use the firmware binaries distributed in his repo (to ensure that the firmware is tested by QCA's internal team). > However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say > 10.2.4.70.42-2 is more recent? I would have assumed otherwise from the > numbers. That looks strange to me as well as a side-note: I am currently preparing and testing a patch to update the ath10k-firmware in LEDE to 10.2.4.70.52 Regards, Martin [0] https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg35623.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt Summit Session Announcements
All, I wanted to let everyone know that the sessions for OpenWrt Summit have been announced and are listed at http://openwrtsummit.org. We have a really broad range of sessions this year that address both the technical and industry sides of the OpenWrt/LEDE communities. I think I can speak for the rest of the summit committee-members when I say that we're very excited by our list of sessions. This will be great chance to meet in person with others who are using or involved with OpenWrt or LEDE. I encourage everyone to check out the session list and consider joining us in Berlin on October 13. It's free to attend, we only ask that you register ahead of time at http://openwrtsummit.org. I look forward to seeing everyone there! Eric Schultz, Chair, on behalf of the OpenWrt Summit Committee: Abhijit Mahajani Beda Kosata Eric Schultz Federico Capoano Hans Dedecker Hauke Mehrtens Imre Kaloz Kathy Giori Luka Perkov Paul Blay Zoltan Herpai -- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org eschu...@prplfoundation.org cell: 920-539-0404 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
