**** BEGIN LOGGING AT Sat Jan 19 02:59:56 2019 Jan 19 08:39:16 Hi, I am getting this error during OpenWRT build: bin/targets/x86/64/openwrt-x86-64-combined-squashfs.img: No such file or directory Jan 19 08:39:19 any idea? Jan 19 08:49:40 maybe a tool is missing? Jan 19 09:05:50 rubberduck: thanks I will check. Jan 19 09:22:35 nbd: ping Jan 19 09:25:04 nbd: if i don't catch you, your latest mt76 bump on 18.06 gives me disconnects within minutes of associating (mt7612 ac). Logread shows this: https://paste.debian.net/plain/1061376 Jan 19 09:25:23 i reverted that commit for now, if you need me to test things let me know. Jan 19 09:28:53 the radio still shows up through 'wifi status' but clients can't see it anymore or reassociate once they lose connection Jan 19 11:03:35 Piraty: don't think there's docs on managing repos. The key is scripts/ipkg-make-index.sh Jan 19 11:03:51 Piraty: also the opkg used by openwrt diverged a lot of from wahtever is upstream in yocto Jan 19 11:10:25 <_lore_> Borromini: what is the commit? Jan 19 11:12:14 <_lore_> f34ad1a8f0d1ee4a3e4b966d58c8f3b8a523a417? Jan 19 11:22:34 _lore_: yes Jan 19 11:23:07 jow: did i read it right that 4.19 will break most 4MB devices? :) Jan 19 11:24:21 <_lore_> is the issue related to 76x2 or 7603? Jan 19 11:24:38 7612 like i said Jan 19 11:25:24 <_lore_> ok, sorry I missed it Jan 19 11:26:03 <_lore_> embedded chip or pcie card? Jan 19 11:26:49 <_lore_> when does the issue happen? after sending some traffic? Jan 19 11:26:50 np. mt7621 SoC, dir-860l b1 Jan 19 11:26:59 so embedded afaik Jan 19 11:27:08 it happens after surfing a bit yes Jan 19 11:27:13 <_lore_> ack Jan 19 11:27:29 <_lore_> are you able to perform a bisect? Jan 19 11:27:48 <_lore_> you can skip mt7603 commits Jan 19 11:30:32 Borromini: I fully expect that Jan 19 11:32:32 Borromini: its not that we want to actively deprecate them but the effort to maintain such devices starts to outweigh the benefits. So given an expected timeframe of 19.x (which still uses 4.14) of around two years and a release in februrary, we can estimate [bianry release] support for 4MB devices until februrary 2021 Jan 19 11:32:39 which, in my opinion, is plenty Jan 19 11:33:47 by then we should have shifted our priorities to ship with ssl, wpa3 etc. by default and will probably have hightened the baseline to 8M flash / 64MB ram Jan 19 11:34:35 its not that kernel 4.19 will break these devices per-se, but most will simply lack the flash space to keep running default images Jan 19 11:36:58 jow: yeah every kernel bump seems to bring that along. Jan 19 11:37:17 i have a few tl-wr841n's in operation but will be phasing those out Jan 19 11:37:44 _lore_: i haven't bisected before, i would be happy to do so but i lack the time this weekend Jan 19 11:37:52 do you have an mt76x2 device as well? Jan 19 11:38:31 <_lore_> yes, but it is working properly with latest fw Jan 19 11:38:47 you're running the 18.06 tip? Jan 19 11:38:56 <_lore_> nope, master Jan 19 11:39:01 ok Jan 19 11:39:18 maybe the mac80211 bump is involved then Jan 19 11:39:49 this is my only mt76 device but as long as 19.x isn't branched i will stick with 18.06 Jan 19 11:43:15 <_lore_> Borromini: I do not think it is a mac80211 issue actually Jan 19 11:57:09 ok Jan 19 11:57:18 you know your way around the code? Jan 19 11:57:45 <_lore_> what do you mean? Jan 19 12:01:23 well it sounded like you kind of knew what was happening Jan 19 12:01:44 or at least rather sure it was mt76 and not mac80211 :) Jan 19 12:01:48 i meant the mt76 code Jan 19 12:03:41 <_lore_> yes, I am working on it for a while now Jan 19 12:03:54 ok Jan 19 12:20:28 jow: (opkg) yeah thanks for hinting to the make-index script. i talked to (what i believe is) yocto's maintainer, he might reach out to you because my questions raised his interest (especially the use of cmake instead of autohell) Jan 19 13:23:19 jow: I guess this might be a reason to wait with 18.06.2 until either we know the pcie ones aren't affected, or there are updated firmwares fixing the vulnerability - https://embedi.org/blog/remotely-compromise-devices-by-using-bugs-in-marvell-avastar-wi-fi-from-zero-knowledge-to-zero-click-rce/ Jan 19 13:25:59 KanjiMonster: do you know who could/would follow up on this? Jan 19 13:26:17 fyi, I am going to push my abi version changes now Jan 19 13:26:25 jow: no idea. I just stumbled upon this just now Jan 19 13:26:36 either nothing will happen or we'll see some nice fireworks thorough the next few hours Jan 19 13:26:54 maybe add a bug report on the mwlwifi git? Jan 19 13:29:34 jow: i suppose that ABI push will be confined to master? Jan 19 13:29:42 just being curious Jan 19 13:30:22 Borromini: I think yes, it will probably not end up in 18.06, allthough it is fully backwards compatible Jan 19 13:30:38 in any case it should be part of 19 Jan 19 13:32:47 :) Jan 19 13:33:27 KanjiMonster: that analysis you linked mentions mwifiex Jan 19 13:35:29 jow: AFAICT the main vulnerability is in the wifi firmware (the threadx stuff) Jan 19 13:43:45 https://github.com/kaloz/mwlwifi/issues/344 Jan 19 13:46:02 compiling opwnwrt with the linux subsystem for windows is boring slow Jan 19 13:58:38 another one out of the stupid quesiton department; "MT7621 SPI driver" is a driver for NOR flash? Jan 19 13:58:45 rubberduck: what hardware? Jan 19 13:59:28 Xeon E5-2630v2 with 64 GByte RAM Jan 19 13:59:51 my i3-3220 with only 16 GByte but native linux is round about 5 times faster at compiling Jan 19 14:00:20 there was a longish thread in the forum about compiling performance on the windows linux subsystem Jan 19 14:00:37 and there users found a massive performance degregation due to the metldown/spectre microcode updates Jan 19 14:00:59 [on windows] Jan 19 14:01:56 rubberduck: https://forum.openwrt.org/t/compilation-has-slowed-down-due-to-intel-microcde-patch-for-spectre2-in-windows10-ubuntu-in-virtualbox/23901 Jan 19 14:02:02 jow: SPI is just a bus protocol; you can attach various devices on it, NOR flashes are the most common use case though (spi connected nand is a recent thing) Jan 19 14:02:43 KanjiMonster: ok, I was looking at https://github.com/openwrt/openwrt/pull/1578 and wondered if it is interfering with / superseding the nand driver fixes I was planning to do Jan 19 14:03:08 (my Xiaomi Mi WiFi Router 3G arrived yesterday) Jan 19 14:03:10 jow: i wrote linux subsystem Jan 19 14:03:18 windows10 has native linux support Jan 19 14:03:23 but its ugly slow Jan 19 14:03:32 rubberduck: yeah, the thread I linked is about the native linux subsystem on windows Jan 19 14:03:53 build job time increased from 20-30m to 80m+ for a user after microcode updates on windows10) Jan 19 14:03:54 jow: the nand driver is for a separate block (parallel nand controller) Jan 19 14:04:16 as the two processors are from the same generation (ivy bridge) and have the same microcode patches it's only windows being so slow on fork() Jan 19 14:04:42 KanjiMonster: ok Jan 19 14:08:39 jow: there are basically 4 types of flash, parallel nor (usually just memory mapped, not used that much anymore), serial nor (spi connected, often memory mapped for fast reads and initial boot), parallel nand (through a separate nand controller block), and serial nand (spi connected, usually requires a different means for the bootloader, e.g. a small nor flash) Jan 19 14:10:18 so the spi driver implements the spi bus hardware functionality and the spi nand driver implements the nad driver support on top of the spi bus? Jan 19 14:15:08 right Jan 19 14:15:22 jow: yes (and on top of the generic SPI nand code there's vendor specific SPI NAND code for Toshiba/Micron/etc. SPI NAND quirks) Jan 19 14:15:57 xdarklight: that's out-of-tree though - the in-kernel effort is to provide a generic spi-nand driver (framework) Jan 19 14:16:43 KanjiMonster: there may have been multiple frameworks, but the mainline one has additional vendor specific logic, see: https://github.com/torvalds/linux/tree/master/drivers/mtd/nand/spi Jan 19 14:16:44 well, they are in staging/ so technically in-tree Jan 19 14:18:17 xdarklight: the spi-nor driver also has various vendor-specific quirks - the important part is that there is "one" spi-nand driver to load, and not one for each vendor Jan 19 14:18:56 the hard part was refactoring the existing nand framework so the spi-nand driver can resuse it (bad block management etc) Jan 19 14:19:05 KanjiMonster: yes, that's why I said that there are vendor specific "quirks" instead of "drivers" Jan 19 14:19:54 xdarklight: Indeed, i missed the "on top of the generic SPI nand code" part, my bad Jan 19 14:21:33 KanjiMonster: with so many frameworks/drivers around it gets confusing Jan 19 14:22:03 the good part is: mt29f_spinand was removed from staging in 5.0 Jan 19 14:22:08 ah, good Jan 19 14:22:30 the only reason for it existing was that the spi-nand driver wasn't ready yet Jan 19 18:19:41 llllllllllouuuuuuujhzgzgfffrrrrrrrrrrőkcmtgkkmkmm , ,,,,,,,,élééééééééfghht Jan 19 18:21:45 oops sorry Jan 19 18:26:15 cat typing detected Jan 19 18:59:10 Hauke: ping Jan 19 19:07:18 jow: pong Jan 19 19:11:45 Hauke: my abi changes are in now and you/we can bump mbedtls and openssl Jan 19 19:12:10 in the yet open openssl pr I requested changes to only support 1.1.1 Jan 19 19:12:22 if the author incorperated these changes we can merge it Jan 19 19:12:54 but another thing - do you have any further blockers for branching 19.01 on your radar? Jan 19 19:13:36 I'll probably need next week to take care of 18.06.2 and 17.01.7 Jan 19 19:14:04 but after that it should be fine, what about simply setting the date to 27th ? Jan 19 19:41:06 jow: thanks Jan 19 19:41:12 I am not aware of any other blcoks Jan 19 19:41:14 blockers Jan 19 19:41:48 we have about 3 targets still on kernel 4.9 Jan 19 19:41:55 we should ask if someone wants to send patches for 4.14 Jan 19 19:42:08 I would suggest to remove kernel 3.18 support from master completly Jan 19 19:42:22 it looks like nobody cares about the targets on 3.18 Jan 19 19:51:48 ok Jan 19 20:29:42 Hauke: i was working on ixp4xx for some time, but something is screwed up around pci, and didn't have time to work it out Jan 19 20:29:55 tried 4.19, same result Jan 19 20:44:52 Is anyone available to help me with building packages with the SDK? Jan 19 20:48:25 jow: that pull request is for speeding up reads on NOR mt7621 flash. Might help with LuCI responsiveness, not sure Jan 19 20:57:17 jgu: whats the problem? Jan 19 20:58:39 Hauke: that kernel refuses to die. kernel.org lists it as EOL while still adding fixes. Jan 19 20:59:35 my phone was just updated to android 9, got a new 3.18 kernel :) Jan 19 21:01:50 karlp: getting a more recent kernel minor version in android is already an improvement Jan 19 21:02:13 I think greg gets paied from google for the LTS kernels Jan 19 21:02:19 karlp: oh? what phone? Jan 19 21:02:37 my moto x did not receive a minor version bump AFAIK Jan 19 21:07:39 jow: Well, I am following the instructions here: https://openwrt.org/docs/guide-developer/using_the_sdk Jan 19 21:07:49 Hauke: not for 3.18 afaik. he already asked twice if anyone still needs this kernel Jan 19 21:08:06 maybe someone responden off-list, dunno Jan 19 21:09:33 jow: I have set up an extra feed pointing to my local copy of the openwrt-packages repo, checked out onto a local branch with my changes (to two packages: getdns and stubby). For whatever reason, following the guide results in (1) the built getdns being the version before the one I have updated it to on my branch; (2) stubby compilation completes successfully, but no ipk is produced Jan 19 21:11:06 rotanid: has to be google. I commented on LWN "I can't believe this is still getting updates" gregkh responded "Me too!" Jan 19 21:11:11 Hauke: mangix xiaomi a1, it's an android one program phone, so have gotten ~monthyl updates since I bought it. Jan 19 21:11:39 was updated from 3.18.71 or 72or something, up to 100something Jan 19 21:13:15 nice Jan 19 21:13:31 does it have an ir blaster? Jan 19 21:15:35 well its nothing bad that a kernel gets updates for long time Jan 19 21:15:55 afaik 4.4 will get updates for a very long time, too Jan 19 21:16:17 but not because of phones, rather more serious stuff Jan 19 21:17:14 iirc, yes, I tried it a bit, but eve the xiaomi app was a bit fiddly with thhe three things we have remotes for h ere. Jan 19 21:17:20 no nfc though Jan 19 21:21:54 jow: ok, actually I have fixed that problem: although I had selected the packages in make menuconfig, I had later re-ran make menuconfig to turn off package signing. It seems when I did that, all the packages were unselected again. Weird. Jan 19 21:22:20 jow: now hitting a different openssl problem :) Jan 19 21:23:46 ugh I miss having an IR blaster. Last phone I had that had it was an HTC One. Jan 19 21:24:03 heh i still use my lg g4 Jan 19 21:36:49 jow: any clue as to how I should make use of this functionality in the stubby package? https://github.com/openwrt/openwrt/commit/dd9da5146299b769fad874d32a8ae110312cb68f Jan 19 21:38:09 jgu: not sure I understand the qustion Jan 19 21:38:58 jow: stubby depends on openssl, and needs it to be built with ECDSA enabled. That commit adds a workaround to the openssl package (I think) to enable that, but I am not sure how to make use of that in the stubby package. Jan 19 21:39:18 jow: oh, adding +@OPENSSL_WITH_DEPRECATED to DEPENDS in the stubby Makefile might be the thing to do Jan 19 21:39:33 ah now I got the context Jan 19 21:39:57 yeah DEPENDS:=... +@OPENSSL_WITH_DEPRECATED Jan 19 21:40:40 but actually the point of the commit is that you do not need to do anything in stubby Jan 19 21:44:06 Hmmm .. Jan 19 21:45:10 Weirdly, stubby does now seem to be building. Jan 19 22:12:05 jgu: if stubby has an issue with deprecated API usage, that should be fixed. Jan 19 22:12:56 mangix: it's not stubby especially. The DNSSEC spec requires ECDSA. OpenSSL has deprecated ECDSA. unbound sufffers with the same problem. Jan 19 22:13:21 I've not really got the apetite for trying to update the DNSSEC specification :) Jan 19 22:20:56 i don't think they've done such a thing Jan 19 22:24:39 sure they have, lots of people refuse ecdsa for the nsa's involvement in it. Jan 19 22:28:30 not fully accurate. NSA was only involved with P-256 384 and 521. OpenSSL supports other curves Jan 19 22:29:12 besides, TLS 1.3 requires ECDSA Jan 19 22:30:50 I think there's confusion regarding deprecated APIs. Jan 19 22:31:37 i can't find anything about ecdsa being deprecated? Jan 19 22:35:02 itsn ot about ecdsa being deprecated but about the clusterfuck the openssl api update policy is Jan 19 22:35:27 :D Jan 19 22:35:50 there was an API that enablesd ECDH that got deprecated in 1.1 (implicit now) but that's about it. Jan 19 22:37:41 https://i.imgur.com/O9UDXeD.gifv **** ENDING LOGGING AT Sun Jan 20 02:59:57 2019