**** BEGIN LOGGING AT Wed Jan 29 02:59:57 2020 Jan 29 03:04:10 * russell-- is allergic to client isolation Jan 29 03:09:54 <[mbm]> same, which is why I'm trying to turn the damn thing off Jan 29 03:14:35 <[mbm]> well, did the cheap solution and turned off multicast_to_unicast on br-lan to remove the ap_isolate from hostapd Jan 29 03:15:43 <[mbm]> I get why multicast_to_unicast was set, what I don't get is why it broke my network Jan 29 07:37:17 greearb__: hi Jan 29 07:37:26 greearb__: I am now Jan 29 08:28:55 for https://lxr.openwrt.org/source/procd/service/instance.c#L827 coverity reports "CID 1457938: API usage errors (PW.BAD_PRINTF_FORMAT_STRING)" is that because of %m ? Jan 29 08:29:14 because it seems to work fine `procd: unable to find /sbin/ujail: No such file or directory (-1)` Jan 29 08:32:06 ynezz: likely. %m is a GNU extension iirc Jan 29 08:32:31 I'd replace it with %s and explicitely pass strerror(errno) as further argument Jan 29 08:33:11 but %m saves some flash space :p (I remember such patches from the past into other owrt C projects) Jan 29 08:35:04 procd has --std=gnu99 Jan 29 08:35:30 actually %m is not GNU but a glibc'ism which has been adopted by uClibc and musl Jan 29 08:35:37 at least according to my local man page Jan 29 08:35:44 thanks for checking Jan 29 08:37:12 for example https://git.openwrt.org/?p=project/mdnsd.git;a=commit;h=78974417e182a3de8f78b7d73366ec0c98396b6c Jan 29 08:40:18 *shrug* Jan 29 08:40:28 its a case-by-case decision I guess Jan 29 08:40:50 :) Jan 29 08:40:51 %m likely does not harm and is less dangerous than other, more esotheric format patterns Jan 29 08:40:57 e.g. ones that allocate memory or somesuch Jan 29 08:57:14 little bit off-topic, but I'm using some Quectel EC2x modems for data/gps and GPS timestamps seems like weird recently Jan 29 08:57:24 $GPRMC,085314.0,A,4938.347106,N,01808.392637,E,16.9,315.9,140600,,,A*5C Jan 29 08:58:05 this is just from a few minutes ago, 140600 is the date which is weird Jan 29 08:58:18 14 for a day, 06 for a month and 00 for a year Jan 29 08:58:38 does GPS have some y2k2 overflow or such? does it rings a bell? Jan 29 09:00:56 iirc GPS has some unusual overflow/wrap around semantics Jan 29 09:01:20 https://www.theregister.co.uk/2019/02/12/current_gps_epoch_ends/ Jan 29 09:02:30 ugh, nice, thanks! Jan 29 09:03:40 maybe you can somehow correct that by applying a fixed offset Jan 29 09:03:56 like convert to unix timestamp, add 20 years, convert to local time again Jan 29 09:24:15 I am supprised that this GPS overflow bug is so common Jan 29 09:25:57 well, it doesnt make sense to me anyway Jan 29 09:26:35 according to this https://www.quectel.com/infocenter/news/475.htm rollover happened on 4.4.2019 Jan 29 09:26:45 and EC20 is listed as fine Jan 29 09:27:09 it started happening around 11.1.2020 Jan 29 09:30:57 ynezz: the coverity thing.. is there a way of putting a code comment in to tell coverity 'yes we know!' - might be worth a comment anyway in relation to this conversation Jan 29 09:32:00 ldir: I would rather replace %m with %s and strerror then adding useless comment or some coverity attribute Jan 29 09:33:08 I'd argue it's a 'useless comment' but ok :-) Jan 29 09:35:35 ldir: ok, so I'm wondering what comment content do you suggest? :) Jan 29 09:35:44 man 3 printf? Jan 29 09:37:03 "%m is glibc & ok, ignore coverity warning' Jan 29 09:37:47 "%m is glibc, musl & ok, ignore coverity warning' Jan 29 09:37:54 m (Glibc extension; supported by uClibc and musl.) Print output of strerror(errno). No argument is required. Jan 29 09:38:50 so I really don't see a point of duplicating this information into the source code Jan 29 09:39:19 coverity should fix this, detect --std=gnu99 and be fine with %m Jan 29 09:40:30 yes I agree, but in the meantime to prevent some overzealous 'low hanging fruit' fixer what is the cost of a comment? Jan 29 09:47:56 well, I prefer clean code Jan 29 09:47:57 it's the sort of thing I might be tempted to fix^wbreak with the result of using more flash space :-) Jan 29 09:49:01 if you tell me, that there is a plan to make 0 coverity bugs, then I'm all in for adding such coverity attributes and/or replacing %m with %s/strerror Jan 29 09:49:19 otherwise its just bikeshedding :) Jan 29 09:49:49 * ldir steps away from the bikeshed Jan 29 09:51:15 I'd say ignore it for now Jan 29 09:51:24 there's more pressing things to take care of :) Jan 29 09:57:17 I'm more curious how it saved space anyway. strerror's going to exist anyway Jan 29 09:58:07 ynezz: btw, current gpsd includes an automatic detection and workarounding logic for the GPS week rollover bug. Jan 29 09:59:56 PaulFertser: well, that GPS week rollover should've happened 4.4.2019, so it makes no sense that I'm seeing such issues from 11.1.2020 Jan 29 10:00:06 ynezz: so you can try feeding the NMEA stream to it and see whether it manages to cope with it. Jan 29 10:01:32 ynezz: well, probably your receiver had some logic of its own for this thing. Or it wasn't rebooted since then. I recommend trying with current gpsd, and probably talking to gemiller on #gpsd , it's an interesting that the breakage occurs just now. Jan 29 10:08:55 karlp: probably because it requires less instructions. By using %m, the logic happens internally in printf(). Otherwise you first need to call strerr, store the intermediate result somewhere, pass an additional argument to printf which takes stack or register space Jan 29 10:24:53 one would think the compiler would recognise such classic behaviour as strerror though, at least these days. Jan 29 10:25:03 but I guess. Jan 29 10:25:51 it cant' turn your %s into a %m for you, Jan 29 10:48:36 ynezz: its known that GPS was not functional on those EC devices with old firmware Jan 29 10:48:50 ynezz: my colleague reported it to Quectel last year and received new firmware Jan 29 10:49:24 also GPS coords where way off .. (error of 10 .. 15 km, even with perfect satellite view) Jan 29 10:50:02 We received newer firmware from quectel. It's annoying that they don't offer a download on their site Jan 29 10:54:54 xback: yep, I assumed so, contacted them, thanks for confirmation! Jan 29 10:55:13 ynezz: I can share the fw and upgrade tool privately if you want Jan 29 10:55:20 it's a windows app .. Jan 29 10:55:34 I've that for linux Jan 29 10:55:42 oh? :-) Jan 29 10:55:57 and it's in source code as well Jan 29 10:56:04 oooh :-) Jan 29 10:57:16 EC20 has Android inside, so it's modified fastboot Jan 29 10:59:14 are we still on track for 19.07.1 tonight? should I be expecting to see some extra security stuff get pushed out of the dark just before the build or is the present state == 19.07.1 other than the number? Jan 29 11:01:05 there'll be more fixes Jan 29 11:03:40 xback: FYI https://osmocom.org/projects/quectel-modems/wiki/EC20#Log-of-flashing-process-from-firmware-version-EC20EQAR02A05E2G-to-EC20EQAR02A09E2G this is from i.mx6 Jan 29 11:16:30 jow: Hauke: fyi regarding 19.07, I won't be pushing a kernel bump today Jan 29 11:22:09 https://openwrt.org/releases/19.07/notes-19.07.1 is ready, proof-reading is welcome! Jan 29 11:22:48 it should just need last-minute changes (date, last-minute fixes, link to advisories) Jan 29 11:31:35 zorun: luci support for configuring firewall snat/masquerade rules and switches for vlan/switch configuration on some devices Jan 29 11:31:52 s/switches/fixes/ Jan 29 11:32:30 Hi is this https://github.com/openwrt/openwrt/commit/ea5078014d3f8a6f662e41cf9dec23028ca303e3 Jan 29 11:32:35 zorun: There is a typo also: "Update mac80211 to 4.19.85 to 4.19.98" Jan 29 11:32:38 part of the make wifi fast stuff? Jan 29 11:32:38 from* Jan 29 11:35:31 xback: fixed, thanks Jan 29 11:36:03 jow: oh right, didn't think of looking at LuCI Jan 29 11:39:30 jow: yay, thanks for merging LuCI translations from master to 19.07 \o/ Jan 29 11:48:14 https://openwrt.org/releases/19.07/notes-19.07.1#luci_web_interface Jan 29 12:00:45 I presume that the versions are going to change on things like libubox or procd wherever this security issue is that's triggering the release too... Jan 29 12:34:01 is there a guide or recomended practice regarding target/linux//config- files (for kernel configs) Jan 29 12:34:44 when going from say 4.19 to 5.4 Jan 29 12:36:46 cp config-4.19 config-5.4; make kernel_oldconfig ? Jan 29 12:37:46 ahh, I think `make kernel_oldconfig` may be what i'm looking for Jan 29 12:37:51 ty Jan 29 13:44:47 this is ABI change, right? https://patchwork.ozlabs.org/patch/1230746/ Jan 29 13:45:02 blobmsg_get_string(struct blob_attr *attr) -> blobmsg_get_string(const struct blob_attr *attr) Jan 29 13:47:22 shouldn't affect the abi Jan 29 13:47:46 see also https://stackoverflow.com/questions/5083765/does-changing-fmystruct-a-to-fconst-mystruct-a-breaks-api-abi-in-c Jan 29 14:02:15 hmm, flashes latest build.. he ddns update stops working... dig dig dig... Jan 29 14:02:33 he hurrican? Jan 29 14:02:40 aye Jan 29 14:02:41 there's a brand new PR fixing it iirc, one tick Jan 29 14:03:16 who broke it?! Been running for years :-) Jan 29 14:03:20 nvm, seems it was 1806, just saw it in my mail feed: https://github.com/openwrt/packages/pull/10964#event-2989426911 Jan 29 14:04:03 maybe still relevant though? Jan 29 14:15:56 * ldir keeps digging Jan 29 14:25:03 hmm, renaming a ddns provider is going to cause a migration issue. Jan 29 14:25:40 and there's tunnelbroker for he tunnels and then there' he's dynamic dns service, one can auto link into the other. Jan 29 14:28:15 yeah, I don't think that PR is/ws correct, just remembered seeing a "ddns hurricane electric pr" earlier. Jan 29 14:29:03 packages 3dbdd67cf93e5f2c271e7663b35353f8c8102757 needs reverting Jan 29 14:29:52 and if there is a new 'correct' way of doing dns updates then it needs doing for ipv6 support not just legacy ip Jan 29 14:30:10 it would help if people could finally standardize ddns somehwat Jan 29 14:30:49 ugh. and that commit message :/ Jan 29 14:30:49 yeah, old he wsas't buggy, domain _was_ username. Jan 29 14:31:05 somebody hasn't heard of linebreaks Jan 29 14:31:20 just an eidtor that was wrapping for them, they didn't even see it Jan 29 14:31:55 DDNS *is* standardized. people just need to use the actual standard, rather than reinventing their own alternatives constantly Jan 29 14:34:34 it would help if PRs were tested . But I guess that's why I like running bleeding edge - oh well :-) Jan 29 14:36:32 from what I remember the 6in4 interface module setup script for HE would automagically update the tunnel end point, and the end point update can be configured to automagically update an HE ddns entry. Jan 29 14:38:06 ldir: pfft, testing prs... all you get from that is long backlog and angry contributors Jan 29 14:38:38 just fix broken prs with differently broken prs later Jan 29 14:53:59 build #248 of mpc85xx/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fgeneric/builds/248 blamelist: Felix Fietkau , David Bauer , Jason A. Donenfeld Jan 29 14:54:51 build #248 of layerscape/armv8_64b is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/248 blamelist: Felix Fietkau , David Bauer , Jason A. Donenfeld Jan 29 15:42:32 any last words before tagging? Jan 29 15:51:12 good luck! Jan 29 15:51:13 :) Jan 29 15:52:30 * ldir offers the words 'run' & 'hide' :-) Jan 29 15:52:35 doh, gotta rename language files. Jan 29 15:54:48 hm, which mt76xx device is ver:1 eco:1 = 0x0101 as in (rt_sysc_r32(SYSC_REG_CHIP_REV_ID) & 0xFFFF) == 0x0101 ? Jan 29 15:56:44 so far I've found following in the dmesg logs: MediaTek MT7688 ver:1 eco:2 = 0x0102, MediaTek MT7628AN ver:1 eco:2 = 0x0102, MediaTek MT7621 ver:1 eco:3 = 0x0103, MediaTek MT7620A ver:2 eco:3 = 0x0203, MediaTek MT7620N ver:2 eco:6 = 0x0206 Jan 29 15:56:53 karlp: if you mean that luci bcp47 change then sorry for that. But eventually I had to give in and follow what weblate wants to do Jan 29 15:57:26 yeah, it's ok, it's straightforward. Jan 29 15:57:39 I had already been wondering about the things poedit was trying to tell me vs what we had :) Jan 29 15:58:08 I don't actually _have_ any translations anyway, just went and made sure it _worked_ and was _possible_ a little while ago :) Jan 29 15:58:33 you could think about publishing your packages, then they'd get (some) translations for free Jan 29 15:59:05 about half of them are public, but I'm not sure they're useful to be anywere like luci, as they rely on other things. Jan 29 15:59:47 the couple of people who've asked about translations were quite happy when I said, "I can give you pot files to fill in if you like" so that's enough for me Jan 29 16:00:20 https://github.com/etactica/owrt_pub_feeds/tree/master/open-translations Jan 29 16:02:33 butcher.py there has been handy for finding un-flagged translations. Jan 29 16:02:38 I don't know how other people do it. Jan 29 16:02:53 I mean, code review, sure, but easy to miss stuff. Jan 29 16:26:25 karlp: what do you mean with unflagged translations? Jan 29 16:26:32 ones not marked fuzzy? Jan 29 16:29:12 ah you mean finding untranslated msgids? Jan 29 16:29:46 yeah it became clear after reading the readme Jan 29 16:29:50 who does that anyway :P Jan 29 16:31:22 yeah, visuall scanning the ui for antyhing legible, not just "xxxxxxx" was super quick and finding things I'd missed :) Jan 29 16:56:55 jow: any idea why modules/luci-mod-status/htdocs/luci-static/resources/view/status/routes.js does not exist in openwrt-19.07? does it still use the Lua code? Jan 29 17:03:27 zorun: yeah, it is still Lua based Jan 29 17:08:02 fudge me! 4.19.100! Jan 29 17:12:09 jow: ok, thanks Jan 29 17:17:04 * Slimey does git pull && ./scripts/feeds update -a && ./scripts/feeds install -a Jan 29 17:21:56 https://openwrt.org/releases/18.06/notes-18.06.7 Jan 29 17:22:05 not much to see for now Jan 29 17:25:04 build #285 of brcm63xx/generic is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/master/images/builders/brcm63xx%2Fgeneric/builds/285 blamelist: Felix Fietkau , David Bauer , Jo-Philipp Wich Jan 29 17:26:01 build #286 of oxnas/ox820 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/286 blamelist: Felix Fietkau , David Bauer , Jo-Philipp Wich Jan 29 17:28:20 <_lore_> ack Jan 29 17:31:58 sigh... people bombarding the gitweb interface with nonesense http requests leaving picture links with putin in the referrer Jan 29 17:32:40 why must the internet be full of crazy dimwits Jan 29 17:33:27 lel Jan 29 17:39:31 jow must be the KGBBot lol Jan 29 18:02:48 jow: hi. i see 19.07.1 has just been tagged, i was wondering if b3e86cbb4f54d92eb4d145c62a7165067c6a7612 might have been worth adding to it as well (although this did not affect me myself, so no idea about its impact) Jan 29 18:10:06 Borromini: looks good, we can add it into the next version Jan 29 18:12:02 Hauke: ok :) Jan 29 18:12:11 thanks! Jan 29 18:13:46 Tapper: The mac80211 update to 4.19.98 only contains some security updated for some marvell driver and other bugfixes Jan 29 18:15:19 jow: thanks for tagging Jan 29 18:46:13 Anyone know what is the default driver version that ath10k-ct uses in OpenWRT now? I'm wondering how far back I need to backport changes, as I am currently developing on 5.2 and 5.4 Jan 29 18:49:12 should be 4.19: Jan 29 18:49:21 https://github.com/openwrt/openwrt/blob/master/package/kernel/ath10k-ct/Makefile#L18 Jan 29 18:49:42 https://github.com/openwrt/openwrt/commit/9c0c1c44013003616e2f5c55c062430dbda3cce5#diff-7ea752e6c9c7887ee5cb8262c7b1f27f Jan 29 18:49:49 ^ grearb__ Jan 29 18:50:07 thanks Jan 29 18:51:50 * Borromini checks openwrt-adm for the kernel votes Jan 29 18:53:10 Don't know what happens when we go for 5.4, though. Should still be 1 or 2 votes majority Jan 29 18:53:26 a tie still so far it seems https://cryptpad.fr/code/#/2/code/view/PvVBSUc8jbD8gQxcOmfrwudZCA+0eD7Xbp53FrG+5uk/embed/present/ Jan 29 18:53:50 adrianschmutzler: as in? probably a delayed 20.0x release to whip 5.4 targets into shape? Jan 29 18:53:58 yes, but two people voted for 4.19 where I do not know whether they will be counted Jan 29 18:54:21 oh Jan 29 18:54:28 * mamarley is hoping for 5.4. Judging from history, even if 4.19 is selected, the release will probably get delayed anyway. Jan 29 18:54:40 mamarley: lol. Jan 29 18:56:59 seems wireguard has been pulled into the 5.6 tree. zx2c4: congratulations Jan 29 22:59:44 build #78 of mvebu/cortexa53 is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/mvebu%2Fcortexa53/builds/78 Jan 30 02:48:08 build #230 of ramips/rt305x is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt305x/builds/230 blamelist: Adrian Schmutzler , Felix Fietkau , David Bauer , Jo-Philipp Wich **** ENDING LOGGING AT Thu Jan 30 02:59:57 2020