[OpenWrt-Devel] [PATCH] samba36: add three CVE patches from 2015-12-16
This is a patch for CVE-2015-5252, CVE-2015-5296 and CVE-2015-5299. A
patchset for these vulnerabilities was published on 16th December 2015.
Signed-off-by: Jan Čermák
---
package/network/services/samba36/Makefile | 2 +-
.../samba36/patches/010-patch-cve-2015-5252.patch | 43
.../samba36/patches/011-patch-cve-2015-5296.patch | 112 +
.../samba36/patches/012-patch-cve-2015-5299.patch | 97 ++
4 files changed, 253 insertions(+), 1 deletion(-)
create mode 100644
package/network/services/samba36/patches/010-patch-cve-2015-5252.patch
create mode 100644
package/network/services/samba36/patches/011-patch-cve-2015-5296.patch
create mode 100644
package/network/services/samba36/patches/012-patch-cve-2015-5299.patch
diff --git a/package/network/services/samba36/Makefile
b/package/network/services/samba36/Makefile
index 9e282f0..7b571a4 100644
--- a/package/network/services/samba36/Makefile
+++ b/package/network/services/samba36/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=samba
PKG_VERSION:=3.6.25
-PKG_RELEASE:=4
+PKG_RELEASE:=5
PKG_SOURCE_URL:=http://ftp.samba.org/pub/samba \
http://ftp.samba.org/pub/samba/stable
diff --git
a/package/network/services/samba36/patches/010-patch-cve-2015-5252.patch
b/package/network/services/samba36/patches/010-patch-cve-2015-5252.patch
new file mode 100644
index 000..8922a6e
--- /dev/null
+++ b/package/network/services/samba36/patches/010-patch-cve-2015-5252.patch
@@ -0,0 +1,43 @@
+From 2e94b6ec10f1d15e24867bab3063bb85f173406a Mon Sep 17 00:00:00 2001
+From: Jeremy Allison
+Date: Thu, 9 Jul 2015 10:58:11 -0700
+Subject: [PATCH] CVE-2015-5252: s3: smbd: Fix symlink verification (file
+ access outside the share).
+
+Ensure matching component ends in '/' or '\0'.
+
+BUG: https://bugzilla.samba.org/show_bug.cgi?id=11395
+
+Signed-off-by: Jeremy Allison
+Reviewed-by: Volker Lendecke
+---
+ source3/smbd/vfs.c | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/source3/smbd/vfs.c b/source3/smbd/vfs.c
+index 6c56964..bd93b7f 100644
+--- a/source3/smbd/vfs.c
b/source3/smbd/vfs.c
+@@ -982,6 +982,7 @@ NTSTATUS check_reduced_name(connection_struct *conn, const
char *fname)
+ if (!allow_widelinks || !allow_symlinks) {
+ const char *conn_rootdir;
+ size_t rootdir_len;
++ bool matched;
+
+ conn_rootdir = SMB_VFS_CONNECTPATH(conn, fname);
+ if (conn_rootdir == NULL) {
+@@ -992,8 +993,10 @@ NTSTATUS check_reduced_name(connection_struct *conn,
const char *fname)
+ }
+
+ rootdir_len = strlen(conn_rootdir);
+- if (strncmp(conn_rootdir, resolved_name,
+- rootdir_len) != 0) {
++ matched = (strncmp(conn_rootdir, resolved_name,
++ rootdir_len) == 0);
++ if (!matched || (resolved_name[rootdir_len] != '/' &&
++ resolved_name[rootdir_len] != '\0')) {
+ DEBUG(2, ("check_reduced_name: Bad access "
+ "attempt: %s is a symlink outside the "
+ "share path\n", fname));
+--
+2.5.0
diff --git
a/package/network/services/samba36/patches/011-patch-cve-2015-5296.patch
b/package/network/services/samba36/patches/011-patch-cve-2015-5296.patch
new file mode 100644
index 000..eaafd1c
--- /dev/null
+++ b/package/network/services/samba36/patches/011-patch-cve-2015-5296.patch
@@ -0,0 +1,112 @@
+From 25139116756cc285a3a5534834cc276ef1b7baaa Mon Sep 17 00:00:00 2001
+From: Stefan Metzmacher
+Date: Wed, 30 Sep 2015 21:17:02 +0200
+Subject: [PATCH 1/2] CVE-2015-5296: s3:libsmb: force signing when requiring
+ encryption in do_connect()
+
+BUG: https://bugzilla.samba.org/show_bug.cgi?id=11536
+
+Signed-off-by: Stefan Metzmacher
+Reviewed-by: Jeremy Allison
+---
+ source3/libsmb/clidfs.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/source3/libsmb/clidfs.c b/source3/libsmb/clidfs.c
+index 23e1471..f153b6b 100644
+--- a/source3/libsmb/clidfs.c
b/source3/libsmb/clidfs.c
+@@ -98,6 +98,11 @@ static struct cli_state *do_connect(TALLOC_CTX *ctx,
+ const char *username;
+ const char *password;
+ NTSTATUS status;
++ int signing_state = get_cmdline_auth_info_signing_state(auth_info);
++
++ if (force_encrypt) {
++ signing_state = Required;
++ }
+
+ /* make a copy so we don't modify the global string 'service' */
+ servicename = talloc_strdup(ctx,share);
+@@ -132,7 +137,7 @@ static struct cli_state *do_connect(TALLOC_CTX *ctx,
+ zero_sockaddr(&ss);
+
+ /* have to open a new connection */
+- c = cli_initialise_ex(get_cmdline_auth_info_signing_state(auth_info));
++ c = cli_initialise_ex(signing_state);
+ if (c == NULL) {
+ d_printf("Connection to %s fai
Re: [OpenWrt-Devel] [PATCH] use NTP server received via DHCP
Happy new year! Thanks for the explanation, I will be sending a new patch today. Regards, Amine. On Wed, Dec 30, 2015 at 2:14 PM, Yousong Zhou wrote: > Hi, > > On 30 December 2015 at 20:12, Amine Aouled Hamed > wrote: > > > > Hi, > > Can you elaborate more on why you prefer uci state? I am just starting > with OpenWRT and the first thing I found was procd. > > > > Most of it is really just personal preference. I prefer uci because > it can provide more structured access/manipulation of the state, e.g. > > - disable those ntpservers on interface down > - when it comes to ntpservers from multiple dhcp interfaces > - the state can be easily checked with uci command if something went wrong > > These can of course also be done with procd data, but uci is already > there... > > Regards, > yousong > -- Amine Hamed | Software Engineer Ocedo GmbH | Hirschstrasse 7 | 76133 Karlsruhe | Germany Email aha...@ocedo.com REGISTERED OFFICE: KARLSRUHE | DISTRICT COURT: MANNHEIM | REGISTER NUMBER: HRB 717873 MANAGING DIRECTOR: MARKUS HENNIG|JAN HICHERT ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] procd: emit events for sound subsystem
Useful e.g. for plugable USB-soundcards. With this change an event/hotplug-call looks like: ACTION: add DEVNAME: snd/timer DEVPATH: /devices/virtual/sound/timer SUBSYSTEM: sound ACTION: add DEVNAME: DEVPATH: /devices/platform/ehci-platform/usb1/1-1/1-1:1.0/sound/card0 SUBSYSTEM: sound ACTION: add DEVNAME: snd/controlC0 DEVPATH: /devices/platform/ehci-platform/usb1/1-1/1-1:1.0/sound/card0/controlC0 SUBSYSTEM: sound ACTION: add DEVNAME: snd/pcmC0D0p DEVPATH: /devices/platform/ehci-platform/usb1/1-1/1-1:1.0/sound/card0/pcmC0D0p SUBSYSTEM: sound ACTION: add DEVNAME: snd/pcmC0D0c DEVPATH: /devices/platform/ehci-platform/usb1/1-1/1-1:1.0/sound/card0/pcmC0D0c SUBSYSTEM: sound ACTION: add DEVNAME: dsp DEVPATH: /devices/platform/ehci-platform/usb1/1-1/1-1:1.0/sound/card0/dsp SUBSYSTEM: sound ACTION: add DEVNAME: audio DEVPATH: /devices/platform/ehci-platform/usb1/1-1/1-1:1.0/sound/card0/audio SUBSYSTEM: sound ACTION: add DEVNAME: mixer DEVPATH: /devices/platform/ehci-platform/usb1/1-1/1-1:1.0/sound/card0/mixer SUBSYSTEM: sound This fixes #21466. Signed-off-by: Bastian Bittorf --- package/system/procd/files/hotplug.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/system/procd/files/hotplug.json b/package/system/procd/files/hotplug.json index 27b4836..516a122 100644 --- a/package/system/procd/files/hotplug.json +++ b/package/system/procd/files/hotplug.json @@ -70,7 +70,7 @@ ], [ "if", [ "eq", "SUBSYSTEM", - [ "net", "input", "usb", "usbmisc", "ieee1394", "block", "atm", "zaptel", "tty", "button" ] + [ "net", "input", "usb", "usbmisc", "ieee1394", "block", "atm", "zaptel", "tty", "button", "sound" ] ], [ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ] ], -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] use NTP server received via DHCP
Hi, please do not use uci state for new features, we consider uci state variables to be deprecated. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] Support for Ubiquiti UniFi AP AC LITE
> On 2016-01-03 22:30, Felix Fietkau wrote: > The additions to the mach file in the patch seem to be free of > dependencies on definitions from other ubnt boards - please move them to > a new mach-*.c file instead of patching them in. > > - Felix > Ah, ok. Then where should the changes to the mach-file go? Is /target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-unifiac.c ok? The intention to include it into the existing one arised, as all ubnt-devices are in just two mach-files. However, I've just noticed that for e.g. TP-Link devices nearly every device has its own mach-file. -- P.Wassi ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Need help with Makefile error *** missing separator
Hi.I not quite understand.I've change the install part as below: define Package/openwrt-dist-luci/install #!/bin/sh $(INSTALL_DIR) $(1)/usr/lib/lua/luci/controller $(INSTALL_DATA) ./files/luci/controller/$(2).lua $(1)/usr/lib/lua/luci/controller/$(2).lua $(INSTALL_DIR) $(1)/usr/lib/lua/luci/model/cbi $(INSTALL_DATA) ./files/luci/model/cbi/$(2).lua $(1)/usr/lib/lua/luci/model/cbi/$(2).lua $(INSTALL_DIR) $(1)/etc/uci-defaults $(INSTALL_BIN) ./files/root/etc/uci-defaults/luci-$(2) $(1)/etc/uci-defaults/luci-$(2) if [ -f "./files/luci/i18n/$(2).zh-cn.lmo" ]; then $(INSTALL_DIR) $(1)/usr/lib/lua/luci/i18n $(INSTALL_DATA) ./files/luci/i18n/$(2).zh-cn.lmo $(1)/usr/lib/lua/luci/i18n fi exit 0 endef Notice the if then course. Here is the error now. if [ -f "./files/luci/i18n/chinadns.zh-cn.lmo" ]; then install -d -m0755 /home/Openwrt/witi-openwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/usr/lib/lua/luci/i18n install -m0644 ./files/luci/i18n/chinadns.zh-cn.lmo /home/Openwrt/witi-openwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/usr/lib/lua/luci/i18n fi bash: -c: line 1: syntax error: unexpected end of file make[2]: *** [/home/Openwrt/witi-openwrt/bin/ramips/packages/base/luci-app-chinadns_1.3.8-1_all.ipk] Error 1 make[2]: Leaving directory `/home/Openwrt/witi-openwrt/package/my_package/openwrt-dist-luci' make[1]: *** [package/my_package/openwrt-dist-luci/compile] Error 2 make[1]: Leaving directory `/homeOpenwrt/witi-openwrt' make: *** [package/openwrt-dist-luci/compile] 错误 2 At 2016-01-04 22:28:36, "Luiz Angelo Daros de Luca" wrote: Andy, Make runs one line per time. Make the "if" inline or backslash each newline (adding semicolon when needed) Regards Em seg, 4 de jan de 2016 11:56, Andy Wong escreveu: For no misunderstanding.Here is the error now http://pastebin.com/t4Rb08kA 在 2016-01-04 21:18:14，"Andy Wong" 写道： >Thanks.I have indented like this：define >Package/openwrt-dist-luci/install#!/bin/sh $(INSTALL_DIR) >$(1)/usr/lib/lua/luci/controller$(INSTALL_DATA) >./files/luci/controller/$(2).lua >$(1)/usr/lib/lua/luci/controller/$(2).lua $(INSTALL_DIR) >$(1)/usr/lib/lua/luci/model/cbi $(INSTALL_DATA) >./files/luci/model/cbi/$(2).lua $(1)/usr/lib/lua/luci/model/cbi/$(2).lua > $(INSTALL_DIR) $(1)/etc/uci-defaults $(INSTALL_BIN) >./files/root/etc/uci-defaults/luci-$(2) $(1)/etc/uci-defaults/luci-$(2) > if [ -f "./files/luci/i18n/$(2).zh-cn.lmo" ]; then $(INSTALL_DIR) >$(1)/usr/lib/lua/luci/i18n $(INSTALL_DATA) >./files/luci/i18n/$(2).zh-cn.lmo $(1)/usr/lib/lua/luci/i18n >fiendefBut another error >appears:enwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/etc/uci-defaults/luci-chinadnsif > [ -f "./files/luci/i18n/chinadns.zh-cn.lmo" ]; thenbash: -c: line 1: >syntax error: unexpected end of filemake[2]: *** >[/home/Openwrt/witi-openwrt/bin/ramips/packages/base/luci-app-chinadns_1.3.8-1_all.ipk] > Error 1make[2]: Leaving directory >`/home/Openwrt/witi-openwrt/package/my_package/openwrt-dist-luci'make[1]: >*** [package/my_package/openwrt-dist-luci/compile] Error 2make[1]: >Leaving directory `/home/Openwrt/witi-openwrt'make: *** >[package/openwrt-dist-luci/compile] 错误 2My if,then course is >intending to find out if *.zh-cn.lmo exist,then install it. >At 2016-01-04 20:20:00, "Jo-Philipp Wich" wrote: >>Hi. >> >>Lines in the isntall section must be indented with at least one tab >>since they're shell instructions. >> >>~ Jow >>___ >>openwrt-devel mailing list >>openwrt-devel@lists.openwrt.org >>https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Luiz Angelo Daros de Luca luizl...@gmail.com___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Need help with Makefile error *** missing separator
Hi On 5 January 2016 at 17:41, Andy Wong wrote: > Hi.I not quite understand.I've change the install part as below: > > define Package/openwrt-dist-luci/install > #!/bin/sh > $(INSTALL_DIR) $(1)/usr/lib/lua/luci/controller > $(INSTALL_DATA) ./files/luci/controller/$(2).lua > $(1)/usr/lib/lua/luci/controller/$(2).lua > $(INSTALL_DIR) $(1)/usr/lib/lua/luci/model/cbi > $(INSTALL_DATA) ./files/luci/model/cbi/$(2).lua > $(1)/usr/lib/lua/luci/model/cbi/$(2).lua > $(INSTALL_DIR) $(1)/etc/uci-defaults > $(INSTALL_BIN) ./files/root/etc/uci-defaults/luci-$(2) > $(1)/etc/uci-defaults/luci-$(2) > if [ -f "./files/luci/i18n/$(2).zh-cn.lmo" ]; then > $(INSTALL_DIR) $(1)/usr/lib/lua/luci/i18n > $(INSTALL_DATA) ./files/luci/i18n/$(2).zh-cn.lmo > $(1)/usr/lib/lua/luci/i18n > fi > exit 0 > endef > > Notice the if then course. > > Here is the error now. > > if [ -f "./files/luci/i18n/chinadns.zh-cn.lmo" ]; then install -d -m0755 > /home/Openwrt/witi-openwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/usr/lib/lua/luci/i18n > install -m0644 ./files/luci/i18n/chinadns.zh-cn.lmo > /home/Openwrt/witi-openwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/usr/lib/lua/luci/i18n > fi > bash: -c: line 1: syntax error: unexpected end of file > make[2]: *** > [/home/Openwrt/witi-openwrt/bin/ramips/packages/base/luci-app-chinadns_1.3.8-1_all.ipk] > Error 1 > make[2]: Leaving directory > `/home/Openwrt/witi-openwrt/package/my_package/openwrt-dist-luci' > make[1]: *** [package/my_package/openwrt-dist-luci/compile] Error 2 > make[1]: Leaving directory `/homeOpenwrt/witi-openwrt' > make: *** [package/openwrt-dist-luci/compile] 错误 2 > Not quite sure about this, but you can try adding semicolons at the end of each command inside the if ; then .. fi block BTW. This is not OpenWrt specific. Try making a minimal Makefile and experiment with it. yousong > > > > At 2016-01-04 22:28:36, "Luiz Angelo Daros de Luca" > wrote: > > Andy, > > Make runs one line per time. Make the "if" inline or backslash each newline > (adding semicolon when needed) > > Regards > > > Em seg, 4 de jan de 2016 11:56, Andy Wong escreveu: >> >> >> For no misunderstanding.Here is the error now >> http://pastebin.com/t4Rb08kA >> >> >> >> >> >> >> 在 2016-01-04 21:18:14，"Andy Wong" 写道： >> >Thanks.I have indented like this：define >> > Package/openwrt-dist-luci/install#!/bin/sh $(INSTALL_DIR) >> > $(1)/usr/lib/lua/luci/controller $(INSTALL_DATA) >> > ./files/luci/controller/$(2).lua >> > $(1)/usr/lib/lua/luci/controller/$(2).lua $(INSTALL_DIR) >> > $(1)/usr/lib/lua/luci/model/cbi $(INSTALL_DATA) >> > ./files/luci/model/cbi/$(2).lua >> > $(1)/usr/lib/lua/luci/model/cbi/$(2).lua $(INSTALL_DIR) >> > $(1)/etc/uci-defaults $(INSTALL_BIN) >> > ./files/root/etc/uci-defaults/luci-$(2) >> > $(1)/etc/uci-defaults/luci-$(2) if [ -f >> > "./files/luci/i18n/$(2).zh-cn.lmo" ]; then $(INSTALL_DIR) >> > $(1)/usr/lib/lua/luci/i18n $(INSTALL_DATA) >> > ./files/luci/i18n/$(2).zh-cn.lmo >> > $(1)/usr/lib/lua/luci/i18n fiendefBut another error >> > appears:enwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/etc/uci-defaults/luci-chinadnsif >> > [ -f "./files/luci/i18n/chinadns.zh-cn.lmo" ]; thenbash: -c: line 1: >> > syntax error: unexpected end of filemake[2]: *** >> > [/home/Openwrt/witi-openwrt/bin/ramips/packages/base/luci-app-chinadns_1.3.8-1_all.ipk] >> > Error 1make[2]: Leaving directory >> > `/home/Openwrt/witi-openwrt/package/my_package/openwrt-dist-luci'make[1]: >> > *** [package/my_package/openwrt-dist-luci/compile] Error 2make[1]: >> > Leaving directory `/home/Openwrt/witi-openwrt'make: *** >> > [package/openwrt-dist-luci/compile] 错误 2My if,then course is >> > intending to find out if *.zh-cn.lmo exist,then install it. >> >At 2016-01-04 20:20:00, "Jo-Philipp Wich" wrote: >> >>Hi. >> >> >> >>Lines in the isntall section must be indented with at least one tab >> >>since they're shell instructions. >> >> >> >>~ Jow >> >>___ >> >>openwrt-devel mailing list >> >>openwrt-devel@lists.openwrt.org >> >>https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> >___ >> >openwrt-devel mailing list >> >openwrt-devel@lists.openwrt.org >> >https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> >> >> >> >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > -- > > Luiz Angelo Daros de Luca > luizl...@gmail.com > > > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-dev
Re: [OpenWrt-Devel] [PATCH] [ar71xx] Support for Ubiquiti UniFi AP AC LITE
On 2016-01-05 10:37, p.wa...@gmx.at wrote: >> On 2016-01-03 22:30, Felix Fietkau wrote: >> The additions to the mach file in the patch seem to be free of >> dependencies on definitions from other ubnt boards - please move them to >> a new mach-*.c file instead of patching them in. >> >> - Felix >> > > Ah, ok. Then where should the changes to the mach-file go? > Is /target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-unifiac.c ok? > The intention to include it into the existing one arised, as all ubnt-devices > are in just two mach-files. However, I've just noticed that for e.g. TP-Link > devices nearly every device has its own mach-file. People just kept adding to the ubnt mach file because there was something there already (and there was some code sharing too), whereas other devices were usually kept separate anyway. I'd like to make sure that all future devices get their own mach files, since that's easier to maintain. At some point, all of this mess is going away anyway when we get proper device tree support. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Need help with Makefile error *** missing separator
Each line in Make is started in a new shell. Your added lines are
executed as (simplified):
bash -c 'if [ -f "./files/luci/i18n/$(2).zh-cn.lmo" ]; then'
bash -c '$(INSTALL_DIR) $(1)/usr/lib/lua/luci/i18n'
bash -c '$(INSTALL_DATA) ./files/luci/i18n/$(2).zh-cn.lmo
$(1)/usr/lib/lua/luci/i18n'
bash -c 'fi'
The first "if" command is invalid because it is not terminated
("unexpected end of file") and the single "fi" command in the end is
invalid syntax as well (preceding if ... then missing).
You need to join your four lines into a single statement by escaping
the newline with a backslash and by terminating statements with a
semicolon:
> if [ -f "./files/luci/i18n/$(2).zh-cn.lmo" ]; then \
> $(INSTALL_DIR) $(1)/usr/lib/lua/luci/i18n; \
> $(INSTALL_DATA) ./files/luci/i18n/$(2).zh-cn.lmo
> $(1)/usr/lib/lua/luci/i18n; \
> fi
Which will result in (simplified)
bash -c 'if [ -f "./files/luci/i18n/$(2).zh-cn.lmo" ]; then $(INSTALL_DIR)
$(1)/usr/lib/lua/luci/i18n; $(INSTALL_DATA) ./files/luci/i18n/$(2).zh-cn.lmo
$(1)/usr/lib/lua/luci/i18n; fi'
~ Jow
On 01/05/2016 10:41 AM, Andy Wong wrote:
> Hi.I not quite understand.I've change the install part as below:
>
> define Package/openwrt-dist-luci/install
> #!/bin/sh
> $(INSTALL_DIR) $(1)/usr/lib/lua/luci/controller
> $(INSTALL_DATA) ./files/luci/controller/$(2).lua
> $(1)/usr/lib/lua/luci/controller/$(2).lua
> $(INSTALL_DIR) $(1)/usr/lib/lua/luci/model/cbi
> $(INSTALL_DATA) ./files/luci/model/cbi/$(2).lua
> $(1)/usr/lib/lua/luci/model/cbi/$(2).lua
> $(INSTALL_DIR) $(1)/etc/uci-defaults
> $(INSTALL_BIN) ./files/root/etc/uci-defaults/luci-$(2)
> $(1)/etc/uci-defaults/luci-$(2)
> *if [ -f "./files/luci/i18n/$(2).zh-cn.lmo" ]; then*
> *$(INSTALL_DIR) $(1)/usr/lib/lua/luci/i18n*
> *$(INSTALL_DATA) ./files/luci/i18n/$(2).zh-cn.lmo
> $(1)/usr/lib/lua/luci/i18n*
> *fi*
> exit 0
> endef
>
> Notice the if then course.
>
> Here is the error now.
>
> if [ -f "./files/luci/i18n/chinadns.zh-cn.lmo" ]; then install -d -m0755
> /home/Openwrt/witi-openwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/usr/lib/lua/luci/i18n
> install -m0644 ./files/luci/i18n/chinadns.zh-cn.lmo
> /home/Openwrt/witi-openwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/usr/lib/lua/luci/i18n
> fi
> bash: -c: line 1: syntax error: unexpected end of file
> make[2]: ***
> [/home/Openwrt/witi-openwrt/bin/ramips/packages/base/luci-app-chinadns_1.3.8-1_all.ipk]
> Error 1
> make[2]: Leaving directory
> `/home/Openwrt/witi-openwrt/package/my_package/openwrt-dist-luci'
> make[1]: *** [package/my_package/openwrt-dist-luci/compile] Error 2
> make[1]: Leaving directory `/homeOpenwrt/witi-openwrt'
> make: *** [package/openwrt-dist-luci/compile] 错误 2
>
>
>
>
> At 2016-01-04 22:28:36, "Luiz Angelo Daros de Luca"
> wrote:
>
> Andy,
>
> Make runs one line per time. Make the "if" inline or backslash each
> newline (adding semicolon when needed)
>
> Regards
>
>
> Em seg, 4 de jan de 2016 11:56, Andy Wong > escreveu:
>
>
> For no misunderstanding.Here is the error now
> http://pastebin.com/t4Rb08kA
>
>
>
>
>
>
> 在 2016-01-04 21:18:14，"Andy Wong" > 写道：
> >Thanks.I have indented like this：define
> Package/openwrt-dist-luci/install#!/bin/sh$(INSTALL_DIR)
> $(1)/usr/lib/lua/luci/controller$(INSTALL_DATA)
> ./files/luci/controller/$(2).lua
> $(1)/usr/lib/lua/luci/controller/$(2).lua $(INSTALL_DIR)
> $(1)/usr/lib/lua/luci/model/cbi $(INSTALL_DATA)
> ./files/luci/model/cbi/$(2).lua $(1)/usr/lib/lua/luci/model/cbi/$(2).lua
> $(INSTALL_DIR) $(1)/etc/uci-defaults $(INSTALL_BIN)
> ./files/root/etc/uci-defaults/luci-$(2) $(1)/etc/uci-defaults/luci-$(2)
>if [ -f "./files/luci/i18n/$(2).zh-cn.lmo" ]; then $(INSTALL_DIR)
> $(1)/usr/lib/lua/luci/i18n $(INSTALL_DATA)
> ./files/luci/i18n/$(2).zh-cn.lmo $(1)/usr/lib/lua/luci/i18n
> fiendefBut another error
> appears:enwrt/build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/openwrt-dist-luci/ipkg-all/luci-app-chinadns/etc/uci-defaults/luci-chinadnsif
> [ -f "./files/luci/i18n/chinadns.zh-cn.lmo" ]; thenbash: -c: line 1:
> syntax e
r
ror: unexpected end of filemake[2]: ***
[/home/Openwrt/witi-openwrt/bin/ramips/packages/base/luci-app-chinadns_1.3.8-1_all.ipk]
Error 1make[2]: Leaving directory
`/home/Openwrt/witi-openwrt/package/my_package/openwrt-dist-luci'make[1]:
*** [package/my_package/openwrt-dist-luci/compile] Error 2make[1]: Leaving
directory `/home/Openwrt/witi-openwrt'make: ***
[package/openwrt-dist-luci/compile] 错误 2My if,then course is
intending to find out if *.zh-cn.lmo exist,then install it.
> >At 2016-01-04 20:20:00, "Jo-Philipp Wich" > wrote:
> >>Hi.
> >>
> >>Lin
[OpenWrt-Devel] [PATCH] dnsmasq: add host-specific lease time option for static hosts
Enable setting a host-specific lease time for static hosts.
The new option is called "leasetime" and the format is similar
as for the default lease time: e.g. 12h, 3d, infinite
Default lease time is used for all hosts for which there is
no host-specific definition.
The option is added to /etc/config/dhcp for the selected hosts:
config host
option name 'Nexus'
option mac 'd8:50:66:55:59:7c'
option ip '192.168.1.245'
option leasetime '2h'
It gets appended to /var/etc/dnsmasq.conf like this:
dhcp-host=d8:50:66:55:59:7c,192.168.1.245,Nexus,2h
Signed-off-by: Hannu Nyman
---
Reference to discussion at https://patchwork.ozlabs.org/patch/561694/
I have included this option in my own build for the last 4 years.
(Ever since I tried to submit it via https://dev.openwrt.org/ticket/11227 )
I have also the Luci part ready.
package/network/services/dnsmasq/Makefile | 4 ++--
package/network/services/dnsmasq/files/dnsmasq.init | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/package/network/services/dnsmasq/Makefile
b/package/network/services/dnsmasq/Makefile
index cddde5c..530d33d 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -1,5 +1,5 @@
#
-# Copyright (C) 2006-2015 OpenWrt.org
+# Copyright (C) 2006-2016 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=dnsmasq
PKG_VERSION:=2.75
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 3ef2b3d..f89bd8c 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -334,7 +334,9 @@ dhcp_host_add() {
config_get_bool broadcast "$cfg" broadcast 0
[ "$broadcast" = "0" ] && broadcast=
- xappend
"--dhcp-host=$macs${networkid:+,net:$networkid}${broadcast:+,set:needs-broadcast}${tag:+,set:$tag}${ip:+,$ip}${name:+,$name}"
+ config_get leasetime "$cfg" leasetime
+
+ xappend
"--dhcp-host=$macs${networkid:+,net:$networkid}${broadcast:+,set:needs-broadcast}${tag:+,set:$tag}${ip:+,$ip}${name:+,$name}${leasetime:+,$leasetime}"
}
dhcp_tag_add() {
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] add UCI option for leasetime per static host
Felix Fietkau wrote at Sun Jan 3 21:19:20 CET 2016: > On 2015-12-30 06:28, ufomanfred at freaktose.net wrote: > > Hi guys, > > > > I wanted to use this feature and decided to figure out how to commit to the > > ... > Patch is still broken (line wrapped). > Also, the subject should have a proper prefix, e.g. 'dnsmasq:' and > ... Jumping into the discussion: I had a similar patch ready in my own build, so I submitted a hopefully correct version as https://patchwork.ozlabs.org/patch/563051/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: set mips16 support
2016-01-04 13:02 GMT+01:00, Cristian Morales Vega : > Signed-off-by: Cristian Morales Vega > --- > target/linux/ramips/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/ramips/Makefile b/target/linux/ramips/Makefile > index 9d7bb5b..378e2f5 100644 > --- a/target/linux/ramips/Makefile > +++ b/target/linux/ramips/Makefile > @@ -10,7 +10,7 @@ ARCH:=mipsel > BOARD:=ramips > BOARDNAME:=Ralink RT288x/RT3xxx > SUBTARGETS:=rt305x mt7620 mt7621 mt7628 mt7688 rt3883 rt288x > -FEATURES:=squashfs gpio > +FEATURES:=squashfs gpio mips16 > MAINTAINER:=John Crispin > > KERNEL_PATCHVER:=4.3 > -- > 2.5.0 AFAIK the RT288X family do not support mips16 (they have a MIPS 4KEc cpu if I'm not wrong). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: set mips16 support
On 2016-01-05 13:18, José Vázquez wrote: > 2016-01-04 13:02 GMT+01:00, Cristian Morales Vega : >> Signed-off-by: Cristian Morales Vega >> --- >> target/linux/ramips/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/target/linux/ramips/Makefile b/target/linux/ramips/Makefile >> index 9d7bb5b..378e2f5 100644 >> --- a/target/linux/ramips/Makefile >> +++ b/target/linux/ramips/Makefile >> @@ -10,7 +10,7 @@ ARCH:=mipsel >> BOARD:=ramips >> BOARDNAME:=Ralink RT288x/RT3xxx >> SUBTARGETS:=rt305x mt7620 mt7621 mt7628 mt7688 rt3883 rt288x >> -FEATURES:=squashfs gpio >> +FEATURES:=squashfs gpio mips16 >> MAINTAINER:=John Crispin >> >> KERNEL_PATCHVER:=4.3 >> -- >> 2.5.0 > > AFAIK the RT288X family do not support mips16 (they have a MIPS 4KEc > cpu if I'm not wrong). Nice catch, thanks. Fixed in r48137 - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] lldpd: fix reload function for when interfaces change
From: Alexandru Ardelean
The problem is that interfaces are specified at start as
command line arguments, making them unchange-able via reload.
That means, we have to move (since lldpd allows this) the
interfaces-match-pattern option to be in a config file and reload
the configuration.
It's either that, or do a 'restart'.
Since we're generating the lldpd.conf file, we'll have to
move the 'sysconfdir' of lldpd to /tmp, where the files will
get written ; this will prevent any unncessary flash writes.
Signed-off-by: Alexandru Ardelean
---
package/network/services/lldpd/Makefile | 1 +
package/network/services/lldpd/files/lldpd.init | 53 +
2 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/package/network/services/lldpd/Makefile
b/package/network/services/lldpd/Makefile
index 81e4a8f..5f413cf 100644
--- a/package/network/services/lldpd/Makefile
+++ b/package/network/services/lldpd/Makefile
@@ -94,6 +94,7 @@ CONFIGURE_ARGS += \
--with-embedded-libevent=no \
--disable-hardening \
--without-xml \
+ --sysconfdir=/tmp \
$(if $(CONFIG_LLDPD_WITH_CDP),,--disable-cdp) \
$(if $(CONFIG_LLDPD_WITH_FDP),,--disable-fdp) \
$(if $(CONFIG_LLDPD_WITH_EDP),,--disable-edp) \
diff --git a/package/network/services/lldpd/files/lldpd.init
b/package/network/services/lldpd/files/lldpd.init
index 6965189..064bac1 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -7,6 +7,8 @@ STOP=01
USE_PROCD=1
LLDPCLI=/usr/sbin/lldpcli
LLDPSOCKET=/var/run/lldpd.socket
+LLDPD_CONF=/tmp/lldpd.conf
+LLDPD_CONFS_DIR=/tmp/lldpd.d
find_release_info()
{
@@ -17,16 +19,43 @@ find_release_info()
echo "${DISTRIB_DESCRIPTION:-Unknown OpenWrt release} @ $(cat
/proc/sys/kernel/hostname)"
}
-start_service() {
+write_lldpd_conf()
+{
. /lib/functions/network.sh
+ local lldp_description
+
+ config_load 'lldpd'
+ config_get lldp_description 'config' 'lldp_description'
"$(find_release_info)"
+
+ local ifaces
+ config_get ifaces 'config' 'interface'
+
+ local iface ifnames=""
+ for iface in $ifaces; do
+ local ifname=""
+ if network_get_device ifname "$iface" || [ -e
"/sys/class/net/$iface" ]; then
+ append ifnames "${ifname:-$iface}" ","
+ fi
+ done
+
+ # Clear out the config file first
+ echo -n > "$LLDPD_CONF"
+ [ -n "$ifnames" ] && echo "configure system interface pattern"
"$ifnames" >> "$LLDPD_CONF"
+ [ -n "$lldp_description" ] && echo "configure system description"
"\"$lldp_description\"" >> "$LLDPD_CONF"
+
+ # Since lldpd's sysconfdir is /tmp, we'll symlink /etc/lldpd.d to
/tmp/$LLDPD_CONFS_DIR
+ [ -e $LLDPD_CONFS_DIR ] || ln -s /etc/lldpd.d $LLDPD_CONFS_DIR
+}
+
+start_service() {
+
local enable_cdp
local enable_fdp
local enable_sonmp
local enable_edp
local lldp_class
local lldp_location
- local lldp_description
local readonly_mode
config_load 'lldpd'
@@ -36,35 +65,24 @@ start_service() {
config_get_bool enable_edp 'config' 'enable_edp' 0
config_get lldp_class 'config' 'lldp_class'
config_get lldp_location 'config' 'lldp_location'
- config_get lldp_description 'config' 'lldp_description'
"$(find_release_info)"
config_get_bool readonly_mode 'config' 'readonly_mode' 0
- local ifaces
- config_get ifaces 'config' 'interface'
-
- local iface ifnames=""
- for iface in $ifaces; do
- local ifname=""
- if network_get_device ifname "$iface" || [ -e
"/sys/class/net/$iface" ]; then
- append ifnames "${ifname:-$iface}" ","
- fi
- done
-
mkdir -p /var/run/lldp
chown lldp:lldp /var/run/lldp
+ # When lldpd starts, it also loads up what we write in this config file
+ write_lldpd_conf
+
procd_open_instance
procd_set_param command /usr/sbin/lldpd
procd_append_param command -d # don't daemonize, procd will handle that
for us
- [ -n "$ifnames" ] && procd_append_param command -I "$ifnames"
[ $enable_cdp -gt 0 ] && procd_append_param command '-c'
[ $enable_fdp -gt 0 ] && procd_append_param command '-f'
[ $enable_sonmp -gt 0 ] && procd_append_param command '-s'
[ $enable_edp -gt 0 ] && procd_append_param command '-e'
[ $readonly_mode -gt 0 ] && procd_append_param command '-r'
[ -n "$lldp_class" ] && procd_append_param command -M "$lldp_class"
- [ -n "$lldp_description" ] && procd_append_param command -S
"$lldp_description"
# set auto respawn behavior
procd_set_param respawn
@@ -83,7 +101,8 @@ reload_service() {
# Custom TLVs are special and should be
# reloaded from config during
[OpenWrt-Devel] [PATCH 2/2] lldpd: add /lib/lldpd.unconf file for reload
Looks like we need to call 'unconfigure' options lldpd has to offer
to do a proper (more complete) reload.
And while we're doing reload, we need to pause lldpd's execution
to prevent it sending unconfigured data/TLVs to the other side
( which could confuse the other side ).
Signed-off-by: Alexandru Ardelean
---
package/network/services/lldpd/Makefile | 9 -
package/network/services/lldpd/files/lldpd.init | 12 +++-
package/network/services/lldpd/files/lldpd.unconf | 9 +
3 files changed, 24 insertions(+), 6 deletions(-)
create mode 100644 package/network/services/lldpd/files/lldpd.unconf
diff --git a/package/network/services/lldpd/Makefile
b/package/network/services/lldpd/Makefile
index 5f413cf..4445867 100644
--- a/package/network/services/lldpd/Makefile
+++ b/package/network/services/lldpd/Makefile
@@ -61,11 +61,12 @@ define Package/lldpd/install
$(INSTALL_DIR) $(1)/etc/init.d
$(INSTALL_DIR) $(1)/etc/lldpd.d
$(INSTALL_DIR) $(1)/etc/config
- $(INSTALL_DIR) $(1)/usr/lib $(1)/usr/sbin
+ $(INSTALL_DIR) $(1)/lib $(1)/usr/lib $(1)/usr/sbin
$(CP) $(PKG_INSTALL_DIR)/usr/sbin/lldp{cli,ctl,d} $(1)/usr/sbin/
$(CP) $(PKG_INSTALL_DIR)/usr/lib/liblldpctl.so* $(1)/usr/lib/
$(INSTALL_BIN) ./files/lldpd.init $(1)/etc/init.d/lldpd
$(INSTALL_DATA) ./files/lldpd.config $(1)/etc/config/lldpd
+ $(INSTALL_CONF) ./files/lldpd.unconf $(1)/lib
ifneq ($(CONFIG_LLDPD_WITH_CDP),y)
sed -i -e '/cdp/d' $(1)/etc/init.d/lldpd $(1)/etc/config/lldpd
endif
@@ -78,6 +79,12 @@ endif
ifneq ($(CONFIG_LLDPD_WITH_SONMP),y)
sed -i -e '/sonmp/d' $(1)/etc/init.d/lldpd $(1)/etc/config/lldpd
endif
+ifneq ($(CONFIG_LLDPD_WITH_LLDPMED),y)
+ sed -i -e '/med/d' $(1)/lib/lldpd.unconf
+endif
+ifneq ($(CONFIG_LLDPD_WITH_CUSTOM),y)
+ sed -i -e '/custom-tlv/d' $(1)/lib/lldpd.unconf
+endif
endef
define Package/lldpd/conffiles
diff --git a/package/network/services/lldpd/files/lldpd.init
b/package/network/services/lldpd/files/lldpd.init
index 064bac1..1cf3ce7 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -98,13 +98,15 @@ service_running() {
reload_service() {
running || return 1
- # Custom TLVs are special and should be
- # reloaded from config during lldpd reload
- $LLDPCLI -u $LLDPSOCKET unconfigure lldp custom-tlv &> /dev/null
+ # Pause lldpd execution so that it won't send out info during reconfig
+ $LLDPCLI -u $LLDPSOCKET pause &> /dev/null
+ $LLDPCLI -u $LLDPSOCKET -c /lib/lldpd.unconf &> /dev/null
write_lldpd_conf
$LLDPCLI -u $LLDPSOCKET -c $LLDPD_CONF -c $LLDPD_CONFS_DIR &> /dev/null
- # Broadcast update over the wire
- $LLDPCLI -u $LLDPSOCKET update &> /dev/null
+ $LLDPCLI -u $LLDPSOCKET &> /dev/null << EOF
+ resume
+ update
+EOF
return 0
}
diff --git a/package/network/services/lldpd/files/lldpd.unconf
b/package/network/services/lldpd/files/lldpd.unconf
new file mode 100644
index 000..b7bdafc
--- /dev/null
+++ b/package/network/services/lldpd/files/lldpd.unconf
@@ -0,0 +1,9 @@
+unconfigure system hostname
+unconfigure system description
+unconfigure system platform
+unconfigure system interface pattern
+unconfigure system interface description
+unconfigure system interface promiscuous
+unconfigure system ip management pattern
+unconfigure lldp custom-tlv
+unconfigure med fast-start
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] configurable opkg repos patch not needed
Hi all, The patch for allowing user to configure their own opkg repos is not as necessary once the 'flavour' configuration patch gets applied (although that will require reworking the patch series it's part of), because if you use the /%f as the tail of the configured packages path you get the desired effect without having to manually configure a list of names. As an aside, I'm feeling a little less discouraged not as I got a note explaining that the comment about talking/writing too verbosely wasn't meant as harshly as I took it, and what really motivated it (ironically it's the fact I was trying to help by being deliberately verbose in my patch descriptions). Still have some personal priorities that limit my time for perhaps a month, and hopefully won't get too easily discouraged as I do have time; at the moment I have too much tendency to see the glass as half full when negative stuff comes up, which doesn't help. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SDK vs. Toolchain+
On 04/01/16 05:40 AM, Felix Fietkau wrote: I'd like to suggest a simpler one, which is in line with the current naming in OpenWrt: The SDK is what builds software for an already running system. It doesn't have to build images, it doesn't have to be used to build full systems, it's just what you use to compile packages for a particular existing build of OpenWrt. This is consistent with many examples listed here: https://en.wikipedia.org/wiki/Software_development_kit It also matches existing examples using embedded devices, e.g. Android SDK, iOS SDK. Does that clarify my thinking a little for you, and do you see, perhaps, the value of the current toolchain+ type of SDK in addition to the kind of SDK I think you're thinking of (That I call a 'real' SDK)? It clarifies your thinking for me, however I don't see much value in adopting your terminology, as it still seems to be somewhat convoluted and non-standard to me. My source of definition is from I now realize is non-standard usage that (some) ODMs use for their 'SDK' for firmware. From what I've seen they are typically not shipping an SDK in the sense you describe above (and which is the more standard terminology), but a system for building an entire firmware. So there are actually three different types of things here: 1) An SDK (a system used to build software for an already existing system) 2) A firmware build system (OpenWrt buildroot, or what I've seen called either an SDK or board support package depending on who is shipping it). 3) A toolchain (prebuilt binaries used to bootstrap a build system such as 1 or 2) / the tools needed to build other things (I wouldn't consider the source for a toolchain as a toolchain itself, but as what can be used to build a toolchain; I think that's a reasonable definition although some people use the terms interchangably and don't distinguish between toolchain source and a toolchain, but I think that cretes confusion because they are actually different things and have different requirements). I think it can be useful to have an SDK that is prebuilt binaries because of the bootstrapping problem and time cost of building, but I also see how this could be abused, and am of two minds about how to deal with the issue that having to build the toolchain for an SDK before being able use the SDK is rather painful (or at least it tests my patience; don't know about other people). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SDK vs. Toolchain+
> On 05 Jan 2016, at 16:04, Daniel Dickinson > wrote: > > am of two minds about how to deal with the issue that having to build the > toolchain for an SDK before being able use the SDK is rather painful (or at > least it tests my patience; don't know about other people). To be honest, it is more of a one-time time cost than a continuous cost. That is, I don't typically rebuilt the entire toolchain on every compile. Perhaps some of your frustration can be alleviated by using a slightly different workflow? Joris___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SDK vs. Toolchain+
On 05/01/16 10:49 AM, Joris de Vries wrote: On 05 Jan 2016, at 16:04, Daniel Dickinson mailto:open...@daniel.thecshore.com>> wrote: am of two minds about how to deal with the issue that having to build the toolchain for an SDK before being able use the SDK is rather painful (or at least it tests my patience; don't know about other people). To be honest, it is more of a one-time time cost than a continuous cost. That is, I don't typically rebuilt the entire toolchain on every compile. Perhaps some of your frustration can be alleviated by using a slightly different workflow? The problem is that I find, at least with ar71xx, that even with a an already compile toolchain that target/linux/compile takes an annoying amount of time (even though nothing is being compiled, there is a lot of stuff that still gets done), and, in addition, target/linux/install takes a very long time because there are preparations for every image, even if you only want two or three profiles (but the two or three means you can't just select one profile and be happy), because you have multiple types of hardware you want to deal with. It's actually target/linux that's the major issue when it comes to allowing not rebuilding every time to be a useful answer. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SDK vs. Toolchain+
On 05/01/16 11:22 AM, Daniel Dickinson wrote: On 05/01/16 10:49 AM, Joris de Vries wrote: On 05 Jan 2016, at 16:04, Daniel Dickinson mailto:open...@daniel.thecshore.com>> wrote: am of two minds about how to deal with the issue that having to build the toolchain for an SDK before being able use the SDK is rather painful (or at least it tests my patience; don't know about other people). To be honest, it is more of a one-time time cost than a continuous cost. That is, I don't typically rebuilt the entire toolchain on every compile. Perhaps some of your frustration can be alleviated by using a slightly different workflow? The problem is that I find, at least with ar71xx, that even with a an already compile toolchain that target/linux/compile takes an annoying amount of time (even though nothing is being compiled, there is a lot of stuff that still gets done), and, in addition, target/linux/install takes a very long time because there are preparations for every image, even if you only want two or three profiles (but the two or three means you can't just select one profile and be happy), because you have multiple types of hardware you want to deal with. It's actually target/linux that's the major issue when it comes to allowing not rebuilding every time to be a useful answer. This does, however, tell me a better way to focus my energy than the SDK stuff I was doing; improving target/linux situation combined with a sourceful SDK would I think be a positive solution. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SDK vs. Toolchain+
Hello, On Tue, Jan 5, 2016 at 5:25 PM, Daniel Dickinson < open...@daniel.thecshore.com> wrote: > On 05/01/16 11:22 AM, Daniel Dickinson wrote: >> >> It's actually target/linux that's the major issue when it comes to >> allowing not rebuilding every time to be a useful answer. >> > > This does, however, tell me a better way to focus my energy than the SDK > stuff I was doing; improving target/linux situation combined with a > sourceful SDK would I think be a positive solution. > > maybe it would be a good idea to find a way to separate the real image building and target/linux/install? Best regards, -- Emmanuel Deloget > Regards, > > Daniel > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SDK vs. Toolchain+
On 05/01/16 11:32 AM, Emmanuel Deloget wrote: Hello, On Tue, Jan 5, 2016 at 5:25 PM, Daniel Dickinson mailto:open...@daniel.thecshore.com>>wrote: On 05/01/16 11:22 AM, Daniel Dickinson wrote: It's actually target/linux that's the major issue when it comes to allowing not rebuilding every time to be a useful answer. This does, however, tell me a better way to focus my energy than the SDK stuff I was doing; improving target/linux situation combined with a sourceful SDK would I think be a positive solution. maybe it would be a good idea to find a way to separate the real image building and target/linux/install? IIRC target/linux/install does two things: 1) Prepares kernel parts of image for each selected profile (that is uImage for those that use uImage, embed commandline, etc) 2) Builds the actual images, when image building is selected In reality the real time-waster is building a huge number of unwanted kernel image parts and/or images. I think think for this part, the lowest cost path is find a way to select only wanted images, for #of images/kernel parts > 1. Basically, if there is a way to do checkboxes instead of a radio list in profile selection, that would solve the issue IMO. target/linux/compile is still somewhat annoying, but it's the lesser of the issues and probably a harder problem to solve in a robust way. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SDK vs. Toolchain+
On 2016-01-05 17:40, Daniel Dickinson wrote: > On 05/01/16 11:32 AM, Emmanuel Deloget wrote: >> Hello, >> >> On Tue, Jan 5, 2016 at 5:25 PM, Daniel Dickinson >> mailto:open...@daniel.thecshore.com>>wrote: >> >> On 05/01/16 11:22 AM, Daniel Dickinson wrote: >> >> It's actually target/linux that's the major issue when it comes to >> allowing not rebuilding every time to be a useful answer. >> >> >> This does, however, tell me a better way to focus my energy than the >> SDK stuff I was doing; improving target/linux situation combined >> with a sourceful SDK would I think be a positive solution. >> >> >> >> maybe it would be a good idea to find a way to separate the real image >> building and target/linux/install? > > IIRC target/linux/install does two things: > > 1) Prepares kernel parts of image for each selected profile (that is > uImage for those that use uImage, embed commandline, etc) > > 2) Builds the actual images, when image building is selected > > In reality the real time-waster is building a huge number of unwanted > kernel image parts and/or images. > > I think think for this part, the lowest cost path is find a way to > select only wanted images, for #of images/kernel parts > 1. > > Basically, if there is a way to do checkboxes instead of a radio list in > profile selection, that would solve the issue IMO. > > target/linux/compile is still somewhat annoying, but it's the lesser of > the issues and probably a harder problem to solve in a robust way. Actually, it might not be too hard to fix. I suggest the following approach: Before updating the .config file in the kernel tree at target/compile time, generate it into a file in tmp/ and compare it against what's in the kernel tree (needs to be a copy that was used before running make oldconfig in the kernel tree). Then, the generic rebuild dependency checks could be used on the kernel tree as well, so if no file was changed, it does not have to call make. The same applies to target/install, with some special cases for initramfs. At least with the new image building code, it's easier to then add proper dependencies on all relevant files. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New "Security" wiki page. Improvements/corrections appreciated
Brian, I think your page did a great job of going through the opportunities for improvement and clarifications in OpenWrt security. prpl's members have bringing up some of these topics as well. I'm happy to help bring myself and prpl into this effort. I also think a consideration of automatic updates for OpenWrt would be appropriate. The fact that every device model is a unique build makes this more difficult but ultimately, I don't think it's in OpenWrt's interest for its users to be running insecure, out of date software by default. (If someone doesn't want their device from updating, that's certainly their right of course). That said, autoupdating will be difficult to do until we have a way to automatically test updates on actual hardware. Having a standard autoupdate mechanism that device manufacturers could use/plug into might be a good first step. We do have contacts with many manufacturers and I'd be happy to help this. Eric -- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org eschu...@prplfoundation.org cell: 920-539-0404 skype: ericschultzwi @EricPrpl ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SDK vs. Toolchain+
* Daniel Dickinson [05.01.2016 18:48]: > The problem is that I find, at least with ar71xx, that even with a an > already compile toolchain that target/linux/compile takes an annoying > amount of time (even though nothing is being compiled, there is a lot > of stuff that still gets done), and, > > in addition, target/linux/install takes a very long time because > there are preparations for every image, even if you only want two or > three profiles (but the two or three means you can't just select one > profile and be happy), because you have multiple types of hardware > you want to deal with. > > It's actually target/linux that's the major issue when it comes to > allowing not rebuilding every time to be a useful answer. some weeks ago i gave some numbers for make clean && make for e.g. ar71xx and it boils down to only some ~140 seconds on cheap and fast hardware. (including ALL images). so what is your problem? slow hardware? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar8327: add IGMP Snooping support
This add support for IGMP Snooping on atheros switches (enabled by default),
which avoids flooding the network with multicast data.
Tested on TL-WDR4300: disabling IGMP Snooping results in multicast flooding
on each specific port, enabling it back again prevents each port from
receiving all multicast packets.
Partially based on: http://patchwork.ozlabs.org/patch/418122/
Signed-off-by: Álvaro Fernández Rojas
---
.../linux/generic/files/drivers/net/phy/ar8216.h | 2 +
.../linux/generic/files/drivers/net/phy/ar8327.c | 139 -
.../linux/generic/files/drivers/net/phy/ar8327.h | 55
3 files changed, 194 insertions(+), 2 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.h
b/target/linux/generic/files/drivers/net/phy/ar8216.h
index 14fe928..616c54f 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8216.h
+++ b/target/linux/generic/files/drivers/net/phy/ar8216.h
@@ -406,6 +406,8 @@ struct ar8xxx_chip {
void (*get_arl_entry)(struct ar8xxx_priv *priv, struct arl_entry *a,
u32 *status, enum arl_op op);
int (*sw_hw_apply)(struct switch_dev *dev);
+ int (*igmp_port_get)(struct ar8xxx_priv *priv, int port);
+ void (*igmp_port_set)(struct ar8xxx_priv *priv, int port, int enable);
const struct ar8xxx_mib_desc *mib_decs;
unsigned num_mibs;
diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c
b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 90ee411..5f6950a 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -662,8 +662,8 @@ ar8327_init_globals(struct ar8xxx_priv *priv)
/* forward multicast and broadcast frames to CPU */
t = (AR8327_PORTS_ALL << AR8327_FWD_CTRL1_UC_FLOOD_S) |
- (AR8327_PORTS_ALL << AR8327_FWD_CTRL1_MC_FLOOD_S) |
- (AR8327_PORTS_ALL << AR8327_FWD_CTRL1_BC_FLOOD_S);
+ (AR8327_PORTS_ALL << AR8327_FWD_CTRL1_BC_FLOOD_S) |
+ (AR8327_PORTS_ALL << AR8327_FWD_CTRL1_IGMP_S);
ar8xxx_write(priv, AR8327_REG_FWD_CTRL1, t);
/* enable jumbo frames */
@@ -677,6 +677,19 @@ ar8327_init_globals(struct ar8xxx_priv *priv)
/* Disable EEE on all phy's due to stability issues */
for (i = 0; i < AR8XXX_NUM_PHYS; i++)
data->eee[i] = false;
+
+ /* Enable IGMP Join/Leave */
+ t = AR8327_IGMP_JOIN_EN0 | AR8327_IGMP_LEAVE_EN0 |
+ AR8327_IGMP_JOIN_EN1 | AR8327_IGMP_LEAVE_EN1 |
+ AR8327_IGMP_JOIN_EN2 | AR8327_IGMP_LEAVE_EN2 |
+ AR8327_IGMP_JOIN_EN3 | AR8327_IGMP_LEAVE_EN3;
+ ar8xxx_rmw(priv, AR8327_REG_FRAM_ACK_CTRL0, 0, t);
+
+ t = AR8327_IGMP_JOIN_EN4 | AR8327_IGMP_LEAVE_EN4 |
+ AR8327_IGMP_JOIN_EN5 | AR8327_IGMP_LEAVE_EN5 |
+ AR8327_IGMP_JOIN_EN6 | AR8327_IGMP_LEAVE_EN6 |
+ AR8327_IGMP_V3_EN;
+ ar8xxx_rmw(priv, AR8327_REG_FRAM_ACK_CTRL1, 0, t);
}
static void
@@ -783,6 +796,78 @@ ar8327_atu_flush_port(struct ar8xxx_priv *priv, int port)
return ret;
}
+static int
+ar8327_igmp_port_reg(int port)
+{
+ if (port > 3)
+ return AR8327_REG_FRAM_ACK_CTRL1;
+ else
+ return AR8327_REG_FRAM_ACK_CTRL0;
+}
+
+static int
+ar8327_igmp_port_fast_join_leave(int port)
+{
+ int ret;
+
+ switch (port) {
+ case 0:
+ ret = AR8327_IGMP_JOIN_EN0 | AR8327_IGMP_LEAVE_EN0;
+ break;
+ case 1:
+ ret = AR8327_IGMP_JOIN_EN1 | AR8327_IGMP_LEAVE_EN1;
+ break;
+ case 2:
+ ret = AR8327_IGMP_JOIN_EN2 | AR8327_IGMP_LEAVE_EN2;
+ break;
+ case 3:
+ ret = AR8327_IGMP_JOIN_EN3 | AR8327_IGMP_LEAVE_EN3;
+ break;
+ case 4:
+ ret = AR8327_IGMP_JOIN_EN4 | AR8327_IGMP_LEAVE_EN4;
+ break;
+ case 5:
+ ret = AR8327_IGMP_JOIN_EN5 | AR8327_IGMP_LEAVE_EN5;
+ break;
+ case 6:
+ ret = AR8327_IGMP_JOIN_EN6 | AR8327_IGMP_LEAVE_EN6;
+ break;
+ }
+
+ return ret;
+}
+
+static int
+ar8327_igmp_port_get(struct ar8xxx_priv *priv, int port)
+{
+ u32 val = ar8xxx_read(priv, AR8327_REG_FWD_CTRL1) >>
+ AR8327_FWD_CTRL1_IGMP_S;
+ if ((val & BIT(port)) != 0)
+ return 1;
+ else
+ return 0;
+}
+
+static void
+ar8327_igmp_port_set(struct ar8xxx_priv *priv, int port, int enable)
+{
+ if (enable) {
+ ar8xxx_rmw(priv, AR8327_REG_FWD_CTRL1,
+ BIT(port) << AR8327_FWD_CTRL1_MC_FLOOD_S,
+ BIT(port) << AR8327_FWD_CTRL1_IGMP_S);
+
+ ar8xxx_rmw(priv, ar8327_igmp_port_reg(port), 0,
+ ar8327_igmp_port_fast_join_leave(port));
+ } else {
+ ar8xxx_rmw(priv, AR8327_REG_FWD_
Re: [OpenWrt-Devel] [PATCH] swconfig: support setting SWITCH_TYPE_LINK attributes
Hi Rafał, > Supported syntax is inspired by ethtool. Example usage: > swconfig dev switch0 port 2 set link "duplex half speed 100 autoneg off" > > Signed-off-by: Rafał Miłecki I think that's the way to go, will try implementing set_port_link() for my good old 1043ND. Ack for this and the kernel patches. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
