**** BEGIN LOGGING AT Mon Dec 07 02:59:57 2020 Dec 07 04:39:02 mangix: okay I'll check it out Dec 07 05:41:41 has anyone heard from KanjiMonster recently? looks like, other than join/quits in the channel, he fell off the edge of the planet back in March or so Dec 07 06:56:31 didn't know the planet had an edge Dec 07 11:14:05 adrianschmutzler: good morning Adrian, wanted to check with you in regards to PR 3380, in regards to eth0 vs eth1, WAN vs LAN, and what the standard practise is for OpenWRT policy ? Dec 07 11:38:53 Tusker: The standard policy is make it like the vendor does, if possible Dec 07 11:39:04 (and reasonable) Dec 07 11:39:30 but I haven't read your most recent comment yet Dec 07 11:40:03 let me check my notes for when I was running factory firmware Dec 07 11:40:21 The commit message at least states that the MAC addresses are from vendor firmware Dec 07 11:40:37 and with a switch it's typically not a problem to identify lan/wan Dec 07 11:40:47 the latter is typically only a problem for two-port devices Dec 07 11:41:41 but let me just go through my mails and maybe discuss that in half an hour Dec 07 11:41:50 OK, sure, will stand by Dec 07 11:47:38 factory firmware has LAN linked to eth1 showing up in the br0 bridge, so it at least matches the factory firmware. Dec 07 12:24:43 anyway, I need to get some sleep, will respond to any question/query/concern on github when you have some time Dec 07 12:25:08 maybe it's just fine now and I merge it :-) Dec 07 12:25:46 but I have to do this carefully, otherwise you can never be sure whether you have a +1/-1 in the right place Dec 07 12:27:21 let me know, I can test anything you want Dec 07 12:27:36 I have uart connected Dec 07 12:28:12 I will have a look shortly. but you may leave, I don't think another day delay will be a problem here Dec 07 12:28:52 btw, what was the conclusion out of the two related versions? Dec 07 12:29:02 f9j1108v2 and f9k1115v2 Dec 07 12:30:20 so, would it make sense to create a DTSI right away? Dec 07 12:30:44 F9J1108V2 seems to be a model that comes with an ADSL modem inside the power plug pack... the first one I bought had a normal power adapter, but this new one I bought has this weird ADSL plug pack. Dec 07 12:31:33 yes, they are pretty much the same hardware from what I can see, and reading the forums, it looks like the only difference is really the firmware magic Dec 07 12:32:04 I don't have a F9K1115V2 to test though, but having a combined DTSI makes sense to me Dec 07 12:33:10 So, I would just move everything to a dtsi and only keep compatible/name in the DTS? Dec 07 12:33:51 according to Alan Luck - https://forum.openwrt.org/t/belkin-f9j1108v2-factory-file-creation/42333/6 - only the factory image differs Dec 07 12:34:05 okay, then I might go along this road Dec 07 12:34:15 also matches ar71xx btw ... Dec 07 12:34:34 would it make sense to just create two factory images in the recipe ? Dec 07 12:34:39 and leave the DTS as is ? Dec 07 12:35:27 that's a regular, philosophical and controversial question Dec 07 12:36:07 I personally am in favor of having separate "devices" in OpenWrt for separate "devices" in the real world. Otherwise, you are getting into trouble if you have to split stuff later ... Dec 07 12:36:25 (e.g. because you have overlooked another difference beforehand) Dec 07 12:36:57 good point Dec 07 12:37:12 And I have made the experience that many problems of ar71xx arose from having that kind of boards, where different devices were treated as a single "board" Dec 07 12:37:19 it could be that the F9K1115V2 has additional LEDs too Dec 07 12:37:50 and that's exactly one of the things that are typically overlooked first and then create problems later: LEDs and buttons Dec 07 12:38:23 *nods* I'll leave it to you to handle it in the best way Dec 07 12:44:19 OK, bed time for me, danke Dec 07 12:45:49 final question Dec 07 12:46:02 why is the setting in 02_network separate again? Dec 07 12:46:12 looks the same as c5/c7? Dec 07 12:46:27 or was this just for testing? Dec 07 13:08:45 ynezz: does your sps30 also show the same values for pm2.5 and pm10? apparently I'm not the only one Dec 07 14:42:17 jow I wrote the netifd extension adding segment routing support (and the kernel config extension to add lwrunnel) .is there still something missing or should I change something? I adopted the naming scheme as u wrote to ip6segmentrouting Dec 07 15:06:49 nick[m]1: no it looks fine, but I didn't do any patch sweeps again since then Dec 07 15:36:58 https://libwebsockets.org/lws-api-doc-master/html/md_READMEs_README_8build.html#wolf interested in building libwebsockets with wolfssl as that's where openwrt is going with default ssl these days, that requires adding '--enable-opensslextra' for wolfssl, I can submit patches to enable them, is it ok to add that 'opensslextra' flag to wolfssl? Dec 07 15:46:46 you can try,but it's a train wreck last time I tried. Dec 07 15:46:58 I've been considering dropping wolf from lws actually Dec 07 15:47:14 lws is a trainwreck itself, but *shrugs* Dec 07 15:47:28 I've sent patches to lws a few times to try and keep wolf building, but it's.. special Dec 07 15:48:02 I take it the current wolf builds don't work? Dec 07 15:48:48 oh, nvm, there's mbedtls ones Dec 07 15:48:54 I must have removed wolf las ttime I stopped working Dec 07 15:49:05 so sure, if you can get it to work again, fine with me Dec 07 15:49:13 I added mbedtls as that's what openwrt was doing _then_ Dec 07 15:49:52 wolfssl Makefile actually has that flag on by default, the --enable-opensslextra Dec 07 15:50:20 you'll probably have to try on 4.1.x or something, which wasn'tworking on half our apps lsa ttime I tried, so its still on my list to try "latest again latest" lws and see what it's like today Dec 07 15:53:40 lws is still 3.1.0 in openwrt, yes I'm to try 4.1-stable now Dec 07 15:59:34 no, I reverted to 2.4 Dec 07 15:59:41 you shouldn't hve 3.1 anymore Dec 07 15:59:50 or did we go back rom 3.2 to 3.1 Dec 07 15:59:56 I can't keep track, lws is a garbge fire Dec 07 16:00:09 mosquitto has committed to replcaing it, and I'll drop maintaining lws as soon as that happens. Dec 07 16:14:52 i'm new to lws but it seems used in quite a lot places, garbage fire wise, is it lws' problem? i'm trying to use it to play with a UI idea, like what owsd does Dec 07 16:20:06 jow: I'm noticing some changes to luci's markup with the latest stable commit.. intentional? Dec 07 16:20:56 the ifacebox containers on the interface page are now borked with my bootstrap mods. Dec 07 16:21:00 (for example) Dec 07 16:21:27 haven't yet had chance to review other differences, but that one jumped off the page. Dec 07 16:25:11 jow: okay thanks! :) Dec 07 16:33:24 dorf: I don't follow Dec 07 16:33:27 it's used in places because there's not a lot of options. Dec 07 16:33:39 ask the developers of all those packages or the maintainers if hey're happy with it. Dec 07 16:33:40 don't recall changing any markup recently (apart fro mthe table/tr/td things) Dec 07 16:33:47 *any markup changes recently Dec 07 16:33:57 but yes, openwrt-19.07 and master are likely diverged Dec 07 16:34:22 I wish the WS protocol were easier to implement Dec 07 16:34:43 but I wouldn't dare to touch it with a ten foot pole Dec 07 16:36:26 yeah, mosq is considering it as these days, without having to support all the earlier draft versions, it's... potentialyl feasible Dec 07 16:36:40 there's a couple of options for client libs, but virtually nothing else for server side. Dec 07 16:39:17 I briefly took a look at the spec and the design is ... horrible Dec 07 16:43:37 well, whe you're starting poitn is "must go inside an existing http connect..." :) Dec 07 16:43:54 lets' add allll the string parsing and headers and garbage and so we can set up some binary magics Dec 07 16:44:46 libwebsockets-4.1.6/lib/tls/openssl/openssl-server.c:421:38: error: dereferencing pointer to incomplete type 'lws_tls_ctx' {aka 'struct WOLFSSL_CTX'} x = sk_X509_value(vhost->tls.ssl_ctx->extra_certs, 0); Dec 07 16:45:08 it actually failed to build, going to send this to lws mailing list before I study its code Dec 07 16:45:43 jow: I just pulled the latest stable updates via opkg, a whole bunch of luci related stuff.. interfaces were tidy before, now I get this: https://ibb.co/CB5Jw2k .. just wondering what changed.. looks like new markup. Dec 07 16:47:29 ctrl-shift-r? Dec 07 16:47:44 the divs -> tables will be a big change ? Dec 07 16:47:47 yeah, that's what got me there :) Dec 07 16:48:04 (ctrl+shift+r) Dec 07 16:48:14 press it a few more times ;) Dec 07 16:48:20 haha, funny. Dec 07 16:48:49 I've never opkg updated luci, did you rm -rf /tmp/luci* or anything? Dec 07 16:49:54 no, just a straight update and hard refresh in the browser. usually works. Dec 07 16:50:51 could be one of my local changes.. probably that. easy enough to remedy, no doubt. Dec 07 16:51:41 re divs -> tables, I think jow's retaining all the pseudo table classes for now, so the transition should be fairly painless. Dec 07 16:52:34 ah, fixed. a nasty little "position: relative" that shouldn't be there :) Dec 07 16:53:53 sorry for the distraction. Dec 07 17:14:27 karlp: essentially s/\.(table|tr|td)/\1/g Dec 07 17:14:48 karlp: I'll keep the CSS classes for a few more months though Dec 07 17:15:12 so instead of
the markup is currently Dec 07 17:15:20 later it will become just Dec 07 17:53:01 karlp: fyi now wolfssl builds with lws, will see how to check it does not break anything Dec 07 17:58:22 jow: hi. when you suggested to rename the interface, were you talking about the 'option ifname' line or about the 'config interface' line itself? Dec 07 17:58:31 since they're both wan... Dec 07 18:24:00 Borromini: config interface itself Dec 07 18:28:56 ok, thanks. right bet then ;) Dec 07 19:03:50 jow: I’ve got an interface alias section for an xfrm tunnel, to set an IPv4 on it and enable multicast… the address gets set but not multicast… where can I start digging to debug this? Dec 07 19:06:10 config is simple enough: http://paste.ubuntu.com/p/8YyfX6Q7HJ/ Dec 07 19:20:28 mangix: pin Dec 07 19:20:29 ping Dec 07 19:34:56 philipp64: good question, maybe "option multicast" is not propagated from alias devices Dec 07 19:35:11 philipp64: did you tzry setting it i nthe "config interface xfrm0" (not xfrm0_s) section? Dec 07 19:51:35 rsalvaterra: can you review this? https://github.com/openwrt/openwrt/pull/3631 dropbear stuff Dec 07 19:52:21 aparcar[m]: And who's reviewing the patches I sent months ago? :P Dec 07 19:52:55 rsalvaterra: me, just send me whatever you need reviewed Dec 07 19:53:06 This series: https://patchwork.ozlabs.org/project/openwrt/list/?series=214560 Dec 07 19:53:10 ideally simple and non controversial, I already burned my fingers this week Dec 07 19:53:30 Ah… can't promise you that. :P Dec 07 19:53:37 sigh, more option bloat Dec 07 19:53:46 jow: I'm open to sugestions. Dec 07 19:53:53 yeah, don't micro-optimize Dec 07 19:54:34 jow: potentially halving the size of dropbear isn't a micro-optimisation… Dec 07 19:54:53 I mean, people were trying to package TinySSH a while ago. Dec 07 19:55:07 halving how? by dropping RSA? Dec 07 19:55:10 Suggestion: how about a minimal variant? Dec 07 19:56:10 jow: Dropping RSA would be a user choice, at compilation time, not the default… Dec 07 19:56:32 and please don't extend this review-bargaining Dec 07 19:57:01 adrianschmutzler: Noted, didn't mean to put it that way, sorry. Dec 07 19:57:17 I started it, sorry I guess Dec 07 19:57:22 I am not opposed to optimizations per so, but the proliferation of compile time knobs quickly turns into an unmaintained mess over time Dec 07 19:57:36 gentroo? Dec 07 19:57:37 five to ten years down the road we'll probably find out that most of these options stopped working years ago Dec 07 19:57:41 because nobody actually changes them Dec 07 19:58:13 which actually happened already, frequently Dec 07 19:58:31 jow: The fstools options scare me, for example. :/ Dec 07 19:58:39 jow: tried both ways, no joy. Dec 07 19:58:45 jow so only better defaults then? Dec 07 19:58:52 philipp64: let me check the netifd source Dec 07 19:59:44 jow, adrianschmutzler, how about my proposal of adding a no-knobs dropbear-minimal variant, supporting only ChaCha20-Poly1305, like TinySSH? Dec 07 20:00:40 a few weeks later people want to add just one more feature to the tiny variant because some random iot device does not support the cipher Dec 07 20:00:56 see recent discussion about shuffling various hostapd features in mini/basic/full Dec 07 20:01:21 I have my part in the hostapd mess, yes… Dec 07 20:01:46 dropbear for me is a small server, for client I re-enabled ssh actually, for the fancy certificate authentication, which is great if you have a few devices to manage Dec 07 20:01:50 and later there's the desire to have a mini-rsa variant because it has to operate in a legacy env wheren othing does EC Dec 07 20:02:18 but since some crap backup solution uses scp to backup stuff, compression support would be desirable Dec 07 20:02:23 so it's mini-rsa-zlib then Dec 07 20:02:27 i hope dropbear can add certificate support as openssh client is still too large in size Dec 07 20:02:33 jow: Dear God, no. Dec 07 20:03:24 So, this is a bit of a dilemma… Dec 07 20:04:02 I don't mind carrying the patches in my tree, but I had lots of "fun" rebasing them as needed… Dec 07 20:06:20 just noticed uhttpd is 3MB in RSS size, lighttpd uses 4MB Dec 07 20:06:20 aparcar[m]: I haven't tested the patch series, but I like the simplification, yes. Dec 07 20:06:45 rsalvaterra: your patch series or the one on github? Dec 07 20:06:48 rsalvaterra: I cannot comment on these patches Dec 07 20:06:52 rr123: And BusyBox's HTTP server? :) Dec 07 20:06:55 rr123: with or without uhttpd-mod-lua ? Dec 07 20:07:19 aparcar[m]: The one from Konstantin, on GitHub, yes. Dec 07 20:07:20 jow: uhttpd-mod-lua is enabled Dec 07 20:07:33 rr123: that's a bit unfair then as half of luci will be preloaded Dec 07 20:07:41 and resident in memory Dec 07 20:07:42 I just wanted to prevent that one-review-for-another gets out of hand at some point Dec 07 20:07:53 i see, no wonder Dec 07 20:07:56 it's perfectly valid to ask for review btw Dec 07 20:08:11 adrianschmutzler: Fully agree, mea culpa. :) Dec 07 20:09:01 even your request was okay, I'm just afraid of what can result if you go down this road ... Dec 07 20:09:31 adrianschmutzler: To be honest, my first thought was "wait, if I'm reviewing the dropbear patches and no one else is, who's reviewing my patches?". :P Dec 07 20:10:03 and that's why nobody reviews any patches ;-) Dec 07 20:10:54 Eheheh! Dec 07 20:10:56 but the question is perfectly okay, unless you reach a point where you really start to "buy" reviews with other reviews Dec 07 20:10:56 I review patches :o Dec 07 20:12:11 aparcar[m]: And merge too! ;) Dec 07 20:12:19 anyway, didn't want to discuss this issue that extensively, actually Dec 07 20:12:40 adrianschmutzler: I'll not establish a #review4review culture Dec 07 20:13:12 Yeah, I guess we'll all pay more attention to those situations. Dec 07 20:13:16 On the contrary, it would be a big help if more non-committer would do (full) reviews Dec 07 20:13:25 You lot could have me doing reviews for patches. hahahahaahah I spell better than I code! Dec 07 20:13:59 Oh, a volunteer! Dec 07 20:14:05 and I code better than I read code! Dec 07 20:14:45 so, you can focus on commit messages (and probably will kill yourself after a week ...) ;-) Dec 07 20:15:06 I will just turn my screen reader up to the fastest speed and if it sounds good I will OK the patch! lol Dec 07 20:15:35 It make my screen reader beet box! Dec 07 20:16:42 adrianschmutzler: I could do reviews too, but sometimes I feel I'm not qualified enough… :P Dec 07 20:17:55 Case in point: https://github.com/openwrt/openwrt/pull/3631/commits/bf90a853034eaed86b7b40cee41c4a8f8cbd79fa Dec 07 20:18:17 I mean, I understand the idea of the dropbear_headers define, but it makes my eyes bleed. Dec 07 20:18:35 well, only review if you feel qualified, of course. Dec 07 20:19:14 rsalvaterra: just review the 5 other commits in that PR and I'll do the makefile magic (including consulting jow for all the special meanings) Dec 07 20:19:21 but there are frequently cases where I have the impression that people are available that could review easily and thereby reduce the time required by committers Dec 07 20:19:29 which would improve the overall throughput Dec 07 20:19:45 adrianschmutzler: can we give people label rights without commit rights? Dec 07 20:20:10 aparcar: i don't know, but I don't really think that would make such a big difference Dec 07 20:20:36 I just see that there are a lot of experts in the room that can provide value on specific subjects Dec 07 20:21:06 labels are a nice system which only seem useless when barely used. I usually just review whatever is tagged with build/tools/scripts Dec 07 20:21:07 while committers might not be competent on every area of the whole project Dec 07 20:21:37 these two groups could perfectly work together for some submissions Dec 07 20:22:34 I'm not aware how other committers use labels. I only need them for filtering _after_ a first look, and typically I only filter targets and releases Dec 07 20:23:45 ynez seems to actually use them for status tracking Dec 07 20:24:03 Well, this is probably an unpopular opinion, but… I really prefer email patches. It's so much easier to provide feedback on a reply. :) Dec 07 20:24:19 This new-fangled pull-request thing… Dec 07 20:27:36 jow: https://github.com/openwrt/openwrt/pull/3663 Dec 07 20:27:38 what's wrong with providing feedback on a git pull request? :) Dec 07 20:27:38 much more of an open process. Dec 07 20:27:50 anyway, I will go and create some food now ... Dec 07 20:28:00 with the 3D printer? ;) Dec 07 20:28:18 3d printed donuts ftw! Dec 07 20:28:31 with the lab called kitchen ... (I'm a chemist :-) ) Dec 07 20:28:52 dorf: A pull request requires me to open a web browser. Which in turn requires a graphical interface. ;) Dec 07 20:28:54 molecular gastronomy... Dec 07 20:29:06 rsalvaterra: ah, you're one of those :) Dec 07 20:29:13 I made enough last night so was mostly warming up and baking a fresh steak Dec 07 20:29:14 adrianschmutzler: lots of chemists and physicists ending up in coding somehow :) Dec 07 20:29:25 dorf: Not always, but most of the time, yes… :P Dec 07 20:29:31 one of the many advantages of being single :D Dec 07 20:30:06 stintel: https://github.com/aparcar/openwrt/commit/745b1756c86940a9f9a9235e86a8324579dda46b are you okay with the libcxx removal, you're the only one contributing there (except mangix ) Dec 07 20:30:32 And here I am, just sipping my tea. :P Dec 07 20:30:43 stintel: my roomates made brownies which is also a plus Dec 07 20:31:04 rsalvaterra: I never did like how links renders my css :| that's a deal break for me :) Dec 07 20:31:43 CSS is the work of the devil. I'd rather read 8051 assembly. Dec 07 20:32:05 aparcar[m]: re: removal, sure, how I understand it is that it's really only useful in combination with clang Dec 07 20:32:20 ok Dec 07 20:32:25 rsalvaterra: the most prolific processor ever, if I’m not mistaked. Dec 07 20:32:28 * mistaken Dec 07 20:32:40 miso stake! Dec 07 20:32:49 or even miso steak! Dec 07 20:33:04 philipp64_: Not the best to start learning, though… like I did at the university. :P Dec 07 20:33:33 stintel: hate to be the squeaky wheel… is there anyone you could delegate review of PR 14028 to? Dec 07 20:34:08 dorf: is that another non-meat travesty? Dec 07 20:34:20 good ol Dec 07 20:34:24 good ol' ribeye! Dec 07 20:34:28 philipp64_: I don't know if ARM already already surpassed it, though… Dec 07 20:34:29 philipp64_: quite the opposite. miso + steak :) Dec 07 20:34:40 mmm… ribeye Dec 07 20:34:47 philipp64_: well dunno, I really don't use the uci implementation and seems dedeckeh has no time Dec 07 20:34:56 or miso infused steak perhaps. miso definitely features, as does meat. Dec 07 20:35:25 if I manage to figure out why wireguard is being so horribly unusable on 1 of my devices ... I'll let you take over maintainership and be done with it Dec 07 20:35:40 rsalvaterra: doubtful… every PC (keyboard controller), smart refrigerator, washing machine, elevator, etc. has an 8051 in it. Dec 07 20:35:46 stintel: What's wrong with WireGuard? Dec 07 20:35:56 stintel: me? Dec 07 20:36:05 rsalvaterra: it stops responding completely if I make config changes and ifup the interface Dec 07 20:36:08 uh…. walked into that one. Dec 07 20:36:19 it goes down and I need to reboot the bloody router to make it come up again Dec 07 20:36:33 stintel: I just do /etc/init.d/network restart… Dec 07 20:36:43 DM me your config? Dec 07 20:37:08 the config is fine, the tunnel works fine on boot, but if I want to make config changes and ifup, it dies Dec 07 20:37:43 sounds like the closeaction is wrong. Dec 07 20:37:47 rsalvaterra: well yeah network restart is almost as intrusive as rebooting, especially on my HA network, it triggers failover to the other router etc Dec 07 20:37:50 on the peer, I mean. Dec 07 20:37:56 philipp64_: I'm talking about wireguard now Dec 07 20:38:03 ah. Dec 07 20:38:08 I know nothing about that. Dec 07 20:38:14 my strongswan configs are rock solid Dec 07 20:39:07 stintel: Wait, ifdown/ifup? Not ip link…? Dec 07 20:39:19 rsalvaterra: yes, the openwrt integration .. Dec 07 20:40:02 Ok… never messed with it directly… Dec 07 20:40:49 actually the 1 tunnel I configured is up atm, and stable for a couple of days already, but not being able to reconfigure without full network restart is not acceptable Dec 07 20:41:07 now where will I test this ... Dec 07 20:43:17 rr123: the tests are mosquito: mqtt over websockets, and ttyd Dec 07 20:43:34 they both exercise different parts of lws and sometimes one worksand the other doesn't Dec 07 20:43:51 then, if you're really keen, try actually using the ssl portions :) Dec 07 20:44:07 anyone here banging on OLSR? Dec 07 20:44:52 Speaking of interfaces (and not directly related to OpenWrt), I'm seen some really nasty stuff on my dad's laptop… If I reboot my router, the Wi-Fi card's firmware fatally crashes on disassoc. Dec 07 20:45:03 *I'm seeing Dec 07 20:45:17 sounds like Intel Dec 07 20:45:25 It *is* Intel. Dec 07 20:45:31 <3 Intel Dec 07 20:45:33 Obviously. :P Dec 07 20:45:34 shoot the card and get ath9k Dec 07 20:45:47 stintel: BIOS whitelist. Dec 07 20:45:59 shoot the laptop :( Dec 07 20:46:08 Lenovo sh*t. Dec 07 20:46:11 Never again. Dec 07 20:52:06 stintel: Yeah, rsync is needed to build Linux since v5.6, or so… :P Dec 07 20:56:25 * rsalvaterra can't believe his zram kernel patch is already at v7… Dec 07 20:57:10 I understand why Linus hates kconfig with such a passion… Dec 07 20:59:46 rsalvaterra: do you have a link to your zrm patch? Dec 07 21:00:10 It's for the upstream kernel, but here it is: https://marc.info/?l=linux-block&m=160734325312652&w=4 Dec 07 21:00:43 I want to be able to deselect lzo if not needed. Dec 07 21:14:25 rsalvaterra: so what’s the alternative to kconfig? Dec 07 21:15:19 philipp64: SAT solver. :P Dec 07 21:15:22 * rsalvaterra runs Dec 07 21:18:37 ynezz: mind rebasing https://patchwork.ozlabs.org/project/openwrt/patch/20191112200129.19396-1-ynezz@true.cz/ ? Dec 07 21:53:50 does patchwork has an mass export function? Dec 07 21:54:41 Anyone here a procd guru? I’m having an issue with an init.d script not being run properly at boot-up… Dec 07 21:56:03 philipp64: not a guru, but what does not properly mean ? Dec 07 21:57:53 I’ve enabled the service, but it doesn’t seem to do anything until I do a ‘start’ explicitly from the command-line. Dec 07 21:58:11 pastebin the script somewhere Dec 07 21:58:16 I’m not sure if it’s running too early, or not seeing an interface state transition change, or what. Dec 07 21:59:31 could be a $PATH issue, where 'login' gives you /usr/sbin or whatever already and procd doesn't have it Dec 07 21:59:46 echo $PATH > /tmp/sillyprocdpath.log Dec 07 21:59:51 here… it’s a mangled version of the isc-dhcp/files/dhcpd.init script that converts ‘host’ and ‘domain’ config records into A and PTR records for Bind… http://paste.ubuntu.com/p/bDbkhvh4hD/ Dec 07 22:00:56 I commended out USE_PROCD in this version but I can’t remember why… Dec 07 22:01:10 line 539 looks like a likely culprit Dec 07 22:01:46 the init script will run long before wan is brought up in many cases Dec 07 22:03:23 that implies I need 604-605? Dec 07 22:03:47 yes Dec 07 22:04:10 assuming the script we're looking at in this paste actually is /etc/init.d/fake-dns Dec 07 22:04:11 jow: could you please give this a final look? i've tested it as good as I understand it https://github.com/openwrt/openwrt/pull/2624/files Dec 07 22:04:49 I think I was hoping that named would detect its config file had changed and auto-reread it, but that requires “procd_set_param file $config_file” doesn’t it? Dec 07 22:05:17 philipp64: well the thing is that the init script bails out on boot before registering anything with procd Dec 07 22:05:34 it will try to resolve the search domains which fails if wan is not up Dec 07 22:05:39 and then it exits Dec 07 22:05:59 do I need “start_service()” instead of “start()”? Dec 07 22:06:07 that should help yes Dec 07 22:06:15 this way the trigger registration should still run Dec 07 22:06:29 btw, the WAN interface is an ethernet (G.PON) with a statically assigned IP address, so it should come up quickly... Dec 07 22:06:41 thne maybe the issue is somehwere lese Dec 07 22:07:50 i was trying to get ftldns(pihole dnsmasq) running with procd, ftldns forks dnsmasq internally and there are a dozen of them are running after reboot, never understand why that happened, but I can manually start ftldns and run it just fine, procd script made something happen for sure Dec 07 22:08:39 jow: does stderr from the PROCD-enabled scripts get logged to syslog? Dec 07 22:09:45 and how do I tell if a script implements ‘reload’ or not? Dec 07 22:10:01 I’d rather ‘reload’ named than restart it… seems gentler. Dec 07 22:11:02 I guess a missing reload_service() func is a good indicator... Dec 07 22:13:44 philipp64: when you set stderr 1 in your procd script stderr wil to to syslog Dec 07 22:13:49 *will go to Dec 07 22:14:01 see https://openwrt.org/docs/guide-developer/procd-init-scripts Dec 07 22:14:11 just… ‘stderr=1’ up at the top? Dec 07 22:15:11 procd_set_param stdout 1 # forward stdout of the command to logd Dec 07 22:15:19 procd_set_param stderr 1 # same for stderr Dec 07 22:15:46 okay… what if the script doesn’t have a persistent process associated with it? it’s just a helper of sorts… Dec 07 23:04:29 aparcar[m]: pong Dec 07 23:04:59 mangix: already merged Dec 07 23:06:30 pushed to packages-abandoned Dec 07 23:06:48 OpenWrt now joins Alpine in kicking libcxx to the curb Dec 07 23:12:39 there seem to be a number of packages that are noticing though Dec 07 23:13:25 ldir-: remove tmp directory and rerun make menuconfig Dec 07 23:15:59 yes, it's happier now Dec 07 23:16:27 yeah build system tends to be unhappy when removing packages in base :) Dec 07 23:17:50 ugh, adventofcode is too much for my brain Dec 07 23:21:08 stintel: what is that? Dec 07 23:21:16 https://adventofcode.com/2020 Dec 07 23:21:47 ah thanks Dec 07 23:30:17 I guess if you're an experienced developer it's easy peasy Dec 07 23:31:40 o_O Dec 07 23:39:34 aparcar[m]: please look into https://patchwork.ozlabs.org/project/openwrt/patch/20201109070922.23088-1-rosenp@gmail.com/ . It's needed for https://github.com/openwrt/packages/pull/13884 Dec 07 23:44:37 mangix: jow is the maintainer Dec 07 23:49:10 the problems look very artificial so that they directly fit computer concepts Dec 07 23:49:14 real problems aren't like this :p Dec 07 23:50:01 the fun part (also, hard part) is turning the real problem into something that a computer can solve Dec 07 23:59:31 zorun: https://patchwork.ozlabs.org/project/openwrt/patch/20200824130959.437942-1-baptiste@bitsofnetworks.org/ Dec 07 23:59:34 this looks important Dec 08 00:09:59 yes, but as noted in the follow-up email, I missed a use-case Dec 08 00:10:29 feel free to submit an improved version, I won't have time to work on this in the near future Dec 08 00:11:16 but I agree it's a "low-hanging" hardening change **** ENDING LOGGING AT Tue Dec 08 02:59:57 2020