**** BEGIN LOGGING AT Mon May 06 02:59:57 2019 May 06 04:29:24 hmh: If they don't have U-Boot env partitions and you want something that is "100%" for any arch, might consider adding a tiny partition yourself and then uci-defaults scripts to read from it May 06 04:30:17 I wouldn't go smaller than 2048 bytes as that is a common NAND page size. May 06 05:17:27 From where does `upgrade/platform.sh` get called? fgrep doesn't find `platform.sh` under either `target/` or `package/` May 06 05:32:55 (got it -- `include` function globs a directory and then source-s all *.sh found) May 06 07:44:50 ldir: wow, that's some black magic ;) May 06 07:45:11 ldir: for net/sched/act_ctinfo.c you probably don't need license text as you alreayd include SPDX-License-Identifier May 06 07:47:24 rmilecki: that has gone in the v3 - I got told off by Greg KH :-) May 06 07:47:38 oh, ok then :) May 06 09:14:40 once upon i time, back when greg kh lived in Portland, i nerdsplained something to him in a public email. embarrassing. May 06 09:27:32 I'm trying to keep in mind Greg KH's grumpy maintainer talk of "Make it clear why I would be monumentally stupid not to take your patch". If licensing is the only comment (so far) I'm very pleased with that. May 06 10:34:13 *yawn* May 06 10:34:22 and its only monday lunchtime May 06 11:13:44 karlp: we create both add-in packages for self-service (source available) and ready-to-use firmware images for home routers, that change them into internet measurement instruments. So, pretty much anything that people currently likes to buy (home users _or_ ISPs) is game. May 06 11:15:39 karlp: right now, that means ath79/ar71xx, and people won't stop asking for raspbery pi support. Unfortunately, some broadcom too, but to these we simply say "buy something else" May 06 11:17:48 jeffsf: messing with the partition table is a sure way to go down an one-way street, isn't it? if it becomes too hard to switch to stock openwrt or to reflash the vendor firmware, it can be a big problem for us :-( May 06 11:20:22 * hmh wonders if we could somehow add a "vital product data" notion to openwrt itself, which it cathers for when dealing with the kernel or the rootfs during first boot and sysupgrade. It is not like it wouldn't be useful as a general feature. May 06 11:22:29 that's ... what non rootfs/kernel/image partitions are for, usually set to read-only. May 06 11:24:05 KanjiMonster: how compatible would it be to sysupgrade from something that has such a partition, to stock openwrt (which doesn't) ? May 06 11:25:27 because yeah, a partition looks like the ideal solution, if it can be done safely and 100% cross-compatible with stock openwrt and vendor (it is okay for the data to be lost when switching to vendor or stock openwrt) May 06 11:27:01 Hi guys, sorry to annoy you, but I have question to ask you. Is there here someone that have experience with PCM/TDM BUS and SLIC? I'm tring to understand a fiew things about channels, timeslots, channel width. (When I studied the PCM interface at school it wasn't containing all this parameters (Only timeslots if the PCM was also used in conjuction with TDM). May 06 11:27:31 hmh: depends a bit on NAND or NOR. NAND/ubi would just keep the partition (since ubi has its own partition table - assuming its a ubi partition then); on NOR flash as part of e.g. the last block of the rootfs, it might cause issues on first flash when it suddenly becomes part of the rootfs again, but wasn't formatted (it's only an issue for sysupgrade with keeping config though I think) - stock firmware ususally overwrites the whole May 06 11:27:31 flash space anyway and doesn't use overlay May 06 11:28:02 s/rootfs again/roofs_data again/ May 06 11:28:43 sysupgrade without keeping config is no issue though May 06 11:31:31 hmh: you could modify your sysupgrade and check if its an image from you, and if not, then forcibly disable keeping config (would be probably best anyway, depending on how much you change) May 06 11:32:07 KanjiMonster: maybe, but we have this local policy that says "if you can do it in a way that is useful to everyone, and send it upstream, try hard to do just that" May 06 11:35:30 maybe it could work with the metadata applied at the end of padded squashfs May 06 11:35:54 if it is persisted across factory reset, then yes May 06 11:36:26 currently the metadata are applied to the sysupgrade image and removed before flashing May 06 11:37:39 before considering a separate new partition idea, I was toying with trying to unlock and squashfs append the data to the rootfs (not the overlay) May 06 11:38:06 squashfs is a read-only filesystem, you can't append anything May 06 11:38:49 KanjiMonster: it is somewhat extend-based, mksquasfs is documented to be able to. May 06 11:39:09 KanjiMonster: but doing that to something already in FLASH is a whole different deal. May 06 11:39:34 it won't work anyway May 06 11:39:51 as you would probably overwrite beginning of the overlay May 06 11:41:32 increasing and replacing the padding to embbed the data would also work, but it is ugly as all heck and I'd rather not go that way. May 06 11:41:34 hmh: I mean you could also just generate per-device images. You can use imagebuilder and use FILES="files-" to add different files for each run (and ugh IMAGEPREFIX(?)="" then to make sure each files has its own name). Would survive factory reset, but would mean secrets embedded in the images (so not quite as secret) May 06 11:42:32 KanjiMonster: and it would also mean dynamically generating those for unassisted upgrades, which is a *PAIN*. That's our last-resort, "we know it will work but we want something better really" choice :( May 06 11:44:33 hmh: where do these secrets come from? generated at first boot? or do they come from the outside? May 06 11:46:09 KanjiMonster: either is acceptable, we would display them on LuCI and also provide a small utility to print a label one can glue to the outside of the box if one wants May 06 11:47:35 KanjiMonster: the idea is to create a "SSID: foo, PW: bar" type of secret to allow the router to safely bring up its radios while still unconfigured. We'd also provide an extra secret that the user can do an IoT-oauth style proof-of-possession to say "this thing is mine" on a cloud portal. May 06 11:48:08 yeah, that's exactly the things we put in uboot env. May 06 11:48:38 I dont' really get it though, you're providing all this, but you somehow have to support "any/all" hardware too? May 06 11:48:48 that doesn't make sense in my mind. May 06 11:48:55 we do not build hardware. May 06 11:49:01 if people want to bring their own hardware, they'ðre on their own for this surely. May 06 11:49:56 karlp: that only works when you care not if you get new users, while it is the *whole point* of our entire effort :( May 06 11:50:31 I'm not following your effort then. May 06 11:51:15 tehy have "any" hgardware, buy some software from you, and get a pdf they can print out to stick on their own hardware with the passwords, and they install it ... how? May 06 11:51:27 via the factory/openwrt existing flash methods? May 06 11:51:39 hmh: if you reuse existing hardware, I would assume they already come with default SSID/passwords with stock firmware - you could figure out how to extract this from the vendor config partitions, then set appropriate defaults on first boot. Such a package might event be acceptable upstream, and you wouldn't need to print out labels, as these default SSIDs/passwors are ususally already printed on devices ;-) May 06 11:52:18 KanjiMonster: yeah, but that requires a lot of expensive effort, since it is a fast moving target :( we considered it. May 06 11:52:53 KanjiMonster: that's time much better spent by talking to manufacturers to get openwrt support upstream, or porting some local router models to openwrt :( May 06 11:53:55 karlp: we only create the firmware, we can get the other side to do some work when they're trying to sell something to an ISP or government, otherwise we have to make it as pain-free as utterly possible to work with something you'd buy on the local computer gear store in brazil. May 06 11:56:33 (and we're a non-profit) May 06 11:57:50 hmh: extracting the default SSID/password(s) is usally quite easy, and vendors often reuse the same location/layout on their whole line May 06 11:58:55 also when generating them on the device you have a chicken-egg problem; the user would need to login to see the credentials, but they need the credentials to login ;) May 06 11:59:04 KanjiMonster: is it on a partition not touched by the first openwrt flash with a "factory" image? May 06 11:59:58 KanjiMonster: that's why we'd provide the "label" on anything we donate, and also on the "you must use an ethernet cable, sorry" default mode-of-operation (radios off) of openwrt :) May 06 12:01:11 We'd also add an "phone app" that can do secure peering to do it, but we will only have time to create that in Q4 or Q1 next year. Yeah, we will contribute it back to openwrt, that's how we work. May 06 12:02:00 hmh: yes, usually in a board_data partition or part of the default u-boot/bootloader environment. Stock firmware needs a way to find these out on a factory reset as well, so it needs to be stored permanently ;) May 06 12:02:18 the deal is that we know for sure >60% of brazil's population doesn't use ethernet to talk to anything, it is all cellphones and wifi. May 06 12:03:01 KanjiMonster: hmm, if this thing doesn't change locations widely on every new model of a vendor, it would be a viable choice, yes. May 06 12:03:20 KanjiMonster: less desireable than some generic new feature for openwrt that would allow us to deploy it on *anything*, though. May 06 12:04:17 so, viable options seem to be: May 06 12:04:21 I don't think there really is a generic way for it, at least I can't come up with one May 06 12:04:44 KanjiMonster: "add a subpartition" can't be made generic enough? May 06 12:05:09 KanjiMonster: optional, because flash space is too precious to waste when one doesn't want the feature, of course. May 06 12:05:10 no May 06 12:06:00 partition layout is taken from different sources, depending on device (on-disk/flash partition layout, dts supplied partition layout, cmdline provided partition layout, maybe more options) May 06 12:06:34 extending openwrt's notion of rootfs or rootfs_data to have some reserved space for that kind of data would be generic enough? May 06 12:08:27 it would require kernel code changes; e.g. openwrt uses the squashfs partition's reported size to know where the rootfs_data begins on NOR device - you would now need to change the code to recognize there is a separate chunk and move the rootfs_data partition further away May 06 12:10:07 Might be easier to reserve space at the _end_ of rootfs_data, then? it also has the property of not moving around... May 06 12:10:37 we'd tell the overlayfs it has 2KiB less than the partition space to work with, or something like that. May 06 12:11:06 (actually, needs to be one erase page size, which is kind of a big problem. stratch that) May 06 12:11:48 KanjiMonster: how palatable is the kernel change. I have no problem whatsoever writing kernel code, been doing that for a decade. May 06 12:16:34 hmh: on NOR, there is a squashfs split code somewhere in drivers/mtd, for NAND, userspace takes care of creating the rootfs_data partition through ubi-utils by creating a partion with maximum size; for emmc/sdcard devices the root-partition size is a build time option (also userspace takes care of it there as well) May 06 12:18:21 KanjiMonster: so, looks doable. Would such changes have a good chance of being accepted upstream? I'd go with "fish around vendor's boot sector" as a short-term solution, and "enhance openwrt's rootfs/rootfs-data to hold a new, generic, vital product data area" as a medium/long-term solution... May 06 12:18:42 hmh: some devices support two images at the same time (one as a fallback); there you'd had the issue that there are two rootfs[_data] partitons, and it could become very confusing if these got differrent secrets May 06 12:19:03 Meh, in fact if the vendor *is* storing their crap in uboot, I can just take a hash of the whole thing. I just need to prove it changes from device to device for that model, so it is an ideal short-term solution. May 06 12:19:49 KanjiMonster: not really, we can document that the second boot is for repair, and switch to a hardcoded secret in that case. May 06 12:20:45 hmh: usually these are flashed alternated, so you have no real control which one is the one OpenWrt was flashed onto/will be booted from in the initial installation May 06 12:21:33 KanjiMonster: on expensive devices, maybe :p I have something in my workbench that just added some uboot logic, and has a 16MiB FLASH but only uses 8MiB for the firmware, so that it can store two of them. May 06 12:22:21 Yeah, meh. But that would be why the lack of 4/32 support on recent OpenWRT renders us unable to support devices that are still being procuded at a rate of a few million new devices/year :( May 06 12:22:31 "cheap is good" :( May 06 12:22:47 (note new devices == manufactured units, not new *models*) May 06 12:25:33 good thing 802.11ac is such a memory hog, new non-bottom-of-line models are 8/64 or better. May 06 12:30:39 KanjiMonster: thank you very much for all the help, I will employ the short-term solution you suggested, and seriously look into how much effort it will take to teach openwrt to prepend or append vital product metadata/data (i.e. secrets usable for ssids, passwords, and anything else the user wants as long as it fits) to the rootfs May 06 12:31:04 (or to store said data at the end of the rootfs_data partition) May 06 12:31:39 the last one is so nice, I will actually look into it even if it has a >90% chance of being a very bad idea due to erase block size. May 06 12:31:55 hmh: storing at the end of rootfs_data doesn't work for UBI based systems, as the "end" isn't clearly defined - you need an actual separate partition for that May 06 12:33:36 KanjiMonster: ok, removing it from the list for good, then. May 06 12:34:20 Adding the extra partition would actually be doable even if I had to do it treewide, but since it would become "non-optional", I won't bother. May 06 14:08:09 hmm, for the record, I just checked 329 tp-link devices of several models, and their u-boot and ART partitions were all unique (md5sum of the /dev/mtd*ro for these were unique). These are somewhat older devices, will need to do the same to "archer-*" devices, but I expect to find the same. May 06 14:09:51 well, if ART contains MAC addresses, then I would expect some uniqueness May 06 14:10:47 so would I, but it is not a given. and I was not about to expect the ARTs of devices in the same manufacturing lot to be different either, unless the MAC or serial number is in there May 06 14:11:24 but looks like using the md5sum (or any other hash) of ART *and* uboot is an acceptable short-term solution on these models. May 06 14:12:19 Certain manufacturers have Murata-style quick-connnect RF test points. Given the cost of populating those, I would guess that they actually qualify each device during test. May 06 14:14:29 There are hints in the cruft in U-Boot that it can be downloaded and flashed from a TFTP server May 06 14:15:05 that's pretty standard. May 06 14:15:08 jeffsf: are these the RF test points you are referring to? https://www.microwavejournal.com/Article_Images/254_fig1.jpg May 06 14:15:23 Hell__: ye May 06 14:15:31 oh, TIL. nice. May 06 14:23:07 hmh: if you use the ART partition, make sure the ART partition differs in more than the mac address, else it's possible to calculate the password based on the mac address in the AP's beacons May 06 14:24:14 KanjiMonster: that's why it is a short-term solution, the only proper solution is to inject an external secret that has nothing to do with MACs (unless we're sure the manufacturer is already doing that) May 06 14:26:04 KanjiMonster: and I'd use both ART and uboot, hash both and use the compound hash of both, so any non-mac derived uniqueness on either one would be represented. May 06 14:27:51 again, short-term stopgap solution. the proper one is to populate a product vital data area with per-device secrets, which we can be sure of, regardless of whatever the manufacturer did (or did not) do. May 06 15:00:29 hmh: add an unpublished key to your hash, and you should be fine. May 06 16:52:25 Is there a write-up of the basic flow of `sysupgrade` somewhere, or just "follow the script"? May 06 16:55:43 In particular, the image verification, tar extraction, and writing to flash May 06 17:08:02 Can someone help me with with a kernel module makefile? May 06 17:19:52 follow the script for sysupgrade is... argh. May 06 17:22:06 anyway, got the final results from my "query the userbase" run for tp-link uboot and ART. The ARTs are *not* unique always, there is some chance of duplicated ones (but it was quite low in my sample: 31 non-unique out of 1461 devices) May 06 17:24:15 uboot did much better, still looking at the results. May 06 17:27:14 hmh: Yes, the joys of the first port to a new platform -- I'm taking notes as I work through the source. May 06 17:28:50 I recall we had to do some very intrusive crap to extend sysupgrade on older openwrt/lede to free up as much RAM as possible, or it would crap out 7 times out of 10 on 32MiB-RAM devices. May 06 17:30:13 killing everything, shutting down all interfaces and removing the entire wireless stack is a pretty basic measure on anything with 32MiB RAM only, got the success rate to 9 out of 10. May 06 17:31:46 hmm, well, *if* you use every partition that has u.?boot in the name on /proc/mtd, the hash is unique, except maybe on Ubnt, but they have uboot_env so we ought to use that instead and inject a real secret. May 06 17:36:03 guys is there a way to mark a kernel module as a dependecy of another one? (Or the other way around) May 06 17:54:38 hitech95: OpenWrt should detect it automatically May 06 17:54:52 based on the DEPENDS line in modinfo May 06 17:54:58 this is also filled automatically May 06 17:56:31 Hauke, yup but i'm making my own module and riht now I have no idea on how i can define the dependency May 06 17:58:51 https://openwrt.org/docs/guide-developer/packages May 06 17:59:02 Looks like there is a dependency flag May 06 17:59:48 lagzilla, it's a runtime dependency. My module need another module to be loaded to work May 06 18:00:37 wouldn't you do that in your init file then? May 06 18:01:42 hitech95: the kernel build system automatically fills DEPENDS based on the functions you reference May 06 18:02:11 Hauke, no i don't have to do anything? May 06 18:02:29 if it works correctly you do not have do do anything May 06 18:03:07 I'll see I'm still tring to compile it. (Having problem with makefile) May 06 18:03:09 hitech95: otherwise you have to do some hacks with Module.symvers May 06 18:04:37 Hauke, i'm kaking two modules: 1) is closed source with binary stuff (I hate vendors) and the second one is "open". the first one exports some methods for the second. May 06 18:05:11 Right now i'm making the makefile for the #1 module. May 06 18:05:22 Or at least i'm failing at May 06 18:31:10 I'm getting *** No rule to make target `/home/nicolo/Documenti/Sviluppo/mylib_api/mylib_api.c', needed by `/home/nicolo/Documenti/Sviluppo/mylib_api/mylib_api.o' any idea? the files are in "/home/nicolo/Documenti/Sviluppo/mylib_api/src/" May 06 18:31:18 I'm noob with Makefiles :( May 06 18:32:29 My makefile: https://pastebin.com/6ax0QLa1 May 06 18:57:10 # May 06 19:02:29 blogic do you have a quick advise how I can compile procd to print debug messages? or wher to add -S in the rootfs May 06 20:04:14 * KevinDB hugs his apu2 May 06 20:17:55 I wonder if coreboot+openwrt could fit in a 8MB flash chip, for x86-based openwrt systems May 06 20:18:42 Hell__, if it's intel ithink no. the coreboot blobs are quite big. let me chack! May 06 20:19:03 well, the rootfs would be somewhere else, but the kernel could definitely be loaded directly by coreboot May 06 20:23:25 ther microcode for my cpu is like 25k, the mrc is 190k, the vbt is 5k. No idea of ime and vboot, but thoose are quite big. BTW the fw for my notebook is exactly 8MB. (I have no idea of the actual free space inside, it have tianocore) May 06 20:32:52 what laptop is this? May 06 21:07:36 aparcar[m]: you can hit 1,2,3,4 during boot May 06 21:09:02 aparcar[m]: is this a running image or are you building one ? May 06 22:37:39 blogic I've tried that, but it doesn't print anything. Seems like it fails to setup the /dev/console or something. I'm trying to modify procd to works while running in an LXC container May 06 22:37:51 blogic You're not by any chance interested in helping me :)? May 06 22:44:28 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/base-files/files/lib/preinit/30_failsafe_wait;h=dd9c7e2b59449b5fa0c9944a1ec9cc703e30cbed;hb=HEAD#l43 May 06 22:44:38 line 60 May 06 22:44:41 hardcode that May 06 23:02:26 blogic I already hardcoded procd to debug level 10 and also get some udhcpc output when pressing 4, however procd never prints anything. Connecting to tty1 works fine... May 06 23:03:56 blogic there are only a few processes running, so I figred procd stock? https://paste2.org/Bjb7EzWe May 06 23:15:28 blogic do you see a problem within this patch that stops procd from printing stuff? https://patchwork.ozlabs.org/patch/1095497/ **** ENDING LOGGING AT Tue May 07 02:59:57 2019