Re: [LEDE-DEV] Recent issues w/ sysupgrade
> On Aug 29, 2017, at 9:16 AM, Philip Prindeville > wrote: > >> On Aug 29, 2017, at 1:19 AM, Stijn Tintel wrote: >> >>> On 29-08-17 09:09, Philip Prindeville wrote: >>> Hi all, >>> >>> I don’t know if sysupgrade is the problem, or if this is where things >>> manifest. >>> >>> But I recently (within the last week, but I only rebase once or twice a >>> week) started seeing issues with doing sysupgrade on x86_64 hardware. >>> >>> The sysupgrade will appear to go okay, but then when the machine reboots, I >>> see: >>> >>> ... >>> Press the [f] key and hit [enter] to enter failsafe mode >>> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level >>> [6.322701] mount_root: loading kmods from internal overlay >>> [6.331183] kmodloader: loading kernel modules from >>> //etc/modules-boot.d/* >>> [6.339194] kmodloader: done loading kernel modules from >>> //etc/modules-boot.d/* >>> [6.470650] block: attempting to load /etc/config/fstab >>> [6.483431] block: extroot: not configured >>> [6.488267] random: procd: uninitialized urandom read (4 bytes read) >>> [6.506070] mount_root: rootdisk overlay filesystem has not been >>> formatted yet >>> >>> >>> Is this related to the mk.f2f changes on Thursday? >> I doubt this will be related. The only real change is >> https://git.lede-project.org/cdb494fd, and on little endian systems >> cpu_to_le64 is a noop. Additionaly I tested this on x86/64 and didn't >> notice any isses. Just look a bit further and you should see this: >> >> Tue Aug 29 07:12:57 2017 user.info kernel: [5.607837] mount_root: >> overlay filesystem has not been fully initialized yet >> Tue Aug 29 07:12:57 2017 user.info kernel: [5.608986] mount_root: >> switching to f2fs overlay >> >> root@LEDE:~# mount | grep overlay >> /dev/loop0 on /overlay type f2fs >> (rw,lazytime,noatime,background_gc=on,user_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6) >> overlayfs:/overlay on / type overlay >> (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work) >> >> Stijn > > It never gets to that point. > > The message about it not being formatted is the last output then it hangs. > I do not see that (the “switching to f2fs overlay” message) on the console when the hang happens at reboot following a sysupgrade (and sometimes even just reflashing the CF card). I have noted, when sysupgrade runs, I do see: [ 379.758026] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null) Upgrade completed Rebooting system... umount: can't unmount /dev: Resource busy umount: can't unmount /tmp: Resource busy but I was seeing those before. So, some progress on the bi-section. I can rebase to here: af922c0 mediatek: update to latest kernel patchset from v4.13-rc 3ec259a procd: fix hotplug-preinit.json syntax 1a3b17a procd: fix hotplug.json syntax a678eb0 ca-certificates: Update to 20170717 8e16e19 imx6: refresh kernel config c0d5990 imx6: add driver for temp/voltage monitoring 2deed55 uboot-lantiq: Enable TFTP PUT support for backups 47dcfcf gpio-button-hotplug: leave platform_device.dev.platform_data untouched but then I need to cherry-pick this fix so things will build: dfee19f mediatek: drop kernel dep on userland module If I try to rebase any further, to: e622b30 netifd: update to latest git HEAD then I see the flakiness at boot time. John or Felix, are there any changes here that would affect booting if the way described above? -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] dnsmasq: forward.c: fix CVE-2017-13704
On Tue, Aug 29, 2017 at 3:29 PM, Kevin Darbyshire-Bryant wrote: > Fix SIGSEGV in rfc1035.c answer_request() line 1228 where memset() > is called with header & limit pointing at the same address and thus > tries to clear memory from before the buffer begins. > > answer_request() is called with an invalid edns packet size provided by > the client. Ensure the udp_size provided by the client is bounded by > 512 and configured maximum as per RFC 6891 6.2.3 "Values lower than 512 > MUST be treated as equal to 512" > > The client that exposed the problem provided a payload udp size of 0. > > Signed-off-by: Kevin Darbyshire-Bryant Acked-by: Hans Dedecker > --- > package/network/services/dnsmasq/Makefile | 2 +- > .../dnsmasq/patches/020-fix-CVE-2017-13704.patch | 37 > ++ > 2 files changed, 38 insertions(+), 1 deletion(-) > create mode 100644 > package/network/services/dnsmasq/patches/020-fix-CVE-2017-13704.patch > > diff --git a/package/network/services/dnsmasq/Makefile > b/package/network/services/dnsmasq/Makefile > index d7f14f9..bd7f610 100644 > --- a/package/network/services/dnsmasq/Makefile > +++ b/package/network/services/dnsmasq/Makefile > @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk > > PKG_NAME:=dnsmasq > PKG_VERSION:=2.77 > -PKG_RELEASE:=9 > +PKG_RELEASE:=10 > > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz > PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/ > diff --git > a/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch > b/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch > new file mode 100644 > index 000..8848131 > --- /dev/null > +++ b/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch > @@ -0,0 +1,37 @@ > +From 38af9b1ac3242a4128e88069c495024caa565f0e Mon Sep 17 00:00:00 2001 > +From: Kevin Darbyshire-Bryant > +Date: Tue, 29 Aug 2017 12:35:40 +0100 > +Subject: [PATCH] forward.c: fix CVE-2017-13704 > + > +Fix SIGSEGV in rfc1035.c answer_request() line 1228 where memset() > +is called with header & limit pointing at the same address and thus > +tries to clear memory from before the buffer begins. > + > +answer_request() is called with an invalid edns packet size provided by > +the client. Ensure the udp_size provided by the client is bounded by > +512 and configured maximum as per RFC 6891 6.2.3 "Values lower than 512 > +MUST be treated as equal to 512" > + > +The client that exposed the problem provided a payload udp size of 0. > + > +Signed-off-by: Kevin Darbyshire-Bryant > +--- > + src/forward.c | 2 ++ > + 1 file changed, 2 insertions(+) > + > +diff --git a/src/forward.c b/src/forward.c > +index f22556a..62c5a5a 100644 > +--- a/src/forward.c > b/src/forward.c > +@@ -1408,6 +1408,8 @@ void receive_query(struct listener *listen, time_t now) > +defaults to 512 */ > + if (udp_size > daemon->edns_pktsz) > + udp_size = daemon->edns_pktsz; > ++ if (udp_size < 512) > ++ udp_size = 512; /* RFC 6891 6.2.3 */ > + } > + > + #ifdef HAVE_AUTH > +-- > +2.7.4 > + > -- > 2.7.4 > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Conditional dependencies in Makefiles
I think I tried that variation too and it was as if CONFIG_SOFT_FLOAT wasn't defined when the dependencies are calculated. I usally check the .packageinfo file to see what the enabled dependency config is. Strangely, I think the problem lies with CONFIG_SOFT_FLOAT itself and the order of config evaluation? /ted -Original Message- From: Alexandru Ardelean Sent: Tuesday, August 29, 2017 2:50 PM To: LEDE Development List ; Ted Hess Subject: Re: [LEDE-DEV] Conditional dependencies in Makefiles What if you do outside of the function def. ifeq ($(CONFIG_SOFT_FLOAT),y) FLOAT_DEPENDS:= +PACKAGE_shine:shine else FLOAT_DEPENDS+= +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 endif and then DEPENDS+=$(FLOAT_DEPENDS) ? On Tue, Aug 29, 2017 at 9:34 PM, Sebastian Kemper wrote: On Tue, Aug 29, 2017 at 05:15:51PM +, Sebastian Kemper wrote: Hi Ted, Maybe a stupid idea, but is there a tab in front of the depends? Does removing it help? No, that doesn't help. I remember trying to do something like this with PKG_BUILD_DEPENDS and couldn't get it working either. Maybe the best you can do is this: define Package/libffmpeg-full $(call Package/libffmpeg/Default) TITLE+= (full) DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus @!SOFT_FLOAT +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 VARIANT:=full endef Downside would be no libffmpeg-full for SOFT_FLOAT setups, obviously :) On another note, are you sure you want deps like these: +PACKAGE_libopus:libopus? According to https://wiki.openwrt.org/doc/devel/dependencies it means that libopus will only get selected by libffmpeg-full if libopus is enabled. I think +PACKAGE_libffmpeg-full:libopus is what you're after. Regards, Sebastian Seb Am 29. August 2017 19:08:11 MESZ schrieb Ted Hess : >Hi all - > >I have a package (ffmpeg) build problem which is trying to specify a >different DEPENDS for soft-float systems and one for hard-float. The >package definition is as follows: > >> define Package/libffmpeg-full $(call Package/libffmpeg/Default) >> TITLE+= (full) DEPENDS+= @BUILD_PATENTED +alsa-lib >> +PACKAGE_libopus:libopus ifeq ($(CONFIG_SOFT_FLOAT),y) >> DEPENDS+= +PACKAGE_shine:shine else DEPENDS+= >> +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 endif >> VARIANT:=full endef > >Thinking the 'ifeq', etc is not proper within a function definition, >I have also tried: > > DEPENDS+=$(if >$(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame- lib:lame-lib >+PACKAGE_libx264:libx264) > >In both cases, the behavior is as if CONFIG_SOFT_FLOAT is not >defined. > >Any help would be greatly appreciated. > >/ted > > >___ Lede-dev mailing list >Lede-dev@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Conditional dependencies in Makefiles
On 2017-08-29 19:08, Ted Hess wrote: > Hi all - > > I have a package (ffmpeg) build problem which is trying to specify a different > DEPENDS for soft-float systems and one for hard-float. The package definition > is > as follows: > >> define Package/libffmpeg-full >> $(call Package/libffmpeg/Default) >> TITLE+= (full) >> DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus >> ifeq ($(CONFIG_SOFT_FLOAT),y) >> DEPENDS+= +PACKAGE_shine:shine >> else >> DEPENDS+= +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 >> endif >> VARIANT:=full >> endef > > Thinking the 'ifeq', etc is not proper within a function definition, I have > also > tried: > > DEPENDS+=$(if $(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame- > lib:lame-lib +PACKAGE_libx264:libx264) Please don't introduce dependencies that magically get added based on whether a different package is selected or not. Either always use shine, or add a separate option to configure whether or not it should be used. Also make sure that anything that affects the build gets proper treatment in CONFIGURE_ARGS and PKG_CONFIG_DEPENDS. Aside from that, there is an easy way to deal with conditional dependencies that depend on multiple options: Just create an intermediate config symbol via Package//config that is hidden and depends on the relevant multiple config symbols. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Conditional dependencies in Makefiles
What if you do outside of the function def. ifeq ($(CONFIG_SOFT_FLOAT),y) FLOAT_DEPENDS:= +PACKAGE_shine:shine else FLOAT_DEPENDS+= +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 endif and then DEPENDS+=$(FLOAT_DEPENDS) ? On Tue, Aug 29, 2017 at 9:34 PM, Sebastian Kemper wrote: > On Tue, Aug 29, 2017 at 05:15:51PM +, Sebastian Kemper wrote: >> Hi Ted, >> >> Maybe a stupid idea, but is there a tab in front of the depends? Does >> removing it help? > > No, that doesn't help. > > I remember trying to do something like this with PKG_BUILD_DEPENDS and > couldn't get it working either. > > Maybe the best you can do is this: > > define Package/libffmpeg-full > $(call Package/libffmpeg/Default) > TITLE+= (full) > DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus @!SOFT_FLOAT > +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 > VARIANT:=full > endef > > Downside would be no libffmpeg-full for SOFT_FLOAT setups, obviously :) > > On another note, are you sure you want deps like these: > > +PACKAGE_libopus:libopus? > > According to https://wiki.openwrt.org/doc/devel/dependencies it means > that libopus will only get selected by libffmpeg-full if libopus is > enabled. I think > > +PACKAGE_libffmpeg-full:libopus > > is what you're after. > > Regards, > Sebastian > >> >> Seb >> >> Am 29. August 2017 19:08:11 MESZ schrieb Ted Hess >> : >> >Hi all - >> > >> >I have a package (ffmpeg) build problem which is trying to specify a >> >different DEPENDS for soft-float systems and one for hard-float. The >> >package definition is as follows: >> > >> >> define Package/libffmpeg-full $(call Package/libffmpeg/Default) >> >> TITLE+= (full) DEPENDS+= @BUILD_PATENTED +alsa-lib >> >> +PACKAGE_libopus:libopus ifeq ($(CONFIG_SOFT_FLOAT),y) >> >> DEPENDS+= +PACKAGE_shine:shine else DEPENDS+= >> >> +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 endif >> >> VARIANT:=full endef >> > >> >Thinking the 'ifeq', etc is not proper within a function definition, >> >I have also tried: >> > >> > DEPENDS+=$(if >> >$(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame- lib:lame-lib >> >+PACKAGE_libx264:libx264) >> > >> >In both cases, the behavior is as if CONFIG_SOFT_FLOAT is not >> >defined. >> > >> >Any help would be greatly appreciated. >> > >> >/ted >> > >> > >> >___ Lede-dev mailing list >> >Lede-dev@lists.infradead.org >> >http://lists.infradead.org/mailman/listinfo/lede-dev >> >> ___ Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Conditional dependencies in Makefiles
On Tue, Aug 29, 2017 at 05:15:51PM +, Sebastian Kemper wrote: > Hi Ted, > > Maybe a stupid idea, but is there a tab in front of the depends? Does > removing it help? No, that doesn't help. I remember trying to do something like this with PKG_BUILD_DEPENDS and couldn't get it working either. Maybe the best you can do is this: define Package/libffmpeg-full $(call Package/libffmpeg/Default) TITLE+= (full) DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus @!SOFT_FLOAT +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 VARIANT:=full endef Downside would be no libffmpeg-full for SOFT_FLOAT setups, obviously :) On another note, are you sure you want deps like these: +PACKAGE_libopus:libopus? According to https://wiki.openwrt.org/doc/devel/dependencies it means that libopus will only get selected by libffmpeg-full if libopus is enabled. I think +PACKAGE_libffmpeg-full:libopus is what you're after. Regards, Sebastian > > Seb > > Am 29. August 2017 19:08:11 MESZ schrieb Ted Hess > : > >Hi all - > > > >I have a package (ffmpeg) build problem which is trying to specify a > >different DEPENDS for soft-float systems and one for hard-float. The > >package definition is as follows: > > > >> define Package/libffmpeg-full $(call Package/libffmpeg/Default) > >> TITLE+= (full) DEPENDS+= @BUILD_PATENTED +alsa-lib > >> +PACKAGE_libopus:libopus ifeq ($(CONFIG_SOFT_FLOAT),y) > >> DEPENDS+= +PACKAGE_shine:shine else DEPENDS+= > >> +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 endif > >> VARIANT:=full endef > > > >Thinking the 'ifeq', etc is not proper within a function definition, > >I have also tried: > > > > DEPENDS+=$(if > >$(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame- lib:lame-lib > >+PACKAGE_libx264:libx264) > > > >In both cases, the behavior is as if CONFIG_SOFT_FLOAT is not > >defined. > > > >Any help would be greatly appreciated. > > > >/ted > > > > > >___ Lede-dev mailing list > >Lede-dev@lists.infradead.org > >http://lists.infradead.org/mailman/listinfo/lede-dev > > ___ Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Sysupgrade and networking
Hi. I was wondering about why the network interfaces stay up during a sysupgrade. No services are available, so about all you can do is ping the box or have your connections reset if you try to connect to it. Would it make more sense to bring all network interfaces down? Worst case scenario is you’re in the middle of an update, and then someone sends you a packet-of-death while the update is incomplete… now you’ve got a corrupted filesystem. -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Conditional dependencies in Makefiles
Hi Ted, Maybe a stupid idea, but is there a tab in front of the depends? Does removing it help? Seb Am 29. August 2017 19:08:11 MESZ schrieb Ted Hess : >Hi all - > >I have a package (ffmpeg) build problem which is trying to specify a >different >DEPENDS for soft-float systems and one for hard-float. The package >definition is >as follows: > >> define Package/libffmpeg-full >> $(call Package/libffmpeg/Default) >> TITLE+= (full) >> DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus >> ifeq ($(CONFIG_SOFT_FLOAT),y) >> DEPENDS+= +PACKAGE_shine:shine >> else >> DEPENDS+= +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 >> endif >> VARIANT:=full >> endef > >Thinking the 'ifeq', etc is not proper within a function definition, I >have also >tried: > > DEPENDS+=$(if >$(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame- >lib:lame-lib +PACKAGE_libx264:libx264) > >In both cases, the behavior is as if CONFIG_SOFT_FLOAT is not defined. > >Any help would be greatly appreciated. > >/ted > > >___ >Lede-dev mailing list >Lede-dev@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Conditional dependencies in Makefiles
Hi all - I have a package (ffmpeg) build problem which is trying to specify a different DEPENDS for soft-float systems and one for hard-float. The package definition is as follows: > define Package/libffmpeg-full > $(call Package/libffmpeg/Default) > TITLE+= (full) > DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus > ifeq ($(CONFIG_SOFT_FLOAT),y) > DEPENDS+= +PACKAGE_shine:shine > else > DEPENDS+= +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264 > endif > VARIANT:=full > endef Thinking the 'ifeq', etc is not proper within a function definition, I have also tried: DEPENDS+=$(if $(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame- lib:lame-lib +PACKAGE_libx264:libx264) In both cases, the behavior is as if CONFIG_SOFT_FLOAT is not defined. Any help would be greatly appreciated. /ted ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] libmpdclient - meson/ninja ?
Hi all - The latest releases of libmpdclient, part of the Music Player Daemon (mpd), has been revised to build with the Meson build system and Ninja. It no longer has support for autotools & make. Since we do not have the availability of this build environment / toolchain, the current version (2.11) will be frozen in the packages library. Any thoughts? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Recent issues w/ sysupgrade
> On Aug 29, 2017, at 1:19 AM, Stijn Tintel wrote: > >> On 29-08-17 09:09, Philip Prindeville wrote: >> Hi all, >> >> I don’t know if sysupgrade is the problem, or if this is where things >> manifest. >> >> But I recently (within the last week, but I only rebase once or twice a >> week) started seeing issues with doing sysupgrade on x86_64 hardware. >> >> The sysupgrade will appear to go okay, but then when the machine reboots, I >> see: >> >> ... >> Press the [f] key and hit [enter] to enter failsafe mode >> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level >> [6.322701] mount_root: loading kmods from internal overlay >> [6.331183] kmodloader: loading kernel modules from //etc/modules-boot.d/* >> [6.339194] kmodloader: done loading kernel modules from >> //etc/modules-boot.d/* >> [6.470650] block: attempting to load /etc/config/fstab >> [6.483431] block: extroot: not configured >> [6.488267] random: procd: uninitialized urandom read (4 bytes read) >> [6.506070] mount_root: rootdisk overlay filesystem has not been >> formatted yet >> >> >> Is this related to the mk.f2f changes on Thursday? > I doubt this will be related. The only real change is > https://git.lede-project.org/cdb494fd, and on little endian systems > cpu_to_le64 is a noop. Additionaly I tested this on x86/64 and didn't > notice any isses. Just look a bit further and you should see this: > > Tue Aug 29 07:12:57 2017 user.info kernel: [5.607837] mount_root: > overlay filesystem has not been fully initialized yet > Tue Aug 29 07:12:57 2017 user.info kernel: [5.608986] mount_root: > switching to f2fs overlay > > root@LEDE:~# mount | grep overlay > /dev/loop0 on /overlay type f2fs > (rw,lazytime,noatime,background_gc=on,user_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6) > overlayfs:/overlay on / type overlay > (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work) > > Stijn It never gets to that point. The message about it not being formatted is the last output then it hangs. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] dnsmasq: forward.c: fix CVE-2017-13704
Fix SIGSEGV in rfc1035.c answer_request() line 1228 where memset() is called with header & limit pointing at the same address and thus tries to clear memory from before the buffer begins. answer_request() is called with an invalid edns packet size provided by the client. Ensure the udp_size provided by the client is bounded by 512 and configured maximum as per RFC 6891 6.2.3 "Values lower than 512 MUST be treated as equal to 512" The client that exposed the problem provided a payload udp size of 0. Signed-off-by: Kevin Darbyshire-Bryant --- package/network/services/dnsmasq/Makefile | 2 +- .../dnsmasq/patches/020-fix-CVE-2017-13704.patch | 37 ++ 2 files changed, 38 insertions(+), 1 deletion(-) create mode 100644 package/network/services/dnsmasq/patches/020-fix-CVE-2017-13704.patch diff --git a/package/network/services/dnsmasq/Makefile b/package/network/services/dnsmasq/Makefile index d7f14f9..bd7f610 100644 --- a/package/network/services/dnsmasq/Makefile +++ b/package/network/services/dnsmasq/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=dnsmasq PKG_VERSION:=2.77 -PKG_RELEASE:=9 +PKG_RELEASE:=10 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/ diff --git a/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch b/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch new file mode 100644 index 000..8848131 --- /dev/null +++ b/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch @@ -0,0 +1,37 @@ +From 38af9b1ac3242a4128e88069c495024caa565f0e Mon Sep 17 00:00:00 2001 +From: Kevin Darbyshire-Bryant +Date: Tue, 29 Aug 2017 12:35:40 +0100 +Subject: [PATCH] forward.c: fix CVE-2017-13704 + +Fix SIGSEGV in rfc1035.c answer_request() line 1228 where memset() +is called with header & limit pointing at the same address and thus +tries to clear memory from before the buffer begins. + +answer_request() is called with an invalid edns packet size provided by +the client. Ensure the udp_size provided by the client is bounded by +512 and configured maximum as per RFC 6891 6.2.3 "Values lower than 512 +MUST be treated as equal to 512" + +The client that exposed the problem provided a payload udp size of 0. + +Signed-off-by: Kevin Darbyshire-Bryant +--- + src/forward.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/src/forward.c b/src/forward.c +index f22556a..62c5a5a 100644 +--- a/src/forward.c b/src/forward.c +@@ -1408,6 +1408,8 @@ void receive_query(struct listener *listen, time_t now) +defaults to 512 */ + if (udp_size > daemon->edns_pktsz) + udp_size = daemon->edns_pktsz; ++ if (udp_size < 512) ++ udp_size = 512; /* RFC 6891 6.2.3 */ + } + + #ifdef HAVE_AUTH +-- +2.7.4 + -- 2.7.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Advertising Opportunities
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello I hope you don't mind me emailing you. My name is Annie and I am the Editorial lead at EditorialPR.com in the UK. We have a client at the moment that's interested in being featured on your website. Do you have any editorial advertising opportunities on the site that we could work together on? Please note; I am on a tight deadline and need to get my placements for next month agreed as soon as possible. So if you are interested please get back to me as soon as possible so I can supply you with the full details of the project. Also if you have more than one site, it would be great if you let me know so we can see if it's suitable for any of our other campaigns. Many thanks Annie-Mai EditorialPR.com This e-mail message (and its attachments) may contain confidential, proprietary or legally privileged information and is intended only for the individual named addressee. You should not review, disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmissions cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete or contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of the message. --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Strange build error
Zoltan Gyarmati https://zgyarmati.de On 08/29/2017 02:33 AM, Philip Prindeville wrote: >> On Aug 28, 2017, at 6:17 PM, Zoltan Gyarmati >> wrote: >> >> On 08/28/2017 01:52 PM, Zoltan Gyarmati wrote: >>> Dear All, >>> >>> i'm fighting with an odd build error on my build server VPS, using >>> current master and the RT5350F-OLINUXINO profile: >>> >>> When trying to re-build the LEDE tree (after a successful initial >>> build), i get this error: >>> make[5]: Entering directory '/home/zgyarmati/lede/build_dir/target-mipsel_24kc_musl/linux-ramips_rt305x/linux-4.9.44' CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHK include/generated/compile.h GEN usr/initramfs_data.cpio AS usr/initramfs_data.o LD usr/built-in.o AR lib/lib.a EXPORTS lib/lib-ksyms.o LD lib/built-in.o LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h lib/lib.a(decompress.o):(.init.rodata+0x2c): undefined reference to `unlzma' lib/lib.a(decompress.o):(.init.rodata+0x38): undefined reference to `unlzma' Makefile:972: recipe for target 'vmlinux' failed >>> The odd thing is that the same config on my laptop (Debian >>> testing/Buster) builds and rebuilds correctly, while on the VPS (Debian >>> 9/Stretch) it fails with the error above. >>> I've checked all the dependencies, digged into the environment to figure >>> out what is the significant difference, but i couldn't hunt this down. >>> My best guess it that is related to the fact that the build server runs >>> on a VPS, but no solid evidence on this yet... >>> >>> Do you have maybe an idea where to look? >>> >> I've tried cross check with building and rebuilding Atheros >> AR7xxx/AR9xxx/8devices Carambola2 profle, >> and it builds and rebuilds without the error above in the same >> environment... > > I’ll ask the obvious question… Are the .config files identical in both cases? > > -Philip > Yes, and anyway, the problem persist if i just do a `make menuconfig`, and select 'MediaTek Ralink MIPS -- RT3x5x/RT5350 based boards -- RT5350F-OLinuXino' target profile, so it doesn't seem to be an issue with my own .config. Since than i've ran a build without ccache, but got the same result... signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 4/4] ramips/RT5350F-OLINUXINO(-EVB) dts: enable ttyS1
Hi, comment inline On 26/08/17 21:54, Zoltan Gyarmati wrote: The RT5350F's second UART pins are available on the base module and on the EVB as well, so enable it in the device tree. Additionaly, the uartlite@c00 and uart@500 nodes swapped in rt5350.dtsi to keep the serial console as ttyS0. Signed-off-by: Zoltan Gyarmati --- target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi | 11 +- target/linux/ramips/dts/rt5350.dtsi| 30 +- 2 files changed, 25 insertions(+), 16 deletions(-) diff --git a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi index 955a13cddd..1632f3c085 100644 --- a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi +++ b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi @@ -46,9 +46,13 @@ &pinctrl { state_default: pinctrl0 { gpio { - ralink,group = "jtag", "rgmii", "mdio", "uartf"; + ralink,group = "jtag", "rgmii", "mdio"; ralink,function = "gpio"; }; + uartf_gpio { + ralink,group = "uartf"; + ralink,function = "gpio uartf"; + }; }; }; @@ -77,3 +81,8 @@ &i2c { status = "okay"; }; + +&uart { + status = "okay"; +}; + diff --git a/target/linux/ramips/dts/rt5350.dtsi b/target/linux/ramips/dts/rt5350.dtsi index a92c113043..f027e17d9d 100644 --- a/target/linux/ramips/dts/rt5350.dtsi +++ b/target/linux/ramips/dts/rt5350.dtsi @@ -83,21 +83,6 @@ interrupts = <3>; }; - uart: uart@500 { - compatible = "ralink,rt5350-uart", "ralink,rt2880-uart", "ns16550a"; - reg = <0x500 0x100>; - - resets = <&rstctrl 12>; - reset-names = "uart"; - - interrupt-parent = <&intc>; - interrupts = <5>; - - reg-shift = <2>; - - status = "disabled"; - }; - gpio0: gpio@600 { compatible = "ralink,rt5350-gpio", "ralink,rt2880-gpio"; reg = <0x600 0x34>; @@ -221,6 +206,21 @@ reg-shift = <2>; }; + uart: uart@500 { + compatible = "ralink,rt5350-uart", "ralink,rt2880-uart", "ns16550a"; + reg = <0x500 0x100>; + + resets = <&rstctrl 12>; + reset-names = "uart"; + + interrupt-parent = <&intc>; + interrupts = <5>; + + reg-shift = <2>; + + status = "disabled"; + }; moving the node makes no sense. the change is a no-op. please remove it and update the patch description John + systick: systick@d00 { compatible = "ralink,rt5350-systick", "ralink,cevt-systick"; reg = <0xd00 0x10>; ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 13/13] sunxi: Add A64 support with cortex53 subtarget
On 29-08-17, Baptiste Jonglez wrote: > Hi, > > On 03-08-17, Hauke Mehrtens wrote: > > This adds initial support for the A64 Allwinner SoC to LEDE. > > It will be build in the new cortexa53 subtarget. > > > > Currently it only supports the pine64 and the image is able to boot on > > this SoC. > > Thanks for the patches! > > I tested them on a pine64+ 1GB but it does not seem to work: the green NIC > LED keeps blinking on and off and the device stays unreachable from the > network. If I force the other end to use 100baseTx-FD, the green NIC LED > stays on instead of blinking, but the device is still unreachable. I just found this comment in the DTS: /* TODO: Camera, Ethernet PHY, touchscreen, etc. */ So, the non-working NIC seems to be expected: this should be more apparent in the patch descriptions to avoid surprises :) (I totally understand that this patch series is about preliminary support for the board) > I will soon look at it more closely with a serial cable. > > > Signed-off-by: Hauke Mehrtens > > --- > > target/linux/sunxi/Makefile | 2 +- > > target/linux/sunxi/cortexa53/config-default | 100 > > > > target/linux/sunxi/cortexa53/target.mk | 13 > > target/linux/sunxi/image/Makefile | 1 + > > target/linux/sunxi/image/cortex-a53.mk | 20 ++ > > 5 files changed, 135 insertions(+), 1 deletion(-) > > create mode 100644 target/linux/sunxi/cortexa53/config-default > > create mode 100644 target/linux/sunxi/cortexa53/target.mk > > create mode 100644 target/linux/sunxi/image/cortex-a53.mk > > > > diff --git a/target/linux/sunxi/Makefile b/target/linux/sunxi/Makefile > > index 65d43358c9..982eecbcbd 100644 > > --- a/target/linux/sunxi/Makefile > > +++ b/target/linux/sunxi/Makefile > > @@ -11,7 +11,7 @@ ARCH:=arm > > BOARD:=sunxi > > BOARDNAME:=Allwinner A1x/A20/A3x > > FEATURES:=fpu usb ext4 display rtc squashfs > > -SUBTARGETS:=cortexa8 cortexa7 > > +SUBTARGETS:=cortexa8 cortexa7 cortexa53 > > MAINTAINER:=Zoltan HERPAI > > > > KERNEL_PATCHVER:=4.9 > > diff --git a/target/linux/sunxi/cortexa53/config-default > > b/target/linux/sunxi/cortexa53/config-default > > new file mode 100644 > > index 00..58ac214695 > > --- /dev/null > > +++ b/target/linux/sunxi/cortexa53/config-default > > @@ -0,0 +1,100 @@ > > +CONFIG_64BIT=y > > +CONFIG_ARCH_DMA_ADDR_T_64BIT=y > > +CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y > > +CONFIG_ARCH_HAS_GIGANTIC_PAGE=y > > +CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y > > +CONFIG_ARCH_HAS_KCOV=y > > +CONFIG_ARCH_MMAP_RND_BITS=18 > > +CONFIG_ARCH_MMAP_RND_BITS_MAX=24 > > +CONFIG_ARCH_MMAP_RND_BITS_MIN=18 > > +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11 > > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y > > +CONFIG_ARCH_SPARSEMEM_DEFAULT=y > > +CONFIG_ARCH_SPARSEMEM_ENABLE=y > > +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y > > +CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y > > +CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y > > +CONFIG_ARCH_WANT_FRAME_POINTERS=y > > +CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y > > +CONFIG_ARM64=y > > +# CONFIG_ARM64_16K_PAGES is not set > > +CONFIG_ARM64_4K_PAGES=y > > +# CONFIG_ARM64_64K_PAGES is not set > > +CONFIG_ARM64_CONT_SHIFT=4 > > +# CONFIG_ARM64_CRYPTO is not set > > +# CONFIG_ARM64_HW_AFDBM is not set > > +# CONFIG_ARM64_LSE_ATOMICS is not set > > +CONFIG_ARM64_PAGE_SHIFT=12 > > +# CONFIG_ARM64_PAN is not set > > +# CONFIG_ARM64_PTDUMP is not set > > +# CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET is not set > > +# CONFIG_ARM64_UAO is not set > > +CONFIG_ARM64_VA_BITS=39 > > +CONFIG_ARM64_VA_BITS_39=y > > +# CONFIG_ARM64_VA_BITS_48 is not set > > +# CONFIG_ARM64_VHE is not set > > +CONFIG_ARM_AMBA=y > > +CONFIG_ARM_GIC_V3=y > > +# CONFIG_ARM_SBSA_WATCHDOG is not set > > +# CONFIG_ARM_SP805_WATCHDOG is not set > > +CONFIG_AUDIT_ARCH_COMPAT_GENERIC=y > > +# CONFIG_COMMON_CLK_VERSATILE is not set > > +CONFIG_COMMON_CLK_XGENE=y > > +# CONFIG_COMPAT is not set > > +# CONFIG_DEBUG_ALIGN_RODATA is not set > > +CONFIG_DEBUG_RODATA=y > > +CONFIG_FRAME_POINTER=y > > +# CONFIG_FSL_ERRATUM_A008585 is not set > > +CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y > > +CONFIG_GENERIC_CPU_AUTOPROBE=y > > +CONFIG_GENERIC_CSUM=y > > +CONFIG_GENERIC_IRQ_MIGRATION=y > > +CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y > > +CONFIG_HAVE_ARCH_HUGE_VMAP=y > > +CONFIG_HAVE_ARCH_KASAN=y > > +CONFIG_HAVE_CMPXCHG_DOUBLE=y > > +CONFIG_HAVE_CMPXCHG_LOCAL=y > > +CONFIG_HAVE_DEBUG_BUGVERBOSE=y > > +CONFIG_HAVE_EBPF_JIT=y > > +CONFIG_HAVE_KVM_MSI=y > > +CONFIG_HAVE_MEMORY_PRESENT=y > > +CONFIG_HAVE_PATA_PLATFORM=y > > +CONFIG_ILLEGAL_POINTER_VALUE=0xdead > > +# CONFIG_KASAN is not set > > +CONFIG_KERNEL_MODE_NEON=y > > +CONFIG_KVM_ARM_PMU=y > > +CONFIG_KVM_ARM_VGIC_V3_ITS=y > > +CONFIG_MODULES_USE_ELF_RELA=y > > +CONFIG_NEED_SG_DMA_LENGTH=y > > +CONFIG_NO_IOPORT_MAP=y > > +# CONFIG_NUMA is not set > > +CONFIG_PARTITION_PERCPU=y > > +# CONFIG_PCI_DOMAINS is not set > > +# CONFIG_PHY_XGENE is not set > > +# CONFIG_PINCTRL_GR8 is not set > > +# CONF
Re: [LEDE-DEV] Recent issues w/ sysupgrade
On 29-08-17 09:09, Philip Prindeville wrote: > Hi all, > > I don’t know if sysupgrade is the problem, or if this is where things > manifest. > > But I recently (within the last week, but I only rebase once or twice a week) > started seeing issues with doing sysupgrade on x86_64 hardware. > > The sysupgrade will appear to go okay, but then when the machine reboots, I > see: > > ... > Press the [f] key and hit [enter] to enter failsafe mode > Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level > [6.322701] mount_root: loading kmods from internal overlay > [6.331183] kmodloader: loading kernel modules from //etc/modules-boot.d/* > [6.339194] kmodloader: done loading kernel modules from > //etc/modules-boot.d/* > [6.470650] block: attempting to load /etc/config/fstab > [6.483431] block: extroot: not configured > [6.488267] random: procd: uninitialized urandom read (4 bytes read) > [6.506070] mount_root: rootdisk overlay filesystem has not been formatted > yet > > > Is this related to the mk.f2f changes on Thursday? I doubt this will be related. The only real change is https://git.lede-project.org/cdb494fd, and on little endian systems cpu_to_le64 is a noop. Additionaly I tested this on x86/64 and didn't notice any isses. Just look a bit further and you should see this: Tue Aug 29 07:12:57 2017 user.info kernel: [ 5.607837] mount_root: overlay filesystem has not been fully initialized yet Tue Aug 29 07:12:57 2017 user.info kernel: [ 5.608986] mount_root: switching to f2fs overlay root@LEDE:~# mount | grep overlay /dev/loop0 on /overlay type f2fs (rw,lazytime,noatime,background_gc=on,user_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6) overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work) Stijn ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev