shoragan has quit [Read error: Network is unreachable]
shoragan has joined #openwrt-devel
shoragan has quit [Quit: quit]
shoragan has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
gch981213 has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
Obi-Wan has quit [Remote host closed the connection]
Obi-Wan has joined #openwrt-devel
skynet2 has quit [Ping timeout: 480 seconds]
vincejv has quit [Remote host closed the connection]
rua has quit [Quit: Leaving.]
vincejv has joined #openwrt-devel
rua has joined #openwrt-devel
guidosarducci has quit [Remote host closed the connection]
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
mrnuke has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
rua has quit []
rua has joined #openwrt-devel
rua has quit [Remote host closed the connection]
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 99.9% packages reproducible in our current test framework.)
rua has joined #openwrt-devel
rua has quit [Quit: Leaving.]
aparcar has joined #openwrt-devel
<aparcar> Mangix: ping
<aparcar> Mangix: ideas on when meson doesn't find mbedtls on a debian machine even if mbedtls-dev is installed?
<KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
rua has joined #openwrt-devel
dermoth has quit [Remote host closed the connection]
dermoth has joined #openwrt-devel
<owrt-images-builds> Build [#163](https://buildbot.openwrt.org/images/#/builders/205/builds/163) of `master_mpc85xx/p1020` failed.
<\x> this zram multicomp thing isnt so bad of a meme hah https://github.com/openwrt/openwrt/commit/d282eb88b199d190788d8a1a13bebbcc8e4d0acf
<Ansuel> context?
robimarko has joined #openwrt-devel
<svanheule> mrnuke: ping
<mrnuke> svanheule: pong
<svanheule> mrnuke: I was looking into a new safeloader image format for the EAP683, and then I remember you were working on the EAP610-Outdoor
<mrnuke> svanheule: is it a binary TOC instead of text strings?
<svanheule> mrnuke: you're aware that your factory image generation script is rather similar to the tplink-safeloader tool from firmware-utils?
<svanheule> yeah, same binary TOC (assuming that's table of contents)
<mrnuke> svanheule: yeah. I looked into tplink-safeloader C program, and immediately thought it was a bad idea
<mrnuke> I think it's the Makefile that should know the "Support list" string. It shouldn't be hardcoded on a board-by-board basis in A C program
<svanheule> integrating the new format won't be straightforward, no
<svanheule> the whole board table in that utility shouldn't be there :P
<svanheule> certainly now that the tool isn't in openwrt.git anymore, adding boards is quite tedious...
<mrnuke> That utility is one of my motivations for using python to pack images
<svanheule> the thing I'm a bit worried about is the explosion of safeloader formats. they're all subtly different, but could share quite a bit of logic
<svanheule> image checksum, soft-version structure, support-list "structure"
<svanheule> maybe it's just time for tplink-safeloader to be rewritten :P
<mrnuke> I would propose we use tplink-2022 as written, and then see if there is a way to share code with the "older" format
<mrnuke> There would be minimal code I could share with the safeloader from firmware-utils. THe MD5 salt would be one.
minimal has joined #openwrt-devel
<mrnuke> Most of the old code deals with the text-based TOC. There's very little python code to deal with the File I/O
<mrnuke> I suppose we could add a packer/unpacker for the safeloader-old TOC in the python code, end reuse most of tplink-2022 wihtout modification
<mrnuke> If I gave you a hexdump of the TOC, it might be obvious. hold on
<svanheule> it appeared more consistent if the ToC started with '>3I' (rootfs size, entry count, ???), followed by the entries (name, offset, size, more info?)
<svanheule> I've been staring at the 683's hexdump for half a day :P
<svanheule> then the non-FF bytes matches exactly with [>3I] + 40 * [>32s3I]
<mrnuke> "3I" doesn't make sense. You'd get the offset + size of entry[n-1], and then the "type" of entry[n]
<svanheule> and the name/base/size order is the same in the text-type ToC
<svanheule> or just a third piece of info about the ToC
<mrnuke> Here's my TOC from the vendor FW: https://paste.centos.org/view/ce068711
<swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
<svanheule> ah, I see, the "type" in your ToC is 0
<mrnuke> Now, it is possible that rootfs is (offset, size, type), and entries are (name, offset, size, type)
<mrnuke> Since "type" didn't seem to be strictly needed, I didn't investigate that much
<svanheule> here's the 683's ToC: https://paste.centos.org/view/f10e1d3e
<svanheule> sure, a zero before or after doesn't make much of a difference :)
<mrnuke> That's the same format! YAY!
<svanheule> entry:type for the EAP683 is 0x1, so that's what made me decide on the triple int ToC header
<svanheule> they seem to be using it on (all?) NAND devices
<mrnuke> I see an extra "00 00 00 01" after the last entry. I am willing to concede that the "type" comes after the name string, and not before it
<svanheule> :P
<svanheule> type or whatever that 0x1 might mean
<svanheule> maybe "flash extra carefully"
<mrnuke> #define TPLINK_CONFUSE_SVANHEULE_AND_MRNUKE BIT(0)
<mrnuke> could be a bitfield
<svanheule> lol
<svanheule> then I decided to look for other supported TP-Link devices that use ubi volume
<svanheule> turns out there's a JSON variant of safeloader images as well
<mrnuke> Extra points if you find an XML!
<svanheule> and the mercusys mr90x uses yet another variant!
<svanheule> XML is so 2005
<mrnuke> Obviously some poor internt at tplink said "text-based TOC is not good enough. And another one said "binary is not good, let's make JSON"
<mrnuke> Surely someone must have thought of other formats!
<svanheule> I wonder how many forks they have of their own tool
<svanheule> must be a nightmare to maintain (haha, as if they're maintaining it)
<mrnuke> Look at Archer be550. The images appear to be encrypted!
<mrnuke> I'm certain we'll see more exciting image format challenges from TPLink
<svanheule> That thing is shaped like an X :O
<svanheule> lost opportunities to have doen that with 802.11ax
<svanheule> 45MB firmware image... yikes
<mrnuke> and root-locked (the bastards)
<mrnuke> I bet you can put one of the old archers next to it, bend the antennas inwards, and spell "AX"
<svanheule> xD
<mrnuke> I think the type might mean [0] = flash me; [1] = metadata
<mrnuke> Look at the eap TOC. there's a "rootfs" type 0, "APPSBL", type 0, and all the rest are type 1
<svanheule> would be odd to include BLE FW images and then not have the upgrade install them
<mrnuke> Oh, true!
<svanheule> fun fact: the BLE firmware isn't a binary blob, but an Intel HEX file
<mrnuke> what the HEX ?
<svanheule> probably the flashing tool takes that as input and they were too lazy to modify it...
<svanheule> bulk of the file is UBI image anyway
<mrnuke> Have you used the mkimage-2022 script to extract the contents?
<svanheule> no
<mrnuke> It can do that ;)
<svanheule> I only found yours after I modified tplink-safeloader to parse the format
<mrnuke> You went through a lot more pain than I did.
<svanheule> modified in a hacky way, so not publishable
<svanheule> well, I was like "this is a safeloader file! I know this!"
<svanheule> *one day later*
<svanheule> truth be told, I *did* use python to do the initial reverse engineering. Starting from this script https://gist.github.com/svanheule/9f82e156a3601d4a726639eb7400ec97
<mrnuke> 2021! That predates my tplink-2022 script
<mrnuke> I find python pretty nifty for these sort of file manipulations
<mrnuke> ANd the way it forces you to serialize and deserialize data is genius. No more pointer casts and byte order errors!
<mrnuke> C is one of the worst languages in my opinion for this sort of work
<mrnuke> svanheule: BTW, I have a ews2910p v3 incoming. IIRC, that should have the I2C version of the BCM controller
<svanheule> I2C version for the MCU interface or a direct I2C connectoin to the BCM PSE chips?
<mrnuke> I2C connection between the CPU and MCU, yes
<svanheule> ok, I have one or two of those device too
<mrnuke> Good to know. When I need a tester for realtek-poe changes, I know where to look :p
* svanheule hides
<svanheule> just kidding, would be nice to be able to use OpenWrt and PoE on that thing
<svanheule> now, that will probably mean I'll have to look into the VLAN issues for realtek...
<mrnuke> realtek-poe changes come for free
<mrnuke> although, I'd love a newer kernel on these unrealtek devices
<svanheule> I think 6.1 was mostly there (thanks to Borromini and bmork), but the chip was eating all frames with the default VLAN config :(
<svanheule> gonna wrap up here for today. Later!
kirdesde has quit [Ping timeout: 480 seconds]
<mrnuke> later!
<Mangix> aparcar: context?
<Mangix> mbedtls needs find_library on each individual library. dependency() doesn't work. upstream refuses to fix it.
<Mangix> https://downloads.openwrt.org/snapshots/faillogs/mipsel_74kc/base/mt76/compile.txt <-- this failure makes no sense. The kernel moved to gnu11 already.
Borromini has joined #openwrt-devel
<Mangix> aparcar: oh funny, dependency() will work with 3.6.0: https://github.com/Mbed-TLS/mbedtls/commit/a4d17b34f354557838e05d2cb47200e8dcaaf59b
Borromini has quit [Quit: Lost terminal]
kirdesde has joined #openwrt-devel
dermoth has quit [Remote host closed the connection]
<aparcar> Mangix: yea eventually figured it out 🙂
dermoth has joined #openwrt-devel
<KanjiMonster> Mangix: the switch to gnu11 happened in 5.18, this is 5.15
robimarko has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<Mangix> KanjiMonster: hmm? this is not backported?
<Mangix> yeah, target/linux/generic/backport-5.15/005-v5.17-02-Kbuild-move-to-std-gnu11.patch
<owrt-images-builds> Build [#165](https://buildbot.openwrt.org/images/#/builders/80/builds/165) of `master_armsr/armv8` failed.
gch981213 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]