**** BEGIN LOGGING AT Thu Oct 18 03:00:00 2018 Oct 18 03:14:37 Monkeh: context? Oct 18 04:04:33 DonkeyHotei: Compex wifi module causes system not to boot. Person gets angry. Hours get wasted. Oct 18 04:05:10 obviously not the compex module i got Oct 18 04:06:01 Which is? Oct 18 04:08:20 https://wikidevi.com/wiki/Compex_WLE1216V5-20 Oct 18 04:09:13 That looks to have exactly the same problem. Oct 18 04:09:55 Among other non-standard connections. Oct 18 04:10:04 i'm connected through it atm, so it seems to work Oct 18 04:10:30 Sure, so did this one Oct 18 04:10:35 Until I put it in a machine you can't do that to. Oct 18 04:11:17 i have no plans at this time to put it in another machine Oct 18 04:11:42 That's nice. Oct 18 04:18:57 Hmm, may actually have to blame PCI instead Oct 18 04:21:33 Yes, I think I can blame PCI and Mikrotik Oct 18 06:36:16 Hauke: never touched AR10. But read some reports that UART images are broken at the moment. might be fixed with https://git.openwrt.org/e86cdf85a7d0bd189e3452ec9e754baa1cf8ab74. Haven't had the time to confirm the issue. Oct 18 07:04:15 pkgadd: thanks, I linked it in the bug report Oct 18 07:05:23 xhm Oct 18 07:05:34 kernel.panic_on_oops defaults to 1? Oct 18 07:53:57 * ldir wanders in Oct 18 07:56:46 jwh: if the device has NOR, you can use mtdoops function to log dmesg to plain storage Oct 18 07:57:59 xback: x86, so should be able to get away with a persistent buffer Oct 18 08:14:43 ldir: Bumping kernels atm .. Oct 18 08:15:48 xback: I thought I saw the lights dim ;-) Has there been another release, or are you doing 'stable-queue'? Oct 18 08:16:20 ldir: New release, posted an hour ago: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v4.14.77 Oct 18 08:16:51 it's not hit my feed reader..yet. Oct 18 08:17:20 aha! There it is. Oct 18 08:19:40 xback: are you going to the conference? Oct 18 08:21:06 yes Oct 18 08:21:31 arriving at midnight Sat-Sun Oct 18 08:23:16 ldir: you? Oct 18 08:23:48 yes - first one... to anything computery Oct 18 08:25:02 I missed the picture of your mega box yesterday...my network had a mega wobble just at the time you were posting links. Oct 18 08:25:53 it's a basic Dell machine, build into a 19" Oct 18 08:26:14 I can share a htop when it's building all targets later on ;) Oct 18 08:27:56 Somehow I doubt I can get such a purchase/machine past missus ldir..... quite rightly :-) Oct 18 08:28:13 We bought it 2nd handed Oct 18 08:28:28 hm, at this rate it may be easier if I just go from here straight to the summit Oct 18 08:29:00 iirc, it was about 4k or so (ex vat) Oct 18 08:51:55 * ldir has email sartura directly re the libssh CVE bump Oct 18 09:00:00 swalker: welll.... how was I meant to know that from your list :) but ok. Oct 18 09:13:18 karlp: you can use https://nvd.nist.gov/products/cpe/search/results?status=FINAL&orderBy=CPEURI&namingFormat=2.2&keyword=c-ares Oct 18 09:13:30 (minus the version id segment) Oct 18 09:18:06 also not sure if "cpe:/a:daniel_stenberg:c-ares" is still in use, it only yields 2 vulnerabilities in 2007 while "cpe:/a:c-ares_project:c-ares" shows vulnerabilities from 2016 and 2017 Oct 18 09:18:24 so I'd say that "cpe:/a:daniel_stenberg:c-ares" is either unofficial or deprecated Oct 18 09:19:09 this is what I get for trying to help :) Oct 18 09:19:22 (https://www.cvedetails.com/product/11384/Daniel-Stenberg-C-ares.html?vendor_id=613 vs. https://www.cvedetails.com/product/34754/C-ares-Project-C-ares.html?vendor_id=15926) Oct 18 09:19:22 but yeah, I was just looking at them all and thinking daniel stenberg is wrong. Oct 18 09:20:25 that might be something for the contribution guidelines Oct 18 09:20:49 are we meant to update to the explicit version CPE on every version bump or anything too? Oct 18 09:20:53 "lookup your packages cpe identifier through https://nvd.nist.gov/products/cpe/search/results?status=FINAL&orderBy=CPEURI&namingFormat=2.2&keyword=c-ares and if it is found, add it as PKG_CPE_ID" Oct 18 09:20:58 or something along these lines Oct 18 09:21:11 karlp: no Oct 18 09:21:26 this is something the processing tools should ifgure out themselves Oct 18 09:21:46 why are you searching for 2.2 not 2.3 btw? Oct 18 09:22:06 because currently people seem to have standardized on 2.2 in the packages repo Oct 18 09:22:18 2.3 uses a more elaborate format Oct 18 09:23:14 and I think a lot of things provided by 2.3 (mainly vectors / platform configurations) do not really apply to our packages Oct 18 09:23:54 iirc 2.3 would allow to express things like "libfoo is only vulnerable on ms windows with version 1.4+ Oct 18 09:24:23 but since we're mainly (only) interested in the org part (to find CVEs by package/source bundle) we do not need these extra attributes Oct 18 09:25:13 at least this is my perception of the current state of affairs Oct 18 09:27:09 jow: regarding ticket: https://bugs.openwrt.org/index.php?do=details&task_id=1830&order=id&sort=desc Oct 18 09:27:41 jow: I would re-enable support for MLC, what's your opinion on this? Oct 18 09:28:31 xback: seems we managed to paint ourselves in a corner again :) Oct 18 09:28:36 *into Oct 18 09:29:21 thoughts: if it was allowed in 17 it should be allowed in 18; and is there any viable alternative? Oct 18 09:29:50 Indeed .. the alternative is a "broken" device which worked perfectly before Oct 18 09:30:12 what is upstreams idea of properly using mlc flash? Oct 18 09:30:18 I've read the discussion on the mailinglist and some say that MLC usage could cause data loss Oct 18 09:30:36 how is MLC even visible to userland or kernel? Oct 18 09:30:37 bu I fully agree (and encoutered it myself) that ubifs itself is not handling power cuts well Oct 18 09:31:14 best part is that the design spec itself mentiones that it's not power cut proof .. Oct 18 09:32:12 xback: however I am usually not the guy to ask for kernel level decisions, I just spend way too much time talking Oct 18 09:32:24 best is to open a discussion on the mailing list Oct 18 09:32:41 ok. thanks for your advice Oct 18 09:33:11 I'm with pravel on this, MLC just has tighter margins for stuff than SLC, blockign MLC by type is just going to make things call themselves SLC so that they wrok, regardless of internal implementation. Oct 18 09:35:05 what are they suggesting people do with hardware with MLC flash instead? Oct 18 09:35:10 "run something else" ? Oct 18 09:35:36 karlp: https://lore.kernel.org/patchwork/patch/920344/ Oct 18 09:37:22 From an OpenWrt point of view. people are running an older version, upgrade to a new one .. device broke (due to MLC unsupported suddenly) Oct 18 09:38:18 ah R. Weinberger Oct 18 09:38:48 xback: yeah, I was just reading that, you pasted it earlier. Oct 18 09:39:00 what's the alternative fs for people on mlc nand? Oct 18 09:39:05 there is none Oct 18 09:39:13 buy hardware that works with the perfect mtd code Oct 18 09:39:26 not adapt the mtd code to work with the hardware ;) Oct 18 09:39:48 yeah, but the thing is, you can't know that ahead of time. Oct 18 09:40:04 and diverging attempts are claimed to be ahrd forks that are frowned upon Oct 18 09:40:13 I understand their reasoning, but it sounds like, "MLC nand? run something other than linux" Oct 18 09:40:19 exactly Oct 18 09:40:31 this hardware breaks my fine code, not my problem Oct 18 09:44:45 sight, this is going to end similar to the last time Oct 18 09:45:10 we're now forced to carry patches, and then upstream refuses to work with us because we "hard forked ubi!!" Oct 18 09:45:47 https://lists.openwrt.org/pipermail/openwrt-devel/2016-August/002191.html Oct 18 09:46:39 or we could add support now (as the product is advertised as compatible), but end it at a certain release? Oct 18 09:46:58 that would be the most reasonable approach, yes Oct 18 09:47:12 in the end we do have to swallow whatever fine decision upstream comes up with Oct 18 09:48:04 xback: however the question still stands; is there any *alternative* ? Oct 18 09:48:16 Hello Oct 18 09:48:19 squashfs + jffs2?! ext4? Oct 18 09:48:54 What should I do in the DTS for a router (Strong 1200) if there is only one button for RESET and WPS? Oct 18 09:49:12 nope, jffs is out too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e104f1e9dab67 Oct 18 09:49:22 jow: I'm not knowledged enough to answer that Oct 18 09:49:25 Right now I only defined it for the RESET Oct 18 09:49:28 "As of Linux 4.17 there are no file systems that specifically handle MLC NAND." Oct 18 09:49:31 jokers... Oct 18 09:49:34 * karlp laughs Oct 18 09:49:46 I can however just ask Richard W. Oct 18 09:49:47 I'm going to go and get a coffee and cry somewhere else instead of saying bad things. Oct 18 09:50:06 xback: don't tell him you're asking for openwrt/lede ;) Oct 18 09:50:39 jow: as the market is moving forward to QLC etc .. sigh .. Oct 18 09:50:54 noted on the "not as Owrt dev" part Oct 18 09:52:19 jow: as of 4.17 .. we are on 4.14 currently, so i'm wondering what the file system to use would be .. Oct 18 09:53:07 a very good question Oct 18 09:54:56 i'll submit a patch re-enabling MLC support to the mailinglist to start the discussion Oct 18 09:55:36 that sounds like a stick poking method not particularly likely to make them happy to find solutions, IMO. Oct 18 09:55:51 but you could probably word it nicely enough :) Oct 18 09:56:22 I meant posting it to Owrt mailinglist ;-) Oct 18 10:21:17 actually about that LTO patch, it would be nice if we could do PKG_LTO:=1 -> enable LTO if CONFIG_PKG_LTO=y, PKG_LTO:=2 enable LTO even is CONFIG_PKG_LTO=n Oct 18 10:21:34 that way we can force enable LTO for some packages that really benefit from it Oct 18 10:22:06 does that make sense or not ? Oct 18 10:23:00 yes, but rename "2" to "force" Oct 18 10:24:07 or something like PKG_LTO:=possible / PKG_LTO:=required Oct 18 10:24:15 some stuff to think about Oct 18 10:24:48 alternatively auto/yes or yes/force Oct 18 10:25:32 I am surprised, not that many breakage yet with LTO enabled for all packages Oct 18 10:29:33 stintel: what's the reasoning behind forcing LTO even if disabled in config? Oct 18 10:34:47 xback: we could replace the MLC check with a (big?) warning that MLC NAND is detected, and reliability and data consistency isn't guaranteed Oct 18 10:36:50 KanjiMonster: we have some packages with LTO enabled currently Oct 18 10:37:17 hostapd, dropbear, netifd, fw3, .. Oct 18 10:37:31 to reduce their size Oct 18 10:37:51 if we introduce CONFIG_PKG_LTO with default off, we still want to be able to force those packages to enable LTO Oct 18 10:38:18 xback: jow: the big issue with MLC NAND is that they have linked pages, where writing/erasing them in the wrong order can cause bit errors in the other (or worse), and MTD/UBI doesn not currently support/handle that Oct 18 10:38:20 at least until we can default it to yes (after we identified and force disable LTO for breaking packages) Oct 18 10:39:04 stintel: so maybe PKG_LTO:=0 disabled, even if CONFIG_LTO=y; PKG_LTO:=1 enabled, even if CONFIG_LTO=n, PKG_LTO unset => follow CONFIG_LTO? Oct 18 10:43:17 * ldir decides that if lib has outstanding CVE and maintainer unresponsive & maintainer company unresponsive & lib is only used by package of said company, then both shalt be removed after a week. Oct 18 10:46:15 ldir: libssh? Oct 18 10:46:30 swalker: in one ;-) Oct 18 10:48:27 karlp: thanks Oct 18 10:49:24 swalker: your local CPE list.... is it just a case of adding your CPE ID to the package makefile? Oct 18 10:49:56 (I'd recommned double checking the upstream list, so you don't put in the old one like I did ;) Oct 18 10:50:03 ldir: and updating the list as karlp & jow saw Oct 18 10:50:26 karlp: aye Oct 18 10:50:46 stintel: you don't find all LTO breakages at compile time, there's lots of runtime breakage too. Oct 18 10:51:09 I can't update the list, but I can update/correct the entry put into the package makefile... I assume that's what you mean. Oct 18 10:51:16 the list's been around before 2016 though :) Oct 18 10:51:32 ldir: correct Oct 18 10:52:23 and no obvious need (to me) to bump the package revision number? Oct 18 10:52:39 no Oct 18 10:52:40 it doesn't change the binary in anyway Oct 18 10:54:21 do we really need to have individual commits for adding the ID to multiple packages, or could it be done as a few (ie when I get a round to it) commits that update a number of packages? Oct 18 10:54:52 ldir: maybe mark it as @BROKEN, so that people that want to get hacked/create a honeypot can still do so? ;) Oct 18 10:55:25 I think for "maintanence" stuff like adding CPE IDs one commit for multiple packages is fine Oct 18 10:57:01 'cos it seems like a menial but boring task that I could just about get my head around :-) Oct 18 10:59:12 I once wrote a hakish perl script that attempted to guess the right cpe ids for all packages by testing various things like download urls, fuzzy name matching etc,. Oct 18 10:59:29 you could go searching for the cpe ids for the other ~800 packages Oct 18 11:01:29 ldir: if you want to spend some time is, you could give http://luci.subsignal.org/~jow/map-cpe.pl a try Oct 18 11:01:48 place it somewhere and execute as perl map-cpe.pl /path/to/feed-clone.git/ Oct 18 11:02:04 I like how nist search returns oldest version first. Oct 18 11:02:15 it'll print out packages and cpe candidates it found, needs manual post processing and verification though Oct 18 11:07:58 russell--: 4.11.9 seems to work OK just like 4.9 Oct 18 11:08:12 https://pastebin.com/raw/ErUDLgG9 if you want to load every package on a VM and use cvechecker's scanning Oct 18 11:09:03 swalker: how does it work? does it look at the binaries? Oct 18 11:09:21 (and why isn't this in the packages repo already?.... :) Oct 18 11:10:12 jow: I've never actually ran it that way to see Oct 18 11:10:41 swalker: took a quick look at the code; it appears to require distro specific glue to talk to the package manager Oct 18 11:11:02 but should be simple to add an opkg "backend", or something reading /usr/lib/opkg/status Oct 18 11:12:50 jow: IIRC cvechecker does string matching with the binary's contents, so doesn't need to be able to run it (but has custom matches/regexes for extracting the versions, so requires patching for each unsupported program) Oct 18 11:13:30 if you want to check binaries directly Oct 18 11:20:43 ldir: as promised -> http://www.xback.be/testbuilding.png Oct 18 11:35:23 russell--: this looks suspicious - i got it while porting my kernel 4.11 patches to kernel 4.12 Oct 18 11:35:27 drivers/mtd/nand/mtk_nand2.c:2129:13: error: 'struct nand_chip' has no member named 'write_page'; did you mean 'write_byte'? Oct 18 11:35:28 nand_chip->write_page = mtk_nand_write_page; Oct 18 11:35:39 it appears NAND API has changed between 4.11 and 4.12 Oct 18 11:35:47 maybe mtd NAND driver was incorrectly ported? Oct 18 11:38:12 xback: resolution? :) Oct 18 11:38:23 right, image info Oct 18 11:38:24 lol Oct 18 11:39:02 this smells badly ./patches-4.14/0040-nand-hack-restore-write_page.patch Oct 18 11:57:55 stintel: the 4.14 bump contains a lot of spectre mitigations. Some new symbols are added for ARM Oct 18 11:58:11 can I ask you if it would be possible to test the bumps later on on your arm64 target? Oct 18 11:58:44 the bump commits in my staging are still missing the new symbols Oct 18 12:05:22 again :/ Oct 18 12:06:09 xback: currently travelling, but I do have my odroid C2 with me, can try but might be for the weekend Oct 18 12:41:21 Is possible to debug OpenWrt kernel modules remotely (with gdbserver)? Oct 18 12:59:59 vk496: AFAICT (remote) debugging the kernel only works over serial Oct 18 13:01:03 KanjiMonster: thnks. Will try Oct 18 13:15:38 russell--: i've just booted 4.12.14 and it's broken after power cut Oct 18 13:16:01 4.12.14 uses that reworked NAND API + OpenWrt hack pack for ramips Oct 18 13:55:33 I see that the default ath10k firmware is ath10k-ct. what is the difference between ath10k-ct and the htt-mgt variant? Oct 18 13:55:53 huaracheguarache: you can find it in git log Oct 18 13:56:16 d15b09aab8a2aedeac2a6fb1e872ae975c9baa42 Oct 18 13:58:19 thanks =) Oct 18 13:58:55 maybe we should reference it in the wiki or so Oct 18 13:59:38 what's the reason behind -ct being the default instead of -ct-htt? greater possibility of bugs? Oct 18 14:03:35 rmilecki: feel free to work out how to do that and push a patch Oct 18 14:03:39 i never tried, Oct 18 14:03:44 blogic: Oct 18 14:03:52 kab-el: Oct 18 14:04:00 blogic: can you send me address where should we send you Turris Mox prototypes? Oct 18 14:04:02 :D Oct 18 14:05:11 sure Oct 18 14:05:14 -> PM Oct 18 14:07:03 huaracheguarache: -ct is compatible with stock driver, -ct-htt isn't Oct 18 14:10:17 stintel: fair enough Oct 18 14:11:44 I wonder how much of an issue wmi buffers are when using -ct firmware, but I've never tried non-htt-mgt firmware Oct 18 14:18:08 blogic: btw offtopic, in the past you worked on mt7621 support (for example WitiBoard). The current kernel has support for mt7621 pci and ethernet etc in staging dir, but mtk_eth_soc driver is also in drivers/net/mediatek Oct 18 14:18:46 blogic: i was looking at the differences between those two and i think it would be not that hard to add support fort mt7621 to net/drivers/mediatek/mtk_eth_soc Oct 18 14:19:07 blogic: and since mt7530 dsa switch is already supported in kernel... Oct 18 14:19:20 blogic: the switch on mt7621 is mt7530 compatible, is it not? Oct 18 14:20:39 kab-el: https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/mt7621_dsa Oct 18 14:20:51 it is indeed easy Oct 18 14:20:57 partially working but then i ran out of time Oct 18 14:21:16 hope to find a free week soonish to resolve the upstream mess Oct 18 14:23:16 hmm, the #ifdefs putting away regulators could be resolved with putting a fixed-regulator into the dts, i think Oct 18 14:23:37 - depends on ARCH_MEDIATEK Oct 18 14:23:39 + depends on ARCH_MEDIATEK || SOC_MT7621 Oct 18 14:23:44 i did that too yesterday :D Oct 18 14:24:33 yes, those are precisely the differences i found Oct 18 14:25:04 yes Oct 18 14:25:16 fixed regulators would be better i agree Oct 18 14:25:31 blogic: i'll look at your patches, hopefully tomorrow, and try to clean them up a little and test them Oct 18 14:25:52 it would be beautiful if i could use mainline kernel on witiboard :) Oct 18 14:25:59 hehe Oct 18 14:26:18 kab-el: i also fixed up pinctrl to drop the old driver and use pinctrl-single Oct 18 14:26:25 i'll need to push those patches aswell Oct 18 14:26:38 yes i created a pinctrl patch as well Oct 18 14:26:42 :D Oct 18 14:26:45 already pushed pwm patches for 4.19 Oct 18 14:26:54 great i ll look at them Oct 18 14:27:05 and there was something else Oct 18 15:18:34 ldir: stintel: I've pushed the kernel bump patches a minute ago to my staging tree .. lots ofwork to get the symbols perfect for all targets .. but it should be final Oct 18 15:19:01 only a minute ago? I've previously cherry-picked them Oct 18 15:19:40 yes, just 4 minutes ago or so. Oct 18 15:19:49 hmm, so the previous ones were not good ? Oct 18 15:19:56 correct Oct 18 15:20:24 both master & 18.06 should be final now Oct 18 15:20:27 openwrt-18.06/4.14.77 built fine though, should I expect runtime issues ? Oct 18 15:20:48 no. but not all targets were included yet Oct 18 15:21:09 only symbols changed between the updates in staging Oct 18 15:21:30 stintel: we peaked too soon :-) Oct 18 15:21:44 ldir: well I'm planning an update of our firewalls tonight Oct 18 15:21:53 hoping the memory leak is going to be resolved Oct 18 15:22:25 I feel really bad when I have to reboot a Linux box to solve a problem :P Oct 18 15:22:43 stintel: don't try windows then ;-) Oct 18 15:23:48 * ldir builds ath79 Oct 18 15:41:21 memleak: https://www.linux-ipv6.be/OpenWrt/Vz0nlT0wsTBXQ8E4.png Oct 18 15:41:47 kernel 4.14.63 Oct 18 17:09:19 xback: fyi, 18.06 w/ 4.14.77 runtime tested on x86/64 Oct 18 17:23:22 how can i tell netifd to stop managing a specific wireless devive? Oct 18 17:23:24 device Oct 18 17:24:06 disabled = 1 doesnt seem to make it actually let go of the netlink Oct 18 17:34:30 russell--: nbd: I was pretty sure that regression is related to the mtk NAND driver, since it appeared in 4.12 and 4.12 got some NAND API changes that required mtd NAND driver update Oct 18 17:34:46 so I built 4.11 and then manually applied all relevane mtd subsystem changes from 4.12 Oct 18 17:34:50 and nothing it still works Oct 18 17:35:07 so it must be something from 4.12 but not from the mtd subsystem Oct 18 17:35:18 which most likely means filesystem Oct 18 17:35:33 but it affects all nand devices, not just mtk Oct 18 17:35:33 i'll probably just start "git bisect"... that will be painfu Oct 18 17:35:43 DonkeyHotei: it does not affect bcm53xx Oct 18 17:36:13 first discovered on powerpc Oct 18 17:36:20 it's really weird :( Oct 18 17:36:50 i cannot explain why bcm53xx is unaffected Oct 18 18:32:59 mkresin: ok then I will try it myself in the next days Oct 18 21:06:19 rmilecki: I might seen that problem with one of the first 4.14 test builds on ipq40xx (Asus RT-AC58U), but that device is in my parents' house now, and it's not something that I can test remotely :( Oct 18 21:31:09 the new apu4b4 will boot up the compex 9984 NIC, but tha apu has only 1 mini-pcie slot (the others are msata and/or usb only), so not *quite* what I was hoping for. Oct 18 21:31:43 Interestingly, if I put a mini-pcie ribbon extender rig (from bplus) between the NIC and the slot, then the apu2c4 recognizes the NIC! Oct 18 21:33:09 Hi! Oct 18 21:34:20 Where can I consult all possible prefixes under base-files/etc/uci-defaults ? Oct 18 21:35:24 or they are not defined? Oct 18 22:43:16 what possible prefixes? **** ENDING LOGGING AT Fri Oct 19 03:00:00 2018