**** BEGIN LOGGING AT Tue Dec 11 03:00:01 2018 Dec 11 03:22:33 build #24 of ath79/nand is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ath79%2Fnand/builds/24 Dec 11 03:34:50 build #1251 of x86/64 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/x86%2F64/builds/1251 Dec 11 03:35:27 build #1196 of ar7/ac49x is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/ar7%2Fac49x/builds/1196 Dec 11 05:59:45 morning Dec 11 06:00:50 i've a procd question Dec 11 06:01:15 why "procd_set_param file" has to be used in start_service() { ... } instead of service_triggers() ( ... } Dec 11 06:01:36 the later seems to be used for specifying reasons for service reload Dec 11 06:05:22 because file is a service wide property like command, stderr, stdout Dec 11 06:12:25 it seems something like "procd_add_file_trigger" in service_triggers() { ... } would fit procd design better Dec 11 06:12:29 to me at least Dec 11 06:12:35 not such if that was possible technically Dec 11 06:15:24 *not sure Dec 11 06:15:28 build #1013 of malta/be is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/malta%2Fbe/builds/1013 blamelist: Koen Vandeputte Dec 11 06:23:14 rmilecki: triggers are actually small json scripts being uploaded Dec 11 06:23:25 rmilecki: while file is registered as checksum source Dec 11 06:23:57 rmilecki: "proce_add_file_trigger" would somehow imply that the file is a trigger or describing a trigger Dec 11 06:24:04 imho Dec 11 06:24:35 it seems a bit inconsistent to me that some triggers are specified in start_service() and some in service_triggers(), that's it :) Dec 11 06:25:10 yeah, but for me "file" is a property, not a trigger Dec 11 06:25:18 like "command" Dec 11 06:25:35 you wouldn't want to move the command attribute to service_triggers() either Dec 11 06:26:15 while sematically it has the same effect as file; if it changes it invalidates the running state Dec 11 07:41:05 jow: well command shouldn't change unless one of the triggers changes Dec 11 07:41:16 so commands itself is not a trigger Dec 11 07:41:34 so command fits start_service() rather than service_triggers() nicely Dec 11 07:43:24 rmilecki: a file is not a trigger as well Dec 11 07:43:37 its a piece of opague data to procd Dec 11 07:43:44 if it changes, the state is invalidated Dec 11 07:44:07 from non-technical PoV sounds like a trigger ;) Dec 11 07:44:18 a trigger is a scriptlet evaluating an ubus event Dec 11 07:44:18 if its change results in state invalidate & reload... Dec 11 07:44:23 it sounds like a trigger :P Dec 11 07:44:42 ok, you probably just know how it works internally Dec 11 07:44:47 well, for sure you know ;) Dec 11 07:45:01 so it probably makes more sense from that PoV Dec 11 07:45:46 the other difference is that triggers register commands (/etc/init.d/$basename reload by default) Dec 11 07:45:58 while procd_set_param file is just an atribute in the service description blob Dec 11 07:46:23 ok, I'm not arguing :) Dec 11 07:46:34 ;) Dec 11 08:10:36 hi Dec 11 08:10:36 the inner workings of procd Dec 11 08:13:27 yeah, that's what I realized thanks for jow Dec 11 08:13:38 that probably matches nicely procd implementation Dec 11 08:14:07 maybe mathces less user logic ;) Dec 11 08:17:02 oh, wait... Dec 11 08:17:12 there are actually two ways of specifying UCI files Dec 11 08:17:23 procd_set_param file /etc/config/yourapp Dec 11 08:17:27 procd_add_reload_trigger "yourapp" Dec 11 08:17:43 use the latter Dec 11 08:17:51 oh crap, that deserves some better documentation Dec 11 08:18:19 /sbin/reload_config Dec 11 08:18:43 reload_config will generate md5sums for uci files Dec 11 08:18:45 so what's the gain/point from/of using procd_set_param file /etc/config/yourapp Dec 11 08:18:55 then send a notification to procd for all changed files Dec 11 08:19:16 procd will then kick the triggers from procd_add_reload_trigger Dec 11 08:19:26 procd_set_param is for generic file changes Dec 11 08:19:43 consider /etc/config not as a file but a config storage Dec 11 08:19:58 procd_set_param file/network/... is for other stuff Dec 11 08:20:07 so I guess procd_set_param file should never be used for /etc/config/* ? Dec 11 08:20:13 rmilecki: in short; procd_add_reload_trigger "yourapp" will only fire if the user calls /sbin/reload_config or makes uci changes through rpcd Dec 11 08:20:37 rmilecki: ubus call service list '{"verbose": true}' Dec 11 08:20:39 rmilecki: procd_set_param file will fire whenever the specified file changed Dec 11 08:20:47 that will dump the full internal state including all triggers Dec 11 08:20:56 rmilecki: or rather it will not fire, it will invalidate the stande on calling init reload Dec 11 08:21:22 rmilecki: https://pastebin.com/PPD0h6Bc Dec 11 08:21:33 this is the internal json_script trigger of uhttpd Dec 11 08:21:58 blogic: that service list method is nice Dec 11 08:21:59 thanks Dec 11 08:22:00 if you look into /bin/reload_config you will see it sends a config.change event Dec 11 08:22:05 that may help me Dec 11 08:22:16 also procd_add_reload_trigger "yourapp" only works for uci files Dec 11 08:22:17 and inside the uhttpd trigger you will see that config.change again Dec 11 08:22:37 param file works for any file, such as native configs, resource files etc. Dec 11 08:23:33 got it, I just thought it doesn't make sense to use param file for UCI configs then Dec 11 08:24:22 correct Dec 11 08:24:35 it usually does not make sense Dec 11 08:25:07 this is what https://openwrt.org/docs/guide-developer/procd-init-scripts document though Dec 11 08:25:11 *documents Dec 11 08:25:41 is it? Dec 11 08:26:18 ah, well the important bit is "or parses the uci file directly" Dec 11 08:26:23 you should add that to procd via 'procd_set_param file /var/etc/your_service.conf' or 'procd_set_param file /etc/config/yourapp' Dec 11 08:26:28 oh Dec 11 08:27:08 basically use procd_set_param file for native configs Dec 11 08:27:25 (configs read by the applicaiton itself, not configs transformed by the init script) Dec 11 08:27:54 and use procd_add_reload_trigger for uci files transformed by the init script Dec 11 08:45:15 this is f* up Dec 11 08:45:30 i don't understand a thing it appears Dec 11 08:47:16 ah, apparently calling "/etc/init.d/tail reload" *forces* reload_service() even if nothing has changed Dec 11 08:47:57 OK, that is actually documented: "If you want to explicitly reload, you still need to issue '/etc/init.d/ reload' manually." Dec 11 08:48:09 I'm still not sure what's the point Dec 11 08:48:18 nevermind Dec 11 08:56:37 rmilecki: reload_service() is always called, yes. It calculates the new desired runtime state of the service (cmdline, triggers, files etc.) and uploads it to netifd Dec 11 08:56:40 rmilecki: erm to procd Dec 11 08:57:10 rmilecki: procd then compares the running state with the just uploaded state. Only if they're different, procd will terminate the associated running process and spawn a new process Dec 11 08:57:19 rmilecki: if both states end up the same, procd will do nothing Dec 11 08:58:00 jow: is I call "reload_config", then reload_service() is called only if something has changed Dec 11 08:58:03 that makes sense Dec 11 08:58:19 and /etc/init.d/foo reload apparently doesn't care if something has changed or not Dec 11 08:58:23 yes Dec 11 08:58:25 OK Dec 11 08:58:33 weird but I can live with that ;) Dec 11 08:59:00 well Dec 11 08:59:13 "/etc/init.d/foo reload" cannot know if something has changed Dec 11 08:59:20 only procd knows Dec 11 08:59:33 i expected that to talk with procd Dec 11 09:00:15 reload_config only works the way you observe because it performs its own state tracking (it has a private md5sum colleciton of every config file) Dec 11 09:00:23 which is actually redundant to what procd does Dec 11 09:00:27 its a hck Dec 11 09:00:29 *hack Dec 11 09:00:43 oh? Dec 11 09:01:00 I thought the state is tracked in procd only and reload_config just uses procd Dec 11 09:01:06 nope Dec 11 09:01:13 ok Dec 11 09:01:14 nice to know Dec 11 09:01:17 its a hacky "config.change" event generator more or less Dec 11 09:02:11 the reason is that the uci cli itself has no concept of a transaction Dec 11 09:03:18 i'm not sure how many more details I want to know :/ Dec 11 09:03:28 ideally you would have something like "uci apply network" which implies "uci commit network + ubus call service event '{ "type": "config.change", "data": { "package": "network" } }' Dec 11 09:04:04 anyhow, the take away should be: Dec 11 09:04:18 - frequently reloading init scripts is fine Dec 11 09:04:25 - reloading init scripts should be side-effect free Dec 11 09:04:43 - only procd should decide whether a process is to be restarted or not Dec 11 09:05:15 any state tracking, checking and testing of state outside of procd is redundant, not authorative and merely an optimization Dec 11 09:05:56 procd init scripts do not launch or stop processes but calculated desired runtime states which are uploaded as json structure to procd Dec 11 09:06:03 *calculate Dec 11 09:06:35 OK, that is more than I wanted to know.. Dec 11 09:06:36 procd decides whether processes need to be spawned, stopped or signalled to reach the desired state according to the various properties set Dec 11 09:06:46 sorry, I thought it may help :) Dec 11 09:07:57 i just want to write a simple procd init.d script... Dec 11 09:08:30 procd makes it f* impossible Dec 11 09:08:38 you need to undesrtand all internals to make it work Dec 11 09:08:52 this is f* user unfriendly :/ Dec 11 09:08:56 ok, developer unfriendly Dec 11 09:11:22 rmilecki: what problems are you having specifically? Dec 11 09:11:50 my problem is I thought I can understand that on my own without just asking for a solution :P Dec 11 09:13:01 jow: can you help me making that work? https://pastebin.com/KLMxM4X3 Dec 11 09:13:27 when I change /etc/config/tail and call "reload_config" I can see reload_service() fires Dec 11 09:13:34 but start_service() does not fire Dec 11 09:13:44 so it does not provide procd updated command line (empty) Dec 11 09:14:06 and it means I can't stop tail doing: uci set tail.enabled=1; uci commit tail; reload_config Dec 11 09:14:29 i meant uci set tail.enabled=0; uci commit tail; reload_config Dec 11 09:16:08 rmilecki: I think you'll get your desired behaviour by dropping your `reload_service()` procedure Dec 11 09:16:26 i think I tried it and it didn't work Dec 11 09:16:28 let me try again Dec 11 09:16:30 the default behaviour of /etc/init.d/service reload is to simply call start() Dec 11 09:17:06 once you provide a reload_service(), only this is called and then completely responsible for doing anything Dec 11 09:17:33 after your `echo "[reload_service]" > /dev/kmsg` you might want to add a `start "$@"` Dec 11 09:18:18 jow: i just tried without reload_service() at all and it doesn't work Dec 11 09:19:15 you mean calling "/etc/init.d/tail reload" after chaing the uci file optoon didn't restart the process? Dec 11 09:19:24 let me describe Dec 11 09:21:17 oh it works Dec 11 09:22:05 I had to fix "uci set tail.enabled=0" and make it "uci set tail.setup.enabled=0" Dec 11 09:22:07 my bad Dec 11 09:22:09 sorry Dec 11 09:22:26 ok, I'm taking a 5 minutes break Dec 11 09:22:35 my brain is boiling Dec 11 09:28:45 jow: ok, that's slowly making sense Dec 11 09:28:51 jow: thanks a lot for your help Dec 11 09:29:23 yw Dec 11 09:29:40 time to grab the time to the office, last time today - yay. Dec 11 09:29:50 *grab the bike Dec 11 09:29:55 bbl Dec 11 09:30:55 jow: are you changing the job? Dec 11 09:31:16 yes Dec 11 09:31:21 more money, less work Dec 11 09:31:49 great! :) Dec 11 09:32:16 congratz :) Dec 11 09:33:13 jow: gratz! Dec 11 09:36:09 jow: so you're right, the solution is to add "start" when implementing a custom reload_service() Dec 11 09:42:56 anyone any idea why with CONFIG_KERNEL_GIT_CLONE_URI="https://github.com/raspberrypi/linux.git", some things that are enabled in .config are completely ignored? e.g. drivers/dma-buf/ seems totally skipped Dec 11 09:42:57 ERROR: module '/home/stijn/Development/LEDE/source/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/linux-github_com_raspberrypi_linux_git-faf0452f03b09c7063a2b14b23f61b3bd7eb264a/drivers/dma-buf/dma-shared-buffer.k Dec 11 09:42:57 o' is missing. Dec 11 09:43:17 CONFIG_DMA_SHARED_BUFFER=y .. Dec 11 09:44:12 so it shouldn't be modular, and iiuc it should be in drivers/dma-buf/modules.builtin Dec 11 09:44:15 which is empty Dec 11 09:44:27 stintel: did you verify CONFIG_DMA_SHARED_BUFFER is still =y after calling make? Dec 11 09:45:05 rmilecki: I grepped that from build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/linux-github_com_raspberrypi_linux_git-faf0452f03b09c7063a2b14b23f61b3bd7eb264a/.config after the error Dec 11 09:45:18 ok, seems correct then Dec 11 09:45:47 some symbols can change between "make kernel_menuconfig" and "make" due to OpenWrt applying config changes but it's not your case Dec 11 11:00:30 dedeckeh: ping Dec 11 11:06:02 rmilecki: last I was testing this, and writing docs, you needed _both_ set param file _and_ add_reload_trigger Dec 11 11:06:44 karlp: a proper doc is highly appreciated Dec 11 11:08:30 you're reading it. Dec 11 11:08:46 teh things that are/were hard to understand were when things didn't happen because changes weren't seen. Dec 11 11:09:01 and things like jow said, when you provide reload_service yourself, things get skipped, Dec 11 11:09:23 oh, my Dec 11 11:09:24 the "how to write an init script" contains as much as I've ever been able to work out based on experiments and asking here in the past. Dec 11 11:09:28 I did more tests just now Dec 11 11:09:32 I think I understand it now! Dec 11 11:10:00 it's _meant_ to be pretty straight forward, and I agree, having somethings in the "open instance" section and some in the service triggers is a little confusing, Dec 11 11:10:09 but if that's the only bit of boilerplate I have to "just do" I'm pretty happy. Dec 11 11:10:22 let me summarize what I've just learned Dec 11 11:10:28 and see if that sounds correct Dec 11 11:11:12 having a uci file in both param file and in service triggers makes _both_ "reload_config" _and_ "/etc/init.d/blah reload" work Dec 11 11:14:14 1) procd_set_param - allows specifing conditions for executing start_service() - after that procd will compare previous command & new command and restart if needed Dec 11 11:14:16 2) procd_add_reload_trigger - allows specifing conditions for executing reload_service() Dec 11 11:14:17 If no reload_service() is defines then start_service() is called Dec 11 11:14:36 yes Dec 11 11:14:49 hoory =) Dec 11 11:14:54 2) is actually more general, it just happens to default to /etc/init.d/$servicename reload Dec 11 11:15:08 ah, ok Dec 11 11:15:09 but can be anything, a killall, writing some file, executing some other command Dec 11 11:15:18 i was pretty close anyway :) Dec 11 11:15:26 true Dec 11 11:16:09 the simple steps are "only provide start_service() and service_triggers(), just run in the foreground, list uci file in both places, profit" Dec 11 11:17:10 I think we should add an "uci apply" Dec 11 11:17:23 which calls uci commit and then issues a change event for the package Dec 11 11:17:43 that would render reload_config mostly obsolete Dec 11 11:17:53 sounds good to me Dec 11 11:18:30 also I still don't understand why /etc/init.d/foo reload FORCES call to the reload_service() Dec 11 11:18:42 it still seems like it should go through procd Dec 11 11:19:04 but something needs to assemeble the state for procd to compare Dec 11 11:19:12 and procd should call that reload_service() only if needed (if some tirgger has fired) Dec 11 11:19:14 which usually happens in start() Dec 11 11:19:41 not doing so would mean replicating all procd state compare logic in the init script to decide whether a reload needs to be done or not Dec 11 11:20:19 i thought procd already keeps that state Dec 11 11:20:28 but I may still not be following it correctly Dec 11 11:20:39 it's very likely I still miss many details Dec 11 11:20:41 I usually think of "/etc/init.d/foo reload" like a "killall -HUP some_service" Dec 11 11:20:59 you throw the hup signal at the service and the service will figure out what needs to be done Dec 11 11:21:04 i expected "/etc/init.d/foo reload" to be like "config_reload foo" Dec 11 11:21:11 you don' Dec 11 11:21:23 t usually write shell script checks etc. to figure out if you should send a killall -HUP Dec 11 11:21:34 since you don't have knowledge of the services inner state Dec 11 11:21:46 and even if you had you usually don't want to replicate C logic in shell Dec 11 11:22:09 i expected procd to keep that state only & all the time Dec 11 11:22:10 the init script reload action sort of replicates this behaviour Dec 11 11:22:43 i probably don't fully understand a problem with but something needs to assemeble the state for procd to compare Dec 11 11:22:50 rmilecki: how would you expect reload to work? Dec 11 11:22:52 stintel: we have a local patch converting DMA_SHARED_BUFFER from bool to tristate; without it it isn't treated as a module and won't appear in modules.builtin Dec 11 11:23:34 jow: but I only just got used to reload_config doing the right thing..... Dec 11 11:23:47 reload_config also properly handles people editing files and then doing "reload_config" Dec 11 11:23:48 rmilecki: i would expect procd to know the current state of every service using procd - that should be stored after starting them for the first time Dec 11 11:23:53 jow: i would expect procd to know the current state of every service using procd - that should be stored after starting them for the first time Dec 11 11:24:04 and reload_config works for when you have your own files too, "uci apply" won't handle that. Dec 11 11:24:05 jow: then I'd expect procd to compare when needed Dec 11 11:24:28 rmilecki: specifically, how exectly should /etc/init.d/foo (/etc/rc.common) decide whether reload() should call service_reload() or not? Dec 11 11:24:54 the way it is right now is great for me thanks. Dec 11 11:24:55 rmilecki: keep in mind, often there's a lot of conversion going on, e.g. translating /etc/config/dhcp to /var/etc/dnsmasq Dec 11 11:24:56 KanjiMonster: ah Dec 11 11:25:05 KanjiMonster: thanks, that's helpful Dec 11 11:25:11 things are working cleanly and more predictably than in the past. Dec 11 11:25:12 jow: /etc/init.d/foo reload should result in "ubus call procd maybe_reload { "service: "foo" } Dec 11 11:25:21 rmilecki: procd does not know about the would-be /var/etc/dnsmasq after editing /etc/config/dhcp Dec 11 11:25:36 rmilecki: so the init script needs to perform the conversion at least, then query procd Dec 11 11:26:01 rmilecki: it is far simply to just redo what start() does Dec 11 11:26:03 jow: one sec Dec 11 11:26:06 thinking Dec 11 11:26:16 KanjiMonster: bah, I should have looked into the debloat patch Dec 11 11:28:36 jow: so I expected: Dec 11 11:28:38 1) /etc/init.d/foo reload to call ubus call procd maybe_reload { "service": "foo" } Dec 11 11:28:39 rmilecki: okay, but for maybe_reload you'd at least need to include all relevant bits - the new (maybe changed) cmdline, any service params and you need to regenerate all transient configs beforehand (e.g. /var/etc/dnsmasq.conf) Dec 11 11:28:39 2) procd to see if any of triggers specified using procd_add_reload_trigger / procd_add_interface_trigger / etc. has changed Dec 11 11:28:41 3) if any trigger has changed its state then procd should call reload_service() Dec 11 11:28:57 triggers cannot change state Dec 11 11:29:02 triggers are ubus events Dec 11 11:29:08 oh Dec 11 11:29:13 that explains a lot Dec 11 11:29:21 KanjiMonster: so we actually need this: https://gist.github.com/f8ed45936861b56a0dcc03ade7c06339 Dec 11 11:30:12 jow: so that's probably an importat bit i misunderstood Dec 11 11:31:27 rmilecki: one could probably summarize the init script reload handling as "throw everything against the wall (recalculate all service states) and see what sticks (let procd only handle those that are actually different)" Dec 11 11:31:34 jow: so if triggers are ubus events... how does it happen that: Dec 11 11:31:36 1) I have procd_add_reload_trigger "foo" Dec 11 11:31:37 2) I change /etc/config/foo Dec 11 11:31:39 3) Calling reload_config triggers reload_service() Dec 11 11:32:05 from /sbin/reload_config: ubus call service event "{ \"type\": \"config.change\", \"data\": { \"package\": \"$(basename $c)\" }}" Dec 11 11:32:53 but my reload_service() gets called only if /etc/config/foo has changed! Dec 11 11:33:14 yes, because reload_config tracks its own state as I tried to explain earlier Dec 11 11:33:21 so who (what software) keep an eye on the /etc/config/foo ? Dec 11 11:33:26 whenever you invoke it, it makes md5sums of all /etc/config/* Dec 11 11:33:28 aaaah Dec 11 11:33:30 ok Dec 11 11:33:39 when you invoke it again, iot fires events for all files with changed md5sums Dec 11 11:33:51 i understand Dec 11 11:34:03 so my original plan would also require moving that feature from reload_config to the procd Dec 11 11:34:14 so procd keeps a state of /etc/config/* Dec 11 11:34:48 you can achive that by using procd_set_param file /etc/config/foo Dec 11 11:35:36 that won't work well/fully with procd_send_signal Dec 11 11:35:36 not sure how much sense it makes to track all of /etc/config/ without knowing which file relates to which service Dec 11 11:36:06 we can know which file relates to which service thanks to the procd_add_reload_trigger Dec 11 11:36:42 okay assuming procd has this info, what then? Dec 11 11:36:50 how do you plan to react on the changes? Dec 11 11:37:07 you don't want to e.g. reload a service just a user did an intermediate save in vi Dec 11 11:37:26 no, calling /etc/init.d/foo reload will still be required Dec 11 11:37:39 i'll just behave a bit smarter, that's it Dec 11 11:38:20 but thats a lot of additional complexity for little gain I'd say Dec 11 11:38:43 i didn't look at the code, so can't comment on that Dec 11 11:38:44 I understand that you want to short-circuit start() or whatever happens to be triggered by reload() Dec 11 11:38:53 you know much more about implementation Dec 11 11:39:46 my point was to /etc/init.d/foo reload trigger a reload only if it's really needed Dec 11 11:39:57 stintel: as a local workaround that would do it, but that's nothing I would commit ;) (also IIRC this isn't the only one where we (re)enabled building as module) Dec 11 11:39:59 just like reload_config triggers reload only if it's really needed (something has changed) Dec 11 11:40:21 rmilecki: I think we might have a different understanding of reload here Dec 11 11:40:38 possibly Dec 11 11:40:41 rmilecki: you seem to want to avoid running the reload preparation shell code Dec 11 11:40:47 KanjiMonster: there's a similar commit for regmap Dec 11 11:40:49 right Dec 11 11:41:03 rmilecki: for me reload means either restarting the underlying unix process or delivering a reload signal to it Dec 11 11:41:18 all the shell fluff around is just preparatory work Dec 11 11:41:49 since reload_service() must be side-effect free (it should not alter system state or do ... things) Dec 11 11:42:08 the only possible saving would be a bit of cpu time Dec 11 11:42:26 yeah Dec 11 11:43:20 but I do understand the need for some kind of code section in init scripts that only runs if the reload preconditions as seen by procd are met Dec 11 11:44:12 right now after changing UCI I have a choice of: Dec 11 11:44:13 1) calling "reload_config" which handles all services - even if I know only a /etc/init.d/foo matters after my UCI changes Dec 11 11:44:15 2) calling /etc/init.d/foo reload which unconditionally calls reload_service() - even if nothing has changed in the UCI file used by /etc/init.d/foo Dec 11 11:44:21 both cases burn few CPU cycles Dec 11 11:44:36 I'm aware it's far from serious Dec 11 11:44:38 service_reload() isn't that, its not a has_service_been_reloaded() or a service_actually_needs_reloading() but more a prepare_maybe_reload_by_prcod() Dec 11 11:45:17 rmilecki: correct Dec 11 11:45:24 I was treating service_reload() as service_actually_needs_reloading() all the time Dec 11 11:45:36 i guess now we're finally on the same page ;) Dec 11 11:46:14 (I think being concerned abotu the cpu cycles from "reload_config" checking other thigns as being misguided) Dec 11 11:46:27 maybe you have other services that actually happened to list a dependency on your file, Dec 11 11:46:31 they'll "do the right thing" Dec 11 11:46:47 true Dec 11 11:46:51 a service_actually_needs_reloading() would be helpful though Dec 11 11:47:09 like I said, having both the config param file _and_ the service trigger means that both individual "etc/init.d/blah reload" and "reload_config" both work. Dec 11 11:47:13 you can use what you prefer. Dec 11 11:48:09 (now is when we bring up that even calling restart won't restart if the commandlines/files haven't changed....) ;) Dec 11 11:48:48 unless a stop() has been implemented Dec 11 11:49:01 nvm Dec 11 11:49:16 OK, I'm really happy we finally understood each other ;) let me get to the work & fix my procd init script now :D Dec 11 11:49:41 rmilecki: there already is a procd_set_param reload_signal FOO, could probably add an procd_set_param reload_command FOO as well Dec 11 11:49:55 which would call "FOO" when the service is about to get reloaded due to state changes Dec 11 11:50:17 oh, that's sth new / undocumented Dec 11 11:50:20 that reload_signal Dec 11 11:50:33 i'll check sources later Dec 11 11:51:13 iirc when reload_signal is set, the running process isn't replaced but simply sent a signal using kill() Dec 11 11:51:33 hrm, I thought I'd added reload_signal already to the wiki, Dec 11 11:51:44 karlp: i'm looking at the https://openwrt.org/docs/guide-developer/procd-init-scripts Dec 11 11:51:44 rmilecki: maybe you can add reload_signal docs Dec 11 11:51:58 it's a wiki afterall. Dec 11 11:52:53 ah, no, there's a bit on the procd_send_signal, but not the reload_signal extra bits Dec 11 11:53:26 I'll add a table of the various service params Dec 11 11:55:42 iirc, ubus servce list, even in verbose, doesn't include all params. (yet) Dec 11 11:56:25 though checking now, it seems to have more than last time I looked, so maybe it's allthere now, under the "data" key Dec 11 11:59:47 jow:pong Dec 11 12:03:45 dedeckeh: I was getting a LuCI pr for an uci option "master" in /etc/config/dhcp Dec 11 12:04:07 dedeckeh: the original description was rather vague so I wonder if you know about this option and its effects Dec 11 12:05:38 jow: master is used in ndp proxy mode and dhcpv6 relay mode Dec 11 12:06:48 it marks an interface as upstream Dec 11 12:07:30 meaning when a RS is received it needs to be forwarded on this interface Dec 11 12:08:20 similar for DHCPv6 messages coming from clients Dec 11 12:09:38 in case a RA is received on an interface in proxy mode it's not forwarded on the master interface Dec 11 12:26:08 dedeckeh: ah ok, so its for selecting the upstream interface in relay mode Dec 11 12:26:24 thanks! Dec 11 12:27:28 jow:yw Dec 11 12:53:31 stintel: I wasn't aware we had that ugly construct already somewhere else. in that case it's probably okay ;) Dec 11 13:17:45 now I have another problem with CONFIG_SND_HWDEP not being in .config, but it is in .config.{old,override,prev,set,target} Dec 11 13:17:57 and due to that: Dec 11 13:17:58 ERROR: module '/home/stijn/Development/LEDE/source/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/linux-github_com_raspberrypi_linux_git-faf0452f03b09c7063a2b14b23f61b3bd7eb264a/sound/core/snd-hwdep.ko' is missing. Dec 11 13:18:56 we carry a patch but it's not changing from bool to tristate, it's just adding a string (description/info?) Dec 11 13:24:40 rmilecki: karlp: https://openwrt.org/docs/guide-developer/procd-init-scripts#service_parameters Dec 11 13:30:02 nice extension of the few examples at the top, thanks Dec 11 13:36:48 stintel: adding a string makes it user selectable, without it it follows the state of its default and any other symbols select'ing it, regardless what the config says Dec 11 13:40:31 learning some stuff today \o/ Dec 11 14:01:24 jow: nice, thank you! Dec 11 14:03:01 KanjiMonster: and do you have an explanation why CONFIG_SND_HWDEP would not be in the .config even though it's enabled in kmod-sound-core and CONFIG_PACKAGE_kmod-sound-core=y ? Dec 11 14:04:28 stintel: as I said, if it is a tristate or bool without any string behind it, it defaults to n, unless some other symbol from the config selects it - it doesn't matter what the .config says what its value is supposed to be Dec 11 14:05:40 KanjiMonster: but we patch it to have a string behind it Dec 11 14:05:47 ah Dec 11 14:05:48 lol Dec 11 14:06:01 we patch it, default kernel doesn't Dec 11 14:06:08 s/default/external/ Dec 11 14:06:15 * stintel goes to make some coffee Dec 11 14:06:22 KanjiMonster: thanks! Dec 11 14:07:41 stintel: yw ;) Dec 11 14:11:53 KanjiMonster: are you subscribed to linux-wireless ? Dec 11 14:12:04 stintel: yes Dec 11 14:12:59 ah, but you were in CC as well. I'm wondering if that brcmfmac patch got stuck in some spam filter Dec 11 14:13:04 as I got no response yet Dec 11 14:15:43 build #1014 of malta/be is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/malta%2Fbe/builds/1014 Dec 11 14:16:21 stintel: https://patchwork.kernel.org/patch/10712383/ Dec 11 14:16:28 State New Dec 11 14:16:31 just wait Dec 11 14:16:55 alright Dec 11 14:17:16 most important thing for me is that we're carrying that patch now Dec 11 14:30:35 can confirm, was awesome to have brcmfmac "just work" when I included the firmware blobbies Dec 11 14:31:26 lots of warnings about not finding perfectlymatched fw blob names and clb or clm or somesuch, but still worked. Dec 11 14:33:49 KanjiMonster: thanks again, was able to build an image now with kernel from https://github.com/raspberrypi/linux.git Dec 11 14:34:11 let's see if this has the same wifi breakage when running without HDMI plugged in Dec 11 14:34:51 well it's not wifi breakage, it's vmalloc/memory breakage causing brcmfmac not to load Dec 11 14:35:48 I'm amazed that after all this years of rPi hype it is still such a pain to run mainline linux on it Dec 11 14:36:06 and people were frowning upon openwrt for not upstreaming target support... Dec 11 14:39:54 jow: yeah, once I get brcm2708 ready for 19.01 I'll start working on a new bcm283x target using upstream kernel and u-boot, and would propose to phase out brcm2708 then Dec 11 14:43:06 but it's quite the mess right now Dec 11 14:48:46 alright, it seems to show the same problem with the external sources. so it must be config related Dec 11 15:01:35 jow: regarding the issue yesterday, i tried running "make toolchain/gcc/final/refresh" but it also fails. (the target folder in builds/toolchain... is also empty) Dec 11 17:22:24 so here's the dmesg of the rpi0w running 4.14.87, without HDMI attached: https://gist.github.com/stintel/9c76246ae41196fcb445bb2277ab348e#file-mnttemprootdmesg-L474 Dec 11 17:22:55 vmalloc: allocation failure ... this stuff is so over my head :( Dec 11 17:33:37 i've a question regarding https://openwrt.org/docs/guide-developer/procd-init-scripts#procd_triggers_on_config_filenetwork_interface_changes Dec 11 17:33:38 "The signal is SIGHUP by default, and must be specified by NAME. (You can get available signals from kill -l on the console)" Dec 11 17:33:42 it does not seem to work for me Dec 11 17:34:04 using procd_send_signal results in the ubus call service signal { "name": "foo", "signal": 0 } Dec 11 17:35:39 it seems that _procd_send_signal() uses *int* see: json_add_int signal "$signal" Dec 11 17:35:41 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/system/procd/files/procd.sh;h=6f16b746ffb42c3c7eeba9fed628676a8eb3e761;hb=HEAD#l423 Dec 11 17:36:07 and it seems procd service expects an *int* see https://git.openwrt.org/?p=project/procd.git;a=blob;f=service/service.c;h=755147c45b59a39a6e8327864e086c123f421ea8;hb=HEAD#l223 Dec 11 17:36:26 can I assume documentation is wrong there? should I use int value? Dec 11 17:36:32 jow? karlp? Dec 11 17:37:11 rmilecki: /lib/functions/procd.sh filters the given signal name string through $(kill -l "$1") and sends the resulting int to procd Dec 11 17:37:26 oh I had to miss that Dec 11 17:37:37 this is done since the signal numbers are not portable Dec 11 17:37:40 ofc I missed that Dec 11 17:38:02 sorry... too much time spent on that already Dec 11 17:40:02 jow: i was testing on LEDE 17.01, that's why... https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=37bb463daa21e2c97365c6543b2bfdfe673c5baa Dec 11 17:40:49 jow: can I cherry-pick that to the 17.01? Dec 11 17:41:45 wat, just move to 18.06 like a good person. Dec 11 17:41:52 rmilecki: yes, please Dec 11 17:41:53 or carry 17.x patches in your own brancehs Dec 11 17:42:33 karlp: I never know when you're ironic and when not Dec 11 17:42:58 the policy for backporting is just so random. Dec 11 17:43:53 well, I tend to backport shell script fixes like the one quoted above, and fixes to the C userspace stuff I maintain Dec 11 17:43:58 17.01 is nearly two years old, signal names are clearly not something that has been missing from any of the init scripts there. Dec 11 17:44:27 karlp: it's a bug that breaks compatibility of custom init.d scripts with old release Dec 11 17:44:29 the problem is that a documented api is broken and behaving differently Dec 11 17:44:45 compared to 18.06 and master (and to its orginial intention) Dec 11 17:44:59 it's broken, but fixed in the current stable release? Dec 11 17:45:13 karlp: it's not my home router I can just switch to the master branch, but a market product that needs to be based on stable release and takes months to switch between releases Dec 11 17:45:25 I mean, sure, this is easy, no sideaffects, sure, but why _this_ one, but not "any random other patch" Dec 11 17:45:38 rmilecki: I know full well why you want it, it also means you ahve a branch for it for your work anyway, so you could carry it there too Dec 11 17:45:41 karlp: i don't see problem with cherry picking any other bug fixes Dec 11 17:45:42 karlp: because we're focus on this one right now Dec 11 17:45:56 rmilecki: the poitn is, where is the line drawn on a bug fix? Dec 11 17:45:56 karlp: i could but I love open source & sharing my work Dec 11 17:46:35 karlp: by common sense. As long as the branch is open I see no reason to not merge fixes like that Dec 11 17:46:56 especially ones that can be cleanly cherry picked, are side-effect free and have no dependencies on updates or major redesigns Dec 11 17:47:06 * rmilecki taking a break Dec 11 17:47:11 going to eat a supper Dec 11 17:47:27 sure, I get that, I understand why it's easy and appealing, it's just still so arbitrary what "open" means. Dec 11 17:47:48 it means nobody declared it done yet Dec 11 17:48:04 it has been communicated that it will remain "open" until 19.x is out Dec 11 17:48:17 since there is not even a branch for 19.x yet, its still open Dec 11 17:48:22 open for what? everything? Dec 11 17:48:33 fuck Dec 11 17:48:36 for fixes Dec 11 17:48:49 the rough agreement so far has been: Dec 11 17:48:52 bugfixes Dec 11 17:48:53 i'm really going away now, need some rest Dec 11 17:49:05 updates to fix bugs or cves Dec 11 17:49:10 no board support backports Dec 11 17:49:17 no updates without a reason Dec 11 17:49:47 so yes, everything that fits these criteria Dec 11 17:50:10 I usually backport buildroot fixes and the like Dec 11 17:50:32 and stuff people ask for [if it fits the rough criteria above] Dec 11 17:51:29 of course there's still some leeway to decide on a case-by-case basis, this is then usually influenced by whatever developer doing it and the area of work Dec 11 17:53:47 I tend to focus on buildroot/ib/sdk fixes and stuff like rpcd or uhttpd Dec 11 17:54:06 plus the random userland bits scattered in mac80211, netifd, base-files etc. Dec 11 17:55:06 I'll usually not touch the kernel at all, and backporting board support is usually a no-go, though there's been cases where a newer revision of an existing model has been added in case it was just a one-line change or a image build recipe without no furzher needed changes Dec 11 17:56:47 if there's things you think that should go into 17.x then I suggest to write either an rfc or a simple mail with hashes Dec 11 17:57:11 from time to time I write such mails to the list, asking if people want things cherry-picked since I have no complete overview myself Dec 11 18:18:19 Hi. I would like to put a password to /etc/shadow directly. I don't know what hash should be applied to the plaintext password Dec 11 18:19:00 alright, seems like I found the culprit. when vc4 is loaded and no HDMI device is connected, vmalloc errors occur Dec 11 18:23:31 guifipedro[m]: crypt("plaintext", "$1$") (a.k.a. md5) Dec 11 18:23:52 guifipedro[m]: you can use for example `mkpasswd -5 plaintext` to produce a hash suitable for shadow Dec 11 18:25:29 Thanks jow for answering. `crypt` not found. the thing with `mkpasswd` is that every take I do the output is different. How then the program knows is that password. Dec 11 18:27:03 so here is the response to the different password thing (https://unix.stackexchange.com/questions/187333/why-mkpasswd-m-sha-512-produce-different-result-every-time-it-is-called), use a different salt everytime, how knows "openwrt/software" which salt to authorize the true password Dec 11 18:29:03 the used salt is part of the password hash Dec 11 18:29:46 the number between the first and second dollar sign is the algorithm (1 for md5), the string between the second and third dollar sign is the salt Dec 11 18:29:54 the string after the third dollar sign is the hash Dec 11 18:30:32 crypt("plaintext", "$1$salt$hash") == "$1$salt$hash" Dec 11 18:30:58 assuming that "plaintext" is the correct password Dec 11 18:31:13 otherwise the "hash" part will be different and the authentication fails Dec 11 18:31:54 jow@wws-7:~$ mkpasswd -5 test Dec 11 18:31:55 $1$z4UwtjTf$Atn9qITNyBRKKv2k8zsLn/ Dec 11 18:32:12 means salt "z4UwtjTf" was used to initialize the md5 coder Dec 11 18:32:41 this entire hash is fed back as salt to crypt() when hashin the entered plaintext password Dec 11 18:33:16 crypt will extract the algorithm and salt from the hash (1 and "z4UwtjTf") and discard the hash part ("Atn9qITNyBRKKv2k8zsLn/") Dec 11 18:33:42 then perform the algorithm (1=md5) and salt it with "z4UwtjTf" Dec 11 18:34:00 if the plaintext is correct, the resulting hash will be exactly "Atn9qITNyBRKKv2k8zsLn/" again Dec 11 18:34:22 this is then concatenated with the input algorithm and salt, resulting in "$1$z4UwtjTf$Atn9qITNyBRKKv2k8zsLn/" Dec 11 18:34:33 which is then compared to the original hash from shadow using strcmp() Dec 11 18:35:23 great! thanks for your great explanation Dec 11 18:36:33 why openwrt uses md5 instead of sha1 sha256 sha512 ? Dec 11 18:36:39 to save space Dec 11 18:36:54 protecting against local password crackers was not a security consideration for openwrt Dec 11 18:37:45 the stronger hash algorithms have actually been disabled in musl: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=toolchain/musl/patches/901-crypt_size_hack.patch;h=8cd7b1989ca6e9f7b890f9a81fbfe33227d1dd12;hb=26d4cb2ca7acde1254f6ce6c0a54e0aca1489a0f Dec 11 18:39:02 I guess we could make that a config option and only patch them out on tiny stuff in the future ? Dec 11 18:39:06 now I know why! thanks Dec 11 18:44:21 stintel: if we officially require 8M+ in 19.x then this would be fine with me Dec 11 18:44:41 stintel: the space savings are significant, the original commit claims ~17KB after LZMA Dec 11 18:44:47 jow: yeah, whenever we get to that point (>=8M?) Dec 11 18:45:27 I think when we decide to do so Dec 11 18:45:37 it will be an unpolular decision either way Dec 11 18:45:41 it will Dec 11 18:46:08 but to be fair, I haven't used any <8M flash devices for 9 years now ... Dec 11 18:46:50 well I come from a freifunk background and for us this way pretty much the norm Dec 11 18:47:01 I see Dec 11 18:47:01 cheap & plenty vs. few & good Dec 11 18:47:31 there's a few "huge" things we can still do Dec 11 18:47:56 get rid of pppoe by default, get rid of opkg by default (maybe offer it as some kind of sfx install archive for extroot users) Dec 11 18:48:06 get rid of luci by default Dec 11 18:48:22 or find a magic way to reduce kernel size :) Dec 11 18:48:26 all of these things will cause confusion Dec 11 18:48:45 but they might be intermediate solutions before we retire device support completely Dec 11 18:50:15 the idea to drop opkg is tempting (along with the entire meta data) Dec 11 18:51:00 then offer a script to bootstrap an opkg install if needed (fetch & unpack the opkg.ipk using tar, prepare config) Dec 11 18:51:18 something else. do you know what the boot flag in Auto{Load,Probe} does ? Dec 11 18:51:30 ah Dec 11 18:51:38 it decided wether the module ends up in /etc/modules-boot.d/ or /etc/modules.d7 Dec 11 18:51:41 put it in /etc/modules-boot.d/ Dec 11 18:51:42 *decides Dec 11 18:51:54 yeah, I figured it right after asking the question Dec 11 18:52:15 for the problem with vc4 causing vmalloc failures if no HDMI attached, that won't help me Dec 11 18:52:56 maybe I should change it to use priority zz so it will be loaded at the very latest, until this problem is properly fixed Dec 11 18:54:26 I suspect most people won't be using vc4 at all, nothing depends on it, but it wouldn't be nice to break someone's wifi in case he/she installed vc4 on a headless system Dec 11 18:59:01 build #729 of layerscape/armv8_32b is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_32b/builds/729 Dec 11 19:16:29 jow: I'm trying to search in linux kernel source the `crypt()` part, or the patch part without success Dec 11 19:17:37 * ldir checks scrollback and is pleased to see one of his patches causing such controversy :-) Dec 11 19:17:54 aaaa, is a glibc thing, outside the kernel, right? Dec 11 19:19:24 oh ffs, now the problem persists even with vc4 not loaded Dec 11 19:19:32 this damn target :( Dec 11 19:19:57 ldir: :P Dec 11 19:20:25 "before we retire device support completely" what implications has this. Where can I read more about that. This looks like openwrt is going to change a lot. At least for community networks? Dec 11 19:21:27 stintel: it was hilarious...I'm thinking "what are they arguing about?", followed the link and went 'oh!' :-) Dec 11 19:22:12 :D Dec 11 19:22:17 guifipedro[m]: on the mailing list i guess Dec 11 19:26:49 so now it appears to be videodev or v4l2-common Dec 11 19:26:50 wth Dec 11 19:27:13 OK. You are talking about 4/32 devices. What about 8/32 devices like https://openwrt.org/toh/alfa.network/n5. We have a bunch of them deployed Dec 11 19:27:46 ( http://lists.infradead.org/pipermail/openwrt-adm/2018-December/000938.html ) Dec 11 19:29:13 ah. so I unload videodev, and I can load vc4, but then I cannot load videodev anymore Dec 11 19:31:10 VmallocUsed: and VmallocChunk: being 0 doesn't help debugging Dec 11 19:31:55 stintel: did you fix your vmap problem? Dec 11 19:32:10 Hauke: no Dec 11 19:32:36 Hauke: so it's not a specific module that causes the problem, it's probably just that if X amount of memory is used, it's over loading modules Dec 11 19:32:46 gonna disable CONFIG_PROC_STRIPPED Dec 11 19:32:58 so that I can at least see VmallocUsed: and VmallocChunk: Dec 11 19:33:16 stintel: have you tried to add a boot param vmalloc= Dec 11 19:33:19 ? Dec 11 19:33:48 Hauke: no, but both with and without HDMI attached, dmesg shows: [ 0.000000] vmalloc : 0xdc800000 - 0xff800000 ( 560 MB) Dec 11 19:33:55 should be enough, no? Dec 11 19:34:03 I mean, the device doesn't even have 560MB :P Dec 11 19:36:43 hmm strange problem Dec 11 19:36:52 I will have something to eat fisrt ;-) Dec 11 19:37:00 Hauke: enjoy Dec 11 19:37:06 and yes, strange problem indeed Dec 11 19:38:01 if I hadn't enabled vc4 due to kodi and v4l due to the camera for the rpi0 I recently bought, maybe I would have never ever encountered the problem Dec 11 19:39:34 s/ ever/ even/ Dec 11 19:41:00 lol, I'm still building with CONFIG_KERNEL_GIT_CLONE_URI="https://github.com/raspberrypi/linux.git" so CONFIG_PROC_STRIPPED isn't gonna do much Dec 11 19:54:32 guifipedro[m]: the background is https://openwrt.org/supported_devices/432_warning - and 8/32 MB devices are even worse from that point of view (as a larger blob for firmware upgrades needs to fit into the RAM as well). 32 MB RAM is a serious limitation these days. Dec 11 19:55:33 a 4 MB flash device 'naturally' limits the amount of services to run - indirectly resulting in less RAM usage Dec 11 19:55:38 8/32's not going to last much longer than 4/32 Dec 11 19:56:24 yep, mostly because of the RAM size Dec 11 19:56:45 They'll last a little longer for those cases where all you need is 200K Dec 11 19:59:51 640kB is all we just need Dec 11 20:00:26 so apparently VmallocUsed and VmallocChunk is 0 kB on all my devices I've checked so far Dec 11 20:00:29 what's that about :/ Dec 11 20:01:44 https://github.com/torvalds/linux/commit/a5ad88ce8c7fae7ddc72ee49a11a75aa837788e0 Dec 11 20:01:47 I see Dec 11 20:02:19 I need /proc/vmallocinfo Dec 11 20:03:14 nbd: ping! Dec 11 20:39:21 lach1012: pong Dec 11 20:41:39 great. I noticed that the ipq40xx builts are failing due to uboot-fb4040. I do have a patch ready that updates the whole package to my latest version and it should fix the issue for good. Thing is, I would like to test it before and I don't know what userspace the builders are running on. Dec 11 20:42:08 nbd: so, how did you do the tests back in the day? Dec 11 20:43:31 i don't think i've ever tested uboot-fb4040 myself Dec 11 20:45:15 hm, so just push and hope for the best? https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=6e527cfb4c8f21289e6cd48e8ca994c2d56172d5 Dec 11 20:45:41 or find somebody that uses the hw Dec 11 20:45:57 maybe blogic Dec 11 20:46:07 Oh, I have the device Dec 11 20:46:26 I know it works, I just don't know if it will compile on the builders Dec 11 20:47:50 ah Dec 11 20:48:28 yeah, i guess just push it and hope for the best Dec 11 20:48:34 especially if builders are failing already Dec 11 21:06:00 I just uploaded new ct FW to my page, and posted email with pertinent info in case someone has time to update the ath10k-ct openwrt firmware package Makefile Dec 11 21:07:28 jow: thanks for your nicely worded explanations. I'm sorry I got rubbed the wrong way. Dec 11 21:09:12 greearb__: changelog? :) Dec 11 21:10:55 currently in a call with a customer, otherwise I'd have a go at it Dec 11 21:11:12 timezones suck Dec 11 21:12:35 openwrt has been running beta CT fw for a while, but here are release notes for the last release, which I just officially called done and uploaded. Dec 11 21:12:52 https://www.candelatech.com/downloads/ath10k-fw-beta/release_notes.txt Dec 11 21:12:59 wave-1 hasn't changed a whole lot Dec 11 21:14:11 wave-2 beta is now all my stuff rebased on top of newer (and thus bisectable) QCA firmware. Dec 11 21:14:14 https://www.candelatech.com/downloads/ath10k-10-4b/ath10k-fw-beta/release_notes_5.txt Dec 11 21:14:36 those builds have been solving problems for folks in the ath10k-ct bug tracker, so I think it is ready for wider use. Dec 11 21:15:08 and we are planning to switch to that new rebased FW internally in our wifi test gear, so it will get a lot more testing shortly. Dec 11 21:15:17 I will load it on my UAP-AC-PRO and test later today. :) Dec 11 21:15:38 that said, I have only really tested 9984 wave-2 'b' firmware Dec 11 21:15:51 Speaking of said device, the blue LED ring seems to be dying. It just gets dimmer and dimmer. stintel, is that happening to yours? Dec 11 21:16:10 mamarley: no, it's blinking like mad Dec 11 21:16:13 terribly annoying Dec 11 21:16:38 stintel: You can actually fix that! Just a sec… Dec 11 21:17:30 yeah I once did it manually by changing the trigger iirc, but there is no LED config for this device at all Dec 11 21:17:45 "config 'led' option 'name' 'dome_blue' option 'sysfs' 'ubnt:blue:dome' option 'trigger' 'none'" in /etc/config/system turns it on steady. Dec 11 21:17:56 Yes, "none", the brightness scale is backward. Dec 11 21:18:22 can i do that with the white one ? Dec 11 21:18:30 "ubnt:white:dome" Dec 11 21:18:43 Otherwise the same, the brightness is still backward. Dec 11 21:19:18 thanks Dec 11 21:19:22 No problem Dec 11 21:20:46 That was one of the first things I did when I set mine up because that flashing LED was annoying, especially when it was still really bright when it was new. Now it is dimmer apparently because it is just a crap-quality LED. Dec 11 21:21:10 Now I know why it looks like all the UAPs at the place where my grandmother lives are off all the time… Dec 11 21:42:33 greearb__: It seems to work, but it spams "[ 196.410057] ath10k_pci 0000:00:00.0: wmi command 0 is not supported by firmware [ 196.417683] ath10k_pci 0000:00:00.0: failed to send pdev bss chan info request: -122" to dmesg. Dec 11 21:44:28 mamarley, hmmm, Hauke was going to post update to ath10k-ct driver, I think that will fix it. I guess you are on a 9880 or other wave-1 NIC? Dec 11 21:44:39 greearb__: mamarley I am also getting this with the ath10-ct based on 4.19 Dec 11 21:45:03 was just about to write this and then saw that mamarley was faster ;-) Dec 11 21:45:08 greearb__: Yes, it is a Wave-1 device. Dec 11 21:45:14 this is 10.1-ct-8x-__fW-021-e2174c5 Dec 11 21:45:44 * mamarley has 10.1-ct-8x-__fH-022-6d741b3d that he just downloaded. Dec 11 21:45:55 the "old" fw with QCA9880 Dec 11 21:47:12 Hauke: Does it otherwise work for you? Dec 11 21:47:38 Hauke, can you try latest FW + latest driver and see if it still fails? Dec 11 21:47:51 greearb__: That's what I'm on. Dec 11 21:48:03 mamarley, do you know if you are using 4.16 or 4.19 ath10k-ct driver? Dec 11 21:48:09 4.19 Dec 11 21:48:57 let me poke at code Dec 11 21:49:42 greearb__: wifi works Dec 11 21:51:02 greearb__: here is a strange comment which searms to be related: https://github.com/greearb/ath10k-ct/blob/master/ath10k-4.19/wmi.c#L9648 Dec 11 21:51:55 the new FW should support it Dec 11 21:53:53 I have 10.1-ct-8x-__fH-022-6d741b3d as shown in dmesg, but I still get the errors. Dec 11 21:58:04 greearb__: these are the feature flags: [ 20.144554] ath10k_pci 0000:02:00.0: firmware ver 10.1-ct-8x-__fW-021-e2174c5 api 2 features wmi-10.x,has-wmi-mgmt-tx,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT crc32 83fdb9cc Dec 11 21:58:38 that stuff relates to a wmi-service flag, not feature flag Dec 11 22:00:32 code looks correct to me, can you see if it is the if (!wmi->ops->gen_pdev_bss_chan_info_req) Dec 11 22:00:32 return -EOPNOTSUPP; code that fails? Dec 11 22:01:19 ok will do Dec 11 22:07:21 cat /sys/kernel/debug/ieee80211/phy0/ath10k/wmi_services shows that WMI_SERVICE_BSS_CHANNEL_INFO_64 is enabled Dec 11 22:07:35 that is good Dec 11 22:11:17 greearb__: gen_pdev_bss_chan_info_req() returns a valid pointer Dec 11 22:12:20 wonder where it is getting that error message from then! Dec 11 22:15:54 I see it Dec 11 22:16:00 pdev_bss_chan_info_request_cmdid is set to not supported Dec 11 22:16:09 .pdev_bss_chan_info_request_cmdid = Dec 11 22:16:09 WMI_10_2_PDEV_BSS_CHAN_INFO_REQUEST_CMDID, Dec 11 22:16:09 .pdev_bss_chan_info_request_cmdid = WMI_CMD_UNSUPPORTED, Dec 11 22:16:15 yes I also found that now Dec 11 22:16:17 yeah, mis-merge it seems Dec 11 22:16:36 I cannot even count the number of times I have made that error… Dec 11 22:17:33 if you remove that second line, it works for you? Dec 11 22:17:40 ie, no spam and you get survey results? Dec 11 22:22:27 greearb__: no spamming any more Dec 11 22:24:09 ath10k-ct repo updated Dec 11 22:24:14 greearb__: thanks Dec 11 22:29:02 greearb__: Works for me also, thanks! Dec 11 22:42:00 Hauke, will you be able to push the new ath10k-ct and fw patches into openwrt? If so, please let me know when it is done so I can update bug-trackers in ath10k-ct github accordingly. Dec 11 22:44:17 build #1112 of brcm2708/bcm2709 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/brcm2708%2Fbcm2709/builds/1112 Dec 11 22:54:24 greearb__: did you already prepare a openwrt patch with the new FW? Dec 11 22:54:46 no, I'm hoping someone else can... Dec 11 23:08:52 greearb__: I am a little bit confused which FW to take for which card ;-) Dec 11 23:14:48 It is already late here, I will go to sleep now Dec 11 23:16:16 Hauke, hopefully that email I sent plus some sleep will make it fairly obvious, but plz ping me tomorrow.. Dec 11 23:18:08 ok Dec 12 00:32:48 build #241 of at91/sama5d2 is complete: Failure [failed targetupload] Build details are at http://phase1.builds.lede-project.org/builders/at91%2Fsama5d2/builds/241 blamelist: Jonas Gorski , Koen Vandeputte , Daniel Gonzalez Cabanelas , Christian Lamparter Dec 12 01:01:11 what's the story with odhcpd? Dec 12 01:45:10 build #115 of layerscape/armv7 is complete: Success [build successful] Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv7/builds/115 **** ENDING LOGGING AT Wed Dec 12 03:00:00 2018