<dwfreed>
yeah, you probably just had stale kconfig, and the makefiles don't have good dependency declarations
<slh>
russell--: Borromini had that issue as well, a make clean sorted it out for him (there may be more gentle approaches, as in more selective cleaning)
duke2 has quit [Remote host closed the connection]
duke2 has joined #openwrt-devel
duke2 has quit [Read error: Connection reset by peer]
<ynezz>
Borromini: FYI I've build tested those changes before pushing https://gitlab.com/ynezz/openwrt/-/pipelines/474868320 this build test simply downloads existing .config from downloads.openwrt.org and runs `make defconfig`
<Borromini>
ynezz: thanks, cleaning the buildroot config scripts fixed it for me.
<ynezz>
maybe this updates could be handled somehow more gracefully, but I'm not sure if it's worth it
<dwfreed>
just need improved Makefile dependencies
<dwfreed>
but if it doesn't happen frequently, you're probably right that it's not really worth the effort
<ynezz>
documenting it in some issue might be a good path forward and perhaps a clue for someone hitting this in the future
<ynezz>
and if it's always reproducible it shouldn't be that hard to fix it :P
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Tapper has joined #openwrt-devel
<Borromini>
well it's not the first time this kind of stuff pops up, i picked up 'make -C scripts/config clean' from earlier issues
<Borromini>
do suppose it's a bit overkill to run it after every update/before every compile locally
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
Lynx- has joined #openwrt-devel
Lynx- has quit []
<\x>
Borromini: that RB5009UG looks so good
<\x>
how usable is it now, sfp working?
<Borromini>
\x: haven't tested it yet but will today
<Borromini>
i'm on the 5.10 image and the 2,5G isn't working for me so far.
<Borromini>
will test the SFP+ this afternoon, I think someone said it works when it's plugged in before booting
pmelange1 has joined #openwrt-devel
pmelange1 has left #openwrt-devel [#openwrt-devel]
pmelange2 has joined #openwrt-devel
<Borromini>
\x: robimarkto said 5.15 is way better to build on, but that his image 'needs some love'
Tapper has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
Tapper has joined #openwrt-devel
<aiyion>
is a bdinfo partition onramips similar to an art partition in ath79?
<Borromini>
no i think that's usually bootloader info
<Borromini>
i think it's rather vendor specific, grepping the tree shows only Cudy and HiWifi using those names
<Borromini>
aiyion: wireless calibration data on mt7621 is often located in the factory partition
<Borromini>
mac addresses seem to be pulled from bdinfo though, often
<Borromini>
when that's present (which doesn't seem to be often)
<aiyion>
I'd be very much interested in someones dump of the partition.
<aiyion>
Cudy implemented a backup function whicht throws crypt over the sysupgrades backup.tar.gz
<aiyion>
as seed it uses a combination of the hostname, the rom_release-file as well as most of the bdinfo partition.
<aiyion>
If bdinfo was (except for the mac) the same, it would be easy to build an exploit for the device.
<Borromini>
aiyion: you could check the commits adding support and ping the people who ported it
<aiyion>
?
<aiyion>
Other than the developers of Cudy, I think I'm the first to do it.
<aiyion>
Cudy LT400 is not part of our main/master iirc.
<Borromini>
git log --oneline|grep -i cudy ?
<Borromini>
shows me three device support commits
<Borromini>
none of those people seem to be affiliated with the manufacturer, judging by their mail addresses
<aiyion>
you got me terrified for a moment.
<aiyion>
Cudy has several devices that are paarently based on openwrt.
<Borromini>
well, 'based' is open for interpretation. They use vendor SDKs.
<Borromini>
that's good but doesn't imply they ported it to mainline OpenWrt.
<Borromini>
only manufacturer I know of that does that is Gl.iNet
<aiyion>
No, Cudy does not care for mainline, I think.
<Borromini>
and they all pretend to be OpenWrt compatible somehow but take that with a grain of salt. rotten SDKs based on stone age OpenWrt releases != OpenWrt support, despite manufacturers happily saying so
<aiyion>
What I mean is, the device I have got does not come with an openwrt release yet.
<aiyion>
"LEDE 17.01.5, 1.9.2" ;)
<stintel>
that's not LEDE
<aiyion>
I'm not sure, whether I'm missing something, but I know this is some crap Cudy developed on their own frankensteining with an old lede/openwrt buildtree.
<stintel>
that's probably just the old MediaTek SDK
<aiyion>
From which I still could sysupgrade to my own openwrt?
<aiyion>
I don't get what you to are warning for?
<stintel>
sysupgrade from their to OpenWrt might work, but don't expect it to. be prepared for things to break and having to recover from it
<stintel>
s/their/there/
<stintel>
I usually tftpboot OpenWrt and sysupgrade from there
<stintel>
if tftpboot doesn't boot, you know something is wrong, if you directly try sysupgrading that image from vendor firmware and it doesn't boot ...
<aiyion>
Ther image is pretty closed down. You cannot tftpboot from it, as it requires the image to be signed by Cudy.
<stintel>
even for tftpboot? that's nasty :(
<aiyion>
aah. Yeah no I dont'expect it to work on the first try, I desoldered the flash a week ago and dumped it. I ordered sockets for the flash from mouser, as you cannot read or write it, while its connected to the board...
pmelange2 has left #openwrt-devel [#openwrt-devel]
<aiyion>
Once I bricked the device, I remove the flash from the socket and put the old image back on it, throw my "exploit"-backup on it and can start again.
<aiyion>
But thanks for the warning.
<stintel>
sounds like my adventures with TP-Link OC200 :P
<aiyion>
It's my first ramips device, I'm really looking forward to be done with my exams for this semester and really have time to work on it.
<aiyion>
stintel: why was that a pain?
<stintel>
oh don't get me started :D
<stintel>
for starters, you can solder a TTL header, but then you still need to solder a level shifter and bridge 4 traces on the PCB
<stintel>
luckily the thing supports unsigned tftpboot, so I was able to install OpenWrt on my one unit that has this level shifter etc
<stintel>
and it boots an unsigned image from flash too
<stintel>
just updating firmware from stock checks signature
<stintel>
it does require an efi enabled kernel
<aiyion>
nice
<stintel>
as for the attempt to overwrite the RSA key in the bootloader ... apparently the bootloader itself is also signed, and changing the RSA key in the NOR flash breaks that so even the bootloader says no
<stintel>
ah, and I forgot to mention my first unit where I nuked the SPI NOR because I read it with a 3.3V SPI controller :P
<aiyion>
ouch
<stintel>
the flash *is* readable when soldered though, just need decent clamps, which 3M are not
<aiyion>
I like the idea of the forum-thread to document the progress, maybe I'll do such a writeup, when I got a little more that a popped root through desoldering :D
<aiyion>
I got proper clamps about a month ago, the cheap clamps from amazon/alibaba are never seeing me again.
<aiyion>
I still hope to find someones bdinfo dump of the lt400, it would be way cooler than trying to bruteforce the images implementation of crypt
<stintel>
forum or elsewhere, taking some notes is important, I forgot to write down exact steps how I injected the other RSA key in the NOR, and while it's not that hard to figure out again, it's just wasted time because I've done that before
<aiyion>
Ive got everything written down, I thankfully learned that lesson a few years back.
<stintel>
:)
<stintel>
I should consider ordering a new flash chip for the other OC200 I nuked when testing quad spi in Linux (was asked to do that before the patch could be accepted - I see why :P)
<Borromini>
stintel: which controller are you using now?
<stintel>
but EUR20 shipping for a 0.5 EUR flash chip
<stintel>
+ customs because thank you EU Commission asswipes
<stintel>
Borromini: what kind of controller do you mean?
<Borromini>
well you said you used a 3.3V SPI controller
<stintel>
ch341a I believe
<stintel>
or could have been a raspberry pi
<stintel>
I have some level shifters so I can still use those, or I can use the odroid xu4
<stintel>
but its pin header is so tiny and that's not compatible with the jumper wires I have
<Borromini>
ok. I have a CH341a as well
<Borromini>
lovely to hear that can nuke flash as well :P
<Borromini>
seems i got very lucky with the 'open heart surgery' on my multigig switch >_>
<stintel>
it's not so much the controller but the OC200 flash chip is 1.8V :P
<Borromini>
oh :)
<Borromini>
there's jumpers for that on the CH341a right? or am i mistaken
<stintel>
not on mine
<Borromini>
no-name thingy came with no documentation whatsoever, took me a bit to figure out what's what
<stintel>
maybe it can do 3.3 and 5
<stintel>
1.8v is uncommon
<Borromini>
yes, probably 3.3 and 5
<Borromini>
ok
<aiyion>
theres a jumper to switch between different modes :/
<aiyion>
that thing has not even a clear 3.3 or 5 volts ;)
<stintel>
svanheule: remind me the tool again to print the original partition layout like you did in the eap225 v1 ?
<stintel>
svanheule: most likely from the driver :P
<svanheule>
stintel: the partition table in the EAP225v1 commit for firmware-utils is just the contents of partition-table
<svanheule>
so probably just "strings mtd1.bin"
<stintel>
mtd0 has them apparently
<Borromini>
i was gonna build EAP615-Wall on 21.02, but since delivery keeps getting delayed (and branching seems rather imminent) I'm gonna hold off on that
<stintel>
svanheule: https://git.openwrt.org/?p=project/firmware-utils.git;a=commit;h=3f1b7c46b658c3f4c1bdcaadc565e92af93f53ee look ok ?
eduardo010174 has joined #openwrt-devel
dangole has joined #openwrt-devel
rah has joined #openwrt-devel
floof58 has joined #openwrt-devel
floof58_ has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
Lynx- has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
<Lynx->
jow with your example trap script the trap function kills the child processes, but is something else needed to kill the parent script itself (if say there is an infinite while loop)?
SherlockDomes has quit [Ping timeout: 480 seconds]
<Grommish>
Anyone with a amrv7_hf target willing to help me test this cross-compile for hf?
Misanthr- has quit [Ping timeout: 480 seconds]
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<rah>
dangole: it's been alleged that you maintain the gnunet packages; assuming that's true, I'm having some problems running it:
<rah>
Sun Feb 20 16:06:27 2022 daemon.err gnunet-service-arm[18238]: Feb 20 16:06:27-668861 namestore-18397 ERROR `mmap' failed at plugin_namestore_flat.c:212 with error: Invalid argument
<rah>
Sun Feb 20 16:06:27 2022 daemon.err gnunet-service-arm[18238]: Feb 20 16:06:27-713452 namestore-18397 ERROR Could not load database backend `libgnunet_plugin_namestore_flat'
<dangole>
rah: I haven't tried the flat backends in a while, so maybe something in the OpenWrt packaging has diverged from what GNUnet is expecting there...
<dangole>
rah: lemme skip through gnunet git history for hints...
<dangole>
rah: but cool that you are trying that, I guess for a long time I've been the only OpenWrt-user of GNUnet...
<rah>
dangole: I'm just trying to get it working to see what it can do
Lynx- has joined #openwrt-devel
<dangole>
rah: ok, it's some edit war going on there: commit 116171c28 NAMESTORE: rename flat plugin to heap. then in 2019 (which I wasn't aware of): commit e96e9584f use mmap() instead of malloc, rename heap->flat as database is persisted in flat file
<dangole>
rah: so as a consequence we will need to also rename the config section generated by OpenWrt once again, I guess
<dangole>
rah: looks like I did that half-way but never tested...
<dangole>
rah: does the file actually exist? or is gnunet trying to mmap() a non-existing file?
<rah>
it does exist; if I remove it and restart gnunet, the errors don't appear
<aiyion>
borromini, stintel: just wanted you to let you two know, I just booted openwrt master from the lt400 :D Thanks again, and have a nice weekend!
<rah>
Sun Feb 20 16:24:26 2022 daemon.err gnunet-service-arm[19596]: Feb 20 16:24:26-725686 util-os-installation-19596 WARNING `access' failed on file `/usr/lib//gnunet/libexec/gnunet-service-zonemaster-monitor' at os_installation.c:798 with error: No such file or directory
<rah>
Sun Feb 20 16:24:26 2022 daemon.err gnunet-service-arm[19596]: Feb 20 16:24:26-747087 arm-19596 ERROR Failed to start service `zonemaster-monitor'
<rah>
dangole: do you know what package gnunet-service-zonemaster-monitor is in?
<robimarko>
svanheule: have you seen RTL switches using Squashfs3
<robimarko>
And verifying its rootfs in U-boot
<robimarko>
I am playing with DGS-1210-28P and it looks like OpenWrt is working on it only because the second FW is left untouched
<svanheule>
robimarko: don't think so, but I have mostly been running tftp-loaded initramfs images
<robimarko>
Otherwise U-boot checks kernel and rootfs partitions
<aiyion>
Lynx-: in line nine you register the trap:
<robimarko>
svanheule: stupid thing is that if you break both of them
<robimarko>
Then you cant even initramfs
<aiyion>
to "INT TERM EXIT"
<robimarko>
As the check is ran even before bootm
<dangole>
robimarko: in general it's a good idea to let U-Boot check the rootfs before launching the kernel ;)
<Lynx->
trap - INT && trap - TERM && trap - EXIT && kill -- ${bg_PIDs[@]} <--- is this correct aiyion
<robimarko>
dangole: Yeah, thats fine
<aiyion>
so when you hit ctrl+c INT is triggering the trap, and as the script exits EXIT is triggered as well.
<robimarko>
But the issue is that they are using big endian Squashfs
<robimarko>
And that is SquashFSv3
<robimarko>
Which has not been supported in ages, like since 2.6 kernel days
<Grommish>
neggles: I know it's middle of the night there but when you get back, would you test the armv7-openwrt-linux-muslgnueabihf? https://github.com/Itus-Shield/float_test
<robimarko>
And then if you break it you cant even boot an initramfs
<aiyion>
you could determine, which handler should really issue the trap.
<robimarko>
You first have to use the bootloader to flash the dump back
<dangole>
rah: I'll add zonemaster-monitor to gnunet-gns package, it wasn't packaged at all
<aiyion>
I'm not sure what your and-chain is supposed to mean, sorry.
<aiyion>
gotta go, play around removing eg the INT registration
<dangole>
rah: due to missing funding and also due to brokenness of the transport service this never happened
<dangole>
rah: i didn't completely abandon that idea though, I still think it'd be very nice to build something like that based on GNUnet
<rah>
I see
<rah>
dangole: this is what I get when running "/etc/init.d/gnunet stop", gnunet-service-ats is segfaulting: https://paste.debian.net/1231628/
<dangole>
rah: ouch. building with gdb and debugging symbols enabled should tell you what's happening, but being a segfault, that's most likely a bug in gnunet itself...
<rah>
dangole: what brokenness is there in the transport service?
<rah>
("also due to brokenness of the transport service this never happened")
<dangole>
rah: it never worked reliably for me. i've mostly tried using gnunet-vpn on top of it and things just went stuck as soon as there was any serious traffic. ie SSH would connect, but calling 'logread' would freeze. i tried to investigate what's going on, but it became clear that there are too many loose ends (at least back then in 2016/17...)
<rah>
I see
<dangole>
rah: I've seen that some work went into that lately, so I hope things are better now
robimarko has quit [Quit: Leaving]
<dangole>
svanheule: pushed all 9 of your realtek patches. thanks a lot for cleaning this!
SherlockDomes has joined #openwrt-devel
<svanheule>
dangole: Thanks for merging. Figured I could already get started sending in some fixes ;)
<dangole>
svanheule: early and often :)
<svanheule>
dangole: I've also noticed that the sole RTL839x device is quite broken, but I still need to determine to what extent
<dangole>
svanheule: unlike...
<dangole>
svanheule: i figured that whole use of the (completely transparent) slave-mii-bus in dsa driver is basically because the mdio driver is missing some devm_* magic because it's probed by the ethernet driver. hence attaching a PHY from that bus via of_phy_connect doesn't work and the slave bus is the work-around for that...
<dangole>
svanheule: once this gets resolved we can remove the slave-mii-bus from dsa driver and then finally have more than one MII bus instead of abusing port-address as MII address which doesn't make much sense and surely won't work with all PHY drivers
<dangole>
svanheule: (because MII bus address is assumed to be 5-bit wide, some phy drivers assume neighbouring ports of a phy package to have adjacent addresses as well. both is borked in the way we do now)
<svanheule>
dangole: to be honest, I've stayed far far away from the networking code until now...
<dangole>
svanheule: i also won't touch the ethernet driver in it's current state, but MDIO is simple enough (just some PIO and that's it, no DMA, doesn't need to perform crazily well, ...)
<dangole>
svanheule: and improving things with overall negative diffstat is always nice ;)
<svanheule>
if there's less code, there's less review work :P
<dangole>
svanheule: also found out that @biot had already cleaned it up once and also separated the MDIO part from the rest of the driver, but that never went into our tree somehow
<svanheule>
dangole: that would be because biot was allergic to OpenWrt...
<dangole>
svanheule: obviously now it won't apply any more, but can serve as a blueprint for how things could be done without all the mess of two identical MII busses (and no way to have more physical busses, though they do exist, and hence abusing port address as MDIO address and so on)
<svanheule>
dangole: do you intend to spend some time on this target? I've been the only one cleaning/upstreaming code for a while now :(
<svanheule>
musashino also helped out a bit, with the patches to rebase on MIPS_GENERIC
<dangole>
svanheule: i've recently been gifted some hardware and it looks interesting, so after my upcoming vacation i intend to do more there
<dangole>
svanheule: i won't be of much help when it comes to low-level MIPS stuff, but all that seems to work fine now from what i can tell. also first time i touch DSA, so i'm still learning...
<svanheule>
dangole: the low-level MIPS stuff needs to be ripped out of OpenWrt, poured of with gasoline, and set alight... it's basically copies of upstream code with ugly hacks
<dangole>
svanheule: won't be me starting that fire unless i know what else would do the job...
<dangole>
svanheule: following up on @biot's abandoned work seems like a good way to learn and improve things, so that's what I'll do next once I return mid-march.
<svanheule>
dangole: sounds good to me, I can work a bit on the low-level stuff
<svanheule>
dangole: but that requires getting IRQ balancing reviewed upstream, submitting a proper driver for the Realtek timers, etc.
<dangole>
svanheule: that'd be great. i can review and merge into OpenWrt up to Tuesday night, then I'll be gone for two weeks.
Borromini has joined #openwrt-devel
danitool has joined #openwrt-devel
pmelange has joined #openwrt-devel
SherlockDomes has quit [Ping timeout: 480 seconds]