<mrkiko> woow! Good 2023!! :D :D
SamantazFox is now known as Guest903
SamantazFox has joined #openwrt-devel
SamantazFox has quit [Max SendQ exceeded]
SamantazFox has joined #openwrt-devel
Guest903 has quit [Ping timeout: 480 seconds]
chuck48 has joined #openwrt-devel
chuck48 has quit [Ping timeout: 480 seconds]
minimal has quit [Quit: Leaving]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
rua has quit [Quit: Leaving.]
danitool has quit [Ping timeout: 480 seconds]
<owrt-2203-builds> Build [#208](https://buildbot.openwrt.org/openwrt-22.03/images/#builders/63/builds/208) of `at91/sama7` completed successfully.
goliath has quit [Remote host closed the connection]
digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
digitalcircuit has joined #openwrt-devel
valku has quit [Quit: valku]
<damex> any idea where i could find edgerouter poe-5 datasheet/schematics? my old one does not show any signs of life and after connecting it to 48v power supply - i get 8v right at the jack
<damex> want to get openwrt running there. runs same cavium processor as edgerouter lite
guidosarducci_ has quit [Ping timeout: 480 seconds]
<mrnuke> damex: the "backup" image is just another rootfs. The kernel doesn't have a redundancy. You won't be able to get to u-boot console without modifying the bootloader.
<damex> mrnuke: so that sg2210p is doomed?
<mrnuke> damex: not really. We just have to figure out why the bootloader is complaining
<damex> > You won't be able to get to u-boot console without modifying the bootloader.
<damex> so that thing, how is it supposed to be recovered at this point?
<mrnuke> damex: You can try to extract the kernel from a vendor update image and flash that via TFTP, or try to flash that -sysupgrade image over tftp
<damex> mrnuke: well, device had to be turned off and it does not come up now. no ethernet lights up after any amount of time. how do i extract 'kernel' from vendor image to try to serve it over tftp?
<damex> mrnuke: i tried flashing -sysupgrade image over tftp and you know how it turned out :)
<mrnuke> damex: There was a script to decrypt/extract the vendor image in this comment: https://github.com/openwrt/openwrt/pull/10486#issuecomment-1245359748
<mrnuke> damex: I take it neither sysupgrade, nor initramfs worked?
<damex> mrnuke: yes, neither sysupgrade or initramfs worked
<mrnuke> damex: I also had a script to extract the data from a decrypted image: https://gist.github.com/mrnuke/2dbcc6afd40c8d5a819457dfff8cdbcf
<mrnuke> Decrypt with openssl enc -d -des-cbc -in encrypted.bin -out decrypted.bin -nosalt -nopad -p -iv f51010736efbabb2 -K 0001020304050607
<mrnuke> It's been a while since I messed with those TP-Link switches
<damex> mrnuke: so decrypt -> extract -> copy uimage.img to tftp root and that's it? is there a way to trigger recovery?
<mrnuke> damex: I remember getting the device stuck in a mode where it wouldn't recover from a bad kernel. The shorting out the CLK pin was the only way to get it out of that mode and trigger recovery
<damex> mrnuke: power it up with shorted clk pin?
<damex> and disconnect 1s later?
<mrnuke> short it out as it's loading the kernel. That uses the standard u-boto codebase. if you short the ping as it's loading the the uimage header, then it should trigger recovery
<damex> mrnuke: how do i know it is loading kernel? i tried shorting it moment after supplying power, after 1s, after 2s and etc.
<damex> there is no serial output available so there is that
rua has joined #openwrt-devel
<damex> i wonder why they tie uboot serial to that properly working kernel >_>
<damex> whole purpose of having uboot access in that case would be to recover
<mrnuke> They modified u-boot to put their (TP-Link's) own serial interface, called BOOTUTIL. That's used on some higher end switches with an actual serial port. I presume they don't want users getting to a uboot shell and "accidentally" erasing important flash sections
<mrnuke> BOOTUTIL isn't very useful on switches without a serial port header
<damex> mrnuke: can't one replace with something more sensible?
<mrnuke> BTW, make sure you check both 38400, and 115200 baud rates. It's possible to change the baudrate by editing the u-boot env
Borromini has joined #openwrt-devel
<damex> i did check, my serial adapter lights up when something comes up even if i don't get proper rate :)
<mrnuke> damex: I modified the bootloader on one of my switches to drop me to a uboot shell. It's doable, but a major pain in the arse, and requires desoldering and extermal programmer
<damex> mrnuke: hm... can't we do it in software since official package bundle uboot+rootfs+kernel+other random stuff?
<damex> i mean... atleast once :D
<damex> before you would actually need an external programmer
<damex> well, i do have ch341a and other stuff but... i'd rather not. and no soic16 clip yet.
<mrnuke> Don't bother with external programmer unless you're willing to solder an SOIC socket. Reason: the reset circuit might drive your ROM in reset, and you nuts
<mrnuke> as far as updating in software, you can after flashing openwrt. From vendor firmware, I don't have a way to SW flash
<damex> mrnuke: argh... well, i didn't expected such resistance from sg2210p that's for sure
<damex> mrnuke: any idea about what could be attempted to do next?
<mrnuke> damex: speaking of resistance, make sure your resistor on the TX line sdin;t blow up. I had to replace one of those tiny resistors that had gone open circuit for no apparent reason
<mrnuke> One of three things: (1) try different baudrates. (2) Double-check continuity form the SOC to the UART headers, and (3) Decrypt and compare the vendor images for 3.26 and your exact version. See if the uimage header is different
<damex> mrnuke: on last sg2210p there is no pads or trace leading to tx pin. i have had to solder directly to 4.6kohm resistor side that is next to soc pins
<damex> it worked just fine
<damex> i wonder why we need 50ohm resistor next to gpio pins if rx and tx go through 4.6kohm resistors
<damex> mrnuke: baud rates is not a problem - uart 'pins' are exposed correctly. problem is that it does not even try to load from tftp. i tried booting it with clk shorted, short it seconds after supplying power and etc. no difference
<mrnuke> No idea. There were other 33 and 50 ohm resistors near pads, so I just chose that as a "reasonable" value
<damex> mrnuke: usually on tplink you just bridge that pads
<mrnuke> You can't short CLK on power on. The SOC needs to load u-boot from flash. You only short CLK as uboot is trying to load the kernel
<damex> robimarko confirmed that it was like that for other tplink devices. i found the same on forums
<damex> mrnuke: yeah, i tried to do it up to 10s after supplying power
<mrnuke> A non-zero resistor gives you some short-circuit current limiting
<damex> wait 1s -> short. wait 2s -> short and etc. no results up to 10s and 10s should be enough to read uboot
<mrnuke> I'd expect to see at least the "Hit any key to stop autoboot" message on the UART
<mrnuke> I need to re-check tomorrow how the thing behaves
<damex> i use that round crappy clips from my logic analyzer connected together. one on clk and second touching ground when needed
<damex> so that part is pretty consistent
rua1 has joined #openwrt-devel
<damex> mrnuke: sadly i don't get any output
rua has quit [Ping timeout: 480 seconds]
<damex> i wonder if there is other 'easy going' openwrt supported switches that wouldn't require hoops with soldering, shorting and praying to voodoo to get it working
csrf has joined #openwrt-devel
rua1 has quit []
chuck48 has joined #openwrt-devel
<Borromini> damex: many of the ZyXELs
chuck48 has quit [Ping timeout: 480 seconds]
<mrnuke> damex: I also wrote support for Engenius EWS-2910P. That can be updated from the vendor web interface
<mrnuke> damex: I would check things systematically (on SG2210P)> Check the RESET, clk, and data pins on the ROM. Make sure that the RESET is being released, the SOC is requesting data from the ROM, and the ROM responds.
<mrnuke> damex: If that doesn't happen, then I would suspect a hardware problem. Otherwise, software
xes_ has joined #openwrt-devel
xes has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
chuck48 has joined #openwrt-devel
danitool has joined #openwrt-devel
rua has joined #openwrt-devel
aleksander has joined #openwrt-devel
rua has quit [Quit: Leaving.]
chuck48 has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<owrt-snap-builds> Build [#426](https://buildbot.openwrt.org/master/images/#builders/72/builds/426) of `imx/cortexa9` completed successfully.
chuck48 has joined #openwrt-devel
rua has quit [Quit: Leaving.]
dansan has quit [Ping timeout: 480 seconds]
chuck48 has quit [Ping timeout: 480 seconds]
csrf has quit [Remote host closed the connection]
csrf has joined #openwrt-devel
chder has quit [Remote host closed the connection]
rua has joined #openwrt-devel
chder has joined #openwrt-devel
zkrx has quit [Ping timeout: 480 seconds]
<Tapper> happy new year people.
zkrx has joined #openwrt-devel
<robimarko> Happy new year
<opty> hny :)
tom- has quit [Quit: WeeChat 3.7.1]
tom- has joined #openwrt-devel
<Borromini> happy NY
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
Borromin1 has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
<vulpes2[m]> hauke: do we have any plans to address the python dependency issues for u-boot?
<vulpes2[m]> I'm thinking of bumping up the u-boot release but I'm getting the dreadful pylibfdt does not seem to be available with python3 error now
<robimarko> Is it binman requiring them?
<vulpes2[m]> Good question, let me double check
<vulpes2[m]> As far as I can tell binman is enabled, yeah
<vulpes2[m]> This is uboot-rockchip
<robimarko> Isnt this a case of swig missing
<robimarko> As pylibfdt will get build
<robimarko> But it requires swig
<vulpes2[m]> As far as I can tell this is the test that failed: https://elixir.bootlin.com/u-boot/v2022.10/source/Makefile#L2049
<hauke> vulpes2[m]: someone should take care of this u-boot build dependecies ;-)
<gch981213> isn't binman already a requirement in uboot-mediatek?
<vulpes2[m]> I can look into the swig and pylibfdt situation, but I haven't tinkered with stuff on the host side before
<vulpes2[m]> Introducing swig at least looks straightforward enough
<vulpes2[m]> gch981213: there seems to be a pylibfdt related patch for uboot-mediatek: https://github.com/openwrt/openwrt/blob/master/package/boot/uboot-mediatek/patches/300-force-pylibfdt-build.patch
<oliv3r[m]> Happy new year!! all
<oliv3r[m]> Anybody know which kconfig symbol I'm missing that triggers this error: Error: opcode not supported on this processor: mips32 (mips32) `ext
<oliv3r[m]> (it worked in the past, so I know its something I did :p)
<hauke> oliv3r[m]: you are probably missing the compiler option to compile for MIPS32r2
<oliv3r[m]> so why did it work yesterday? :)
<oliv3r[m]> i haven't changed my container. More importantly, how do I enable it!
<oliv3r[m]> actually, if openwrt updates these kinds of dependencies, it will affect my container i'd think
<oliv3r[m]> i'll wipe my builddir to see what happens
<oliv3r[m]> ah wait, the compiler doesn't actually reside there, have to pull my container to update!
<oliv3r[m]> still strange while this break even though I didn't touch the container, as it's been running for days/weeks.
<oliv3r[m]> using the latest sdk container, though it's 2 months old; I think i was using a 6 month old one before; so doubt that'll make a difference ..
<Znevna> only logical explanation, you've been hacked
aleksander has quit [Quit: Leaving]
<oliv3r[m]> haha, yeah, the container must be hacked :)
<oliv3r[m]> But not it gets worse, I threw away the container, pulled the sdk one; and now I get this: Error: opcode not supported on this processor: mips32 (mips32) `ext
<oliv3r[m]> er, copy paste fail :) ../../build_dir/host/zstd-1.5.2/build/meson/meson.build:11:0: ERROR: Executables created by c compiler gcc are not runnable.
<oliv3r[m]> really not what I wanted to mess with today
<oliv3r[m]> frustratingly of course, all other packages are compiling just fine (-j8 :p)
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
<robimarko> vulpes2[m]: Hm, so U-boot has a stupid logic
<robimarko> They check if DTS is present and if so then assume that pylibfdt should be as well
<robimarko> Otherwise if DTC is not present they build it
dansan has joined #openwrt-devel
zorun has joined #openwrt-devel
<vulpes2[m]> Force building dtc with the patch in uboot-mediatek worked but I had to build scripts/dtc/pylibfdt as well
floof58 is now known as Guest939
floof58 has joined #openwrt-devel
<robimarko> I am not sure if dtc is one of the host tools that is used
<robimarko> But its available for sure, what is not is pylibfdt
<robimarko> Basically, the U-boot logic needs to not just check for dtc
<robimarko> And then assume that pylibfdt is present
<robimarko> But to check and if not build it
<vulpes2[m]> but if you look here it's specifically checking pylibfdt: https://elixir.bootlin.com/u-boot/v2022.10/source/Makefile#L2049
<robimarko> Yes, but it wont trigger a build if not present
<robimarko> It will only build dtc and pylibfdt is dtc is not present
<vulpes2[m]> $(MAKE) $(build)=scripts/dtc doesn't seem to even build pylibfdt either, I had to explicitly tell it to do $(MAKE) $(build)=scripts/dtc/pylibfdt as well
<stintel> philipp64: whould you mind having a look at the problem described in https://git.openwrt.org/52dbd50a2d9ee2c5b39a49922f4680d5413d8297 and suggest if I should report this in openwrt/packages or rather strongSwan upstream
Guest939 has quit [Ping timeout: 480 seconds]
<stintel> I'm reverting to 5.10 for now which does not expose this problem and VPN tunnels going down multiple times per day while on holiday is ....
<stintel> philipp64: fyi I also asked Thermi
<vulpes2[m]> Since this is working now I'll just patch out the checks and force build pylibfdt + dtc for the moment like uboot-mediatek did. I can look into fixing this properly with the upstream in the future.
<robimarko> Sounds like a plan
<vulpes2[m]> hauke: what's your preferred approach to add swig to the build system? from what I can tell we can just install it on the host system instead of building it from source?
<robimarko> It can be added as a prerequisite but a check for it needs to be added as well
<robimarko> So it will just use the host one
<aiyion_> I'm just looking over the patch to add support for the DAP-X1860, which does behave like the commit message suggests, extended test will follow tomorrow night, when I'm with the router again;
<aiyion_> The wifi interfaces irritates me though.
<vulpes2[m]> sure, let's just put swig in a prerequisite check then
<robimarko> Does MacOS provide swig?
<robimarko> Cause if not that would break support for it
<aiyion_> "phyX-staY" spawns out of nowhere when one opens an accesspoint, while phyX does not appear until one does. Any ide, where I can read up on this supposedly new behaviour?
aiyion_ is now known as aiyion
<aiyion> *idea
<vulpes2[m]> swig is available on homebrew: https://formulae.brew.sh/formula/swig#default
rsalvaterra has quit [Remote host closed the connection]
rsalvaterra has joined #openwrt-devel
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
minimal has joined #openwrt-devel
<Borromin1> aiyion: maybe due to recent changes introduced in netifd?
<hauke> vulpes2[m]: The build system should check for swig
<hauke> maybe also check if it was compiled with python support
<hauke> and maybe only require it when a u-boot which needs it is build
<vulpes2[m]> sure, I can put that in, should be a straightforward patch
<vulpes2[m]> managed to bump uboot-rockchip to 2022.10 and it seems to work fine on rk3399, building for rk3328 now
G10h4ck has joined #openwrt-devel
<vulpes2[m]> work on rk3328 too
<vulpes2[m]> how should I conditionally check for a dependency only when u-boot.mk is involved?
<G10h4ck> Hi!
<vulpes2[m]> I can put a check in prereq-build.mk but then it would be checked regardless of whether u-boot.mk is used or not
Borromin1 has quit [Ping timeout: 480 seconds]
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
<tmn505> it should be fine to put it in prerq-build.mk, cause sometime u-boot is necessary to build the final image
Borromini has joined #openwrt-devel
floof58 has quit [Read error: Connection reset by peer]
Luke-Jr has quit [Ping timeout: 480 seconds]
floof58 has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
<swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
<vulpes2[m]> hauke: dependency check for swig: https://github.com/openwrt/openwrt/pull/11666
<vulpes2[m]> I wasn't able to find a reliable way to check for Python support so it was omitted.
<vulpes2[m]> Suggestions on how to make this per-target or putting this check into u-boot.mk would be welcome if you think it's necessary.
nixuser has quit [Ping timeout: 480 seconds]
nixuser has joined #openwrt-devel
<Znevna> why do you put DC1 before those names?
dansan has quit [Quit: The C preprocessor is a pathway to many abilities some consider to be unnatural.]
<hauke> vulpes2[m]: thanks
<hauke> The CI is failing becasue it can not find swig ;-)
<dwfreed> heh
<hauke> I think the mediatek u-bot used swig some time ago, but I am not sure if it still uses it
<hauke> I think some build dependencies are per package but I am not sure
dansan has joined #openwrt-devel
dansan has quit []
<Znevna> luxul is the best supported openwrt router! it has huge capacitors and power brick
<Znevna> >.>
SamantazFox is now known as Guest956
SamantazFox has joined #openwrt-devel
SamantazFox has quit [Max SendQ exceeded]
SamantazFox has joined #openwrt-devel
G10h4ck has quit [Quit: Konversation terminated!]
Guest956 has quit [Ping timeout: 480 seconds]
<ynezz> vulpes2[m]: package/boot/uboot-mediatek/patches/300-force-pylibfdt-build.patch
G10h4ck has joined #openwrt-devel
srslypascal is now known as Guest958
srslypascal has joined #openwrt-devel
<robimarko> Wait, wasnt swig dependecy of pylibfdt itself?
csrf has quit [Ping timeout: 480 seconds]
csrf has joined #openwrt-devel
Guest958 has quit [Ping timeout: 480 seconds]
csrf has quit [Quit: Leaving]
G10h4ck has quit [Ping timeout: 480 seconds]
G10h4ck has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
takimata has quit [Quit: wat?]
takimata has joined #openwrt-devel
Borromini has left #openwrt-devel [#openwrt-devel]
<philipp64> stintel: memory leak? Dec 30 06:26:13 ar0 ipsec: 08[IKE] nonce allocation failed
<philipp64> what happens if you run an older StrongSwan on 5.15?
SamantazFox_ has joined #openwrt-devel
SamantazFox_ has quit [Max SendQ exceeded]
SamantazFox_ has joined #openwrt-devel
SamantazFox_ has quit [Max SendQ exceeded]
SamantazFox_ has joined #openwrt-devel
<philipp64> aparcar: you around?
<philipp64> mention on which mailing list that the patches are superseded?
<aparcar[m]> The apu patches are now on the mailing list and on GitHub
SamantazFox has quit [Ping timeout: 480 seconds]
<philipp64> from one of my boxes:
<philipp64> Dec 28 11:17:33 OpenWrt kernel: [ 0.000000] DMI: PC Engines apu6/apu6, BIOS v4.12.0.5 09/25/2020
G10h4ck_ has joined #openwrt-devel
G10h4ck has quit [Ping timeout: 480 seconds]
<G10h4ck_> I am fiddling with hostapd, is there a way the make clean it only and force also redownloading from git branch ?
<vulpes2[m]> ynezz: yeah that's the patch I've tried and it worked when I force built pylibfdt as well
<vulpes2[m]> but now it has stopped working and I get a huge spam of errors swig, apparently now it thinks every character in basedir is an option
<vulpes2[m]> *from swig
<stintel> philipp64: haven't tried, Thermi suspects a read from /dev/urandom failed
<philipp64> low entropy?
<philipp64> Because the failed to allocate looks like an OOM/memory leak to me.
<stintel> there is 3.5GB of free memory
<stintel> 5.10 is now also showing the same behavior :/