**** BEGIN LOGGING AT Tue Jun 18 02:59:57 2019 Jun 18 07:27:52 stintel: these CVEs appear to be severe, seems that we should put out new point releases asap Jun 18 08:03:23 jow: :/ Jun 18 08:45:01 morning all Jun 18 08:45:41 stintel: ldir: I noticed it yesterday. will push the CVE bumps today. Jun 18 08:45:56 xback: much appreciated! Jun 18 08:46:02 xback: and good morning to you too Jun 18 08:51:21 xback: excellent. Jun 18 08:52:12 ldir: ynezz: https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=e85dab82b657d912d4d332e8213bb7ccfeba5e00 Jun 18 08:52:21 mind if I add your SoB's here guys? Jun 18 08:52:51 ldir: I've stolen the patch from your ctinfo branch without asking and adapted it to add the patch here in the bumps. Thanks for that :) Jun 18 08:53:24 xback: morning, it's fine with me Jun 18 08:53:39 lol - I'm glad I'm actually doing something useful :-) Steal away! Jun 18 08:54:06 ldir: also fine for you to add your SoB to the bumps? Jun 18 08:57:02 finally bit the bullet and set up ansible for our infra and used that to deploy the preliminary workarounds for the SACK / MSS size issues Jun 18 08:58:02 jow: great. I've some ansible stuff too I used on the infra before Jun 18 08:59:19 erm, I got as far as building it on x86 but not actually running it 'cos .127 appeared. Yeah go on then add it... it didn't obviously break the build, and that was using gcc 9 Jun 18 10:11:33 mangix: I'll decide whether to do that or fix and backport upstream ag71xx driver next month, when I'm with my pile of ath79 routers. Jun 18 10:28:53 ynezz: is print(("%s" % var)) the recommended way ? Jun 18 10:33:23 Does anyone else see /boot mounted multiple times? Jun 18 10:35:06 stintel: well, it's 2to3 Jun 18 10:35:17 ah Jun 18 10:36:21 https://realpython.com/python-f-strings/ Jun 18 10:37:06 if we're putting effort in it I'd prefer those: f"Hello, {name}. You are {age}." Jun 18 10:37:14 sure, be my guest :) Jun 18 10:37:25 :P Jun 18 10:37:47 requires 3.6 Jun 18 10:38:03 what are you guys going with as "3" ? Jun 18 10:38:21 2.7 is EOL in 1/2020 Jun 18 10:38:37 I'd go with 3.6. it's the default in any modern distro? Jun 18 10:38:55 karlp: debian 9 ships 3.7 as "python3" - seems like a sane choice to me Jun 18 10:40:31 no problem, just curious what number was being picked :) Jun 18 10:40:41 https://devguide.python.org/#status-of-python-branches Jun 18 10:40:49 3.6 is listed as "security", 3.7 as "bugfix" Jun 18 10:41:05 ubu 18.04lts is 3.6 Jun 18 10:41:32 I interprete this as 3.6 is frozen and in LTS mode, 3.7 is maintained Jun 18 10:41:57 so >=3.6 Jun 18 10:42:02 and f strings should be fine Jun 18 10:42:12 we're going to have to upgrade our infra though :) Jun 18 10:42:18 thats okay Jun 18 10:42:22 maybe we can schedule a window for that and go for it Jun 18 10:42:35 I can most likely help if we can plan it in advance Jun 18 10:42:35 speaking of this... we really need to find some cdn sponsoring Jun 18 10:42:45 the download server is severly overloaded Jun 18 10:44:14 have any experience with that ? Jun 18 10:45:00 a little bit Jun 18 10:45:24 cool. I haven't :( Jun 18 10:46:55 I'd probably try to approach cloudflare or something, but not sure if that'd be okay with the others Jun 18 10:47:44 are there any non-US-based alternatives ? Jun 18 10:49:17 OVH maybe? Jun 18 10:51:18 NACEVI is a Czech company Jun 18 10:51:27 or OnApp (UK) Jun 18 10:52:39 CDNetworks in HongKong Jun 18 10:52:55 we could try contacting them Jun 18 10:53:40 would probably start with OVH, NACEVI sounds interesting as it seems to be backed by the Czech government and the Czech broadband forum Jun 18 10:53:43 jow: can you explain the file size missmatch? I overheard you implemented that feature some time ago https://github.com/aparcar/attendedsysupgrade-server/issues/172 Jun 18 10:54:19 aparcar[m]: it means the downloaded file size is different to the file size mentioned in the locally available package feed lists Jun 18 10:54:30 aparcar[m]: without the file size check it would complain about mismatching checksum Jun 18 10:54:50 aparcar[m]: the file size check is an additional security measure to prevent padding attacks to provoke hash collissions Jun 18 10:54:50 jow: oh cool that NACEVI sounds interesting indeed Jun 18 10:56:09 jow: sound reasonable, however what causes the error? Outdated local index? Jun 18 10:56:18 aparcar[m]: yes, outdated local index Jun 18 10:56:29 stintel: appears to be limited to video streaming though Jun 18 10:56:47 I would not be against OVH Jun 18 10:57:21 yeah, will try to figure out if there's any sponsorship possibilities for OVH Jun 18 10:58:55 sure, they're using OpenWrt at OVH Jun 18 10:59:06 interesting Jun 18 10:59:08 https://github.com/ovh/overthebox Jun 18 11:00:23 ah, I've seen that before Jun 18 11:11:35 oh fsck. Germany will have toll for passenger vehicles starting 2020 ? Jun 18 11:16:24 yeah, and the fun thing I've read about it is: the state wmight actually loose money due to it Jun 18 11:16:42 because administrative overhead exceeds any possible income Jun 18 11:19:22 heh Jun 18 11:20:32 stintel: don't worry, they'll likely task an industry consortium involving t-systems, which will guarantee that the project will be over time, over budget and likely illegal under european law Jun 18 11:21:08 jow: well that's how I found out: https://www.apnews.com/526e128779234b0ba71893b48845382a Jun 18 11:21:39 well honestly I wouldn't mind toll that much Jun 18 11:21:46 as long as they keep the no speed limit zones Jun 18 11:22:10 these zones are increasingly getting rare Jun 18 11:22:19 kernel bumps with the CVE fixes pushed to staging Jun 18 11:22:43 the push for 4.19 in master contains an additional fix seen during refresh Jun 18 11:22:45 jow: still plenty on my trajectory ;) Jun 18 11:38:36 * ldir sets a build going Jun 18 11:46:14 also running compile tests here. If they succeed, I would push within 30 minutes :) Jun 18 11:51:05 jow: we Jun 18 11:51:07 oops Jun 18 11:51:26 there's also the possibility of running something like mirrorbits ourselves Jun 18 11:51:44 like lineageos, VLC, freifunk are doing Jun 18 11:51:46 https://mirrorbits.lineageos.org/TIMESTAMP?mirrorlist Jun 18 11:51:50 https://cdn.media.freifunk.net/171223_OpenInfrastructure.jpg?mirrorlist Jun 18 11:51:52 * ldir needs a bigger boat^Wbox Jun 18 11:52:39 ldir: I'm repeating myself a bit but there's always https://cfarm.tetaneutral.net/ ;) Jun 18 11:55:45 zorun: thanks for the reminder :) Jun 18 11:55:50 I've just applied for an account Jun 18 11:56:06 great ! Jun 18 11:58:57 btw, anybody planning to come to Battlemesh this summer in Paris? Jun 18 11:59:05 we just published a schedule: https://www.battlemesh.org/BattleMeshV12#Talk_Schedule_and_Workshops Jun 18 12:05:59 xback: it works for me on x86 (apu2) :-) Jun 18 12:08:00 ldir: Thank you :) Jun 18 12:08:07 did you build 4.14 or 4.19? Jun 18 12:13:50 4.14 Jun 18 12:14:27 when I last tried 4.19 won't build under macos - I'm dreading the switch! Jun 18 12:16:37 x86/64 4.19 -> perf breaks Jun 18 12:16:47 like usual Jun 18 12:17:02 ldir: do you maybe have that enabled ? Jun 18 12:18:43 no, it's a libelf availability issue when building out of tree modules e.g. anything cake or apu2 or wireguard related. Jun 18 12:19:04 Perf may well be b0rken too :-) Jun 18 12:19:42 I see Jun 18 12:32:52 zorun: there is, but that would require (root/ssh) access to all mirrors, wouldn't it? Jun 18 12:48:21 I'm having lots of troubles trying to solve this dependency when compiling openwrt sdk for 18.06.2 `No package 'protobuf' found` Jun 18 12:49:10 (for debian 9 stable) Jun 18 12:49:39 kernel CVE patches pushed to master & 19.07 Jun 18 12:49:54 currently compile/runtime testing 18.06 .. those will follow within an hour or so Jun 18 12:55:33 do we haev to do a new minor release soon? Jun 18 12:56:12 Hauke_work: we could kick off one today Jun 18 12:56:50 jow: I have a kernel update for lede 17.01 prepared at home Jun 18 12:58:04 Hauke_work: okay, what about defining a deadline, say tomorrow or thursday Jun 18 12:58:18 then I'll do tags and trigger release builds Jun 18 13:02:18 ok Jun 18 13:02:25 jow: a deadline is good Jun 18 13:05:17 Hauke_work: okay, then lets define thursday 16:00 utc Jun 18 13:06:13 jow: ok fine with me, can you please send a mail Jun 18 13:12:21 ynezz: Can I have your opinion on this one? https://github.com/openwrt/openwrt/pull/1967 Jun 18 13:12:46 ynezz: it will add a static delay .. but I also don't see another option. and it does indeed solve issues Jun 18 13:12:54 ynezz: I tend to merge it as-is for now Jun 18 13:13:50 well, hackish :) Jun 18 13:15:15 I checked the uqmi commands .. but was not able to find a command which can be checked multiple times in search of a flag Jun 18 13:15:25 which alters at some point Jun 18 13:15:44 pepe2k: ^ Jun 18 13:20:25 jow: no, I don't think so, a normal mirror maintained by rsync should be fine Jun 18 13:24:55 xback: https://i.postimg.cc/CxKzQwyY/qmi-ctl-sync.jpg Jun 18 13:28:32 pepe2k: so issuing the sync cmd should already return an ack? Jun 18 13:29:41 xback: haven't looked there for a long time but I think simply sending sync without waiting for indication msg won't work all the time Jun 18 13:30:50 "Description of QMI_CTL_SYNC_IND Jun 18 13:30:50 This indication synchronizes service and control points. The QMI_CTL_SYNC_IND command is only sent at modem bootup, including modem restarts. The indication is delivered using a backoff schedule of 0s, 1s, 2s, 4s, 8s, 16s, 32s, and 64s, after which the service stops sending indications. See Appendix B for state diagrams that explain the behavior of service and control points." Jun 18 13:32:44 xback: I'm not sure if I understood correctly the problem from the PR Jun 18 13:33:07 the sync clears the modem state, wiping all instance ID's open Jun 18 13:33:27 immediatly after that, we try to set a new wds profile Jun 18 13:33:37 and make a connection Jun 18 13:34:24 but running the commands behind sync tend to return errors once in a while Jun 18 13:36:40 xback: can you check whether the modem actually sends CTL_SYNC_IND after the RESP? Jun 18 13:38:06 xback: instead of that sleep() maybe we should wait in --sync for response and indication messages before exiting? Jun 18 13:41:44 pepe2k: I'll try to check it Jun 18 13:42:16 pepe2k: meanwhile, please also check the mail I just replied to (regarding a uqmi patch for unexpected responses) Jun 18 13:42:44 pepe2k: the coding style is wrong, but what's your 2 cents on the problem there? Jun 18 13:46:32 morning' Jun 18 13:47:10 xback: might be related but the author didn't give much context :/ Jun 18 13:48:23 yeah, he was actually onto something, I've reviewed it and wanted to merge it, but then -ENOREPLY Jun 18 13:51:37 I'm adding that uqmi patch locally into our products here Jun 18 13:51:54 works really well. lot less issues I have to admit Jun 18 13:52:13 I'm going to poke Mantas from 8devices if he could slap his colleague with some trout Jun 18 13:59:00 how far are the tcp sack panic patches for openwrt? Jun 18 13:59:24 almost three miles Jun 18 14:00:22 Hello, i have this nasty error "firmware_loading_store: map pages failed" anyone for help? Jun 18 14:00:56 xback: this actually looks like a bug fix but I would want to know what other messages where previously incorrectly considered by uqmi as resp type Jun 18 14:02:43 pepe2k: ynezz: just got a private reply back from the patch author. "Don't have time now .. maybe someday later" Jun 18 14:03:01 re-asked to provide some context in that case Jun 18 14:03:28 hm, bummer Jun 18 14:04:36 xback: can we ask Florian (GH PR author) to test it instead of the sleep workaround? Jun 18 14:05:31 jow: the most critical thing is the reliability of the main server running mirrorbits Jun 18 14:06:23 yeah, should be possible. Jun 18 14:06:35 jow: does it sound like something that should be run in-house or externalized? Jun 18 14:06:39 pepe2k: ill make a branch in my staging containg the local patch being used here Jun 18 14:06:43 and will ask him to test Jun 18 14:06:53 zorun: I will give it a spin later Jun 18 14:06:56 xback: ok Jun 18 14:07:01 it's a critical service, but that would mean one more thing to maintain Jun 18 14:07:17 pepe2k: thanks for your 2 cents :) appreciated! Jun 18 14:07:18 in the long run I'd still like to leverage some preexisting CDN solutions to good gegraphic distribution Jun 18 14:07:23 *to get Jun 18 14:07:59 and yes, yet another critical service isn't so great but right now the server already is critical so... not worse than before Jun 18 14:08:04 xback: welcome! Jun 18 14:08:18 makes sense (but it would be a pity to centralize yet another thing on cloudflare/fastly/etc) Jun 18 14:08:23 true Jun 18 14:08:43 pepe2k: any help? :( Jun 18 14:09:17 DuDu371: ath10k? Jun 18 14:09:45 I have been thinking of setting up a community-based CDN that would be accessible for free software projects, but the most difficult part is governance/trust/etc Jun 18 14:10:14 but pooling resources means better geopgrahical diversity so it would make a lot of sense Jun 18 14:10:33 zorun: well, the intention is not to switch to a CDN and then decommission the server Jun 18 14:10:43 "ask zorun and he'll mirror your stuff" might be a decent solution to avoiding governance/trust Jun 18 14:10:46 but the idea is to have opkg feed sources and download links etc. point to the cdn Jun 18 14:10:53 jow: this is no joking question... Jun 18 14:11:12 the CDN will still be fed by our machines Jun 18 14:12:30 zorun: I'll see how far mirrorbrain is getting us Jun 18 14:12:38 sorry, mirrorbits Jun 18 14:13:01 but it'll obviously not have any benefit unless we switch default urls to the redirector Jun 18 14:15:35 zx2c4: it's important so that things continue to work in the long-term (at least in my opinion, I know you work differently ;) ) Jun 18 14:16:07 jow: ok, I can help if you need a hand Jun 18 14:16:24 you don't plan to come to the battlemesh, do you? Jun 18 14:18:44 mirrorbits might not help that much with small files, because every request has to go through the redirector (unless it is itself clustered, but that starts to be really complicated) Jun 18 14:18:56 rubberduck: ? Jun 18 14:19:28 the tcp sack panic bug is not trivial as this may also crash openwrt routers Jun 18 14:20:25 well, you can workaround it, by iptables, powering off your router etc. :) Jun 18 14:21:10 or backporting the fix to the openwrt kernel versions. Jun 18 14:21:21 and that is my question. is domebody working on? Jun 18 14:21:35 it's already done Jun 18 14:21:40 rubberduck: I know. There are mitigations available, fixes are pushed to master, openwrt-19.07, openwrt-18.06 Jun 18 14:21:47 fine Jun 18 14:25:10 pepe2k: ath9k Jun 18 14:25:57 Hauke_work: mosquittoe 1.6.3 just released, I'll start updating now. Jun 18 14:29:22 ynezz: Just noticed you pushed the 4.19 bumps Jun 18 14:29:42 could it be you forgot cns3xxx? I noticed it in an older reply in the mail chain, but it seems to be lacking now :) Jun 18 14:30:10 Hauke_work: re: CONFIG_NET_DSA_LEGACY, that's valid point, the legacy bindings were removed long time ago. I'll send patch to remove it. Jun 18 14:30:16 pepe2k: the strange thing is that if i exec che script manualy (the dd command of eeprom extract) from shell, the file is created and ath9k is initialized Jun 18 14:32:12 xback: well, I've planned to bump all I've build tested, then there were some objections, then they should be runtested/acked so... Jun 18 14:32:31 s/then they/that they/ Jun 18 14:32:41 no worries :) Jun 18 14:32:53 i'll do it then Jun 18 14:36:25 tmn505_: thanks Jun 18 14:38:49 xback: but I've actually noticed, that you're already testing 4.19 bumps on cns3xxx but forget to ask you for Ack, sorry Jun 18 14:40:52 ynezz: no problem :) Jun 18 14:41:12 I bet lots of people are cheering at your commit :) Jun 18 14:46:17 Thanks ynezz for "official" 4.19 Jun 18 14:55:35 hey, is it just me or kernel bump to 4.19 goes wrong? error: http://sprunge.us/8IHUSt Jun 18 14:56:56 bugger - openwrt building borked on macos Jun 18 14:58:08 https://pastebin.com/tixkHLZd Jun 18 14:58:32 ldir: dizzy said we don't support that anymore ;) Jun 18 14:58:47 k'thx'bai Jun 18 15:00:33 i asked here some time ago about how producers get the individual data (SSIDs, etc) on the device while flashing but forgot about the details. is it written into a partition of the flash storage? Jun 18 15:00:48 and does openWRT provide mechanisms for that? Jun 18 15:02:01 charolastra: yes, no Jun 18 15:02:08 pepe2k: fixed xD Jun 18 15:02:58 so if i want SSIDs to survive a hard reboot, i need to make individual images? Jun 18 15:04:56 16:15:36 zx2c4: it's important so that things continue to work in the long-term (at least in my opinion, I know you work differently ;) ) Jun 18 15:04:57 i most certainly dont disagree with the importance of things working in the long-term. seems like an important virtue, especially for a mirroring system. Jun 18 15:18:28 and when attempting x86 https://pastebin.com/qaW24R8j - the wireguard thing is a red herring Jun 18 15:19:17 main.c missing? Jun 18 15:22:27 if you give my macbook a minute or 10 I'll produce a similar failure in another module. it's not wireguard Jun 18 15:23:13 ive seen errors like that when a build starts before untar completes Jun 18 15:25:27 here's a new one, similar, this time for exfat-nofuse https://pastebin.com/4tFdUQxC Jun 18 15:28:18 zx2c4: to set your mind at rest main.c is alive & well at wrt/build_dir/target-x86_64_musl/linux-x86_64/WireGuard-0.0.20190601/src ;-) Jun 18 15:28:27 so which linux distribution is preferable to build images? Jun 18 15:29:41 I think most of them will work. Jun 18 15:31:08 stopped using Void linux and Alpine linux because some weird random errors, now on debian stretch (stable) can't build image since kernel bump to 4.19 for ath79 Jun 18 15:32:10 MY_R: can you pastebin the error? Jun 18 15:32:17 already done it Jun 18 15:32:30 06.18 [16:55] hey, is it just me or kernel bump to 4.19 goes wrong? error: http://sprunge.us/8IHUSt Jun 18 15:33:15 MY_R: Have you tried doing a "make dirclean" and rebuilding? It looks like something with the build environment is screwed. Jun 18 15:34:05 mamarley, it is fresh docker image which working just fine with any previous commit and with fresh git clone Jun 18 15:48:15 anyone have contacts with wikidevi admin(s)? captchas dont work Jun 18 15:55:54 nm Jun 18 16:01:06 charolastra: not necessariyl separate images, you can have them in things like uboot-env partitions that aren't touched by factory resets Jun 18 16:04:01 hmm, is that writeabel through software or do i need to interface the hardware? Jun 18 16:08:09 karlp: ping ^ Jun 18 16:13:57 well, thanks for the info but i gotta go. will research that Jun 18 16:36:17 stintel, ynezz: account approved! enjoy! Jun 18 16:40:01 zorun: nice, thanks a lot! Jun 18 16:49:28 jow: did dizzy really say that? Jun 18 16:57:57 <_abc_> https://www.theregister.co.uk/2019/06/17/linux_tcp_sack_kernel_crash/ is this affecting openwrt boxes? Current? Jun 18 16:59:40 https://forum.openwrt.org/t/sack-panic-multiple-tcp-based-remote-denial-of-service-vulnerabilities/39028?u=jeff Jun 18 17:00:30 “The kernels containing the fixes for these CVE's have been pushed to master, 19.07 and 18.06. 17.01 will follow within 1 .. 2 days normally.” Jun 18 17:12:44 ldir: no he didn't. was just a tongue-in-cheek remark about a review comment I've recently seen about a package having "ifeq ($(HOST_OS),FreeBSD)" which was commented as " Jun 18 17:12:47 Not supported, drop Jun 18 17:12:50 " Jun 18 17:13:06 LOL @jow Jun 18 17:14:20 not sure if a HOST_OS,Darwin would've been acceptable Jun 18 17:16:12 zorun: cool! Jun 18 17:17:28 I don't know either. Jun 18 17:18:28 ldir: back on topic - so with Linux 4.19 you started to see thise build failures? Jun 18 17:18:56 * _abc_ wonders if the sack cve fix update will also fix the ping performance issues on his ar71xx boxes Jun 18 17:19:13 ldir: can you pastebin some examples? Jun 18 17:20:12 yes, and I already have. But I can generate some more in a little while. Jun 18 17:20:22 nm, will search the backlog Jun 18 17:21:26 ldir: does it happen only for x86/64 builds? Jun 18 17:21:28 if you search a bit further back (2 weeks??) when I first flagged this, I think nbd was around too. Jun 18 17:22:19 it appears to be doing something else wrong for ath79 builds. Jun 18 17:22:33 the failure mode reminds me on https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=a9f6fceb4255ba847415cf82035f5fde3dc0ce2a Jun 18 17:22:39 maybe we should host our own pastebin with a (for team members only) "convert to bug button" Jun 18 17:22:50 https://pastebin.com/h8fTa4gh Jun 18 17:24:58 my initial hit on this from 2+ weeks implicated STACK_VALIDATION - behaviour changed with libelf-dev (from homebrew) installed. Jun 18 17:26:05 ldir: can you build this standalone without errors? https://raw.githubusercontent.com/torvalds/linux/b326272010b6656210193d7ab93fa184087e8ee1/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c Jun 18 17:26:20 but it's a cross-compile thing where host doesn't have STACK_VALIDATION but the 'out of tree' kernel modules are somehow picking up 'libelf' that openwrt has built and throwing a wobbler Jun 18 17:26:52 I think there's Linux header search paths bleeding in, triggering the error you see Jun 18 17:27:22 standalone as in gcc -o calc_vmlinuz_load_addr calc_vmlinuz_load_addr.c Jun 18 17:28:02 yes Jun 18 17:28:24 "Usage: ./calc_vmlinuz_load_addr " as proof :-) Jun 18 17:29:43 can you also do a make target/linux/install V=sc to see the gcc command lines used? Jun 18 17:30:48 sure - hold on a minute or two - need to deal with dog & food Jun 18 17:33:18 https://pastebin.com/yZRC3Hfc Jun 18 17:36:31 can you replicate the error with the standalone gcc call when adding -I/Users/kevin/wrt/staging_dir/host/include ? Jun 18 17:39:44 You mean gcc -o calc_vmlinuz_load_addr calc_vmlinuz_load_addr.c -I /Users/kevin/wrt/staging_dir/host/include - that works Jun 18 17:41:32 without space after -I Jun 18 17:41:35 but okay Jun 18 17:42:05 whats the contents of arch/mips/boot/compressed/.calc_vmlinuz_load_addr.d ? Jun 18 17:45:39 doesn't exist Jun 18 17:45:59 ~/wrt/build_dir/target-mips_74kc+dsp2_musl/linux-ath79_generic/linux-4.19.52/arch/mips/boot/compressed Jun 18 17:47:00 ldir: actually nvm, been looking at the wrong source Jun 18 17:47:04 the error is quite obvious now Jun 18 17:47:11 https://github.com/torvalds/linux/commit/bec0de4cfad21bd284dbddee016ed1767a5d2823 Jun 18 17:47:27 that line 16 addition is what makes they tool nonportable Jun 18 17:47:32 *this tool Jun 18 17:48:01 this include line smells and I wonder if its the proper thing to do even on Linux Jun 18 17:48:15 heh, yep. looks pretty gross :) Jun 18 17:48:25 ../../../../ -- how did that ever get past reviewers???? Jun 18 17:48:30 cc stable for 2.6.32+ :) Jun 18 17:49:01 even sadder is that this is all to get #define SZ_64K 0x00010000 Jun 18 17:49:35 seems like it should be a command ine argument, if they were working on getting it to be page size, which was different on different archs. Jun 18 17:50:17 so my patch suggestion would be sed -i -e 's/SZ_64K/0x00010000/g' -e '/sizes.h/d' arch/mips/boot/compressed/calc_vmlinuz_load_addr.c Jun 18 17:50:47 karlp: well that thing is for mips32 only so probably okay to hardcode Jun 18 17:51:06 eyah, was just thinking, "ins't this just for mips anyway? can't it just be hardcoded?" Jun 18 17:55:32 I'll try that Jun 18 17:55:47 jow: working on it :) Jun 18 17:56:32 f00b4r0: great - thanks! Its not urgent at all, so take your time Jun 18 17:57:35 jow: no worries. I'll take a snapshot of the VM once i'm done, so I can revert to that if it happens again :) Jun 18 17:58:54 jow: i'll take the opportunity to reboot the metal to a newer kernel, while i'm there. Jun 18 18:00:59 jow: fwiw there is a set root password on these VMs. If you've lost it it might be a good idea to disable root entirely Jun 18 18:02:04 its randomized but I don't have the passwords with me Jun 18 18:02:34 but yes, disabling it entirely probably makes sense. At least I don't need root ssh access there Jun 18 18:04:42 jow: ok so I have an ath79 build Jun 18 18:05:39 ldir: maybe you can use your recently obtained mighty upstreaming powers to humbly suggest a patch to this Jun 18 18:06:35 ldir: could be that I'm mistaken but I have the feeling that the build would also fail on Linux if the host happens to have no Linux headers preinstalled Jun 18 18:06:46 lol! Jun 18 18:07:24 I've another test I wish to do 'cos I'm not convinced this is the only issue... Jun 18 18:07:28 that .c program will include "../../../../include/linux/sizes.h" from the source tree but that header in turn will try to include which is then taken from /usr/include Jun 18 18:11:25 jow: all done. Metal is rebooting. Jun 18 18:19:58 did I missed some anger? :p Jun 18 18:22:29 MY_R: I've seen that error before, you don't have toolchain build and trying to do kernel menuconfig? are you insane? :) Jun 18 18:22:34 MY_R: mips-openwrt-linux-musl-gcc: not found Jun 18 18:23:06 that kernel_menuconfig target is probably missing some dependency Jun 18 18:23:20 ynezz, before 4.19 it was working just fine, ye weird it didnt find it Jun 18 18:24:27 yes, it's possible, that something has changed in that kernel part Jun 18 18:24:43 :( Jun 18 18:25:50 well just use some workaround for the timebeing `make toolchain/install kernel_menuconfig CONFIG_TARGET=subtarget` Jun 18 18:28:11 ynezz: Anything special about urngd starting? The TurrisOS people use haveged, which throws random: ubusd: uninitialized urandom read warnings in dmesg. Jun 18 18:28:23 meaning it's not starting early enough Jun 18 18:30:49 urngd has START=00 in the initscript Jun 18 18:32:55 i mentioned that. They're saying 00 is not enough. It needs to run in preinit or something Jun 18 18:33:49 I didn't tried -1 :) Jun 18 18:35:02 iirc usbd is launched by procd Jun 18 18:35:07 *ubusd Jun 18 18:35:17 I even played with that idea as well Jun 18 18:36:52 I was running urngd before ubusd, but it didn't helped much, because it still takes time to init that jitter rng Jun 18 18:37:30 and this would make urngd hard dependency for no gain, so I've scrathed that idea Jun 18 18:37:57 right. with haveged it warns on jshn and procd as well. Basically same behavior as with urandom-seed. Jun 18 18:38:06 in a few minutes I'll know if your master debug skills have fixed ath79 build on macos. It's looking hopeful. Jun 18 18:38:38 and I would need to refactor procd or urngd little bit as well, because that early service can't fail, since it's restarted forever Jun 18 18:38:46 I only have urngd installed and get none of these errors Jun 18 18:38:49 but I also suspect x86 is still b0rken. But let's see. Jun 18 18:39:07 on my mt7621 device Jun 18 18:42:37 mangix: I would simply conclude, that jitter rng used by urngd is simply faster then the haveged stuff, so it urngd can feed kernel with more noise in short time Jun 18 18:43:27 ldir: http://phase1.builds.openwrt.org/builders/x86%2F64/builds/1533 build fine on real OS :) Jun 18 18:44:09 ynezz: makes sense Jun 18 18:44:17 * ldir looks in trout cupboard... Jun 18 18:48:57 hmm, libuhttpd-2.2.1/src/utils.c:79:24: error: too many arguments for format Jun 18 18:49:17 ustream_printf(us, "\r\n", len); Jun 18 18:49:36 wait, or look deeper? Jun 18 18:51:17 nmrh: fc454ca15305e332a35c9bc1e60dde18f69ac210 has introduced format string checks Jun 18 18:52:29 someone has already reported it here, even with the patch, he even got a review here, but didn't moved forward with that Jun 18 18:53:26 _abc_: ping - describe your ping problem Jun 18 18:53:34 k, i'll wait Jun 18 18:55:12 nmrh: http://logs.nslu2-linux.org/livelogs/openwrt-devel/openwrt-devel.20190617.txt look at the posts of luaraneda Jun 18 18:55:24 ty Jun 18 18:55:38 ty = send a patch :) Jun 18 18:56:09 we can help you with that, no worries Jun 18 18:57:17 nmrh: well, looking at it now again, it should be fixed with 3c401f45c988aa6333a03efea1b1ac0318a8c11d Jun 18 18:57:37 let me have a look Jun 18 18:58:13 git.openwrt.org/91fcac34ac014a565fdd6312de088d312b5ba7ec Jun 18 19:03:41 looks like this was merged a couple of days ago, now i need to figure out why I'm running into it now Jun 18 19:05:49 nmrh: the problem in ustream_printf should be fixed since some days Jun 18 19:09:30 yea, i'm not sure why I hit it just now... give me a minute Jun 18 19:09:43 maybe the uhttpd package wasn't updated Jun 18 19:10:08 it was Jun 18 19:11:14 jow: ath79 is fixed thanks to you. x86 remains broken Jun 18 19:16:25 https://pastebin.com/V5ARR92y Jun 18 19:17:34 ynezz, ah ye thank you for workaround! :) Jun 18 19:18:11 ldir: does it occur when you disable the stack protection thingies in kernel_menuconfig ? Jun 18 19:19:10 will try Jun 18 19:19:35 indeed, that strange error looks like objtool again Jun 18 19:19:50 someone should fix it upstream :) Jun 18 19:20:12 jow: on uClibc-ng, I managed to make a package compile by filtering out ICONV_C[PP]_FLAGS . The error seems to be caused by this: https://github.com/openwrt/openwrt/blob/master/package/libs/libiconv/src/include/iconv.h#L16 . Any thoughts? Jun 18 19:26:04 <_abc_> ldir: ping problem: ar71xx tl-wr741nd with 18.06.2 (and also .1) reacts slowly to "fast ping streams" on lan. Specifically, fast pings sent with f.ex. while :; do ping -w1 -c1 $routerip; done ;; the routerip is the AP router bezond the openwrt box which acts as wifi client with nat. The ping stream has normal ping times (~1.5ms) but stalls every second, after 10-15 pings, then starts again at the top Jun 18 19:26:10 <_abc_> of the next second, another 10-15, stall, repeat. Jun 18 19:26:42 i don't get it, if I clone into uhttpd i see the latest changes Jun 18 19:26:43 <_abc_> ldir: I upgraded from 18.06.1 to .2 just to check this is consistent. Other router used instead of this one, exact same config, does not show the problem. Including not 17.x openwrt. Jun 18 19:26:55 but my build tree is different Jun 18 19:27:14 will try make dirclean and try again... Jun 18 19:27:39 but I know I did that (twice) about 2 hours ago... Jun 18 19:27:46 <_abc_> ldir: So I tried every tweak I could in the tcp/ip stack via sysfs, no change. No rate limit is in effect, no QoS is installed. Jun 18 19:28:50 ok I'll see if I see anything similar - I have 2 archer c7s as AP and sometimes pings have high latency and packet loss. Jun 18 19:28:56 nmrh: do you have CONFIG_SOURCE_TREE_OVERRIDE and/or a git-src symlink in package/network/services/uhttpd/ ? Jun 18 19:29:48 mangix: which error? Jun 18 19:29:50 i'll have to look, I don't think i have a git-src symlink Jun 18 19:30:51 jow: https://downloads.openwrt.org/snapshots/faillogs/arc_arc700/packages/dosfstools/compile.txt Jun 18 19:31:15 cat .config | grep CONFIG_SOURCE_TREE_OVERRIDE returns nothing Jun 18 19:33:48 I have some backports of which are fixing some CVEs for hostapd for 18.06: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commitdiff;h=71233d01f38c1770db87be19219827fe041367e6 Jun 18 19:33:49 <_abc_> ldir: be sure to ping the AP, i.e. through the openwrt as client to the AP, or one hop after it if transparent Jun 18 19:33:59 <_abc_> ldir: one more thing: I use plain WPA2 here. Jun 18 19:34:10 I am unsure if I should push them to openwrt-18.06 as they are mostly not relevant for our use cases Jun 18 19:34:20 and didn't got much testing Jun 18 19:35:13 oh, I have an idea about how this can be my fault... Jun 18 19:36:38 <_abc_> Hehe. Is this timely in the context of git used on openwrt? https://devclass.com/2019/06/18/github-acquires-pull-panda-pushes-toolset-for-free/ Jun 18 19:36:52 * _abc_ is a git n00b, just saw the info and am sharing the link Jun 18 19:37:02 i think i've been recycling the same .config for too long Jun 18 19:42:45 <_abc_> Speaking of .config, are you using the pre-created default config when building "default" new / updated released code or are you using your "own" tweaked one, hoping for the best? Jun 18 19:42:51 <_abc_> nmrh: is this what you referred to? Jun 18 19:43:24 _abc_: I've been using my "own tweaked" one Jun 18 19:43:28 mangix: seems like it lacks -liconv, maybe the ldflags got dropped/filtered during the build Jun 18 19:43:55 I try a default config seed and see if that resolves it Jun 18 19:44:05 Hauke: ping Jun 18 19:44:11 Borromini: pong Jun 18 19:45:35 <_abc_> Is there anything in the tcp/ip stack in openwrt 18.06.2 or any version which would stall and restart in second rhythm? For any reason? kernel scheduler? net scheduler? Any ideas what to look at? Jun 18 19:46:22 did you tried latest ar71xx snapshot? Jun 18 19:46:40 maybe mib counters Jun 18 19:47:22 https://forum.openwrt.org/t/vi-error-on-new-build/39048 Jun 18 19:47:28 didn't we bump busybox recently? Jun 18 19:47:31 <_abc_> No, I never use the snapshot for these boxes, they are to route internet for the other boxes :) Can't afford for them to have problems. Jun 18 19:50:42 _abc_: then I'm out of ideas, sorry Jun 18 19:54:48 <_abc_> ynezz: it's ok, some day the problem will emerge. Is there a debug setting one can activate in a default image kernel which would show timestamped network events in the dmesg/logview etc? Jun 18 19:56:58 Hauke: concerning FS #2297, you may well be right I am experiencing an unrelated issue. I tested your patch ynezz linked me to and that breaks my dir-860l again - https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/patch/?id=d6ed083f5cc621e15c15b56c3b585fd524dbcb0f Jun 18 19:58:16 _abc_: well, the situation with ar71xx is following, 19.07 is the last release (should be out soon) with ar71xx, we've already disabled ar71xx snapshot images, so now the focus is towards ath79 (ar71xx successor) Jun 18 19:58:28 Borromini: do you have a serial connected to your device? Jun 18 19:58:31 so for me, reverting the MIPS hardened copy bits fix my mt7621 dir-860l. both ath79 WNDR3700 v1 models I have are choking on recent master/19.07 images as well, but reverting the hardened copy bits doesn't seem to do anything for them. Jun 18 20:00:01 <_abc_> ynezz: I am aware. But I would like to play with these trusty boxes a while longer, I hw modded them etc. Jun 18 20:00:55 _abc_: openwrt-19.07 branch for ar71xx should be already considered stable, so if you can build your own images, I would try it Jun 18 20:02:04 _abc_: otherwise you've to wait for the v19.07.0-rc1 and then report back Jun 18 20:03:37 i have no serial access to either the mt7621 or the ath79 devices, so i hope someone else can test mt7621 and older ath79 devices (and has a way to restore them if things go wrong) Jun 18 20:05:17 MY_R: I'm almost 100% sure, that the problem you're seeing is not related to the 4.19 kernel bumps Jun 18 20:06:30 Borromini: I have been running 4.19 on my UAP-AC-PRO for quite some time without any issues. (It can be restored easily using TFTP without serial access.) Jun 18 20:06:56 ynezz, with this commit is still fine aa3f9736ea67200dd840093b848606ced27d388e [kernel: bump 4.19 to 4.19.52] Jun 18 20:07:17 MY_R: nm, it was wrong window, it is caused by the kernel bump Jun 18 20:07:29 :) Jun 18 20:08:56 <_abc_> ynezz: I'll wait, I have my hands full, openwrt hw mods are on back burner here. Jun 18 20:18:37 MY_R: 4.19.48 has introduced it with `jump_label: move 'asm goto' support test to Kconfig` CC_HAS_ASM_GOTO Jun 18 20:22:06 ynezz, great, so you know how fix it and soon I can use again kernel menuconfig earlier and not after whole toolchain build ;) Jun 18 20:22:15 nope Jun 18 20:23:05 they need target toolchain in order to set CC_HAS_ASM_GOTO variable Jun 18 20:24:00 :\ Jun 18 20:24:06 evolution :) Jun 18 20:25:07 better start updating wiki/doc :D Jun 18 20:25:50 jow:busybox was updated to 1.31.0 last weekend Jun 18 20:27:40 MY_R: or switch to 5.2, where it's already handled nicely it says `scripts/Kconfig.include:35: compiler 'mehgcc' not found` :) Jun 18 20:30:04 ynezz: MY_R: the obvious solution is to make the toolchain a build prerequisite for the kernel_*config targets ;) Jun 18 20:30:25 MY_R: https://git.kernel.org/torvalds/c/902a6898bfb4878eb186d9223d12c903a5f60fa5 Jun 18 20:30:31 KanjiMonster: yeah Jun 18 20:32:36 so we get another kind of bug reports, 4.14 oldconfig took ~1800x less time to finish... Jun 18 20:32:41 but I wanted just update kernel with fixed SACK crap :< :D and my wdr3600 still didnt have 4.19 inside ;) Jun 18 20:36:23 ynezz: you'll need the toolchain later anyway to do anything with your changed config, so tough luck *closes as not a bug* ;) Jun 18 20:50:22 KanjiMonster: the tough bit is to make it depend on toolchain if the kernel is > 4.14 Jun 18 20:50:55 since it's include/toplevel.mk where you can't do `ifeq ($(strip $(call kernel_patchver_ge,4.19.0)),1)` Jun 18 20:51:56 or just make it hard dependency and call it a day? Jun 18 20:53:04 http://paste.debian.net/1088379/ Jun 18 20:55:55 aaaargghh I'm trying to turn off CONFIG_STACK_VALIDATION=y but it keeps coming back Jun 18 20:57:06 okay... any hints on why my W268R (a Ralink RT3050 as a wifi client) disconnects from the AP (An ath10k APU2, not openwrt) like 4-5 seconds after connecting if i enable WDS and put it into a bridge? Jun 18 20:57:30 target/linux/generic/config-4.19 says it is unset - target/linux/x86/64/config-4.19 has it enabled but I have deleted those lines so I thought generic would apply. Jun 18 20:58:11 then it tries again and again with a progressively longer backoff .. (and i think claiming it as AUTH_FAILED... but based on my reading the ath10k says it left on it's own) Jun 18 20:58:30 ldir: it can be set by the kernel itself Jun 18 20:59:18 select STACK_VALIDATION if HAVE_STACK_VALIDATION -> select HAVE_STACK_VALIDATION if X86_64 :) Jun 18 20:59:48 How do I stop the bastard thing for purposes of testing/proving something Jun 18 21:02:04 probably by removing `select HAVE_STACK_VALIDATION if X86_64` Jun 18 21:09:26 ynezz: thank you - it looks hopeful - not cheering yet. Jun 18 21:13:53 ynezz: I'd probably just make it a hard dependency (wouldn't be surprised if the commit eventually trickles downstream) - a bit shorter version (untested): https://pastebin.com/hQPjx0eK Jun 18 21:14:47 but the thing is, that kernel_patchver_ge isn't available Jun 18 21:15:37 ynezz: ah, I thought that diff implied you found where you can do that Jun 18 21:15:48 I've tried to move this to target/linux/Makefile but then there's no toolchain/install etc. Jun 18 21:17:13 ynezz: you could try what happens if you include include/kernel.mk in include/toplevel.mk Jun 18 21:17:30 monsters everywhere Jun 18 21:17:45 I'm afraid I can kill something like IB/SDK Jun 18 21:21:27 https://pastebin.com/eGvFnr1c ? Jun 18 21:24:13 it's building toolchain for 4.14 and 4.19 as well Jun 18 21:28:50 but it's going to work in target/linux/Makefile Jun 18 21:31:42 bah, but then there it's not possible to depend in toolchain/install Jun 18 21:31:50 s/in/on/ Jun 18 21:38:03 ynezz: maybe just always depend on it and call it a day; 4.14-'s days are numbered anyway Jun 18 21:39:52 KanjiMonster: yeah, that's my plan, maybe someone else could improve it Jun 18 22:32:31 ok, so after make distclean; new config.seed (which hasn't been updated since Jan 1) and a few menuconfig "tweeks" build faild again with uhttpd error Jun 18 22:33:47 i'm off to the forums to look/post details there... Jun 18 22:34:31 you're building latest master, right? Jun 18 22:34:35 yes Jun 18 22:34:54 last sucsessful build about 6-7 days ago Jun 18 22:36:15 building for ipq806x/r7500v2 only, a few kmods included in image for usb, strongswan... Jun 18 22:36:32 ath10k-ct-htt Jun 18 22:37:49 i'll post my .config and the error in the dev forum in a minute Jun 18 22:38:53 make package/uhttpd/{clean,prepare} V=s 2>&1 | grep tar Jun 18 22:39:00 this should be enough Jun 18 22:39:06 k Jun 18 22:39:44 you should be compiling uhttpd-2019-06-16-91fcac34 Jun 18 22:48:45 https://forum.openwrt.org/t/trouble-building-master-with-package-uhttpd/39054 Jun 18 22:49:52 i did superficially check the makefile but mabey I missed something Jun 18 22:54:07 nmrh: interesting, can you please provide output of `make package/uhttpd/{clean,compile} V=s` as well? Jun 18 22:54:17 sure, give me a min Jun 18 22:55:10 nmrh: and output of `scripts/diffconfig.sh` as well Jun 18 22:57:55 exceeded char limit (+59k) pastebin ok? Jun 18 22:58:12 it looks like it compiled without error Jun 18 22:59:16 so where is the error? :) Jun 18 23:00:03 first: https://pastebin.com/unA04w0W Jun 18 23:01:06 looks okish Jun 18 23:03:24 the error: https://pastebin.com/Tj3FYbT8 Jun 18 23:04:08 oh, I see it now Jun 18 23:04:40 package/feeds/packages/libuhttpd/compile Jun 18 23:06:30 I'm trying to compile master but get the error "as: unrecognized option '-EL'" while compiling "toolchain/gcc/initial compile" ("toolchain-mipsel_24kc_gcc-7.4.0_musl/gcc-7.4.0") Jun 18 23:06:51 nmrh: you should report it at https://github.com/openwrt/packages/issues Jun 18 23:06:57 I checked out a fresh git copy and started from the beginning, but still doesn't work Jun 18 23:07:12 k Jun 18 23:07:48 My last working compile was r10231 (1fd900ddc2) Jun 18 23:08:24 I'm on fedora 30, GCC 9.1.1 Jun 18 23:08:57 does anyone have similar problems? Jun 18 23:16:10 Crickets might just mean that the Europeans have gone to sleep Jun 19 01:17:46 build #370 of apm821xx/sata is complete: Failure [failed images] Build details are at http://release-builds.lede-project.org/17.01/images/builders/apm821xx%2Fsata/builds/370 blamelist: Hauke Mehrtens Jun 19 02:01:37 You guys ever see ipv6 crap out after a few hours on 4.19? It's done it pretty consistently for me on the master branch for a while now. 4.14 has been fine Jun 19 02:03:45 No process crashes or errors of any kind in the system or kernel logs **** ENDING LOGGING AT Wed Jun 19 02:59:57 2019