<aparcar[m]>
Pepes: I didn't set it up, neither did I for any of my other repositories where it alerts me whenever some security issue appears. My point it, I think it's enabled by default and now is the first time it alerted. We can just disable it
<aparcar[m]>
I just disabled it in the setting
<aparcar[m]>
would be cool however to make it work with makefiles
Monkeh has quit [Quit: No Ping reply in 180 seconds.]
Monkeh has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<philipp64>
aparcar[m]: what's the address for the admins?
<aparcar[m]>
philipp64: did you ever touch any libressl stuff?
<philipp64>
No, just openssl
<philipp64>
Why?
<aparcar[m]>
philipp64: I'm trying to compile something with libressl rather than openssl and I get an error, as I'm entirely clueless I was wondering if it's an issue which is complicated or not
<aparcar[m]>
The packages uses EVP_MD_CTX_FLAG_FINALISE which isn't found in libressl
* russell--
is seeing weirdness on meraki mr24 ethernet, if i cold boot it, link appears, but no traffic. if i boot via an older recover firmware, then warm boot, ethernet passes traffic
<russell-->
this is a recent v5.10 kernel build
<russell-->
v5.4 kernel does the same thing
<russell-->
the other end of the cable is a ubiquiti ERX
<philipp64>
aparcar[m]: looking at the code, I think it can be patched... just put #ifdef EVP_MD_CTX_FLAG_FINALISE / #endif around line 88 in apk_crypto.h ...
<philipp64>
The flag is for an optimization that's only relevant if you're doing signing (which you're not).
<aparcar[m]>
philipp64: people should pay you more
<Borromini>
aparcar[m]: hate to be that stickler but shouldn't device support commits include flashing instructions etc? 571511ef2994fbe617172217cd6df14d5614d184 has nothing of the sort. Not even a commit message beyond the title.
<Borromini>
aparcar[m]: nevermind me, forgot i was looking at your staging tree, not master >_>
<aparcar[m]>
Borromini: oh it's old I'm just dragging things
<Borromini>
:)
<russell-->
i thought maybe the er-x was relevant, but turns out not. plugged into a normal dumb switch, same behavior ... going back to previous builds to see if i can bracket where the problem was introduced.
<russell-->
r15696-17fa01bb79 was fine
<russell-->
r16186-bf4aa0c6a2 is also fine
<Borromini>
russell--: what's happening?
<russell-->
ethernet not working on cold boot on mr24
feriman has quit [Quit: WeeChat 3.1]
<russell-->
if i boot a working kernel, then warm booting after is fine.
<russell-->
warm booting for a not-good kernel still doesn't work
<russell-->
so, /me expects some register isn't being configured correctly
<Borromini>
with 5.10?
<russell-->
both
<russell-->
5.4 and 5.10
<russell-->
r16634-5d8ea6d34f is bad
<Borromini>
oh :-/
<russell-->
i don't usually cold boot devices in the testbed, so i hadn't noticed previously
<philipp64>
aparcar[m]: well, anything would be a start. I fixed several sev5 potential CVE's and that's apparently not worth paying...
<philipp64>
I know people who would pay a lot to know about potential exploits.
<russell-->
r16516-e6d66375cb also bad
plntyk has quit [Remote host closed the connection]
plntyk has joined #openwrt-devel
claviger-pc has joined #openwrt-devel
<claviger-pc>
does anyone know if the SXTsq Lite2 (RBSXTsq2nD) works with the builds for the LHG 2 (RBLHG-2nD) as suggested in the wiki (https://openwrt.org/playground/mikrotik_test) ??
<PaulFertser>
claviger-pc: do you think it's unsafe to just try to verify that?
<claviger-pc>
I would be willing to try, but I would rather not have to buy the device to try it
<plntyk>
claviger-pc, same cpu, same flash size, same eth port speed - so it might be compatible
<claviger-pc>
I have run openwrt on unsupported devices, so I am not bothered by it, but I do not have time for developing support for it, just need a solution for a good high power AP
<claviger-pc>
the wiki implies that it is the same board inside as the LHG 2, but this is not confirmed precisely in the Mikrotik documentation
<PaulFertser>
claviger-pc: oh, I wouldn't recommend mikrotik anything for running OpenWrt these days. They tend to use some tricky partitioning and calibration data storage, so even many boards that were "nicely" supported with ar71xx can not run current releases (ath79) unfortunately, and it involves plenty of development effort to fix.
claviger-pc has quit [Remote host closed the connection]
<PaulFertser>
claviger-pc: well, hardware might be a bit better but the decisions made by vendor developers make supporting it too tricky.
<PaulFertser>
claviger-pc: oh, I wouldn't recommend mikrotik anything for running OpenWrt these days. They tend to use some tricky partitioning and calibration data storage, so even many boards that were "nicely" supported with ar71xx can not run current releases (ath79) unfortunately, and it involves plenty of development effort to fix.
<plntyk>
PaulFertser, was there some post on that - where ? mailing list or forums ?
<PaulFertser>
plntyk: hm, not really, I'm not following it too closely. You can compare the list of mikrotik boards for ar71xx and ath79, and then check mikrotik "github pull requests" and pending patches.
rmilecki has joined #openwrt-devel
<russell-->
r16433-e48c6400e4 seems to be good
<claviger-pc>
PaulFertser: okay, that is a big help to know! Thanks! I will just go with the cpe210 then, as it seems well supported
<PaulFertser>
claviger-pc: look at hw revision too, always, for all vendors.
<claviger-pc>
yeah, for the cpe210, there are 3, and it seems like current models are v3, supported. Also, ordering amazon, fast delivery and easy return
<PaulFertser>
The most impressive built quality in "home AP/router" equipment I saw was in xiaomi mir3g-v1. But then they released locked-down v2 which was a completely different board, so damn them.
adschm has joined #openwrt-devel
<mangix>
nbd: thanks for merging
<nick[m]4>
blocktrron: did you already test owe wolfssl fix? xD
<PaulFertser>
plntyk: yes, but it's not only partitioning borders. It's also related to using tricky erase sizes on SPI models (that nobody else used), it's also about packing essential board configs (including wireless calibration data) in obscure ways.
<zorun>
CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
<jow>
this is currently being dealt with by kill_remaining (so its not worse as before) but since that will happen pretty much immediately after the service delete calls, procd will not have a chance to cleanly shut down the services according to their init script params (signal, wait time etc.) before the uncodintional TERM signals are delivered
<jow>
apart from that, the commit is a good intermediate step imho and it will solve the problem of procd respawning stuff unintentionally
<xdarklight>
hauke: my VDSL download speed problem is getting weird: something during system boot halves the performance. when I start a 1GiB download (http://mirror.de.leaseweb.net/speedtest/1000mb.bin) right after DSL showtime on my computer (connected via the ath10k wifi) then the average download speed of that file is ~10MB/s (that's 80Mbit/s). Starting the same download after the first iteration is through my download speed drops to ~5MB/s
<xdarklight>
hauke: so we may still have some IRQ issue, but I don't understand (yet) why it seems to be fast for any connection which is established right after DSL showtime but then getting much slower afterwards. I guess I'll try with another device and start with a fresh system configuration to narrow it down
<blocktrron>
can you provide me a full 5.10 dmesg?
<russell-->
yeah, still building, standby ...
<wb9688>
This is why those new fancy CPUs with lots of cores are awesome; they're so quick at conpiling stuff
<blocktrron>
I should've just not touched this at803x mess
<blocktrron>
OTOH, it would've broken inevitably with the next kernel
anxy has joined #openwrt-devel
<russell-->
fwiw, i checked some of my older builds and for 5.10, 16142-g12dbad1a86 (circa march 9) was okay, and 16516-ge6d66375cb (circa april 13) was bad
<blocktrron>
AT803X was not enabled for 5.10 until r16091, so i wonder how it was supposed to work on earlier revisions. See 18a9eff0f607139bc0215197ed8957432d5632e8
<russell-->
that's ath79, the mr24 is apm821xx
<blocktrron>
urgh
<blocktrron>
Okay
<blocktrron>
i got cisco'd
* russell--
runs errand, back in 15m
<blocktrron>
russell--: build 5.10 again from my staging tree please
<djStolen>
hi all. as i mentioned couple of days back, i bricked my xiaomi 3c router even though doing everything as described here: https://openwrt.org/toh/xiaomi/mir3c
<djStolen>
meanwhile, i digged myself a little bit
<djStolen>
and figured out that breed bootloader is not open sourced.
<djStolen>
at least havent found any source myself
<mangix>
strange
<mangix>
include/prereq-build.mk is totally broken
<djStolen>
also found out that u-boot is supporting uC used in Xiaomi 3C and while doing my research found many more info, also did some board research myself. So would like to share this knowledge with the rest of you, therefore, could u give me the access to edit this page?