**** BEGIN LOGGING AT Tue Jan 26 02:59:57 2021
Jan 26 04:29:52 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 98.3% packages reproducible in our current test framework.)
Jan 26 04:40:49 <aparcar[m]> mangix: I think you mdns patch is merged tomorrow
Jan 26 06:50:24 <mangix> aparcar[m]: ok
Jan 26 08:09:46 <aparcar[m]> nbd: ping
Jan 26 08:21:48 <nbd> aparcar[m]: pong
Jan 26 08:23:34 <aparcar[m]> nbd: mwarning1 and me trying to add initramfs files to the profiles.json file. The current state is here: https://github.com/mwarning/openwrt/commit/053a726660deb38c5d6da57bf75607fc3cf70c6d I don't understand how the device variables are somewhat delayed exported. Would it be possible to make variables like DEFAULT_PACKAGES etc directly accessible?
Jan 26 08:26:44 <nbd> i will look into it
Jan 26 08:26:45 <nbd> brb
Jan 26 08:44:32 <grift> ttyd with selinux sandbox works pretty nice out of the box (its not targeted by default): https://www.youtube.com/watch?v=iRHGtnPKBtA
Jan 26 08:52:06 <nbd> aparcar[m]: i don't think DEFAULT_PACKAGES is easily accessible from that context. you can work around it by getting the package list from opkg
Jan 26 08:52:35 <aparcar[m]> isn't it possible to just export the profile vars?
Jan 26 08:52:42 <aparcar[m]> because we have the profile name anyway?
Jan 26 08:53:39 <nbd> the initramfs image doesn't have the per-device packages though
Jan 26 08:53:48 <nbd> so not sure why you would want to add them to the initramfs json
Jan 26 08:58:34 <aparcar[m]> brb sorry
Jan 26 09:32:40 <aparcar[m]> nbd: so we have the profile_id available. isn't that enough to export the specific variables?
Jan 26 09:33:13 <aparcar[m]> https://github.com/mwarning/openwrt/blob/053a726660deb38c5d6da57bf75607fc3cf70c6d/include/image.mk#L555
Jan 26 09:33:26 <aparcar[m]> isn't this line used to export the variables?
Jan 26 10:05:10 <aparcar[m]> nbd: I'm off for today, please ping me if you have an idea how to make these variables available. the other option would be to do quite some python changes to stuff things together with seem like a terrible workaround
Jan 26 10:09:25 <aparcar[m]> mangix: which messenger are you using now? thinking about replacing the matrix client...
Jan 26 10:10:28 <olmari> aparcar: plenty alternative matrix-clients out there ;)
Jan 26 10:46:57 <mangix> aparcar[m]: IRC? I use a quassel docker container on my VM.
Jan 26 10:47:57 <mangix> I used to use irssi with screen.
Jan 26 11:00:22 <Hauke> What do you think about the symlink added here: https://patchwork.ozlabs.org/project/openwrt/patch/20201215093531.1763475-4-a.heider@gmail.com/ ?
Jan 26 11:00:46 <Hauke> symlink to ../ltq-vdsl-app/src in package/network/config/ltq-adsl-app/src
Jan 26 11:20:25 <mangix> What was that?
Jan 26 14:03:08 <barhom> Are there any good way to remove a firewall rule by name? I feel like removing a firewall rule by id (i.e. uci delete firewall.@rule[X]) is prone to racing conditions errors
Jan 26 14:18:17 <hurricos> barhom: you can name your rules. I don't know if uci takes them up, but ...
Jan 26 14:18:38 <barhom> Yeh, I can name them. But I can't delete a rule by name
Jan 26 14:18:48 <hurricos> Yes you can!
Jan 26 14:19:29 <hurricos> you can uci show them by name. I don't mean the e.g. firewall.@rule[x].name.
Jan 26 14:20:30 <barhom> Maybe, I haven't found the syntax if so
Jan 26 14:20:37 <hurricos> I mean the firewall.$name. you can name them by saying e.g. config rule $name\n\t${etc}
Jan 26 14:21:14 <barhom> Here is an example, firewall.@rule[20].name='Passthrough-port-995'
Jan 26 14:21:16 <hurricos> then you get an uci node like firewall.$name=rule, firewall.$name.name='whatever option you set for name'
Jan 26 14:21:39 <barhom> I can't access that rule with "uci show firewall.Passthrough-port-995"
Jan 26 14:23:01 <hurricos> no, not the firewall.$name.name -- you can directly name nodes.
Jan 26 14:23:24 <barhom> ah yes
Jan 26 14:23:53 <hurricos> now how you do that with uci I don't know off the top of my head
Jan 26 14:24:30 <barhom> ok, I understand what you mean. I'll try it
Jan 26 14:24:39 <barhom> thanks
Jan 26 14:25:06 <hurricos> It also won't cause race conditions, since the order doesn't change -- just confirmed that :)
Jan 26 14:25:42 <hurricos> (if you name them like that) - that is, a node doesn't stop counting for the index just because you name it.
Jan 26 14:29:40 <hurricos> OK, found it. The syntax (from uci help) is:
Jan 26 14:29:43 <hurricos> rename     <config>.<section>[.<option>]=<name>
Jan 26 16:21:20 <reiffert> Hi. My openwrt stable keeps dying. According to someone here these issues are solved with trunk. How can I compile trunk and include luci, nmap and tcpdump as packages? Last time I tried I couldn't install packages after compiling.
Jan 26 16:25:49 <grift> in make menuconfig also tick "[*] Build the OpenWrt Image Builder"
Jan 26 16:26:27 <grift> when its done compiling, extract the image builder .xx and use that to create an fireware image:
Jan 26 16:27:02 <grift> mv ~/openwrt/bin/targets/*/*/openwrt-imagebuilder*.tar.xz ~
Jan 26 16:27:09 <grift> tar xf openwrt-imagebuilder*.tar.xz
Jan 26 16:27:18 <grift> cd openwrt-imagebuilder*-x86_64
Jan 26 16:27:29 <grift> make image
Jan 26 16:28:05 <grift> ls bin/targets/*/*
Jan 26 16:28:26 <grift> use the sysupgrade image from there and you should be able to use opkg then
Jan 26 16:32:37 <reiffert> WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
Jan 26 16:32:41 <reiffert> how to cope with this?
Jan 26 16:34:18 <grift> just ignore it i guess
Jan 26 16:37:57 <stintel> grift: you've enabled BUSYBOX_CONFIG_PAM and need to "install" the package from the packages feed; ./scripts/feeds install libpam
Jan 26 16:38:05 <stintel> ehr, reiffert ^
Jan 26 16:41:28 <reiffert> WARNING: No feed for package 'libpam' found
Jan 26 16:43:27 <grift> i just ignore that message, not easily intimidated by warnings
Jan 26 16:43:28 <reiffert> succeeded
Jan 26 17:35:14 <reiffert> sysupgrade openwrt-ramips-mt7621-mikrotik_routerboard-750gr3-squashfs-sysupgrade.bin
Jan 26 17:35:17 <reiffert> Device mikrotik,rb750gr3 not supported by this image
Jan 26 17:35:20 <reiffert> Supported devices: mikrotik,routerboard-750gr3 mikrotik,rb750gr3 - Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA
Jan 26 17:36:17 <reiffert> mhm any suggestions? install trunk from snapshots and then install this here?
Jan 26 17:38:10 <stintel> reiffert: sysupgrade -n (this will cause you to lose all configuration though)
Jan 26 17:38:16 <grift> not sure , but i would probably revert to stock and then do a factory install
Jan 26 17:38:41 <reiffert> stintel: can I push the config backup later on?
Jan 26 17:38:43 <stintel> reiffert: the other option is rm /etc/config/network; sysupgrade -f - you will then only lose network config, which should be relatively easy to reconstruct
Jan 26 17:39:00 <stintel> reiffert: the problem is /etc/config/network - your backup will not be compatible due to the move to DSA
Jan 26 17:39:53 <reiffert> I have a couple of vlans .. guess I need to figure a way to create them with CLI / uci?
Jan 26 17:42:51 <reiffert> stintel: after deleting etc/config/network .. will the remaining config survive?
Jan 26 17:44:55 <stintel> reiffert: it should
Jan 26 17:45:12 <stintel> did it like that on my DIR-860L not so long ago
Jan 26 17:54:09 <reiffert> I'll try tomorrow, dont have a laptop with me for rescue
Jan 26 17:55:52 <reiffert> do we know which packets make the switch or ip-stack die?
Jan 26 18:17:02 <aparcar[m]> mangix: https://git.openwrt.org/?p=project/mdnsd.git;a=summary
Jan 26 18:52:30 <blogic> aparcar[m]: ;)
Jan 26 19:07:54 <Borromini> svanheule[m]: sorry for the clusterfuck :P doesn't help our main tester atm is posting a single message a day. i ordered my isolated uart adapter off tindie. will test once i have it.
Jan 26 19:28:28 <Borromini> guys can i unpack a sysupgrade image? any instructions for that somewhere?
Jan 26 19:28:51 <Borromini> i wanna make sure packages do end up inside and make V=s in the buildroot doesn't seem to show that
Jan 26 19:29:03 <ldir-> What fun! https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit
Jan 26 19:30:21 * ynezz graps popcorn and waits for Rust hordes
Jan 26 19:30:44 <ynezz> s/graps/grabs/
Jan 26 19:31:29 <Borromini> is that responsibile disclosure, 13 days?
Jan 26 19:33:23 <ldir-> Mac OS 11 Big Sur is 1.8.31 - My latest firmware Qnap boxen are 1.8.16 - I mean fucking hell!
Jan 26 19:34:28 <Borromini> debian testing is 1.9.5p1
Jan 26 19:37:03 <aparcar[m]> ynezz: oh so I have root hen on the openrwt servers ;)
Jan 26 19:37:15 <Borromini> finally ;)
Jan 26 19:37:42 <svanheule[m]> Borromini: no worries, let me know if you find anything that doesn't work after you get serial on your device :-)
Jan 26 19:38:26 <svanheule[m]> Borromini: the people porting the Archer A6/C6U are working hard on nailing down the switch initialisation of the SoC, so that problem might get solved by itself :D
Jan 26 19:38:43 <Borromini> svanheule[m]: cool, haven't kept an eye on it
Jan 26 19:38:48 <Borromini> but good to know :)
Jan 26 19:39:59 <Borromini> can someone tell me (and from what point on) i should extract the squashfs part from the image? binwalk gives this: https://paste.debian.net/1182855/
Jan 26 19:40:34 <Borromini> i reckon i only need the squashfs part to see the actual upgrade image contents, but i don't know how to read the numbers that binwalk prints
Jan 26 19:40:47 <rsalvaterra> ldir-: OMG, that's a nasty one.
Jan 26 19:41:07 <svanheule[m]> Borromini: binwalk -e will just try to extract everything it finds, so no need to extract the squashfs first
Jan 26 19:41:24 <Borromini> svanheule[m]: oh! thanks let me try that.
Jan 26 19:42:23 <Borromini> sweet, obviously didn't know about that
Jan 26 19:45:40 <rsalvaterra> ldir-: How wonderful, both Debian Sid and Ubuntu 20.04 are still vulnerable.
Jan 26 19:46:21 <rsalvaterra> *20.10
Jan 26 19:46:49 <Borromini> rsalvaterra: yeah nothing newer than 1.9.5p1. hence my question about how responsible that qualys disclosure is. I have no idea about 'lead time' on such far-reaching exploits
Jan 26 19:47:15 <Hauke> rsalvaterra: my debian stable just got a new sudo version
Jan 26 19:47:37 <ldir-> Surely this is much worse than the dnsmasq vuln
Jan 26 19:48:23 <Hauke> ldir-: yes, we were informed in Octiber about the dnsmasq problem
Jan 26 19:48:25 <ldir-> but having said that, I'd rather it be known and closed as a low hanging fruit vector for a state actor.
Jan 26 19:48:30 <Hauke> this sudo problem was much shorter
Jan 26 19:48:42 <Borromini> Hauke: i'm on testing and mine is 1.9.5p1-1
Jan 26 19:48:48 <Hauke> ldir-: you still need normal user access to the system
Jan 26 19:48:51 <rsalvaterra> It's a local root exploit. It could only be worse if it were remote.
Jan 26 19:49:03 <Borromini> oh local. move along :P
Jan 26 19:49:21 <Borromini> i haven't told my wife about sudo yet so nothing to worry about ;)
Jan 26 19:49:39 <rsalvaterra> Borromini: Any incidents reported? :P
Jan 26 19:49:48 <Borromini> :P
Jan 26 19:50:27 <rsalvaterra> Obligatory xkcd… https://xkcd.com/838/
Jan 26 19:50:42 <ldir-> https://xkcd.com/149/
Jan 26 19:51:14 <ldir-> ^^^ that's what happens to Borromini when wife discovers sudo! :-D
Jan 26 19:51:25 <rsalvaterra> Haha!
Jan 26 19:53:04 <Borromini> :D
Jan 26 19:53:09 <grift> debian has selinux, if that was enabled and the policy was leveraged properly then normal users would not be able to exploit this because it requires access to cap setuid, users that would have access would be able to gain root but would be stuck in there selinux domain probably and so damage would be contained (disclaimer i havent tried it so i might be wrong)
Jan 26 19:53:11 <ldir-> Hauke: combine that with a command injection vuln... and inject a sudo
Jan 26 19:53:20 <grift> in openwrt this is exploitable even with selinux
Jan 26 19:53:36 <grift> but openwrt is not really a multi -user system
Jan 26 19:54:08 <ldir-> grift: indeed, I log in as root to it all the time!
Jan 26 19:54:27 <Borromini> i get why people are confused when you tell them 'do not compile as root!'
Jan 26 19:54:36 <Borromini> after all you have to log in as root on what you compile :P
Jan 26 19:54:46 * Borromini hides in the silly jokes closet
Jan 26 19:54:55 * ldir- locks the door
Jan 26 19:55:01 <Borromini> :(
Jan 26 19:55:11 <Borromini> at least make sure there's some air coming in :P
Jan 26 19:55:28 <ldir-> brb
Jan 26 20:01:02 * ldir- cuts round hole - tries to fit square lithium hydroxide canister through it - dammit!
Jan 26 20:01:33 <Borromini> you're dangerous!
Jan 26 20:02:34 <ldir-> possibly - I think mostly just silly
Jan 26 20:02:48 <Borromini> :P
Jan 26 20:05:31 <ldir-> Borromini: but you get the Apollo 13 reference right?
Jan 26 20:06:07 <Borromini> no, sorry
Jan 26 20:06:16 <Borromini> that went right over my head
Jan 26 20:06:19 * Borromini googles
Jan 26 20:07:58 <ldir-> Borromini: hopefully https://www.bbc.co.uk/programmes/w27vq7zw works
Jan 26 20:08:48 <Borromini> yeah found it
Jan 26 20:10:09 <rsalvaterra> ldir-: "I don't care what anything was designed to do. I care about what it can do." ;)
Jan 26 20:11:03 <rsalvaterra> OpenWrt spirit right there.
Jan 26 20:11:12 <ldir-> rsalvaterra: I'm trying to make sure Borromini has breathable air after I locked him in his silly jokes closet :-)
Jan 26 20:12:39 <rsalvaterra> Oh, dnsmasq 2.84 final!
Jan 26 20:13:17 <Borromini> hehe
Jan 26 20:14:19 <ldir-> ahhh, yes, well - there's a slight silly with that 'cos if you build it from source it reports version as 'v2.84rc2' still.
Jan 26 20:15:59 <ldir-> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014644.html
Jan 26 20:17:30 <ldir-> It's one of those rare moments where there were no changes between an rc and release.
Jan 26 20:18:52 <rsalvaterra> Ah, I'm not building a new image, then. :P
Jan 26 22:03:23 <owrt-snap-builds> build #609 of sunxi/cortexa8 is complete: Failure [failed targetupload]  Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa8/builds/609  blamelist: Felix Fietkau <nbd@nbd.name>, Birger Koblitz <git@birger-koblitz.de>
Jan 26 22:04:19 <owrt-snap-builds> build #604 of ipq40xx/generic is complete: Failure [failed targetupload]  Build details are at http://buildbot.openwrt.org/master/images/builders/ipq40xx%2Fgeneric/builds/604  blamelist: Felix Fietkau <nbd@nbd.name>, Birger Koblitz <git@birger-koblitz.de>
Jan 26 22:06:46 <owrt-snap-builds> build #638 of octeon/generic is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/638  blamelist: Felix Fietkau <nbd@nbd.name>, Birger Koblitz <git@birger-koblitz.de>
Jan 26 23:12:23 <Hauke> stintel: I have a Zyxel GS1900-8 without PoE, it boots the openwrt-realtek-generic-zyxel_gs1900-8hp-v1-initramfs-kernel.bin
Jan 26 23:12:45 <Hauke> I haven't seen any specaail entry for PoE in the dts file
Jan 26 23:12:56 <Hauke> *special
Jan 26 23:13:04 <Hauke> I will create a seperate DTS file anyway
Jan 26 23:23:48 <pkgadd> Hauke: the PoE stuff is done in userspace
Jan 26 23:25:14 <Hauke> pkgadd: thanks
Jan 26 23:26:06 <pkgadd> Hauke: this is the patch I've been using on mine, https://paste.debian.net/1182874/ (it needs slight updating for https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=ca4832fcac83bc375a48648bd77d3283d0742128 and https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=1fb413e6579a34a0040b526e681298909dfaa5ac --> AAHH hwid)
Jan 26 23:27:30 <pkgadd> the only reason why I haven't submitted it yet, is because I need to test the reset GPIO over serial console again
Jan 26 23:28:31 <pkgadd> the gs1900-8 (v1.2 PCB) seems to be identical to the allnet all8208m (but very different OEM firmware/ flash partitioning), my gs1900-8: https://sl-h.de/tmp/IMG_20210113_131639.jpg  vs allnet: https://biot.com/switches/_detail/wiki/dsc01052_s.jpg?id=all8208m
Jan 26 23:28:48 <pkgadd> the reset GPIO is the only DTS difference between them
Jan 26 23:30:25 <Hauke> pkgadd: I also have the gs1900-8 version 1.2
Jan 26 23:30:42 <Hauke> but the "gs1900-8" is not printed onm the PCB ;-)
Jan 26 23:31:40 <pkgadd> interesting, same case design? https://sl-h.de/tmp/IMG_20210113_211622.jpg
Jan 26 23:32:27 <pkgadd> I also got myself a used gs1900-24e, should be supportable as well (but I haven't looked in detail, yet)
Jan 26 23:35:23 <pkgadd> OpenWrt runs really well on the gs1900-8, surprisingly fast (luci) as well
Jan 26 23:46:15 <pkgadd> untested (in terms of UIMAGE_MAGIC/ KERNEL_INITRAMFS and reset GPIO), but this should be it, https://github.com/pkgadd/openwrt/commit/3d86d0ea763da6016603e0ac376dd92276b74f11
Jan 26 23:48:52 <Hauke> pkgadd: yes same casing
Jan 26 23:49:06 <Hauke> I almost had done the same changes already
Jan 26 23:50:24 <pkgadd> yep, it's a rather trivial addition, based on its siblings just a different hwid and lua-rs232 is not needed (which is used as part for the userspace PoE support)
Jan 26 23:55:14 <Hauke> it looks like there is a problem with RX
Jan 26 23:55:23 <Hauke> I do not receive any packets
Jan 26 23:57:12 <pkgadd> the marking on the PCB is wrong, rx <--> tx are mixed up
Jan 27 00:00:05 <pkgadd> this was my serial log from (just before-) sysupgrading the OpenWrt image, https://paste.debian.net/hidden/6e697aaa/
Jan 27 00:02:04 <Hauke> pkgadd: I also had the problem with the serial, but switching this was my 2. try ;-)
Jan 27 00:07:35 <Hauke> the default network config looks broken, it expects VLAN 100
Jan 27 00:08:04 <pkgadd> that's the same for all devices of realtek target so far
Jan 27 00:08:14 <pkgadd> I'm not really a fan of that either
Jan 27 00:10:06 <pkgadd> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/realtek/base-files/etc/board.d/02_network;h=2568fd2e0e0620d0281e826628d4d1840d8c2398;hb=HEAD#l25  there it explicitly sets up the management VLAN on VID 100, leaving the untagged ports as WAN
Jan 27 00:53:33 <aliceussr> Hello! Who can help me compile the driver for rt5390 (Soc) from the rt5390 driver (PCI)?
Jan 27 01:13:20 <mangix> aparcar[m]: can you look into https://patchwork.ozlabs.org/project/openwrt/patch/20210121045145.2209388-1-rosenp@gmail.com/ ?
Jan 27 01:15:28 <aparcar[m]> mangix: I did, it compiles fine but I'm afraid to do such a big thing
Jan 27 01:24:39 <aparcar[m]> mangix: accepted. I rechecked with dango
Jan 27 01:26:58 <mangix> cool
Jan 27 01:27:16 <mangix> that commit should be no-op honestly. Nothing in OpenWrt uses the old ABI
Jan 27 01:27:32 <mangix> but there is a significant size reduction
Jan 27 01:28:14 <aparcar[m]> sweet
Jan 27 02:26:52 <mangix> hmm anyone have any insight as to why ccache is not default?
**** ENDING LOGGING AT Wed Jan 27 02:59:57 2021