**** BEGIN LOGGING AT Mon Feb 25 02:59:57 2019 Feb 25 08:55:25 stintel: latest kernel bump in master contained a few commits for memory leaks on network level. dit it solve your leak by any chance? Feb 25 08:55:55 xback: ooh interesting. I have not built a new image for the device where I have the most impact, but I'll try to do that soonish Feb 25 08:56:03 xback: thanks for the heads-pu Feb 25 10:40:18 so adding the dependency on kmod-input-core to kmod-input-touchscreen-ads7846 fixed most targets Feb 25 10:40:34 but there are some extra symbols exposed on several targets Feb 25 10:40:46 should I add those symbols to generic configs, or to the target specific configs Feb 25 10:41:32 for the interested: kernel bumps pushed to my staging Feb 25 10:42:21 I would say target ... like CONFIG_TOUCHSCREEN_IPROC, it is only going to be exposed ever if ARCH_BCM_IPROC=y Feb 25 10:42:32 which is only the case in bcm53xx Feb 25 10:42:46 xback: what do you think about that? Feb 25 10:42:58 I'd like to push out fixes but stuck on deciding that :) Feb 25 10:43:53 stintel: add it to the kmod? adding it to the target configs will only make working with make kernel_*config harder, as these will then be removed every time Feb 25 10:59:07 ideally the target configs are in a state where running make kernel_defconfig will leave them unmodified **** BEGIN LOGGING AT Mon Feb 25 10:59:24 2019 Feb 25 11:32:08 xback: ath79 Archer C7 v2 is happy here with the bump Feb 25 11:32:29 KanjiMonster: do you see a problem with adding them to generic config ? Feb 25 11:32:33 ldir: great. thanks :) Feb 25 11:35:07 stintel: if it's its own driver, then generic config is fine Feb 25 11:35:41 if it had been an option for a driver, then it should be part of the kmod's KCONFIG Feb 25 11:39:39 KanjiMonster: it's its own driver Feb 25 11:39:49 KanjiMonster: thanks, I will add the missing ones to the generic config Feb 25 11:39:59 to fix last part of the fallout Feb 25 13:45:18 barf. sysupgraded my virtual router and I arrive at a grub prompt Feb 25 13:50:02 nice. anyone build x86 image recently? factory image -> grub prompt Feb 25 14:01:39 error: ext4_allocate_best_fit_partial: failed to allocate 35 blocks, out of space? Feb 25 14:01:46 bah. that should really be a fatal error Feb 25 14:03:56 because of that there is no kernel image, yet the process continues and I end up with an image without kernel which obviously doesn't boot Feb 25 14:09:07 stintel: I've just tried to boot http://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-combined-squashfs.img.gz in QEMU and it works Feb 25 14:09:22 OpenWrt SNAPSHOT, r9428-0b4b1027c6 Feb 25 14:09:30 ynezz: I tried the same, and yes it works. must be LXC or other extra kernel options that cause my kernel to be > 4MB Feb 25 14:09:57 last time I do a "quick fix and test" during lunch break Feb 25 14:10:35 or just optimize more and do lunch&dinner break :) Feb 25 14:12:51 increasing CONFIG_TARGET_KERNEL_PARTSIZE to 8 seems to fix my issue Feb 25 14:40:30 stintel: anyway, making making `error: ext4_allocate_best_fit_partial:` fatal is a good point Feb 25 14:41:24 I can look into it if I find some time after work Feb 25 14:58:16 i made a config that causes Apple devices to stop all their network traffic after some time. like not sending ACK after SYN,ACK, etc. on release and selfbuilt images from git. could someone please have a quick look and spot a messup with my config: http://gw.mokka.at/firmware/etc.tar.gz or alternativly plain text: http://gw.mokka.at/firmware/etc/ Feb 25 14:59:17 the device is using the mt76 where issues like connection drops are reportet but nothing like the issue i'm facing Feb 25 16:07:20 Where in the build system can the UBI volume name for the root filesystem be changed from "rootfs" to, in my case, "ubifs" ? Feb 25 16:08:27 At least grep of ./include/ or ./target/linux/ isn't revealing anything obvious to me Feb 25 16:08:38 as far as a "tunable" goes Feb 25 16:10:59 (reason is an ARM bootloader that passes `root=ubi0:ubifs` and being able to install without cracking the case to change U-Boot env) Feb 25 16:12:52 (at least confirming that it doesn't work, as setting `root=ubi0:rootfs` fails to mount the root filesystem) Feb 25 16:15:19 jeffsf: https://github.com/openwrt/openwrt/blob/master/target/linux/generic/pending-4.14/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch Feb 25 16:17:35 Awesome, thanks! I'll look at that -- I've been beating on rch/arm/boot/compressed/atags_to_fdt.c rather unsucessfully Feb 25 16:25:42 jeffsf: what does the rootfstype= from your commandline say? if it doesn't include squashfs, it might fail for that reason Feb 25 16:26:41 OEM config of bootloader provides init=/sbin/init rootfstype=ubifs ubi.mtd=11,2048 root=ubi0:ubifs rootwait rw Feb 25 16:27:09 where ubi.mtd selects which of the two firmware images to boot from (11 or 13) Feb 25 16:27:17 or, well, is being booted from Feb 25 16:29:44 Working override is `set bootargs ubi.mtd=11 root=/dev/ubiblock0_0` (then "normal" NAND boot from U-Boot) Feb 25 16:35:25 (trying adding CONFIG_MTD_ROOTFS_ROOT_DEV now to see what happens) Feb 25 16:38:11 OK, `gunzip -c /proc/config.gz | fgrep CONFIG_MTD_ROOTFS_ROOT_DEV` says it's already there, but later in the boot process seems easier to work with than the very early boot phase Feb 25 17:38:18 Hello all, I have ported Archer-C5-v1 to ath79. Everything works fine, except upgrading. I had to force sysupgrade, because of following error during sysupgrade: Feb 25 17:38:26 Device archer-c5 not supported by this image Feb 25 17:38:29 Supported devices: tplink,archer-c5-v1 Feb 25 17:38:30 Image check 'fwtool_check_image' failed. Feb 25 17:38:38 Is that acceptable? Feb 25 17:44:01 use SUPPORTED_DEVICES Feb 25 17:47:59 If i add "SUPPORTED_DEVICES += archer-c5" to the device define it should work? Feb 25 17:48:43 terual: yes Feb 25 17:49:28 Thanks Feb 25 18:05:49 DonkeyHotei: Looks like it has REOOT_DEV at that point `ubiblock: Checking for rootfs; vi->name: 'rootfs', ROOT_DEV: 32505867` (added pr_notice) Feb 25 18:06:12 But at least I can track back things to find out where to modulate that Feb 25 18:27:49 lynxis: ping Feb 25 19:25:59 All Kernel 4.14 and later are at least DTB _aware_ as in won't crash on DTB reads, even if the target doesn't use DTBs, correct? Feb 25 19:27:08 (namely, can safely try to read a property from the /chosen node, even if not a DTB boot) Feb 25 20:18:17 aparcar[m]: pong Feb 25 20:27:40 jeffsf: are you jeff kletsky by any chance? Feb 25 20:28:53 if so, re https://bugs.openwrt.org/index.php?do=details&task_id=2123, can you try https://github.com/openwrt/openwrt/pull/1862 and https://github.com/openwrt/openwrt/pull/1861 Feb 25 20:30:49 Yes, I am Feb 25 20:31:19 I will be able to try this evening, US Pacific time Feb 25 20:34:04 Reading them, I can definitely checkl 1861 against "classic" ath10k; checking 1862 _may_ be limited by CT firmware support, but I'll check it as well Feb 25 20:37:27 we set mcast_rate in our firmware and have checked meshing on openwrt master without problems, plain and encrypted Feb 25 20:38:00 we set mcast_rate in our firmware and have checked meshing on openwrt master without problems, plain and encrypted Feb 25 20:56:52 hexa-: Thanks, really appreciate finding what looks to be the root cause. I'll definitely check this evening! Feb 25 21:19:34 jeffsf: I wonder if you're knowledgable about SAEs security properties Feb 25 21:19:51 Past "works for me", alas, no Feb 25 21:20:59 meh. -- I'm wondering what security properties are broken when the PSK is public knowledge Feb 25 21:21:16 like if the derived session key is still somewhat safe, at least from passive attacks Feb 25 21:29:43 I have vague thoughts, and don't base much on this, that the SAE is around confirming identity of the other party, not on setting up the encryption Feb 25 21:30:17 yup, the psk is primarily used to solve the authentication problem of plain diffie hellman Feb 25 21:31:06 the rfc defines the password among other things as a "potentially low-entropy word" Feb 25 21:31:24 I have gone under the assumption, perhaps wrongly, that the channel encryption is comparable to other 802.11 encryption -- which, in my case, means you had better be encrypting the data you're sending over the channel securely ;) Feb 25 21:32:35 well, it's transport crypto, so going with e2ee is the usual recommendation Feb 25 21:35:19 hexa-, regarding the PSK, you can only decrypt if you have the handshake Feb 25 21:35:40 and you can only decrypt that specific session Feb 25 21:35:44 yup, I assumed as much, so only active attacks are an issue Feb 25 21:36:02 like deauthenticate the session and capture the handshake Feb 25 21:36:05 not really Feb 25 21:36:18 the station will reauth from time to time Feb 25 21:36:24 so redoing the handshake Feb 25 21:36:29 hm ouch Feb 25 21:36:46 APs sometimes send deauth too Feb 25 21:37:13 not as many as in the average attack though Feb 25 21:37:28 so when I capture the handshake and know the PSK I cant decrypt the session? Feb 25 21:37:42 s/cant/can/ Feb 25 21:38:22 yes Feb 25 21:38:27 for that specific user Feb 25 21:38:59 if he reauth and don't get that handshake, that new session can't be decrypted Feb 25 21:41:29 ok, so better than nothin at all Feb 25 22:43:48 asked a couple days ago but no response - any suggestions on how to get a proper stack trace w/gdb on ath79? i've rebuilt userland and placed it on overlay - all symbols are there. however i've just been getting "warning: Warning: GDB can't find the start of the function at 0x7fff3048" after the debugged program crashes. that's with all symbols, no strip. musl, stackprotector, ath79 Feb 25 22:44:19 about to give up and rebuild with glibc :/ Feb 25 23:45:22 m4t: gdb requires that you use regular string instead of sstrip AFAIK Feb 25 23:45:30 *strip Feb 25 23:45:40 mangix: everything is completely unstripped Feb 25 23:46:11 ah, no idea then Feb 25 23:47:50 :( Feb 25 23:55:07 could be that it's clobbering it so badly that it can't get a trace Feb 25 23:55:14 im rebuilding with glibc Feb 25 23:57:23 and without ssp etc Feb 26 01:32:08 Can I strangle whoever decided that "the bootloader is always right" for ARM platforms? Feb 26 01:32:51 Upside is I'm learning more about init than I ever wanted to Feb 26 01:37:59 i don't think anyone decided that for ALL arm Feb 26 01:40:57 Sigh -- at least one too many for me Feb 26 01:41:49 It doesn't look like this board gets ATAGs, just the FTD, so the "old" command line hacks don't work Feb 26 01:42:22 s/FTD/FDT/ -- don't need any flowers :wink: Feb 26 01:42:44 kernel can override any of that Feb 26 01:43:13 Yeah, trying to figure out where, without destroying all other devices on the same platform Feb 26 01:44:04 Thinking that if I can do0 it in init, then I can pass the init arg in with /chosen/bootargs-append after -- Feb 26 01:44:46 Makes it "safe" for anyone not passing the magic init arg Feb 26 01:45:16 ynezz: Is this related to your tx timeout patch for ath79? https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/drivers/net/ethernet/atheros/ag71xx?h=NHSS.ILQ.2.15&id=7b3504ee3cea29500c86db080e02f7520f25501a Feb 26 01:45:27 (Until some "smart" OEM decides to pass init args from the bootloader) Feb 26 02:00:23 most device tree based archs ignore the bootloader cmdline, dual-boot capable devices just need to parse it for the to-be-booted partition set. Feb 26 02:01:00 Bootloader command line (ignored): board=NBG6817 root=/dev/mmcblk0p5 rootwait zld_ver=2.04 console=ttyHSL1,115200n8 mtdparts=m25p80:0xC0000(SBL)ro,0x40000(TZ)ro,0x40000(RPM)ro,0x80000(u-boot)ro,0x10000(env)ro,0x10000(ART)ro,0x10000(dualflag),0x210000(reserved) ---> Kernel command line: rootfstype=squashfs,ext4 rootwait noinitrd root=/dev/mmcblk0p5 Feb 26 02:06:31 I'll look at that again, but I haven't had any luck with the command-line mangling patches in arch/arm/boot/compressed/atags_to_fdt.c **** ENDING LOGGING AT Tue Feb 26 02:59:57 2019