**** BEGIN LOGGING AT Fri Feb 15 02:59:56 2019 Feb 15 08:20:07 blimey another kernel bump - must be CVE related Feb 15 08:21:47 ahh CVE-2019-3819 is actually mentioned in the changelog Feb 15 09:07:12 ldir: nearly done here with refresh Feb 15 09:07:43 xback: excellent service as usual :-) Feb 15 09:10:18 Feb 15 09:26:09 xback: you know 4.14.101 has just appeared!!!! Feb 15 09:38:59 ldir: yeah, I noticed just before starting :) Feb 15 10:11:49 ldir: pushed to staging Feb 15 10:12:42 ldir: whats your source for finding the CVE fixes? I checked the diff but didn't see CVE keyword .. altough I recall a patch being queued for it Feb 15 10:13:07 xback: I saw it in the changelog Feb 15 10:14:20 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.100 Ctrl-F CVE "This fixes CVE-2019-3819." Feb 15 10:14:24 got it Feb 15 10:22:32 seems like 4 CVE's (incl this one) got fixed in 4.19.21 which was already pushed yesterday .. Feb 15 10:24:44 Hauke: yes, please let us do it in the march 7th - march 17th time frame Feb 15 10:25:01 Hauke: maybe you could communicate that on the list, that people shall finish their pending work in master until then Feb 15 10:25:38 we can expect 19.03.0-rc1 two to four weeks after that Feb 15 10:25:41 xback: there's also a nice webpage for kernel cve's https://www.linuxkernelcves.com Feb 15 10:26:01 (will need some time to redo the build cluster) Feb 15 10:47:36 gaspode: thanks for the suggestion Feb 15 10:48:05 would be nice to have a simple resource which can be checked. "show all CVE's fixed between mainline version X and Y" Feb 15 10:48:29 jow: wb :) Feb 15 10:49:43 xback: hi :) since you're here... I wondered Feb 15 10:50:12 there was this uqmi firewall zone patch. Was it you who wanted to test it? Feb 15 10:50:47 a very similar issue has been reported for ncm recently so I ideally want to merge the same fix there, but iirc we still hadn't conclusive runtime test results Feb 15 10:56:39 jow: correct. It's still here applied in a local repo Feb 15 10:56:47 I haven't forgotten it :) Feb 15 10:59:12 could we do another test today? Feb 15 11:06:01 jow: I'll do my utter best to test it today. already started a build Feb 15 11:06:21 iirc: it was teamviewer which was hampering us last time Feb 15 11:06:43 ah right Feb 15 11:06:55 I'll simply spin up a windows vm Feb 15 11:20:18 is there a quick way to apply a saved configuration while building a firmware image? just unzip it into openwrt/files? Feb 15 11:23:08 charolastra: more or less, yes Feb 15 11:23:37 charolastra: sysupgrade --create-backup might help to identify actually changed files Feb 15 11:23:45 charolastra: untar the resulting archive into files/ Feb 15 11:23:59 should result in things like files/etc/shadow, files/etc/config/network etc. Feb 15 11:24:15 cool, i'll try Feb 15 11:28:54 also i'm wondering how the big producers manage to set unique SSIDs and passwords for each device. they certainly won't build a firmware image for each device. maby just launch a script through ssh? Feb 15 11:34:37 charolastra: they usually program a small oem partition through uart access Feb 15 11:34:55 charolastra: this oem partition contains some sort of key/value variable store Feb 15 11:35:11 the firmware is then programmed to derive its macs etc. from there Feb 15 11:35:26 random macs and passwords are preset there as well Feb 15 11:35:43 ah, makes sense Feb 15 11:36:01 *random ssids Feb 15 11:40:51 jow: hardware is ready. waiting on the build finish (eta 30 minutes). TeamV v14 will be used Feb 15 11:42:53 v14 is open in a win7 vm here Feb 15 11:43:28 i'll PM you login details asap when all is up Feb 15 11:44:26 thanks. do you have any ncm setup as well by any chance? Feb 15 11:55:41 jow: srry .. no ncm afaict Feb 15 12:01:01 * russell-- just encountered a failure to fit all my package/files bits on an 8MB flash device Feb 15 12:01:09 flashing through TFTP on a stock device worked fine by holding the reset button for some time but now that it's flashed it won't enter that TFTP mode again. how to flash a "recovery" image? Feb 15 12:31:07 jow, all is ready Feb 15 14:55:20 Does anyone understand the situation with libudev in 18.06? It's moved over to libudev-fbsd.... and that package has been patched to allow the usbip package to compile. But not to actually work? Feb 15 14:56:12 hm, last time I checked usbip had other issues Feb 15 14:56:43 Would there be objections to making libudev from eudev available again? Or do the stubs in the patches just need filling out (are there particular licensing issues in doing so?) Feb 15 14:58:01 jwh: don't believe so... with libudev replaced with the package from 17.x it works great, at least for USBIP exporting a device plugged into the OpenWRT system. I've not tried it the other way around. Feb 15 14:58:28 hm, I'm sure vhci was broken (I did some research but I can't remember what it was now) Feb 15 15:00:31 vhci is the other way around - ie connecting remote USB devices to the OpenWRT device over IP Feb 15 15:00:34 I've not tried that Feb 15 15:00:46 yeah Feb 15 15:01:09 but the way it exports it (at least now), it still tries to enumerate the vhci controller and breaks Feb 15 15:01:12 unless its been fixed since Feb 15 15:32:57 hello, I'm having some issues with channel 100 not being available on ath10k-wave 1. 'iw reg get' indicates I have DFS-FCC set everywhere properly, and freq 5500 shows as available Feb 15 15:33:32 but, when dumping the phy info freq 5500 through 5700 is disabled. This radio should be in STA mode, btw. Feb 15 15:34:16 any clever way to show what part of the code is disabling these channels? Feb 15 15:42:20 gah, reboot and it is 'fixed' Feb 15 16:36:09 greearb_: I would say I've had no problems with being on channel 100, but DFS. :) Feb 15 16:37:06 I'll add kernel debugging next time I feel motivated Feb 15 16:43:14 anyone have time and interest to bisect a kernel warning in my wave-2 firmware for netgear r7800? https://github.com/greearb/ath10k-ct/issues/66 Feb 15 16:44:00 Same with this one: https://github.com/greearb/ath10k-ct/issues/65 Feb 15 17:54:55 192.168.100.20/24 Feb 15 17:55:26 sorry paste fail! Feb 15 18:18:35 jow: ok I wil comunicate the 19.3 branch Feb 15 18:36:04 Hey guys, is there a way to flash .bin via mtd using luci? Or is it ssh-only kinda thing? Feb 15 19:02:08 dedomraz: luci supports forcing and image to be flashed. otherwise not really Feb 15 19:15:24 @mangix forcing? Is there a way to force openwrt on top of lede? Seems the only way to do it is via mtd Feb 15 19:45:38 dedomraz: which device? You shouldn't have to resort to low-level writes if you've already got OpenWrt/LEDE running for virtually any device Feb 15 19:45:52 gl-inet b1300 Feb 15 19:46:37 Running OEM firmware, or release/snapshot from OpenWrt directly? Feb 15 19:46:41 Every time I try to upgrade from luci - it says that its a different device (and since Lede was running the device on ipq80xx and openwrt switched it to ipq40xx - I am thinking thats why its not picking it up Feb 15 19:47:03 Command line or through U-Boot Feb 15 19:47:16 It has LEDE snapshot, and I am trying to flash openwrt snapshot Feb 15 19:47:21 All via command line Feb 15 19:47:46 But wanted to check if there is a way to mtd it via luci (or force a flash, without it checking if its the correct device) Feb 15 19:47:59 sysupgrade, confirm *why* it doesn't want to upgrade. Based on that make a decision if you are confident that `sysupgrade -F` won't brick your device Feb 15 19:48:50 Even on this channel, probably only a dozen have the knowledge and reason to *write* to MTD directly Feb 15 19:49:24 It doesn't want to because currently its running on ipq80xx base, and the newer one is based on ipq40xx, so its thinking its the wrong device (I did flash it via mtd and its working, but I have about 20 released for a customer, and want to be able to give them a .bin file and they can upgrade it via luci) Feb 15 19:50:23 GL.iNet's U-Boot implementation is, as I understand it, based on pepe2k's. It has a direct-upload capability for firmware through the browser. Feb 15 19:50:45 (At least the on on my AR300M-Lite and AR750S do) Feb 15 19:51:03 That would be a decent approach to explore, in my opinion Feb 15 19:51:16 It does, yes. But having to explain to my front-desk people on how to flash it via u-boot would make my life a living hell basically lol Feb 15 19:53:34 I can always whip a script to run mtd via rc.local so it flashes it on boot, but wanted to see if I need to go that route, or if there is a way to force sysupgrade to flash, before I get into the "dirty tricks" drawer :P Feb 15 19:53:56 Yes, `-F` Feb 15 19:54:08 root@OpenWrt:/# sysupgrade --help Feb 15 19:54:16 But not via luci, right? Feb 15 19:54:24 No, not via LuCI Feb 15 19:54:36 Darn. Oh well. Thank you!! Feb 15 19:54:59 Most users who aren't comfortable with command-line interaction have no business using `-F` or mtd utilities Feb 15 19:55:42 I couldn't agree more, thats why I am trying to avoid using those on their devices and have them do it via luci Feb 15 19:55:54 The other option would be a full-custom build that is stated to be compatible with the current device's /etc/board.json sense of "what" they are Feb 15 19:56:44 That would be a transition build, that would "accept" that it's OK to flash on their current state, but record them as the "right" target for future upgrades Feb 15 19:57:20 (I've never tried that across architectures though) Feb 15 19:57:33 (just board names) Feb 15 19:58:26 I am doing the compiling, so thats a good idea, I will look into it. Thank you! Feb 15 20:46:00 dedomraz: luci supports forcing flash on current snapshot. Feb 15 20:46:38 Oh nice, so that would basically be the last time I need to do mtd, after that - they can just force it (hopefully there will be no need of course) Feb 15 21:32:24 dedomraz: I mean, if running snapshots is your thing Feb 15 21:33:05 dedomraz: forcing will be needed for ar71xx to ath79 Feb 15 21:34:19 on that note, I'm a little annoyed by the "phy reset is missing" error on ath79 on my archer c7v2 Feb 15 21:38:45 gch981213: is it possible to port the ath79 spi patch to kernel 4.19? Feb 15 21:57:43 hey guys. what happened to all the staging trees on git.openwrt.org? Feb 15 21:59:30 there's just ldir's staging dir everything else is gone. Feb 15 22:02:47 Got a "new" device on the bench (IPQ4019) and not seeing /dev/log being generated -- any suggestions as to where to look/configure? Feb 15 22:05:37 (Running syslog-ng -- but thankfully not systemd, as some of the search results discuss) Feb 15 22:06:39 what's wrong with systemd? Feb 15 22:07:02 LOL, don't get me started on "religion" ;) Feb 15 22:09:31 Looks like /dev/log is not the source of my problems, as syslog-ng.conf defines Feb 15 22:09:43 source kernel {file("/proc/kmsg" program_override("kernel"));}; Feb 15 22:11:02 Something to come back to another day -- might be a version change since my September builds Feb 15 22:18:25 jeffsf: there was a recent version bump from the Turris guys Feb 15 22:28:56 Interesting, thanks mangix -- a quick search shows some issues with multiple syslog-ng processes, which I'm also seeing here Feb 15 22:29:54 mangix: do you still have all the staging trees on git.openwrt.org? Feb 15 22:30:13 now it's not just ldir's showing but also hauke's Feb 15 22:30:20 something weird with that web UI Feb 15 22:30:58 Borromini: what is with my stging tree Feb 15 22:31:27 Hauke: nothing with yours. there's no staging trees showing on git.openwrt.org Feb 15 22:31:32 except ldir's and now yours Feb 15 22:31:44 I see the same here at https://git.openwrt.org/ Feb 15 22:32:16 jeffsf: as in just those two staging trees? Feb 15 22:33:04 Hauke: https://postimg.cc/RJ1XP261 Feb 15 22:33:37 Correct, only hauke.git and ldir.git for openwrt/staging Feb 15 22:33:44 thanks Feb 15 22:46:40 jeffsf: turris people use glibc instead of musl. Might explain why they would see no issues Feb 15 22:48:18 I am seeing all staging trees Feb 15 22:48:49 jow: could you please check if one of the git servers is broken, it looks like we have different content on the servers Feb 15 22:49:29 Hauke: thanks. Feb 15 22:49:51 Borromini: you should thank jow for the infrastructure Feb 15 22:50:19 Hauke: i thank jow for the infrastructure and you for pointing to where the issue might be :-) Feb 15 22:50:54 there is a cluster of two servers for git, it could be that one of them is broken Feb 15 22:50:57 git.openwrt.org. 27392 IN CNAME git-01.infra.openwrt.org. Feb 15 22:50:57 git-01.infra.openwrt.org. 3600 IN A 46.101.214.210 Feb 15 22:51:01 I pushed something some minutes ago Feb 15 22:51:12 Hauke: as did ldir. and both of your trees are showing up Feb 15 22:51:26 at first, only ldir's was showing Feb 15 22:51:39 then yours became visible again as well Feb 15 22:51:54 i had xback's tree cached in my browser and that just gave a 404 Feb 15 22:53:34 bedtime here, goodnight. Feb 15 22:54:11 when I use IPv4 I get an Error 404, when I use IPv6 I get the content for this URL: https://git.openwrt.org/?p=openwrt/staging/xback.git;a=summary Feb 15 23:01:09 sadly it's not as simple as IPv4 vs IPv6, I have IPv6 enabled (native DTAG) and only get error 404., same with IPv4. I can only see the staging repos via he.net IPv6 (AMS) Feb 15 23:03:32 (neither from the myloc data centre in Düsseldorf) Feb 15 23:35:53 looks like support for airtime fairness is coming in linux 5.1, see https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/commit/?id=962c382d482afc6280ff6f3c28331774bc331e1e and http://lists.infradead.org/pipermail/hostap/2019-February/039649.html Feb 15 23:36:35 and I wonder if that could be backported to openwrt before the next major release Feb 15 23:37:39 backported to 4.14/4.19 that is Feb 15 23:47:18 Of course -- once you get logging up and running and everything you need for a meaningful ath10k bug report Feb 15 23:47:32 the thing starts running smoothly Feb 15 23:53:02 wasnt there something like airtime fairness already? maybe i mixed it up... Feb 15 23:55:32 rotanid: https://support.ruckuswireless.com/articles/000002008 Feb 16 01:34:25 hexa-: fairly meaningless for now. ath9k and mt76 have support for it already Feb 16 01:34:37 thats what i thought... **** ENDING LOGGING AT Sat Feb 16 02:59:57 2019