01:06 <vulpes2[m]> I've discovered a bug, LEDs without a label will not work when aliased to `led-boot`, `led-failsafe`, etc.

02:52 <soxrok2212> so i found a strange u-boot header in a flash dump on my xdr6086, dd'ed it out and now trying to open it in ghidra to RE it and hopefully find what i need, but ghidra doesnt recognize like any of it

02:52 <soxrok2212> any tips?

02:53 <soxrok2212> u-boot is apparently xz compressed (or at least can be, and is in this case) now in mtk devices. i have it extracted i believe

02:53 <soxrok2212> s/extracted/decompressed

03:16 <soxrok2212> think i mightve found an overflow or a bug O.o

07:57 <owrt-snap-builds> Build [#828](https://buildbot.openwrt.org/master/images/#builders/1/builds/828) of `ath79/generic` completed successfully.

08:52 <karlp> vulpes2[m]: what do you mean with your led labels? if you have no label, no colour and no function, you get a sysfs entry for the node name. if you have color, or function you get <colour>:<function> even if that leaves dangling ':'

08:52 <karlp> you could be running itno something not handling bad filenames?

13:28 <soxrok2212> love finding buffer overflows in bootloaders :)

13:28 <Habbie> hah

13:41 <soxrok2212> no idea how to make it useful though

13:54 <Habbie> soxrok2212, surely somebody will one day run into a similar device with some lock on it

13:54 <Habbie> soxrok2212, i know i have a bootloader here for which an overflow would be welcome

13:55 <soxrok2212> i should phrase it differently. i have a use for it but i dont know how to put it to use for that problem

13:55 <soxrok2212> :)

13:55 <Habbie> hehehe

13:55 <soxrok2212> very hard to debug a bootloader when i dont have any access to the device outside of uart input to a restricted console :P

13:56 <Habbie> yes

14:35 <rmilecki> hauke: i thought my quilt was borked because it was insisting on full diff of simple file rename

14:35 <rmilecki> i see your quilt did the same in the b97e5ac78596 ("bcm4908: Refresh kernel patches")

14:35 <rmilecki> can quilt be made smarted to handle renames without full diff?

14:36 <rmilecki> ynezz: ?

15:31 <Ansuel> stintel if you can check the email i sent some info about the idea of putting preinstall precompiled tools in a container

15:31 <soxrok2212> Ansuel: i got u-boot extracted from that bin

15:31 <soxrok2212> and found a 0-day in it

15:32 <Ansuel> interesting?

15:33 <soxrok2212> apparently mtk xz compresses BL2 and fip packages now, so it was in there, just compressed

15:33 <soxrok2212> theres 2 more commands that arent blocked, go and goash

15:34 <Ansuel> did you check if it does scan for some magic bootenv to unlock everything?

15:35 <soxrok2212> i attempted to. i can't get ghidra to properly open the bin so most of it has been hexdump/string searching. haven't found anything yet. i think the goash command does that but it expects some string (singed key/cert?) to unlock it

15:35 <soxrok2212> but that code also has the overflow

15:36 <soxrok2212> go will attempt to launch an application in member, goash i think starts a console but im not sure yetf

15:36 <soxrok2212> in memory* not in member

15:36 <soxrok2212> you can point go to a memory address and it'll execute it if it can

15:38 <Ansuel> strange that ghidra can't open the bin there shouldn't be anything special in how it's compiled

15:38 <soxrok2212> im not sure i extracted it right

15:39 <soxrok2212> in the whole flash dump, theres a header 0x010064AA which is apparently u-boot usb https://github.com/3F/aml_s905_uboot

15:39 <soxrok2212> that's at 0x20000

15:41 <soxrok2212> then the xz compressed data starts at 0x20088, so i basically dd'ed out everything from 0x20088 until it was followed by 0x0000 which is apparently standard for xz compressed data, but mkimage doesn't do that and im not sure if mtk tools that build the bin do either so i don't know where it actually ends

15:42 <soxrok2212> i also dont know if i need to stick the uncompressed data back in at 0x20088 and then decompile the whole bin from 0x20000 with that strange u-boot header

15:51 <soxrok2212> i can see go and goash in memory but when i look for references in code they dont seem to exist which doesn't make sense

17:47 <vulpes2[m]> karlp: sorry, forgot to mention that I do have color and function defined in my dt

17:47 <vulpes2[m]> see this issue I opened for details: https://github.com/openwrt/openwrt/issues/11243

18:15 <f00b4r0> hmm, i migrated a router configuration to some other hw and now my LAN doesn't get RAs... what did I do wrong

18:24 <KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 99.6% packages reproducible in our current test framework.)

18:28 <hauke> rmilecki: the kernel refresh check in the github CI was failing

18:28 <hauke> it would be nice if quilt would detect a rename

22:14 <iyesin> Hello folks. I have a question regarding policy of accepting 3rd-party patches. The thing is: I currently using two OrangePI R1 Plus LTS (and one non-lts) boards as openwrt routers. I'm totally fine with them except the fact I need to use kinda outdated openwrt fork by Xunlong. I would be much happier to see this platform as fully supported by OpenWRT. Integrating Xunlong's patches into openwrt main tree does not seems extremely hard to me.

22:15 <iyesin> I'm ready to invest my resources (my time and money) into this work. My question is: is there any legal/political/ethical show stoppers for this kind of work?

22:18 <slh> Disclaimer: I'm not an OpenWrt developer and the following is just my unfounded opinion, but sunxi and rockchip are traditionally targets with very little to no patching, as they're pretty actively developed upstream in mainline linux - so ideally the patches go into linux-next first and are merely backported to OpenWrt, so they'll go away after the next kernel bump

22:23 <iyesin> Thank you, slh. Unfortunately, this query gives no result https://github.com/torvalds/linux/search?q=orangepi-r1-plus-lts

22:27 <slh> I'd write up a patch series to lkml, CC'ing Rob Herring, Krzysztof Kozlowski and Heiko Stuebner

22:28 <iyesin> I mean, there are some changes in kernel that references rk3328. Which is a good sign. The bad (for me and other owners of these boards) part, there are no mentions of orangepi in https://github.com/torvalds/linux/blob/18fd049731e67651009f316195da9281b756f2cf/arch/arm64/boot/dts/rockchip/Makefile

22:28 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 99.6% packages reproducible in our current test framework.)

23:03 <vulpes2[m]> <iyesin> "Hello folks. I have a question..." <- This board is sufficiently similar to the nanopi r2s that you might have a good chance of being able to get it working with a dt similar to that.

23:04 <vulpes2[m]> However, there is a chance that your onboard RTL8153B might not work with mainline due to a missing USB3 PHY driver: https://patchwork.kernel.org/project/linux-rockchip/list/?series=385165&archive=both

23:05 <vulpes2[m]> Some boards will work ootb without issues, some will only work with the rk vendor kernel, the reason is unknown at this time.

23:07 <vulpes2[m]> My recommendation would be looking into the commits adding support for the r2s, and try to do something similar with your orangepi board.

23:08 <slh> that would make upstream merging a lot easier, yes

23:09 <rmilecki> iyesin: perfect situation is if board / platform is supported upstream

23:09 <rmilecki> iyesin: then you can be pretty much 100% sure OpenWrt will take those patches

23:10 <rmilecki> iyesin: so if you have actual time & money to invest into that, i'd suggest sending patches upstream

23:10 <rmilecki> to maintainers of correct subsystems

23:10 <rmilecki> so they end up in Linus's stree

23:11 <vulpes2[m]> yeah, from what I can tell, openwrt developers prefer having the dt sent to lkml for certain architectures like sunxi and rk

23:11 <vulpes2[m]> for things like ramips it's fine to have downstream dt, but for sunxi and rk it seems to be less acceptable

23:12 <vulpes2[m]> I'm not an openwrt developer, this is just my casual observation so far

23:13 <slh> rockchip and sunxi have very strong community support for mainline, so there's little reason to add downstream patches

23:13 <slh> aside from occassional targetted backports