**** BEGIN LOGGING AT Wed Aug 08 03:00:02 2018
Aug 08 03:20:39 <luke-jr> would be nice if the x86_64 images had wifi drivers, wpa_supplicant, etc :/
Aug 08 03:50:25 <cheng08> Guys I have a usb serial console, how can I access the linksys e1200 with open-wrt firmware cmd to reset the router?
Aug 08 03:52:21 <DonkeyHotei> generally yes
Aug 08 03:53:02 <cheng08> DonkeyHotei: I try to access the router using putty but not working
Aug 08 03:53:50 <DonkeyHotei> sometimes the pinout on wiki reverses rx and tx because people get confused
Aug 08 03:56:14 <DonkeyHotei> there is a lot of info here https://openwrt.org/docs/techref/hardware/port.serial
Aug 08 04:18:35 <m4t> anyone know if there is a pending fix for this? /home/matt/devel/openwrt/openwrt/staging_dir/host/bin/ucert: error while loading shared libraries: libjson-c.so.2: cannot open shared object file: No such file or directory
Aug 08 04:20:25 <m4t> if i had to take a guess... 7a52ce3fafab59a17f692a3a24717c8b0f358407 + -DUSE_RPATH="${STAGING_DIR_HOST}/lib"
Aug 08 04:25:29 <cheng08> DonkeyHotei: I try that but the putty not responding
Aug 08 04:26:08 <DonkeyHotei> perhaps the usb adapter is faulty, or the soldering on the device
Aug 08 04:27:04 <cheng08> the serial usb console is working on the switch
Aug 08 04:27:39 <DonkeyHotei> the switch has low-voltage serial?
Aug 08 04:28:30 <cheng08> catalyst cisco sqitch
Aug 08 04:28:33 <cheng08> switch
Aug 08 04:28:41 <Monkeh> .. what adapter are you using?
Aug 08 04:29:07 <cheng08> and the serial read the console in the windows hardware
Aug 08 04:29:22 <cheng08> I put the serial in internet port
Aug 08 04:30:14 <Monkeh> Er
Aug 08 04:30:29 <Monkeh> The ethernet port? On the outside of the router?
Aug 08 04:30:45 <DonkeyHotei> did you read the page i linked, like at all?
Aug 08 04:31:16 <cheng08> I use serial adapter sir
Aug 08 04:31:44 <cheng08> https://shopee.ph/USB-to-Serial-RS232-Converter-Cable-i.23880785.1085406968/similar?from=ads&gclid=CjwKCAjwhqXbBRAREiwAucoo-88fAq6o7vPLJQ7AbpBWBuPoaMK2z7kb_kb6-KuOrdNDC-v84X_mlBoCsPgQAvD_BwE
Aug 08 04:31:47 <cheng08> like that sir
Aug 08 04:32:00 <m4t> it's not like a cisco rj-45 to db9
Aug 08 04:32:03 <Monkeh> You're using the wrong one and you can't plug it in like that anyway.
Aug 08 04:32:37 * m4t disables package signing for the time being
Aug 08 04:33:08 <cheng08> okay sir so I need to soldering it or serial console only?
Aug 08 04:34:50 <DonkeyHotei> you also need to convert between 12V and 3.3V
Aug 08 04:35:30 <DonkeyHotei> there is a lot of information about it on the page i linked
Aug 08 04:47:24 <cheng08> okay sir I will read it first
Aug 08 05:21:38 <nyt> anyone having trouble building with busybox / bzip2 freaking out?
Aug 08 05:23:06 <nyt> just scrolls: (BZIP2_SMALL) [8] (NEW)   Trade bytes for speed (0:fast, 9:small) (BZIP2_SMALL) [8] (NEW)   Trade bytes for speed (0:fast, 9:small) (BZIP2_SMALL) [8] (NEW)   Trade bytes for speed (0:fast, 9:small) (BZIP2_SMALL) [8] (NEW)   Trade bytes for speed (0:fast, 9:small) (BZIP2_SMALL) [8] (NEW)   Trade bytes for speed (0:fast, 9:small) (BZIP2_SMALL) [8] (NEW)   Trade bytes for speed (0:fast, 9:small) (BZIP2_SMALL) [8] (NEW)   Trade bytes for
Aug 08 05:23:06 <nyt> speed (0:fas
Aug 08 05:32:29 <blogic> hi
Aug 08 05:35:33 <obaid> blogic: hello
Aug 08 05:53:10 <nyt> looks like 12fb4bb834dc715ce43bf428c35b489e89e776a1 broke it
Aug 08 05:56:47 <luke-jr> is there a way to provide my own wpa_supplicant.conf file?
Aug 08 05:58:33 <nyt> files/ directory
Aug 08 05:59:54 <luke-jr> nyt: ?
Aug 08 06:00:32 <nyt> anything you put in files ends up on the file system
Aug 08 06:00:38 <nyt> so if you want something in etc/config/whatever
Aug 08 06:00:41 <nyt> create files/etc/config/whatever
Aug 08 06:01:46 <luke-jr> okay, but wpa_supplicant.conf is being generated at runtime in RAM disks?
Aug 08 06:01:56 <luke-jr> or is there some place I can put one to override it?
Aug 08 06:02:35 <nyt> also why are you needing to manually adjust that out of curiosity?
Aug 08 06:03:35 <luke-jr> no way to disable scan_ssid it seems; but mainly because I want to have my wifi client connect to any of various SSIDs, including the "any SSID that's open"
Aug 08 06:05:20 <luke-jr> (I'm basically using OpenWrt as just a wifi client)
Aug 08 06:12:23 <obaid> hello all .. I am trying to compile my openWRT CC with ledtring-netdev support .. I am selecting ledtrig-netdev from make menuconfig .. But, i don't see it in firmware. Also i don't file this file in lib/modules folder .. Any help ??
Aug 08 06:15:22 <Fishman> obaid: why are you compiling an old build?  18.06 is current, CC is old and vulnerable
Aug 08 06:19:08 <obaid> Fishman: It is because the drivers i am using in compatible only with CC
Aug 08 06:19:48 <obaid> is **
Aug 08 06:27:39 <Fishman> *are :-)
Aug 08 06:46:21 <nyt> so busybox in master is broke if you enable bzip2
Aug 08 06:46:31 <nyt> yes gets pipe'd to to build
Aug 08 06:46:37 <nyt> and it's looking for 0-9 for BZIP2_SMALL
Aug 08 06:46:55 <nyt> since it's not getting included with the grep for CONFIG_BUSYBOX_CONFIG
Aug 08 06:46:59 <nyt> since it's in CONFIG_BUSYBOX_DEFAULT
Aug 08 06:51:37 <nyt> looks like busybox needs some love in archival/Config.in to fix
Aug 08 07:06:47 <nyt> https://github.com/openwrt/openwrt/pull/1256
Aug 08 07:09:59 <mkresin> nyt: please rework your commit message. the commit message needs a prefix ("busybox: ")
Aug 08 07:10:06 <nyt> k
Aug 08 07:10:28 <nyt> i also horked something in the help, will submit a new req
Aug 08 07:10:40 <mkresin> nyt: and the commit message doesn't include an information. It should at least answer the question "Why do we need the commit"
Aug 08 07:10:51 <dedeckeh> nyt:no need to create a new PR
Aug 08 07:10:57 <mkresin> nyt: please update your PR instead
Aug 08 07:11:01 <nyt> k
Aug 08 07:11:07 <dedeckeh> nyt:you can just do a forced push
Aug 08 07:14:31 <xcoom> Hello All!
Aug 08 07:14:36 <xcoom> Anyone using here 1806 activelly?
Aug 08 07:14:41 <xcoom> like for daily use
Aug 08 07:16:12 <mkresin> xcoom: ask the question you have in mind. no one will reply to such an open question
Aug 08 07:16:13 <wigyori> morning
Aug 08 07:19:18 <nyt> https://github.com/openwrt/openwrt/pull/1256
Aug 08 07:20:44 <nyt> better?
Aug 08 07:31:37 <mkresin> nyt: yes. but still not correct
Aug 08 07:31:48 <nyt> howso
Aug 08 07:32:09 <mkresin> nyt: mail address in signed-off-by need to be enclosed by <>
Aug 08 07:32:22 <nyt> will amend
Aug 08 07:32:32 <mkresin> nyt: From/author line is different from Signed-of-by: https://patch-diff.githubusercontent.com/raw/openwrt/openwrt/pull/1256.patch
Aug 08 07:33:13 <mkresin> nyt: check the submitting patches guideline on openwrt.org. it should provide a guide to fix the from/author line
Aug 08 07:33:19 <nyt> was just copying the old sob from svn commit days
Aug 08 07:33:37 <nyt> my github address will not match my sob address, though
Aug 08 07:33:49 <nyt> its a spam filtering thing
Aug 08 07:34:21 <nyt> how important is that
Aug 08 07:34:23 <mkresin> nyt: don't discuss with me, check 'git log' to see how it is done and/or follow the submitting patches guideline
Aug 08 07:34:41 <nyt> that's kind of stupid
Aug 08 07:36:22 <nyt> whatever tho, adjusted
Aug 08 07:37:09 <mkresin> nyt: "From: " still doesn'T match the Signed-off-by
Aug 08 07:37:21 <mkresin> bbl
Aug 08 07:38:03 <xcoom> mkresin: For Wireguard also a RSA keypair is okay?
Aug 08 07:40:23 <nyt> nfc how to actually update that
Aug 08 07:43:59 <m4t> nyt: it's git config
Aug 08 07:44:18 <nyt> have gloval user.name set
Aug 08 07:44:32 <m4t> hmm
Aug 08 07:44:35 <mkresin> nyt: the third and the last time. check the submitting patches guideline on openwrt.org. Everything is mentioned there
Aug 08 07:44:44 <nyt> <nyt> have gloval user.name set
Aug 08 07:45:33 <m4t> maybe it's local on the repo for some reason?
Aug 08 07:46:23 <mkresin> nyt: the following might work: git commit --amend --author="Your Name <mail@domain.tld>"
Aug 08 07:46:55 <mkresin> xcoom: no idea. never used wireguard.
Aug 08 07:47:31 <xcoom> mkresin: Have you used simple-adblock?
Aug 08 07:47:32 <nyt> yeah needed the --author for that to get pushed through
Aug 08 07:47:33 <nyt> thx
Aug 08 07:50:53 <nyt> now to see what extra headache is needed to deal w/ base-files signature chain stuff
Aug 08 07:52:04 <nyt> any docs for the ucert stuff anywhere?
Aug 08 07:52:43 <andy2244> whats up with those errors on a feeds update? ".find.bin: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed." ?
Aug 08 08:18:54 <andy2244> oh not a openwrt issue, for some reason my locales where broken, had to set them again: localectl set-locale ...
Aug 08 08:23:47 <jow> andy2244: export LC_ALL=C
Aug 08 08:24:07 <jow> OpenWrt bundles a copy of glibc from the host it was built on
Aug 08 08:24:32 <jow> despite binary patching, it still tends to load stuff from the foreign host system, which leads to those assertions
Aug 08 08:25:29 <nyt> so after those usign commits, can no longer build with signed packages checked, base-files fails.
Aug 08 08:25:34 <andy2244> ah oki, but seems my host locales where actually broken
Aug 08 09:57:45 <dangole> ping jow
Aug 08 09:58:47 <Tapper> Just reading through https://forum.openwrt.org/t/openwrt-18-06-0-release/17955/45
Aug 08 09:59:12 <Tapper> It seems to me that 4-32 meg routers are ded and should be droped
Aug 08 09:59:19 <jow> pong dangole
Aug 08 09:59:40 <jow> dangole: stuck in a meeting and lunch afterwards
Aug 08 09:59:44 <jow> is now+45m okay for you?
Aug 08 10:00:15 <dangole> jow: ok
Aug 08 10:00:30 <jow> great :)
Aug 08 10:01:09 <xcoom> jow: In the 18.06 release packages like. atk10-firmware are updated daily?
Aug 08 10:08:03 <jow> xcoom: no
Aug 08 10:08:12 <jow> only if someone updates the package
Aug 08 10:44:53 <Tapper> Hi is there ath79 snapshots?
Aug 08 10:54:15 <dangole> jow: ready when you are
Aug 08 10:57:51 <KanjiMonster> jow: I found a flaw in the plan of moving drivers to kmods as much as possible: we still don't support per device rootfs for initramfs images
Aug 08 11:04:33 <jow> dangole: ready now
Aug 08 11:04:35 <jow> KanjiMonster: hm
Aug 08 11:08:19 <KanjiMonster> jow: the main issue (so far for me) implementing it is that you need to recompile the kernel multiple times with different rootfs-paths (not the issue), which you obviously can't do parallel - but the new device code expects to be able to do that, and I haven't found a way to prevent a canned recipe from being run in parallel
Aug 08 11:08:57 <jow> KanjiMonster: the way I understood is that recipes are save as long as they stick to $^ (input files) and $@ (output file)
Aug 08 11:09:18 <jow> once you start working with fixed paths, stuff will blow up
Aug 08 11:09:52 <KanjiMonster> jow: the only way to avoid that would be to create a copy of the whole kernel tree for every rootfs variant to build
Aug 08 11:10:18 <KanjiMonster> (and modify the kernel build code to cope with that)
Aug 08 11:10:56 <jow> I think you could define an image build step "recompile with rootfs path" that runs under flock
Aug 08 11:12:50 <KanjiMonster> we would need to move the kernel (initramfs) build from a collection of recipies to a shell script for that
Aug 08 11:13:43 <KanjiMonster> we setup the config and rootfs in multiple steps/recipies, so we can't just only run the actual make invocation in flock
Aug 08 11:14:03 <jow> hm, okay
Aug 08 11:14:27 <KanjiMonster> the other way would be to have a defined step in the build code where we iterate over the to be generated rootfs's, but I haven't found the right place for that
Aug 08 11:14:43 <jow> its all make target dependency driven
Aug 08 11:14:48 <KanjiMonster> yeah
Aug 08 11:14:59 <jow> expressed in the form of runtme generated code which is eval'ed
Aug 08 11:15:14 <jow> that makes it so extremely hard to follow, you'll never find explicit invocations
Aug 08 11:15:16 <KanjiMonster> and Make doesn't support "don't compile these two targets in parallel", only "don't run in parallel, full stop"
Aug 08 11:15:20 <andy2244> jow: making progress converting packages to libtirpc, will have to replace portmap with rpcbind. Btw do you want PR per package or one big for all libtirpc related changes?
Aug 08 11:16:01 <jow> KanjiMonster: I thought that is what .NOTPARALLEL is for
Aug 08 11:16:28 <KanjiMonster> jow: .NOTPARALLEL disables parallel build for the whole file
Aug 08 11:17:16 <jow> KanjiMonster: another technique I've seen which - iirc - is also used for the new image building code is daisy-chaining all the targets
Aug 08 11:17:30 <jow> image c depends on image b depends on image a
Aug 08 11:17:35 <jow> even if they're unrelated
Aug 08 11:19:49 <jow> hm its not that, but I've seen it somewhere
Aug 08 11:21:49 <jow> so I think whenever you $(eval) a new target recipe, you export its name as PREV_RECIPE or similar
Aug 08 11:22:05 <jow> then when you $(eval) the next, you simply make it depend on $(PREV_RECIPE)
Aug 08 11:22:21 <jow> the first one will have an empty dependency
Aug 08 11:22:45 <jow> this way you do not even need an explicit list of targets beforehand
Aug 08 11:26:19 <KanjiMonster> will need to think about this
Aug 08 11:27:18 <jow> andy2244: I'd start with an all in one PR and only break it down if asked to
Aug 08 11:28:32 <andy2244> oki, btw you want a clean change or should i keep/expand the $(LIBRPC) rules.mk logic?
Aug 08 11:29:15 <jow> expand?
Aug 08 11:29:16 <KanjiMonster> andy2244: some size comparisons (librpc vs lib<replacement>, uncompressed and compressed) are always nice
Aug 08 11:30:24 <andy2244> jow: need to add "LIBRPC_INCLUDE=-I$(STAGING_DIR)/usr/include/tirpc"
Aug 08 11:31:00 <andy2244> or i can just add this normally in every package without VARs?
Aug 08 11:31:19 <jow> afair librpc is only need on !GLIBC
Aug 08 11:31:29 <jow> hence the macros, to be able to disable it
Aug 08 11:31:35 <jow> but maybe I'm wrong
Aug 08 11:31:42 <andy2244> ah ok
Aug 08 11:33:23 <jow> so the librpc currently in the tree was operated out of uclibc because musl libc lacks an own librpc implementation
Aug 08 11:33:48 <jow> I guess libtirpc is a generic replacement intended to target various environments
Aug 08 11:33:59 <jow> it probably makes sense to always use it, even on uclibc and glibc hosts
Aug 08 11:34:10 <karlp> glibc is trying to kill the builtin rpc.
Aug 08 11:34:11 <jow> hwoever as KanjiMonster mentioned, size difference plays a given rule
Aug 08 11:34:18 <karlp> tirpc lets you have v6 as well.
Aug 08 11:34:20 <jow> *role
Aug 08 11:34:33 <jow> so if tirpc is suddenly 200k bigger, it would be an issue
Aug 08 11:34:43 <andy2244> ok lemme check
Aug 08 11:35:41 <jow> karlp: sounds even better
Aug 08 11:35:58 <jow> then we could kill the builtin rpc stuff on every libc and simply rely on an installable package
Aug 08 11:36:17 <karlp> yeah, that's the goal upstream,
Aug 08 11:36:28 <karlp> it's why musl doesn't have it either,
Aug 08 11:39:55 <KanjiMonster> nothing in the base package set depends on it (except busybox, and only if you enable it), so size shouldn't be that huge of an issue
Aug 08 11:40:37 <dangole> jow: now i had lunch (spontanously)
Aug 08 11:40:43 <jow> :D
Aug 08 11:40:46 <dangole> jow: back now, but only got 20 minutes
Aug 08 11:40:56 <jow> dangole: lets start
Aug 08 11:40:57 <dangole> should be enough though
Aug 08 11:41:03 <andy2244> ok librpc.so: 544kb libtirpc.so:135kb for my arm target
Aug 08 11:41:21 <jow> dangole: so first of all, can you give a brief executive summary on what is ucert, how it relates to usign
Aug 08 11:41:40 <dangole> https://git.openwrt.org/?p=project/ucert.git;a=blob;f=README.md
Aug 08 11:41:55 <jow> skimming...
Aug 08 11:42:18 <dangole> ucert wraps around usign and uses usign to sign usign-pubkeys inside a blob/blobmsg structure combined with other attributes
Aug 08 11:42:42 <dangole> staging_dir/host/bin/fwtool -s /dev/stdout openwrt-ramips-mt7621-zbt-wg3526-32M-squashfs-sysupgrade.bin | staging_dir/host/bin/ucert -D -c /dev/stdin
Aug 08 11:43:41 <dangole> that dumps the attached signature-chain from a sysupgrade image
Aug 08 11:44:05 <jow> okay, so it allows for trust delegation
Aug 08 11:44:28 <dangole> exactly
Aug 08 11:44:37 <jow> means instead of exposing our personaly proviate develoepr keys we can simply sign the buildbot keypair for example
Aug 08 11:44:43 <jow> *personal private
Aug 08 11:44:53 <dangole> yes, exactly
Aug 08 11:45:02 <dangole> and revoke them, if needed
Aug 08 11:45:05 <dangole> the idea is that devices without opkg cannot update openwrt-keyring
Aug 08 11:45:26 <dangole> but may need to check whether a (possibly automated) update is legitimate
Aug 08 11:45:37 <jow> understood. How is the data encapsulated in the image? base64 encoded as part of the existing json metadata? some further wrapping format aroudn the entire image?
Aug 08 11:45:54 <jow> the ucert signature data that is
Aug 08 11:46:03 <dangole> fwtool already allows for a trailing signature to be appended, we discussed that in battlemesh in porto back then
Aug 08 11:46:23 <dangole> ucert uses a blob containing a payload and the signature
Aug 08 11:46:33 <dangole> the payload is a blobmsg and hence can be pretty much everything
Aug 08 11:46:48 <f00b4r0> KanjiMonster: out of curiosity, why is per-device rootfs required for modularizing drivers in initramfs?
Aug 08 11:46:59 <jow> dangole: okay so a signed firmware image is a serialized blobmsg?
Aug 08 11:47:43 <jow> blobmsg_hdr attr_hdr image data attr_hdr signature data
Aug 08 11:48:08 <KanjiMonster> f00b4r0: because the rootfs of the ramdisk image will only compile those packages that are enabled for every device, but if we e.g. move the switch drivers into kmods and only include it for some device, then the ramdisk image won't contain any switch drivers, thus might be not reachable over network
Aug 08 11:48:12 <dangole> the firmware image itself is not inside the blob, as we would need to strip that off before flashing it
Aug 08 11:48:32 <f00b4r0> KanjiMonster: i see
Aug 08 11:49:21 <KanjiMonster> f00b4r0: and we have a few devices where booting a ramdisk image is a prerequisite for installing OpenWrt (mikrotik, turris omnia)
Aug 08 11:49:23 <jow> dangole: understood, so what is the payload in the firmware image case? A checksum of the preceeding image data?
Aug 08 11:49:35 <dangole> jow:  but that's all existing fwtool stuff. the idea was just instead of only having an appeneded signature, have the possibility for delegation, revocation and do that in a way which is extendable
Aug 08 11:49:47 <dangole> a payload can be eg. a usign pubkey
Aug 08 11:49:58 <f00b4r0> KanjiMonster: indeed. I know that's orthogonal but is there a particular reason to modularize what looks like "essential" drivers?
Aug 08 11:49:59 <dangole> and that's the only payload currently processed inside of ucert
Aug 08 11:50:22 <dangole> === CHAIN ELEMENT 01 ===
Aug 08 11:50:22 <dangole> signature:
Aug 08 11:50:22 <dangole> ---
Aug 08 11:50:22 <dangole> untrusted comment: signed by key b5043e70f9a75cde
Aug 08 11:50:22 <dangole> RWS1BD5w+adc3v5hrhCfn6VQRFcm2JQhZIHVttvvEVZxvCRcMotuCf0Uqi2d1mNrdQECdwgNcmjULKKJNT2hH+mnvpk3kMGP4wQ=
Aug 08 11:50:22 <dangole> ---
Aug 08 11:50:24 <dangole> payload:
Aug 08 11:50:25 <KanjiMonster> f00b4r0: not having to include them into every image, thus reducing image sizes
Aug 08 11:50:26 <dangole> ---
Aug 08 11:50:28 <dangole> "ucert": {
Aug 08 11:50:30 <dangole> 	"certtype": 1,
Aug 08 11:50:32 <karlp> stahp
Aug 08 11:50:32 <dangole> 	"validfrom": 1533695223,
Aug 08 11:50:34 <KanjiMonster> dangole: please use pastebin
Aug 08 11:50:34 <dangole> 	"expiresat": 1565231223,
Aug 08 11:50:38 <dangole> 	"pubkey": "untrusted comment: LEDE usign key for unattended build jobs\nRWS1BD5w+adc3j2Hqg9+b66CvLR7NlHbsj7wjNVj0XGt\/othDgIAOJS+\n"
Aug 08 11:50:39 <f00b4r0> i see
Aug 08 11:50:41 <dangole> }
Aug 08 11:50:43 <dangole> ---
Aug 08 11:50:45 <dangole> === CHAIN ELEMENT 02 ===
Aug 08 11:50:47 <dangole> signature:
Aug 08 11:50:49 <dangole> ---
Aug 08 11:50:51 <dangole> untrusted comment: signed by key b5043e70f9a75cde
Aug 08 11:50:53 <dangole> RWS1BD5w+adc3hJ2FJwcRwV34oO3cjZ7A9nI0MV/d/FeHbL2YiX4r5fkj/81/gzBRS9+KBIYZ3+QAA0tMR2VwzM9u3CM50ZzjgQ=
Aug 08 11:50:55 <dangole> ---
Aug 08 11:50:57 <dangole> KanjiMonster: sorry
Aug 08 11:50:58 <karlp> I like tha tyour client rate limited though
Aug 08 11:51:02 <karlp> that's cute at least.
Aug 08 11:51:55 <f00b4r0> KanjiMonster: I'm not sure the size gain offsets the minor, but real, performance penalty of using a lot of modules
Aug 08 11:53:36 <KanjiMonster> f00b4r0: every device would include only a handful, so I don't think there will be much of a performance penalty (also I don't think modules vs. built-in provides any performance difference for drivers)
Aug 08 11:55:41 <jow> dangole: ok. how are revocations handled?
Aug 08 11:56:09 <jow> dangole: some crl-equivalent?
Aug 08 11:57:34 <jow> dangole: and - how exactly is the trailing firmware signature verifying the firmware image? Through a file data hash? Asking because I'm not familiar with fwtool either
Aug 08 11:57:47 <jow> thats another undocumented thing that suddenly appeared in the past :)
Aug 08 11:59:33 <azrdev> hi! https://openwrt.org/releases/17.01.5 redirects to https://openwrt.org/releases/17.01/changelog-17.01.4   i think that's a mismatch :)
Aug 08 12:00:17 <azrdev> also, is there a release announcement mailing list / RSS feed  or similar somewhere? i.e. to get a notification when I should upgrade my device
Aug 08 12:01:03 <azrdev> if not, is there a reason why / would it be useful to file this as a feature request?
Aug 08 12:01:31 <dangole> jow: the signature is extracted and stripped off by fwtool, the remaining firmware+metadata is then verified using usign
Aug 08 12:01:43 <jow> azrdev: fixed. no, no, maybe
Aug 08 12:02:21 <dangole> jow: revokers can be all in one file which is provided via HTTP and checked either before sysupgrade or regularly eg. using a cron job
Aug 08 12:02:32 <jow> dangole: ok, so similar to a CRL
Aug 08 12:03:27 <dangole> jow: yes, just that ANY valid key can revoke ANY other key (while X.509 requires the revoker to be signed by the issuing authority)
Aug 08 12:03:47 <jow> dangole: how is sysupgrade behaving when faced with an image having a mismatching signature?
Aug 08 12:04:17 <jow> I assume it will abort with an error, similar to when the metadfata does not match the boardname
Aug 08 12:04:19 <dangole> jow: currently it just warns you, unless you got IMAGE_REQUIRE_SIGNATURE=1 set a env variable
Aug 08 12:04:24 <jow> okasy
Aug 08 12:04:53 <azrdev> jow: kthx!
Aug 08 12:05:08 <dangole> jow: long-term i thought of doing it exactly as you described for metadata, ie. fail unless '-F' is passed on the sysupgrade cmdline
Aug 08 12:07:07 <OutBackDingo> okay any ideas why this is broken or how to reesolve ?  https://pastebin.com/5AQPuLAm
Aug 08 12:07:54 <f00b4r0> KanjiMonster: the main perf issue is fragmentation: TLB misses
Aug 08 12:07:58 <f00b4r0> (sorry, was on the phone)
Aug 08 12:07:59 <jow> dangole: sounds quite well for me so far, thanks for the short intro.
Aug 08 12:08:02 <dangole> jow: every build-slave should be provisioned with individual key-build, key-build.pub and key-build.ucert, generated as described in ucert README.md
Aug 08 12:08:54 <jow> dangole: do you think that http://phase1.builds.lede-project.org/builders/ar71xx%2Ftiny/builds/324/steps/images/logs/stdio could be related to the ucert changes in the image build code?
Aug 08 12:08:56 <f00b4r0> KanjiMonster: I'm wondering if you could filter content at the image-generator step, which would allow you to run in parrallel
Aug 08 12:10:16 <KanjiMonster> f00b4r0: IIRC the kernel uses huge TLB entries for its space, so TLB misses shouldn't be an issue (if it even maps - on mips32 it doesn't)
Aug 08 12:10:25 <dangole> jow: yes, that was my bad and fixed by commit ec78f03de5 ("image: fix build without ucert") which wasn't yet included in ar71xx/tiny build #324
Aug 08 12:10:35 <jow> dangole: ah great
Aug 08 12:10:50 <jow> a final doubt about the ucert integrity
Aug 08 12:11:03 <KanjiMonster> f00b4r0: also the image builder can't generate ramdisk images, since it requires recompilation of the kernel, and the imagebuilder doesn't ship a compiler (or the full kernel sources)
Aug 08 12:12:01 <f00b4r0> KanjiMonster: memory fragmentation is bound to increase the number of TLB entries and misses, but I agree it's probably minor.
Aug 08 12:12:16 <f00b4r0> KanjiMonster: I'm not thinking about imagebuilder
Aug 08 12:12:29 <jow> dangole: the outer usign singature of the ucert basically guarantees that the information within the ucert (validity time, expiry time, embedded usign pubkeys) is genuine and same as the point when it was signed
Aug 08 12:12:44 <f00b4r0> I'm thinking in the images step of the build process, filtering content that gets into the initramfs image from a full rootfs tree
Aug 08 12:12:56 <f00b4r0> i.e. the equivalent of rsync --exclude or --include
Aug 08 12:12:59 <jow> dangole: and I assume there is some canonical representation of the ucert (valid blobmsg) which is signed, right?
Aug 08 12:13:05 <KanjiMonster> f00b4r0: and the main issue is that ramdisk kernel generation requires a recompilation of the kernel, which you can't parallelize
Aug 08 12:13:07 <f00b4r0> i don't know how feasible/easy that would be to implement
Aug 08 12:13:23 <dangole> jow: yes, sounds right
Aug 08 12:14:13 <f00b4r0> KanjiMonster: that's another thing I'm not familiar with: why is a recomp needed? I thought we built all kernel binaries for all devices within a target?
Aug 08 12:14:18 <jow> dangole: ok, I think I've understood the trust model now
Aug 08 12:14:33 <jow> dangole: imho we should consider merging usign and ucert into one program
Aug 08 12:14:46 <dangole> jow: it's not exactly a canonical representation because the order of attributes is not sorted, ie. you can generated lots of ucerts with identical attributes but different hashes by changing the order or even adding whitespace to the (base64-encoded, text-representation) of usign signatures
Aug 08 12:15:09 <jow> dangole: this is something we should tackle imho, and require certain proeprties in the blobmsg
Aug 08 12:15:10 <dangole> jow: and right, taken really seriously, we should normalize all that
Aug 08 12:15:17 <KanjiMonster> f00b4r0: that only applies to ramdisk kernels since the ramdisk in built-in in the kernel (so its size has influence on the generated code - e.g. code which needs to know where the kernel ends etc)
Aug 08 12:15:27 <jow> dangole: like no empty fields, strict order, padding considerations etc.
Aug 08 12:15:30 <dangole> jow: ah sure, some attributes are mandatory
Aug 08 12:15:49 <dangole> jow: strict order and padding (and maybe salting) => you are absolutely right
Aug 08 12:16:00 <dangole> jow: that's all missing at this point
Aug 08 12:16:06 <jow> okay
Aug 08 12:16:31 <dangole> jow: if we want that, it'd be nice to add an option to usign to deal with binary formats instead of those base64-encoded text-file stuff
Aug 08 12:17:27 <jow> you mean binary signatures?
Aug 08 12:17:34 <dangole> jow: sorting/ordering is something i was already missing a couple of times when dealing with blobmsg (and, particularly, blobmsg_json)
Aug 08 12:17:40 <dangole> yes, and binary public keys
Aug 08 12:17:40 <KanjiMonster> f00b4r0: ramdisk kernel generation is basically compiling the kernel with kernel options set to "please include a ramdisk image with the contents of the following directories: ..., using foo compression")
Aug 08 12:18:24 <dangole> jow: having some sorting features in libubox would be nice imho but i considered that out-of-scope
Aug 08 12:18:47 <jow> dangole: I'd think that ucert binary encoding is a strict subset of blobmsg
Aug 08 12:19:05 <jow> dangole: like sorting gurantee, no unlimited nesting etc.
Aug 08 12:19:31 <jow> dangole: and therfore the ucert utility should take care of reordering fields if nescessary - and not rely on libubox
Aug 08 12:20:26 <f00b4r0> KanjiMonster: i see
Aug 08 12:20:50 <jow> dangole: so from my pov (without any particular prio) the following points would be worthwhile: merge usign and ucert, canonicalize the ucert encoded format and enforce it
Aug 08 12:21:07 <dangole> jow: hm, that'd also be option (re-ordering and limiting nesting inside ucert), but adds up to be more complexity than all of current ucert together...
Aug 08 12:21:22 <jow> dangole: all new implementations start out lean and clean :D
Aug 08 12:21:55 <jow> will see if I can some time to look into it in detail
Aug 08 12:22:01 <jow> *can find some
Aug 08 12:22:23 <jow> I'd also consider moving fwtool to ubux
Aug 08 12:22:31 <dangole> jow: and the outer part (the blob having only SIGNATURE and PAYLOAD) is processed first, ie. all the attack surface of the inner blobmsg structure is only exposed once the signature was found valid
Aug 08 12:22:40 <jow> having it as single-source-file executable in package/ was somewhat unexpected
Aug 08 12:23:26 <dangole> jow: i agree. i also thought of integrating ucert into usign and making that a multi-call executable...
Aug 08 12:24:32 <jow> my general feeling is that the same ucert attributes should lead to the same binary representation of the cert
Aug 08 12:24:34 <dangole> jow: i got to go for now, contact me via email if you got more questions or findings to share
Aug 08 12:24:53 <jow> anything else likely means exposing attack surface we might not even anticipate yet
Aug 08 12:25:08 <f00b4r0> KanjiMonster: I get the issue. Two comments: 1) I'm still wondering if it's such a good idea to move "essential" drivers into modules (for people not using imagebuilder, they'll end up with jffs2 overhead); and 2) is there a problem having a "larger" initramfs anyway? It's all in RAM after all...
Aug 08 12:25:24 <jow> thanks for your time and explainations
Aug 08 12:26:20 <f00b4r0> by 2) I mean you could shrink the flash image while keeping a large "has it all" initramfs: it's only used for first install
Aug 08 12:29:15 <jwh> hm
Aug 08 12:30:18 <azrdev> jwh: done https://bugs.openwrt.org/index.php?do=details&task_id=1750
Aug 08 12:31:36 <KanjiMonster> f00b4r0: the modules would go into the squashfs, not jffs2, since they are included in the rootfs
Aug 08 12:33:43 <KanjiMonster> f00b4r0: and generating a rootfs with all per-device packages would break once two devices include conflicting packages
Aug 08 12:33:52 <jwh> azarus: itym jow :D
Aug 08 12:34:08 <jwh> oh, he left
Aug 08 12:34:51 <f00b4r0> KanjiMonster: not all per-device packages. All per-device drivers you want to make modules. i.e. keep the initramfs as they are now, and only touch the squashfs
Aug 08 12:35:01 <f00b4r0> I'm not sure I'm making myself clear
Aug 08 12:36:00 <KanjiMonster> f00b4r0: you already now have the issue that swconfig will be missing if it isn't part of the default package set of the target
Aug 08 12:36:53 <f00b4r0> KanjiMonster: ok. Sounds to me like an "easy" way around this is to define different defaults for initramfs and squashfs
Aug 08 12:37:24 <f00b4r0> this way you don't have to deal with per-device rootfs for initramfs generation
Aug 08 12:38:04 <KanjiMonster> f00b4r0: I'd rather fix it properly than some crude workaround
Aug 08 12:38:16 <f00b4r0> it doesn't have to be crude :)
Aug 08 12:38:47 <jwh> f00b4r0: hey while you're there
Aug 08 12:38:49 <f00b4r0> i'm merely thinking that further exhausting buildbot resources to fine tune initramfs material is not a very good tradeoff
Aug 08 12:39:12 <jwh> can you stop per device rootfs causing packages set to n being added as m?
Aug 08 12:39:15 <jwh> :D
Aug 08 12:39:15 <KanjiMonster> well yes, you need to find out what packages/drivers/etc are needed so everthing works OOTB
Aug 08 12:39:41 <f00b4r0> KanjiMonster: we already have that info in the current state of things, haven't we?
Aug 08 12:39:41 <KanjiMonster> also ramdisk images aren't enabled by default exept for a select few targets needing them
Aug 08 12:40:11 <KanjiMonster> f00b4r0: yes, through the DEVICE_PACKAGES
Aug 08 12:40:19 <f00b4r0> *nod*
Aug 08 12:40:47 <KanjiMonster> so you suggest including all DEVICE_PACKAGES in the ramdisk?
Aug 08 12:41:06 <f00b4r0> aye
Aug 08 12:41:24 <KanjiMonster> that will break if two devices include conflicting packages
Aug 08 12:41:35 <f00b4r0> can that happen?
Aug 08 12:42:47 <f00b4r0> it's not immediately obvious to me how kernel/driver-related packages could be conflicting
Aug 08 12:43:31 <KanjiMonster> we also have a few conflicting drivers (e.g. brcm-wl vs b43)
Aug 08 12:44:22 <KanjiMonster> and many devices have limits on how large a (netbooted) kernel may be, so including everything can break that
Aug 08 12:47:18 <f00b4r0> hmm ok. I'm very biased towards mikrotik devices where we pretty much have "one image to rule them all"; which imo is an ideal situation. I don't have a clear idea of how much of a "common base" exists for other devices
Aug 08 12:48:27 <f00b4r0> i'd be inclined to think it would make sense to have a limited number of initramfs shared across devices: saves resources, increases testing coverage, reduce maintenance burden
Aug 08 12:48:32 <f00b4r0> but maybe that's not feasible.
Aug 08 12:55:43 <DonkeyHotei> ucert problem in #openwrt ...
Aug 08 13:12:49 <blogic> dedeckeh: i am assuming 0e84393ee27bc2c209863a0a006dea8b716cfb11 should be cherry-picked into 18.06
Aug 08 13:19:09 <dedeckeh> blogic:this has been cherry-picked into 18.06 (https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=eb568e0abac158016c61fae68154722e9d112dfc)
Aug 08 13:19:45 <blogic> dedeckeh: ok
Aug 08 13:24:43 <jow> I wonder if we should update mwlwifi in 18.06
Aug 08 13:28:03 <blogic> jow: yes, wondering myself
Aug 08 13:28:09 <jow> writing devicd
Aug 08 13:28:12 <jow> *davidc
Aug 08 13:28:13 <blogic> not without proper testing i guess
Aug 08 13:28:18 <blogic> please do so
Aug 08 13:29:43 <blogic> wigyori: 10e393262c
Aug 08 13:29:50 <blogic> wigyori: i'll backport that one to 18.06
Aug 08 13:33:32 <mkresin> m4t: ping
Aug 08 13:33:44 <m4t> mkresin: hey
Aug 08 13:34:14 <mkresin> m4t: query? follow up to our chat about the FIs partition
Aug 08 13:34:50 <m4t> i don't really have anything new. i removed the unused subroutines in platform.sh but that's it
Aug 08 13:35:21 <mkresin> m4t: it's me who has something new
Aug 08 13:35:29 <m4t> oh ;)
Aug 08 13:37:49 <blocktrron> blogic: i'm a bit confused with the at803x DT patch. In patchwork it is listed as accepted but you commented about using at803x_priv and i neither found said commit in the master nor your staging treee. I don't want to be pushy, but i'm currently looking into improving the problems you pointed out. So it would be ok for me to skip this commit (and also the one for sgmii aneg)
Aug 08 13:38:15 <blogic> blocktrron: yes
Aug 08 13:38:18 <blogic> got sidetracked
Aug 08 13:38:28 <blogic> so basically the at803x is the usual QCA clusterf*ck
Aug 08 13:38:42 <blogic> i'll merge the patches as is and then fix that crappy driver upstream properly
Aug 08 13:38:51 <blogic> sorry forgot to update my status mails
Aug 08 13:43:04 <blocktrron> blogic: ok for me, should i submit a v2 for the commit nitpick?
Aug 08 13:43:16 <blogic> no
Aug 08 13:43:22 <blogic> i manually fixed stuff while merging
Aug 08 13:43:34 <blogic> i'll push once i finished the 18.06 backports
Aug 08 13:44:24 <blogic> jow: pushed a pile of 18.06 cherries
Aug 08 13:47:24 <blogic> blocktrron: https://patchwork.ozlabs.org/patch/953887/
Aug 08 13:47:30 <blogic> this one fails to apply, rest is merged
Aug 08 13:48:38 <blocktrron> blogic: thanks. I will look into the one for the Koala
Aug 08 13:49:35 <KanjiMonster> blocktrron: is that at803x patch submitted upstream?
Aug 08 13:49:44 <blogic> KanjiMonster: i'll handle it
Aug 08 13:50:01 <blogic> KanjiMonster: at803x is a mess and uses 3 code patterns plus lots of QCA brainfartery
Aug 08 13:50:20 <blogic> KanjiMonster: and i have local staged support for the at8033 copper/fiber coherency feature
Aug 08 13:50:29 <blogic> so i'll do a prpoer refactoring round next week
Aug 08 13:51:11 <KanjiMonster> blogic: I see. I suggest renaming the option to match the expected "<vendor>,<option>" format before it gets used
Aug 08 13:51:30 <blogic> i'll handle that in one sweep
Aug 08 13:51:45 <blogic> there are some options only on pdata others only on of, others on both
Aug 08 13:52:03 <blogic> some features are probed via the pdata struct others moved to the _priv struct and used from there
Aug 08 13:52:12 <blogic> and so on and so forth
Aug 08 13:58:18 <owrt-1806-builds> build #75 of armvirt/64 is complete: Failure [failed kmods]  Build details are at http://release-builds.openwrt.org/18.06/images/builders/armvirt%2F64/builds/75  blamelist: Christian Schoenebeck <christian.schoenebeck@gmail.com>, Antti Sepp?l? <a.seppala@gmail.com>, John Crispin <john@phrozen.org>, Florian Eckert <fe@dev.tdt.de>, Masashi Honma
Aug 08 13:58:18 <owrt-1806-builds> <masashi.honma@gmail.com>, Koen Vandeputte <koen.vandeputte@ncentric.com>, Lukas Mrtvy <lukas.mrtvy@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Eneas U de Queiroz <cote2004-github@yahoo.com>, Luk?? Mrtv? <lukas.mrtvy@gmail.com>, Zoltan HERPAI <wigyori@uid0.hu>, Pawel Dembicki <paweldembicki@gmail.com>
Aug 08 14:01:49 <owrt-1806-builds> build #74 of brcm47xx/legacy is complete: Failure [failed kmods]  Build details are at http://release-builds.openwrt.org/18.06/images/builders/brcm47xx%2Flegacy/builds/74  blamelist: Christian Schoenebeck <christian.schoenebeck@gmail.com>, Antti Sepp?l? <a.seppala@gmail.com>, John Crispin <john@phrozen.org>, Florian Eckert <fe@dev.tdt.de>, Masashi Honma
Aug 08 14:01:49 <owrt-1806-builds> <masashi.honma@gmail.com>, Koen Vandeputte <koen.vandeputte@ncentric.com>, Lukas Mrtvy <lukas.mrtvy@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Eneas U de Queiroz <cote2004-github@yahoo.com>, Luk?? Mrtv? <lukas.mrtvy@gmail.com>, Zoltan HERPAI <wigyori@uid0.hu>, Pawel Dembicki <paweldembicki@gmail.com>
Aug 08 14:04:52 <jow> blogic: ^^^ kernel: usb: dwc2 DMA alignment fixes
Aug 08 14:05:04 <owrt-1806-builds> build #76 of mxs/generic is complete: Failure [failed kmods]  Build details are at http://release-builds.openwrt.org/18.06/images/builders/mxs%2Fgeneric/builds/76  blamelist: Christian Schoenebeck <christian.schoenebeck@gmail.com>, Antti Sepp?l? <a.seppala@gmail.com>, John Crispin <john@phrozen.org>, Florian Eckert <fe@dev.tdt.de>, Masashi Honma
Aug 08 14:05:04 <owrt-1806-builds> <masashi.honma@gmail.com>, Koen Vandeputte <koen.vandeputte@ncentric.com>, Lukas Mrtvy <lukas.mrtvy@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Eneas U de Queiroz <cote2004-github@yahoo.com>, Luk?? Mrtv? <lukas.mrtvy@gmail.com>, Zoltan HERPAI <wigyori@uid0.hu>, Pawel Dembicki <paweldembicki@gmail.com>
Aug 08 14:13:42 <wigyori> blogic: sure, the intel-microcode will follow in a few hours
Aug 08 14:13:53 <wigyori> (actually that amd64-microcode commit was my wedding day)
Aug 08 14:13:57 <wigyori> ;)
Aug 08 14:15:00 <wigyori> on a slightly related topic
Aug 08 14:15:02 <wigyori> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=5faa9556b1c10a4b21208615bddb7480401fa213
Aug 08 14:15:16 <wigyori> was someone able to dig through this bug ?
Aug 08 14:17:45 <andy2244> jow: ok got rpcbind to build, but having problems starting it: it looks for a /etc/netconfig ?
Aug 08 14:19:43 <KanjiMonster> nice commit message ;P https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=fe90d14880ad80e5cbc0eba036f8f9f83fa77396
Aug 08 14:20:32 <jow> :D
Aug 08 14:20:41 <jow> blame yahoo
Aug 08 14:20:59 <jow> andy2244: hm, /etc/netconfig is something not existing on openwrt
Aug 08 14:21:42 <jow> andy2244: in doubt just ship a dummy file along with the pacakge
Aug 08 14:22:04 <jow> the manpage of netconfig mentions things like "osinet"
Aug 08 14:22:37 <andy2244> can try, can you check if we actually need valid entries for openwrt?
Aug 08 14:24:24 <owrt-1806-builds> build #74 of omap/generic is complete: Failure [failed kmods]  Build details are at http://release-builds.openwrt.org/18.06/images/builders/omap%2Fgeneric/builds/74  blamelist: Christian Schoenebeck <christian.schoenebeck@gmail.com>, Antti Sepp?l? <a.seppala@gmail.com>, John Crispin <john@phrozen.org>, Florian Eckert <fe@dev.tdt.de>, Masashi Honma
Aug 08 14:24:24 <owrt-1806-builds> <masashi.honma@gmail.com>, Koen Vandeputte <koen.vandeputte@ncentric.com>, Lukas Mrtvy <lukas.mrtvy@gmail.com>, Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>, Eneas U de Queiroz <cote2004-github@yahoo.com>, Luk?? Mrtv? <lukas.mrtvy@gmail.com>, Zoltan HERPAI <wigyori@uid0.hu>, Pawel Dembicki <paweldembicki@gmail.com>
Aug 08 14:25:52 <andy2244> jow: ah cool libtirpc actually provides a netconfig, did just not install it.
Aug 08 14:26:22 <andy2244> https://www.irccloud.com/pastebin/VztwAeUm/
Aug 08 14:30:02 <andy2244> ok, works now with the netconfig
Aug 08 14:30:39 <blogic> jow: my bad, let me fix the dwc2 patch
Aug 08 14:34:00 <jow> blogic: the 1st one is already upstream since 4.14.59
Aug 08 14:34:15 <jow> blogic: the 2nd one applies
Aug 08 14:35:07 <jow> blogic: http://luci.subsignal.org/~jow/0001-kernel-rebase-dwc2-DMA-alignment-patches.patch
Aug 08 14:38:23 <karlp> hrm, did people not like the up/down/cross/apply images on the buttons? I see they were just dropped and replaced with colours in "luci-theme-bootstrap: align CSS with markup changes" ?
Aug 08 14:38:38 <karlp> cbi-input-add and so on...
Aug 08 14:43:49 <jow> karlp: I wanted to get rid of them to save space
Aug 08 14:59:32 <jow> karlp: congratulations for uncovering yet another uci bug (and another one related to it)
Aug 08 15:00:05 <jow> ubus call uci add '{ "config": "network", "type": "interface", "name": "foo bar" }' -> { "section": "foo bar" }
Aug 08 15:00:16 <jow> despite carefully checking the return values of uci_lookup_ptr() and uci_set()
Aug 08 15:00:31 <jow> turns out that libuci is unimpressed and simply takes the name, because yolo
Aug 08 15:00:38 <jow> leading to this gem:
Aug 08 15:00:44 <jow> # uci changes
Aug 08 15:00:45 <jow> Segmentation fault
Aug 08 15:00:48 <jow> because:
Aug 08 15:00:59 <jow> # cat /tmp/.uci/network
Aug 08 15:00:59 <jow> network.foo bar='interface'
Aug 08 15:01:03 <jow> head -> desk
Aug 08 15:01:08 <jwh> nice
Aug 08 15:02:05 <jow> need to figure out why the uci cli properly fails with invalid argument
Aug 08 15:02:12 <jow> seems it performs additional checks
Aug 08 15:03:23 <karlp> jow: you're welcome, I guess :)
Aug 08 15:03:36 <karlp> wasn't even doing it deliberately, just fat fingered a dialog :)
Aug 08 15:03:59 <jow> luci defers validation to rpcd which defers it to libuci which ... apparently is a bad idea
Aug 08 15:05:05 <karlp> I've presently just turned on some client validation to reject whitespace. rabbit hole was too deep for me
Aug 08 15:05:23 <jow> the fix will be in rpcd
Aug 08 15:05:31 <jow> and another one in libuci
Aug 08 15:11:26 <jow> I also like how uci_validate_name() is part of uci_internal.h ... gnarf
Aug 08 15:13:03 <andy2244> jow: i can't use procd if the daemon forks itself right?
Aug 08 15:13:14 <jow> andy2244: yes
Aug 08 15:14:26 <andy2244> guess i have to use those service_start/stop helpers than
Aug 08 15:14:39 <jow> no nofork for rpcbind ?
Aug 08 15:15:07 <andy2244> https://linux.die.net/man/8/rpcbind
Aug 08 15:15:16 <andy2244> not that i can see
Aug 08 15:15:26 <andy2244> except for running it in debug mode?
Aug 08 15:15:50 <jow> would be an idea
Aug 08 15:16:17 <karlp> rpcbind -f?
Aug 08 15:16:19 <jow> unless you specify procd_set_param stderr/stdout 1, the stdio is thrown away anyway
Aug 08 15:16:30 * karlp wonders where my rpcbind comes from....
Aug 08 15:16:36 <andy2244> i can try thanks
Aug 08 15:18:13 <karlp> http://manpages.ubuntu.com/manpages/xenial/man8/rpcbind.8.html (and fedora) both hve the -f option...
Aug 08 15:19:14 <andy2244> lol nice tip, was going by the manual page, it actually has (rpcbind [-adhilswf])
Aug 08 15:23:21 <andy2244> worked yay
Aug 08 15:24:09 * karlp cheers
Aug 08 15:24:13 <karlp> gotta make up for filing bugs
Aug 08 15:56:40 <Robby> is there a known problem (I can't find anything though) where if you compile your own image from the master and/or openwrt-18.06 branch that IPv4 networking seems to be broken? I cannot reach the router at 192.168.1.1 where with openwrt-provided builds it works just fine
Aug 08 15:56:57 <Robby> I can however reach the router and login with ssh via its linklocal IPv6 address
Aug 08 15:57:19 <Robby> the device is a Linksys EA3500 (kirkwood audi)
Aug 08 15:58:07 <Robby> when I login via IPv6 I can see the interfaces though, and I see one that is configured with 192.168.1.1 so it should actually work
Aug 08 15:58:16 <Robby> tried flushing iptables rules
Aug 08 15:58:30 <Robby> checked routing table, nothing really stands out
Aug 08 16:02:19 <jow> karlp: thats a very large can of worms you've opened there
Aug 08 16:02:25 <jow> will not manage to fix it today
Aug 08 16:04:24 <karlp> oh dear :)
Aug 08 16:04:44 <karlp> are you going to track it, or should I refile soemthign on flyrspray?
Aug 08 16:04:54 <jow> its okay, will take care of it
Aug 08 16:05:05 <karlp> no rush on my part, just something I noticed.
Aug 08 16:05:16 <jow> libuci api is totally broken and insecure
Aug 08 16:05:28 <jow> it does not perform any checking on the passed parameters
Aug 08 16:05:49 <karlp> yeah, developing an application with libuci was an adventure in segfault to discover what was required...
Aug 08 16:06:18 <jow> and not when using libuci primitives directly. The only thing that performs something remotely resembling input validation is uci_parse_ptr() which we do not use
Aug 08 16:10:13 <andy2244> yay nfs-kernel-server compiles with ipv6 support and under Alpine/musl using libtirpc... 2 converted 7 to-go
Aug 08 16:34:36 <andy2244> jow: so in cases like twisted "PKG_BUILD_DEPENDS:=USE_MUSL:librpc" i should just use libtirpc no matter the clib? So remove such special handling?
Aug 08 16:53:47 <jow> andy2244: yes
Aug 08 17:18:13 <DonkeyHotei> Robby: that is not a known problem in general. is the interface you see configured with 192.168.1.1 the same interface configured with the link-local ipv6 address you used to get in?
Aug 08 17:23:37 <Hauke> jow: there are some security problems fixed in mbedtls, see 5b614e33476269ccb7b526e9e7e5f67eacdb9dc1 in master
Aug 08 17:23:42 <Hauke> should we backport this to 18.06?
Aug 08 17:23:50 <Hauke> we should probably deactivate most of the new stuff
Aug 08 17:27:21 <jow> Hauke: yes
Aug 08 17:31:18 <Hauke> jow: ok I will take care after dinner
Aug 08 17:33:44 <jwh> hmmm
Aug 08 17:34:06 <jwh> I can't see any option to universally set -O2 rather than -Os, is that right?
Aug 08 17:34:28 <DonkeyHotei> for the entire build, you mean?
Aug 08 17:34:38 <jwh> yeah, well at least as a default
Aug 08 17:34:57 <jwh> like umm, CONFIG_TARGET_OPTIMIZATION for example
Aug 08 17:35:12 <DonkeyHotei> CONFIG_TARGET_OPTIMIZATION
Aug 08 17:35:23 <jwh> it's hard to overwrite that as its target dependant (mtune etc)
Aug 08 17:35:46 <DonkeyHotei> oh, you want to change the default for all targets?
Aug 08 17:36:11 <jwh> I can just change the *.mk stuff, but trying an experiment to apply all my local changes without touching the tree
Aug 08 17:36:14 <jwh> :D
Aug 08 17:36:36 <jwh> doesn't look too hard to make it an option actually
Aug 08 17:36:41 <jwh> thoughts?
Aug 08 17:37:05 <DonkeyHotei> it's not really needed
Aug 08 17:37:39 <jwh> kernel is already taken care of as the speed/size option can already be set
Aug 08 18:03:35 <xn0r> why doesn't this produce any output: a="$(rmmod asdf 2>&1)"; echo "$a"
Aug 08 18:04:15 <xn0r> is busybox that broken?
Aug 08 18:07:34 <jow> xn0r: no, its openwrt rmmod which behaves in a nonstandard way
Aug 08 18:07:44 <jow> when not attached to a tty, it'll send the error to syslog instead
Aug 08 18:10:13 <xn0r> jow: any way around this?
Aug 08 18:10:59 <nyt> so compiling with signed packages checked now causes base-files to fail to build
Aug 08 18:14:54 <jow> nyt: fail how?
Aug 08 18:15:57 <nyt> tries to sign with usign/ucert
Aug 08 18:16:10 <nyt> doesnt select the packages
Aug 08 18:16:12 <nyt> but even after selecting them
Aug 08 18:16:15 <nyt> it still fails for some reason
Aug 08 18:16:30 <nyt> there's not much output indicating failure reason
Aug 08 18:17:17 <nyt> i'll reselect signed pcakages and try again
Aug 08 18:18:11 <nyt> so it selects usign, but not ucert
Aug 08 18:18:33 <nyt> i think usign tries to call ucert, but without a specific path, then fails
Aug 08 18:18:44 <nyt> it was real late when i was looking at it last night
Aug 08 18:19:10 * jwh ponders
Aug 08 18:19:40 <jwh> bake ssh keys into images and check running versions etc like that, or cron?
Aug 08 18:21:14 <nyt> trying again with ucert-full selected
Aug 08 18:22:05 <nyt> go figure now it builds
Aug 08 18:22:15 <nyt> with just ucert selected, it didnt seem to
Aug 08 18:22:25 <nyt> gonna remove this ucert key and try again that way
Aug 08 18:22:43 <nyt> but i think a dependency needs to be added for ucert if selecting signed packages
Aug 08 18:22:47 <nyt> or ucert-full
Aug 08 18:29:47 <nyt> https://github.com/openwrt/openwrt/pull/1256 was also an annoying one
Aug 08 18:30:46 <nyt> the speed at which the make flooded my console was amazing
Aug 08 18:32:12 <jow> xn0r: can only think of something lame like   a="$(rmmod foo >/dev/console 2>/tmp/err.$$; cat /tmp/err.$$; rm /tmp/err.$$)"; echo "$a"
Aug 08 18:33:42 <nyt> hmf, now it's compiling even with the base ucert selected... losing my mind
Aug 08 18:36:22 <luaraneda> jwh: Did you solve the m4 -- glibc-2.28 compile problem on arch? I'm applying a patch that I found on a fedora repository (m4-1.4.18-glibc-change-work-around.patch)
Aug 08 18:36:24 <andy2244> nyt: not just you, also did just run into the problem with certs selected
Aug 08 18:36:59 <jwh> luaraneda: nope, rolled back to 2.27-3 for now
Aug 08 18:37:12 <jwh> no time so I've left it to the appropriate people at arch to fix
Aug 08 18:38:26 <luaraneda> great, now I'm having the same problem with findutils too...
Aug 08 18:39:15 <jwh> fixing it is a total time vacuum, so I'm just not going to bother
Aug 08 18:39:26 <nyt> ah still had the bins in staging dir after unselecting
Aug 08 18:39:28 <jwh> 2.27-3 doesn't cause any problems
Aug 08 18:39:28 <jow> xn0r: ah, even simpler: a="$(3>&1 1>&2 2>&3 rmmod xt_time)"; echo "[$a]"
Aug 08 18:39:30 <nyt> making clean thrn trying again
Aug 08 18:39:40 <jow> well, "simpler"
Aug 08 18:40:40 <luaraneda> jwh: Thanks! I'll rollback to 2.27-3 as well
Aug 08 18:41:55 <jwh> at least, not obvious problems - my builders are only lxc containers
Aug 08 18:48:24 <nyt> mucking with the ucert stuff now after a dirclean... will see which fails and which doesnt
Aug 08 18:48:32 <nyt> but pretty sure need ucert-full selected to build base-files
Aug 08 18:51:13 <nyt> annoying since mmc-utils and cshark don't compile with gcc 8
Aug 08 18:51:24 <nyt> i need to fix and submit pull reqs, but im just manually patching after each dir clean
Aug 08 19:01:32 <xn0r> jow: thanks
Aug 08 19:01:45 <xn0r> jow: nice workaround with a new fd ;)
Aug 08 19:15:11 <jwh> mmmm
Aug 08 19:15:33 <jwh> is there any ds-lite stuff in either the kernel or packaged in openwrt?
Aug 08 19:19:45 <SwedeMike> jwh: openwrt supports ds-lite
Aug 08 19:20:14 <SwedeMike> jwh: you just have to opkg install it
Aug 08 19:20:42 <jwh> SwedeMike: mmm, CPE only?
Aug 08 19:20:50 <jwh> or is there headend stuff in packages too?
Aug 08 19:20:53 <Borromini> did someone hack blogic's mail account?
Aug 08 19:20:57 <SwedeMike> jwh: CPE only afaik
Aug 08 19:21:04 <jwh> mmm, guess thats ok
Aug 08 19:21:09 <jwh> I can figure something out for the headend
Aug 08 19:34:15 <nyt>     while (isspace(line[0]))
Aug 08 19:34:15 <nyt>         strncpy(&line[0], &line[1], sizeof(line));
Aug 08 19:34:17 <nyt> wow mmc-utils
Aug 08 19:34:17 <nyt> really :/
Aug 08 19:59:47 <nyt> and of course it's on git.kernel.org instead og github so can't easily submit a pull req with the fix
Aug 08 21:00:44 <Hauke> wigyori: wil you also update the intel microcode?
Aug 08 21:07:43 <wigyori> Hauke: yes
Aug 08 21:08:18 <DonkeyHotei> does amd even have a new update? i thought it was only intel
Aug 08 21:14:30 <wigyori> amd has the latest as 20180524
Aug 08 21:14:39 <wigyori> intel has 201807something
Aug 08 21:30:34 <Hauke> wigyori: thanks
Aug 08 21:46:26 <Zero_Chaos> http://dpaste.com/0GBW0FF is preventing my builds, ucert failure
Aug 08 21:48:10 <nyt> in contact with mmc-utils devs getting it fixed
Aug 08 21:48:23 <nyt> now the mess that is cshark :/
Aug 08 21:50:39 <Zero_Chaos> nyt: is there a way to get past that error? skip it?
Aug 08 21:50:51 <nyt> select ucert-full
Aug 08 21:51:34 <Zero_Chaos> <3
Aug 08 21:52:19 <Zero_Chaos> I don't actually have either ucert selected, hope this fixes it
Aug 08 21:52:36 <nyt> you have signed packages selected
Aug 08 21:52:46 <nyt> so its trying to sign base-files with ucert
Aug 08 21:52:47 <nyt> but theres a bug
Aug 08 21:52:57 <nyt> which selects usign but not ucert
Aug 08 21:53:10 <nyt> ill submit a pull req to fix it in a few but working on a couple other packages first
Aug 08 21:53:32 <Zero_Chaos> nyt: you rock, thanks for the help
Aug 08 21:53:39 <nyt> np
Aug 08 22:12:22 <nyt> i think openwrt-keyring also might not have been selected earlier, i can't even trigger the build error now with ucert and ucert-full unchecked
Aug 08 22:15:24 <huaracheguarache> blogic: just wanted to say that I've been running your mac80211 build on my r7800 a couple of days and have seen no issues. however, the firmwares in that repo seem to be somewhat old and kalle updates it like once a year.
Aug 08 22:17:17 <huaracheguarache> blogic: for the qca9984 that is
Aug 08 22:45:54 <andy2244> Whats going on with the "mc" package, there is a CONFIG_MC_VFS option, but no VFS is ever installed ?
Aug 08 22:46:44 <karlp> if you're running form a ramdisk image, there's no functional difference vs running from flash is there?
Aug 08 22:46:50 <karlp> I mean, you can't save config, sure, but other than that?
Aug 08 23:01:20 <nyt> pull reqs for cshark submitted, waiting for mmc-utils devs to commit the patch i sent them also
Aug 08 23:01:25 <nyt> now finally testing this ucert/usign fun
Aug 08 23:03:37 <nyt> looks like whatever changed earlier is working now
Aug 08 23:03:40 <nyt> even without ucert selected
Aug 08 23:29:14 <xn0r> why is nat reflection required to access an internal service with an external ip?
Aug 08 23:30:09 <jwh> umm, because the forwarding rule applies to the incoming interface so it doesn't match otherwise?
Aug 08 23:30:36 <jwh> or zone, in this case I guess
Aug 08 23:38:38 <xn0r> jwh: so a packet comes in through br-lan (let's say eth0.2 physical) with destination address <WAN IP> (which eth0.1 has), what happens with the packet?
Aug 08 23:40:36 <jwh> haven't checked how fw3 does it, but usually the rules are just duplicatedd on the inside interface too
Aug 08 23:41:04 <jwh> so I'd imagine it does similar
Aug 08 23:41:22 <xn0r> yes I understand what the rules look like but I'm wondering what happens with the packets
Aug 08 23:41:35 <xn0r> when they go through netfilter
Aug 08 23:41:46 <jwh> the same as happens if they came in on the outside interface...
Aug 08 23:44:18 <xn0r> ok so they appear in the input chain on eth0.1, destination IP <WAN IP> but source IP <IP of the internal host>?
Aug 08 23:44:47 <jwh> likely so, yes, but destination interface not IP
Aug 08 23:46:30 <xn0r> in iptables terms the in-interface would be eth0.1, no?
Aug 08 23:47:53 <jwh> probably in the chain
Aug 08 23:48:01 <jwh> but, just a thought
Aug 08 23:48:07 <jwh> you could check the rules it installs ;)
Aug 08 23:49:08 <jwh> I haven't investigated how fw3 does it because I don't do horriblenes like nat loopback :D
Aug 08 23:56:26 <xn0r> nothing to do with fw2, just netfilter. I checked, it comes in through br-lan and goes through mangle PREROUTING, nat PREROUTING, filter INPUT (still in through br-lan, still WAN IP as dest IP)
Aug 08 23:58:03 <jwh> so... whats this got to do with openwrt developmnet? :D
Aug 08 23:58:11 <jwh> development*
Aug 08 23:58:46 <xn0r> jwh: so if you use DNAT it doesn't work if you access <WAN IP:DNATed port> from within your network
Aug 08 23:59:25 <xn0r> jwh: I wondered about the firewall rules that get created automatically (on openwrt)
Aug 08 23:59:42 <jwh> umm, you appear to be asking conflicting questions
Aug 09 00:00:00 <jwh> "nothing to do with fw3 (which is what openwrt does), but I was wondering what fw3 does"
Aug 09 00:00:03 <jwh> :D
Aug 09 00:00:12 <xn0r> I don't see the question
Aug 09 00:00:32 <xn0r> my earlier question was about how packets traverse netfiler, yeah
Aug 09 00:00:42 <xn0r> to understand the need for the rules that fw3 creates
Aug 09 00:01:01 <jwh> fw3 doesn't just add simple rules, it has chains (and some other bits)
Aug 09 00:01:46 <jwh> but like I said, dump the rules to see how it crafts the ruleset
Aug 09 00:06:10 <xn0r> well effectively it is a simple DNAT & SNAT rule plus the DNAT rule for NAT "reflection" or "loopback" or whatever other name it's called
Aug 09 00:07:45 <xn0r> (the SNAT rule is part of the reflection)
Aug 09 00:09:10 <jwh> pretty standard
Aug 09 01:47:09 <OutBackDingo_> /home/dingo/archer-c7-v4/staging_dir/host/bin/ucert: error while loading shared libraries: libjson-c.so.2: cannot open shared object file: No such file or directory
Aug 09 01:47:09 <OutBackDingo_> Makefile:204: recipe for target '/home/dingo/archer-c7-v4/build_dir/target-mips_24kc_musl/linux-ar71xx_generic/base-files/.configured_f8a7ef425d28326c27dae6762b223070_8e081b74cf069e1e6800a5bbcbb282f0' failed
Aug 09 01:47:16 <OutBackDingo_> hard to imagine that this is still broken
Aug 09 01:50:05 <jwh> since when?
Aug 09 01:55:52 <OutBackDingo_> jwh: been 24 hours now
Aug 09 02:16:04 <jwh> WFM
Aug 09 02:16:30 <nyt> i had same issue, but latest master didn't have it
Aug 09 02:16:40 <jwh> [jwh@aurbuilder nspv2]$ ldd staging_dir/host/bin/ucert |grep json
Aug 09 02:16:40 <jwh>         libblobmsg_json.so => /home/jwh/nspv2/staging_dir/host/lib/libblobmsg_json.so (0x00007f58904db000)
Aug 09 02:16:44 <jwh>         libjson-c.so.2 => /home/jwh/nspv2/staging_dir/host/lib/libjson-c.so.2 (0x00007f58904ce000)
Aug 09 02:31:55 * swalker commented out the brokenness for now
Aug 09 02:33:05 <OutBackDingo_> jwh: seems im noot the onl;y one having the issue either, as it still exists ion a fresh check out
Aug 09 02:33:53 <jwh> what does the whole log for ucert say?
Aug 09 02:34:04 <jwh> coz sounds like broken environment
Aug 09 02:34:39 <luaraneda> jwh: Could you test this series on glibc 2.27-3? please, and if you update to 2.28 and test it again it would be great
Aug 09 02:34:40 <luaraneda> http://lists.infradead.org/pipermail/openwrt-devel/2018-August/013524.html
Aug 09 02:34:43 <jwh> do you need ucert?
Aug 09 02:35:26 <OutBackDingo_> jwh: broken environment ?
Aug 09 02:35:48 <OutBackDingo_> everything built fine for days until last night
Aug 09 02:36:23 <jwh> luaraneda: gimme fetchable patch urls :D
Aug 09 02:36:45 <OutBackDingo_> even in #openwrt
Aug 09 02:36:49 <OutBackDingo_> [01:12:09] <Guest55435> bug: openwrt/staging_dir/host/bin/ucert: error while loading shared libraries: libjson-c.so.2: cannot open shared object file: No such file or directory
Aug 09 02:36:50 <OutBackDingo_> [01:12:22] <Guest55435> its a fresh git clone
Aug 09 02:37:57 <jwh> shouldn't really have to ask, but bother to post useful info (os, distribution, env, host package versions etc)
Aug 09 02:37:59 <luaraneda> jwh: github branch: https://github.com/luaraneda/openwrt/tree/tools-fix-compilation-with-glibc-2.28-v1
Aug 09 02:38:04 <jwh> untoreh: ta
Aug 09 02:38:20 <jwh> uh, luaraneda even
Aug 09 02:39:19 <luaraneda> jwh: Or if you prefer the individual patches:
Aug 09 02:39:20 <luaraneda> https://github.com/luaraneda/openwrt/commit/d0475764d8038f3741b54cf576fa90b7b4775429.patch
Aug 09 02:39:20 <luaraneda> https://github.com/luaraneda/openwrt/commit/c43ce286e83fed2fb80dd7f2791cc3668f0c0079.patch
Aug 09 02:40:12 <jwh> yeah
Aug 09 02:42:11 <jwh> doing build runs
Aug 09 02:43:28 <jwh> its kinda ridiculous that tools are bundling gnulib, but heh
Aug 09 02:43:54 <jwh> I wonder if m4 has a configure option similar to make
Aug 09 02:44:17 <jwh> it can use a gnulib checkout rather than any bundled one
Aug 09 02:47:23 <jwh> luaraneda: looks good with 2.27... trying 2.28 now
Aug 09 02:48:09 <agb> /1/44
Aug 09 02:54:05 <luaraneda> jwh: Only the tarball has gnulib bundled, which is included when executing the bootstrap script. If you clone the repo, gnulib is not bundled (yet)
Aug 09 02:55:08 <jwh> aah
**** ENDING LOGGING AT Thu Aug 09 02:59:59 2018