Re: [LEDE-DEV] hostapd: cli treat UNKNOWN COMMAND as failing
I'll get git send-email configured with a working SMTP server and send
this again, even in plain text mode my email client wrapped the lines.
On Sat, Apr 8, 2017 at 8:33 PM, Denton Gentry wrote:
> Avoid infinite loop at 100% CPU when running hostapd_cli
> if CONFIG_CTRL_IFACE_MIB is not defined.
>
> _newselect(4, [3], NULL, NULL, ...)
> recvfrom(3, "UNKNOWN COMMAND\n", 4095, 0, NULL, NULL) = 16
> sendto(3, "STA-NEXT UNKNOWN COMMAND", 24, 0, NULL, 0) = 24
>
> Signed-off-by: Denton Gentry
> ---
> .../patches/381-hostapd_cli_UNKNOWN-COMMAND.patch | 35
> ++
> 1 file changed, 35 insertions(+)
>
> create mode 100644
> package/network/services/hostapd/patches/381-hostapd_cli_UNKNOWN-COMMAND.patch
>
> diff --git
> a/package/network/services/hostapd/patches/381-hostapd_cli_UNKNOWN-COMMAND.patch
> b/package/network/services/hostapd/patches/381-hostapd_cli_UNKNOWN-COMMAND.patch
> new file mode 100644
> index 000..0e0a763
> --- /dev/null
> +++
> b/package/network/services/hostapd/patches/381-hostapd_cli_UNKNOWN-COMMAND.patch
> @@ -0,0 +1,35 @@
> +From e41c99b9ca39d1be92ff67e2ab4e90b30bc2c247 Mon Sep 17 00:00:00 2001
> +From: Denton Gentry
> +Date: Sat, 8 Apr 2017 23:55:07 +
> +Subject: [PATCH] hostapd_cli: FAIL and UNKNOWN COMMAND are errors.
> +
> +Otherwise, running hostapd_cli without having
> +CONFIG_CTRL_IFACE_MIB defined results in an infinite
> +loop at 100% CPU:
> +
> +_newselect(4, [3], NULL, NULL, {tv_sec=10, tv_usec=0}) = 1 (in [3],
> left {tv_sec=9, tv_usec=87})
> +recvfrom(3, "UNKNOWN COMMAND\n", 4095, 0, NULL, NULL) = 16
> +sendto(3, "STA-NEXT UNKNOWN COMMAND", 24, 0, NULL, 0) = 24
> +_newselect(4, [3], NULL, NULL, {tv_sec=10, tv_usec=0}) = 1 (in [3],
> left {tv_sec=9, tv_usec=89})
> +recvfrom(3, "UNKNOWN COMMAND\n", 4095, 0, NULL, NULL) = 16
> +sendto(3, "STA-NEXT UNKNOWN COMMAND", 24, 0, NULL, 0) = 24
> +---
> + hostapd/hostapd_cli.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/hostapd/hostapd_cli.c b/hostapd/hostapd_cli.c
> +index a2fd9ac..a6e1289 100644
> +--- a/hostapd/hostapd_cli.c
> b/hostapd/hostapd_cli.c
> +@@ -771,7 +771,7 @@ static int wpa_ctrl_command_sta(struct wpa_ctrl
> *ctrl, const char *cmd,
> + }
> +
> + buf[len] = '\0';
> +- if (memcmp(buf, "FAIL", 4) == 0)
> ++ if (memcmp(buf, "FAIL", 4) == 0 || memcmp(buf, "UNKNOWN
> COMMAND", 15) == 0)
> + return -1;
> + if (print)
> + printf("%s", buf);
> +--
> +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] Planning v17.01.1
Hi, I'd like to start preparing the v17.01.1 release during the upcoming week with the goal to release final binaries during the easter holidays (~14.04. - 17.04.). You can find the current list of changes since v17.01.0 at https://lede-project.org/releases/17.01/changelog-17.01.1 If you want specific fixes cherry-picked/backported to lede-17.01, please mention them in a reply to this mail. If you have any objections to the release time frame, please speak up :) Also, please reply with a quick ACK / NACK on whether you'd like to see an -RC build before 17.01.1 final. Thanks, Jo 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] Planning v17.01.1
On 04/09/2017 10:14 AM, Jo-Philipp Wich wrote: > Hi, > I'd like to start preparing the v17.01.1 release during the upcoming > week with the goal to release final binaries during the easter holidays > (~14.04. - 17.04.). > You can find the current list of changes since v17.01.0 at > https://lede-project.org/releases/17.01/changelog-17.01.1 > If you want specific fixes cherry-picked/backported to lede-17.01, > please mention them in a reply to this mail. > If you have any objections to the release time frame, please speak up :) > Also, please reply with a quick ACK / NACK on whether you'd like to see > an -RC build before 17.01.1 final. > Thanks, > Jo Hi Jo, An RC may attract some people unsure of building their own. The wider feedback may sort out a few bugs before final release. Thanks for the continued effort. Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Sysupgrade on Mikrotik RB912
Hello Edwin, On Mon, Mar 20, 2017 at 4:04 PM, Edwin van Drunen wrote: > * Longer story: > The installation procedure for LEDE 17.01 on Mikrotik RB-912 boards should be > as follows: > - TFTP boot the board using the "vmlinux-initramfs.elf” image > - scp the "squashfs-sysupgrade.bin” image to /tmp Which exactly image did you use 'nand-64m' or 'nand-large'? > - use sysupgrade to install the LEDE sysupgrade image > > After a reboot the system will always attempt to boot from the network, > because a kernel can not be found. > The MTD6 partition (previously rootfs) is now in UBI format and hosts the > kernel and the root partitions inside. > But routerboot looks for a kernel in MTD5 and (probably?) only supports YAFFS. > > I was able to get LEDE to boot by doing these extra steps: > - TFTP boot an old OpenWRT initramfs image (14.07) that supports YAFFS > - MTD erase /dev/mtd5 > - mount /dev/mtdblock5 /mnt > - copy the LEDE LZMA kernel image to /mnt, renaming it to “kernel” and chmod > a+x. > > The kernel loads just fine from the YAFFS partition and the rootfs is mounted > using UBIFS (as overlay on squashfs), which is a big improvement over YAFFS. > But now I will not be able to sysupgrade to a newer version of LEDE and can’t > access the kernel partition, because YAFFS is not supported on LEDE. > > Am I missing something or is this just the way it is for now? I test new sysupgrade with several Mikrotik boards (RB912 in particular) and despite some ambiguous it works like a charm. Most notable is selection of proper image from two's available: "nand-64m" or "nand-large". You could find related discussion here [1]. In short, you should use 'nand-64m' image for NAND with 512-bytes pages, and 'nand-large' for NAND with 2048-bytes pages. All RB912 boards which I saw are equipped with NAND IC with 2048-bytes pages, so the common choise for this boards is 'nand-large-squashfs-sysupgrade.bin' image. 1. Mikrotik RB411AH sysupgrade issues // http://lists.infradead.org/pipermail/lede-dev/2017-February/006195.html -- Sergey ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Sysupgrade on Mikrotik RB912
Hello Sergey, My RB912 boards came with 2048-byte pages and I installed the nand-large image, specifically: https://downloads.lede-project.org/releases/17.01.0/targets/ar71xx/mikrotik/lede-17.01.0-r3205-59508e3-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin I have installed it on 23 boards so far and none would boot after a regular sysupgrade. They all needed the kernel partition (MTD5) to be formatted to YAFFS and the kernel manually copied. I used this initramsfs image: https://downloads.lede-project.org/releases/17.01.0/targets/ar71xx/mikrotik/lede-17.01.0-r3205-59508e3-ar71xx-mikrotik-vmlinux-initramfs.elf This problem and the solution were mentioned before on this mailing list, but I never got a definite answer on if this is normal behaviour. Now I am curious to know if your boards are maybe different or there is some other small detail I am not getting right. Met vriendelijke groet / With kind regards, Edwin van Drunen > On 9 Apr 2017, at 18:37, Sergey Ryazanov wrote: > > Hello Edwin, > > On Mon, Mar 20, 2017 at 4:04 PM, Edwin van Drunen wrote: >> * Longer story: >> The installation procedure for LEDE 17.01 on Mikrotik RB-912 boards should >> be as follows: >> - TFTP boot the board using the "vmlinux-initramfs.elf” image >> - scp the "squashfs-sysupgrade.bin” image to /tmp > > Which exactly image did you use 'nand-64m' or 'nand-large'? > >> - use sysupgrade to install the LEDE sysupgrade image >> >> After a reboot the system will always attempt to boot from the network, >> because a kernel can not be found. >> The MTD6 partition (previously rootfs) is now in UBI format and hosts the >> kernel and the root partitions inside. >> But routerboot looks for a kernel in MTD5 and (probably?) only supports >> YAFFS. >> >> I was able to get LEDE to boot by doing these extra steps: >> - TFTP boot an old OpenWRT initramfs image (14.07) that supports YAFFS >> - MTD erase /dev/mtd5 >> - mount /dev/mtdblock5 /mnt >> - copy the LEDE LZMA kernel image to /mnt, renaming it to “kernel” and chmod >> a+x. >> >> The kernel loads just fine from the YAFFS partition and the rootfs is >> mounted using UBIFS (as overlay on squashfs), which is a big improvement >> over YAFFS. >> But now I will not be able to sysupgrade to a newer version of LEDE and >> can’t access the kernel partition, because YAFFS is not supported on LEDE. >> >> Am I missing something or is this just the way it is for now? > > I test new sysupgrade with several Mikrotik boards (RB912 in > particular) and despite some ambiguous it works like a charm. > > Most notable is selection of proper image from two's available: > "nand-64m" or "nand-large". You could find related discussion here > [1]. > > In short, you should use 'nand-64m' image for NAND with 512-bytes > pages, and 'nand-large' for NAND with 2048-bytes pages. All RB912 > boards which I saw are equipped with NAND IC with 2048-bytes pages, so > the common choise for this boards is > 'nand-large-squashfs-sysupgrade.bin' image. > > 1. Mikrotik RB411AH sysupgrade issues // > http://lists.infradead.org/pipermail/lede-dev/2017-February/006195.html > > -- > Sergey signature.asc Description: Message signed with OpenPGP ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Planning v17.01.1
On 9.4.2017 17.14, Jo-Philipp Wich wrote: I'd like to start preparing the v17.01.1 release during the upcoming week with the goal to release final binaries during the easter holidays (~14.04. - 17.04.). ... Also, please reply with a quick ACK / NACK on whether you'd like to see an -RC build before 17.01.1 final. The proposed timing for 17.01.1 sounds good. NACK for rc. I see no need for rc1 as long as there is no last-minute rush to backport things on large scale. 17.01 builds have been so stable that there should be no major problems. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] MT7621 support Jumbo frames
Hello all, I found the message below in a conversation from back in August, 2016 in this mailinglist. I did not find a reply to this question. Has there ever been one? Or does anyone else happen to know the answer to this question? Thank you very much in advance. Yours sincerely, Jaap Buurman August, 2016 message: Hi all, in the MT7621 ethernet driver code (drivers/net/ethernet/mediatek/soc_mt7621.c) the FE_FLAG_JUMBO_FRAME flag is not during the device initialization. This prevents the user to set an MTU greater than 1500. Is this correct? Does MT7621 support jumbo frames? Thanks. -- gaetano catalli ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support
Hello Paul, Sorry for a late reply. On 06.04.2017 14:24, Paul Oranje wrote: Thanks for the info. The systematics for the generation of the build config from the makefiles is still quite obscure to me. A wiki lemma that puts some light in this would be welcome; once I do understand I may write one. That would be really kind. See my questions/comments/replies in-line below. Ciao, Paul Op 6 apr. 2017, om 09:51 heeft Piotr Dymacz het volgende geschreven: Hello Paul, On 05.04.2017 23:23, Paul Oranje wrote: Hello, I’m wondering how to make LEDE build automatically an initramfs image (for use with u-boot tftp recovery boot), when the ENH200EXT is selected as the target device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working image is build that can be tftp-booted alright, but I would prefer that it is build automatically beside the sysupgrade image. The context would, as requested, be "target/linux/ar71xx/image/generic.mk". The "generic" subtarget doesn't have included "ramdisk" feature: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2 It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS": https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34 Does that mean that the initramfs can only be triggered by manually setting “CONFIG_TARGET_ROOTFS_INITRAMFS=y” ? AFAIK, yes. That would mean that the LEDE build-bots would not generate initramfs images and people would need for the initial install to build such images themselves. Likely I’ve not understood well how it works and what follows hints how to do it. https://github.com/lede-project/source/blob/master/config/Config-images.in#L11 On the other hand, "mikrotik" subtarget uses initramfs images as they are required for initial LEDE flash: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2 Adding "FEATURES += ramdisk” to the "Device/enh200ext” definition in "target/linux/ar71xx/image/generic.mk” does not work (tried it). "FEATURES" variable belongs to the target, not particular device and thus cannot be changed/extended like this. Since the initramfs is only needed for some ar71xx target profiles, the FEATURES declaration should not be set in “target/linux/ar71xx/generic/target.mk”. If the FEATURE should be set in the context of a target.mk, then a new makefile "target/linux/ar71xx/engenius/target.mk" would be needed, or to what other makefile could/should "FEATURES += ramdisk” then be added ? A separate subtarget just for one device is a bad idea. AFAIK, the only way to include initramfs by default would require extending "FEATURES" in ar71xx/generic subtarget target.mk config, but... Is the initramfs image required for initial LEDE image flash on your device or is it just useful with recovery mode? The stock firmware cannot install a LEDE factory image, so the initramfs image is indeed needed for the initial install. I'm not sure if enabling initramfs images for a whole subtarget just because of a single device makes sense at all. The preferred way is to have a working "factory" image for this device or at least detailed how-to for installing "sysupgrade" image inside vendor firmware, using some custom approach (failsafe?). Can you explain what/where is exactly problem with upgrade from vendor firmware to LEDE on your device? I have just extracted enh200ext-etsi-v1.5.1.0.bin (downloaded from [1]), and I see that it's based on very old OpenWrt version (KAMIKAZE, r20146). mtd and sysupgrade tools are there, also failsafe could be working. What's more, vendor upgrade script is just a regular shell script (/etc/fwupgrade.sh) and doesn't look complicated. With little bit more effort you should be able to find out (based on this script code) how to prepare a working "factory" image. If there is a working failsafe in this device, you could also make use of it and install LEDE with "mtd -r write...". [1] http://www.engeniusnetworks.com/product/product.php?c=14&s=34&p=92 -- Cheers, Piotr From what I have understood so far, the clause would be something like: define Device/enh200ext DEVICE_TITLE := Engenius ENH200EXT DEVICE_PACKAGES := rssileds BOARDNAME := ENH200EXT CONSOLE := ttyS0,115200 Side note: this is default under ar71xx target, drop this line in your next patch please. OK, I’ll drop the CONSOLE line. Defaults: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/image/Makefile#L99 -- Cheers, Piotr IMAGE_SIZE := 8192k IMAGES := initramfs.bin sysupgrade.bin MTDPARTS := spi0.0:256k(u-boot)ro,64k(u-boot-env),6272k(firmware),1536k(failsafe),64k(art)ro endef TARGET_DEVICES += enh200ext The sysupgrade image is build, but the initramfs image is not build. I suppose an IMAGE/initramfs declaration must be added, but I do not know
Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support
Hi Piotr, This is going to end up in a fairly steep learning proces for me, so it may take up a little more time; so when this small project may wait for your input so now and then, should not be a real problem. Still, solving this one might further a few other ones. As, usually see replies/question/comments below. As a side-note: the vendor firmware deployed OpenWrt with the Atheros LSDK 9.2 closed-source driver for the AR9285 wifi chip. Could that explain why LEDE with the ath9k driver maxes txpower at 16 dBm while the stock firmware maxes out at 27 (or 26 ?) dBm ? Thanks for taking your time, Paul > Op 9 apr. 2017, om 22:06 heeft Piotr Dymacz het volgende > geschreven: > > Hello Paul, > > Sorry for a late reply. > > On 06.04.2017 14:24, Paul Oranje wrote: >> Thanks for the info. >> The systematics for the generation of the build config from the makefiles is >> still quite obscure to me. A wiki lemma that puts some light in this would >> be welcome; once I do understand I may write one. > > That would be really kind. > >> See my questions/comments/replies in-line below. >> >> Ciao, >> Paul >> >> >>> Op 6 apr. 2017, om 09:51 heeft Piotr Dymacz het volgende >>> geschreven: >>> >>> Hello Paul, >>> >>> On 05.04.2017 23:23, Paul Oranje wrote: Hello, I’m wondering how to make LEDE build automatically an initramfs image (for use with u-boot tftp recovery boot), when the ENH200EXT is selected as the target device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working image is build that can be tftp-booted alright, but I would prefer that it is build automatically beside the sysupgrade image. The context would, as requested, be "target/linux/ar71xx/image/generic.mk". >>> >>> The "generic" subtarget doesn't have included "ramdisk" feature: >>> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2 >>> >>> It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS": >>> https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34 >> Does that mean that the initramfs can only be triggered by manually setting >> “CONFIG_TARGET_ROOTFS_INITRAMFS=y” ? > > AFAIK, yes. > >> That would mean that the LEDE build-bots would not generate initramfs images >> and people would need for the initial install to build such images >> themselves. Likely I’ve not understood well how it works and what follows >> hints how to do it. >> >>> https://github.com/lede-project/source/blob/master/config/Config-images.in#L11 >>> >>> On the other hand, "mikrotik" subtarget uses initramfs images as they are >>> required for initial LEDE flash: >>> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2 >> >> Adding "FEATURES += ramdisk” to the "Device/enh200ext” definition in >> "target/linux/ar71xx/image/generic.mk” does not work (tried it). > > "FEATURES" variable belongs to the target, not particular device and thus > cannot be changed/extended like this. Meanwhile I’ve spent some time browsing and inductively came to that very same conclusion. > >> Since the initramfs is only needed for some ar71xx target profiles, the >> FEATURES declaration should not be set in >> “target/linux/ar71xx/generic/target.mk”. If the FEATURE should be set in the >> context of a target.mk, then a new makefile >> "target/linux/ar71xx/engenius/target.mk" would be needed, or to what other >> makefile could/should "FEATURES += ramdisk” then be added ? > > A separate subtarget just for one device is a bad idea. AFAIK, the only way > to include initramfs by default would require extending "FEATURES" in > ar71xx/generic subtarget target.mk config, but… Fair enough. Does an added ramdisk feature result by default in building initramfs images for all profiles below the subtarget ? If so, would it be doable to undo that effect in the default Device/Profile/Build definition ? >>> Is the initramfs image required for initial LEDE image flash on your device >>> or is it just useful with recovery mode? >> The stock firmware cannot install a LEDE factory image, so the initramfs >> image is indeed needed for the initial install. > > I'm not sure if enabling initramfs images for a whole subtarget just because > of a single device makes sense at all. The preferred way is to have a working > "factory" image for this device or at least detailed how-to for installing > "sysupgrade" image inside vendor firmware, using some custom approach > (failsafe?). > > Can you explain what/where is exactly problem with upgrade from vendor > firmware to LEDE on your device? See below. > I have just extracted enh200ext-etsi-v1.5.1.0.bin (downloaded from [1]), and > I see that it's based on very old OpenWrt version (KAMIKAZE, r20146). mtd and > sysupgrade tools are there, also failsafe could be working. The sysupgrade command in incomplete (dependency on a missing component). But l
Re: [LEDE-DEV] MT7621 support Jumbo frames
Probably was not in the interest of the driver writers. Based on the copyrights though, it's mostly LEDE/OpenWRT developers. Try modifying the code to test if jumbo frames work. On Sun, 2017-04-09 at 21:20 +0200, Jaap Buurman wrote: > Hello all, > > I found the message below in a conversation from back in August, 2016 > in this mailinglist. I did not find a reply to this question. Has > there ever been one? Or does anyone else happen to know the answer to > this question? Thank you very much in advance. > > Yours sincerely, > > Jaap Buurman > > August, 2016 message: > > > Hi all, > > in the MT7621 ethernet driver code > (drivers/net/ethernet/mediatek/soc_mt7621.c) the FE_FLAG_JUMBO_FRAME > flag is not during the device initialization. This prevents the user > to set an MTU greater than 1500. Is this correct? Does MT7621 support > jumbo frames? > > Thanks. > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
