<Grommish>
aparcar: Last email I saw on that was Hauke wanting to switch it to source-only
hgl has quit [Quit: Bye]
<Grommish>
There have been conflicting reports on whether the mem leak observed was corrected or not and if there are two separate issues involved
rua has quit [Quit: Leaving.]
swalker has quit [Remote host closed the connection]
Acinonyx_ has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Acinonyx has quit [Ping timeout: 480 seconds]
Acinonyx_ has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<Slimey>
Grommish np
philipp64 has joined #openwrt-devel
rua has quit [Quit: Leaving.]
minimal has quit []
philipp64 has quit [Quit: philipp64]
amaumene has quit [Read error: Connection reset by peer]
amaumene has joined #openwrt-devel
<kerneltoast>
mangix: you can still achieve similar functionality to XDP's ingress filtering by using eBPF TC, but TC is indeed slower because the TC hooks run after the SKB is created. XDP also has a generic mode that doesn't require driver support, but it's not as fast as running XDP hooks directly in the driver
danitool has quit [Ping timeout: 480 seconds]
<mangix>
kerneltoast: right. My line of thinking is: XDP ethernet driver == fast qosify. no XDP driver == slower qosify.
<kerneltoast>
xdpgeneric == medium qosify
amaumene has quit [Read error: Connection reset by peer]
amaumene has joined #openwrt-devel
<mangix>
in the case of mvneta (marvell ethernet driver), it supports hardware buffers (enabled by default currently) and XDP (enabled if hardware buffers are off)
<mangix>
It's an open question if disabling hardware buffers would be better for QoS reasons
philipp64 has joined #openwrt-devel
<kerneltoast>
mangix: hardware buffers can't coexist with XDP since the CPU needs to see the packets to run your XDP programs i guess
<kerneltoast>
you could buy a really expensive netronome NIC with XDP offloading support though :P
<mangix>
rsalvaterra: you should bump ramips to 5.15 using Ansuel's work as a base so I can test it :).
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<aiyion>
I'm trying to build an initramfs, now that I've got the spi backed up. The uboot on the device has an "image check" in place, that seems to enforce the name of the image to be "R2" instead of "MIPS OpenWrt Linux-5.10.96" can someone point me to devices, that have a similar quirk? mt76x8
<aiyion>
I think I'm aiming for a uimage
<aiyion>
(with the image name "R6"
<rsalvaterra>
mangix: I'm still not sure if we should default to zstd by default for zram.
<gch981213>
aiyion: UIMAGE_NAME works for sysupgrade, but I'm not sure whether it works for initrd. You can give it a try.
<aiyion>
gch981213: odes not matter, as long as anything boots. thanks!
goliath has joined #openwrt-devel
<aiyion>
gch981213: just tested: UIMAGE_NAME odes affect the initramfs image as well. Thank you!
srslypascal has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
<aiyion>
the image name worked well, that error is gone. But after checking it, the device goes straight on to the installed uboot and powers up like it would normaly.
<aiyion>
The oem-images do contain their own uboot. Is there possibly a need to do this as well? Or does my image simply not meet another criteria and fails silently, so thedevice just starts from the beginning much like a reboot?
<aiyion>
ah no thats for offsets in the partitions apparently
GNUmoon has joined #openwrt-devel
<aiyion>
I padded the current initramfs with the first 0x50000 of an oem image, now I at least get a proper error: "flash image
<aiyion>
In RSAVerify(): Hash check failed!
<aiyion>
rsa_verify: rsa verify failed: -1
<aiyion>
rsa verify failed
<aiyion>
" the line flash image did not come up in the serial console before, so I am looking for the openwrt-way to build an image similar to what I just did with dd.
<aiyion>
How to I pad the resulting image with 327680 bytes of 'valid' garbage, such that the uimage header lies in 0x50000 in the resulting image?
<aiyion>
not pad, but prepend, sorry.
<Borromini>
aiyion: doesn't the error message suggest you'd need some kind of key to encrypt the image with also?
<Borromini>
one you should be able to extract from the OEM image
<aiyion>
possibly; I've only done one device yet and that was an ar71xx-ath79 conversion.
<aiyion>
I figured my image validity is a problem to solve afterwords.
<aiyion>
without prepending the image I do not reach the rsa error.
GNUmoon2 has joined #openwrt-devel
<Borromini>
no idea about that, sorry
<Borromini>
what device is this?
<aiyion>
cudy lt400
<aiyion>
2.4GHz wifi router with a LTE modem.
<Borromini>
i'm seeing e.g. IMAGE/default := append-kernel | pad-offset $$$$(BLOCKSIZE) 64 | append-rootfs in target/linux/ath79/image/generic.mk
<Borromini>
maybe that's something you can try (more examples in the makefiles)
<aiyion>
this device is not ath79, but that feature is likely generic across targets?
<aiyion>
ramips mt76x8
<Borromini>
i reckon it's pretty generic, but you can check the mt76x8 makefiles
GNUmoon has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
bluew has quit [Quit: Leaving]
<rsalvaterra>
mangix: You there?
<aparcar>
hauke: stintel ping
<aparcar>
what do we do with octeon? i'd like to prepare stuff before our next meeting on the 15th
<stintel>
10|14:48:12 < stintel> so I'm going to conclude it's very rare to hit it and switch octeon to 5.10
<stintel>
feel free to merge your PR, I was going to do it in the weekend probably
<aparcar>
stintel: thanks I'll merge it
<aparcar>
I missed that message
<rsalvaterra>
aparcar: "Playing" with Ansuel's 5.15 preliminary pull and ramips/mt7621. Make that what you will. O:)
<rsalvaterra>
Hopefully I won't go blind. :P
<aparcar>
rsalvaterra: uhm, does it fix 11s or how would that concern me?
<aparcar>
I'm just the one looking that ./scripts/dump-target-info shows me a lot of 5.10
<Borromini>
:P
<rsalvaterra>
Oh, sorry, new context.
<aparcar>
stintel: can I add acked by you to the bump?
<aparcar>
rsalvaterra: yea, on mt7621 specifically
<aparcar>
how am I supposed to build a management mesh network with that...
<rsalvaterra>
Hm… that's the mt76 driver, not the MT7621 SoC, right?
<aparcar>
yea I guess
<rsalvaterra>
I'd say that's nbd's turf… I'm not really into the sordid details of mt76. :/
mitome has quit [Remote host closed the connection]
mitome has joined #openwrt-devel
mitome has quit [Remote host closed the connection]
<rsalvaterra>
blogic: Is 315-owrt-hack-fix-mt7688-cache-issue.patch still relevant? It's a hack from 2015… :/
nitroshift has quit [Quit: Gone that way --->]
<aiyion>
This feels like poking in the dark -.-'
daemon has joined #openwrt-devel
<aiyion>
pad-extra looks promising
daemon has quit [Quit: Page closed]
<aiyion>
or not.
eduardo010174 has joined #openwrt-devel
pmelange1 has joined #openwrt-devel
<aiyion>
If someone has time to throw a hint: Im looking for a way to prepend the uimage with whatever like this https://bpa.st/EFTA Currently I only have the latter: https://bpa.st/YU6A
pmelange has joined #openwrt-devel
pmelange1 has quit [Ping timeout: 480 seconds]
pmelange has left #openwrt-devel [#openwrt-devel]
<aiyion>
afk for 20 minutes...
rua has quit [Ping timeout: 480 seconds]
dwmw2 is now known as dwmw2_gone
rua has joined #openwrt-devel
Borromini has joined #openwrt-devel
dangole has joined #openwrt-devel
gch981213 has quit [Quit: leaving]
valku has joined #openwrt-devel
SherlockDomes has joined #openwrt-devel
minimal has joined #openwrt-devel
<SherlockDomes>
Hi all, when using an external toolchain how does OpenWRT know where to look for kernel userspace headers?
<SherlockDomes>
And one other question, why do we need to patch-spec the toolchain? Is it simply to add references to STAGING_DIR? I assume the kernel userspace headers included will be the paths builtin into gcc and not any directiroy in staging_dir?
<SherlockDomes>
thanks!
<jow>
SherlockDomes: yes, patch-spec is done to make gcc search everything relative to STAGING_DIR
<jow>
kernel userspace headers are simply expected to reside in $STAGING_DIR/include/linux
<jow>
unless I misunderstood your question
<SherlockDomes>
Ahh ok makes sense, thanks! so we are supposed to copy Linux userspace headers from the cross-toolchains original search directory to $STAGING_DIR/include/linux?
<SherlockDomes>
I'm not an expert on cross-toolchains, but my assumption is that a cross-toolchains needs to be built against a specific Linux user space headers, specficially the libc associated with the toolchain is built against a specific Linux user headers. So you're not supposed to decouple them.
<SherlockDomes>
sorry gotta head, bbl
Borromini has quit [Ping timeout: 480 seconds]
AndyCap has quit [Server closed connection]
AndyCap has joined #openwrt-devel
<stintel>
typical. octeon switched to 5.10 in master and what do I see now? leak :P
<stintel>
so I configured macvlan, but the image I was running didn't have macvlan included, and then I started seeing the leak
<stintel>
could the ethernet driver leak things when it's receiving packets but has no L3 config?
<mangix>
rsalvaterra: pong
<rsalvaterra>
mangix: I've been looking at 5.15 on ramips, but some patches aren't that trivial to rebase. Others don't apply at all because the files were moved/deleted.
<rsalvaterra>
(Hopefully that means the patches aren't needed anymore, but I'm not so sure.)
<aiyion>
Can somebody tell me whether there's an option to have the uimage start at an offset, if there is no other relevant content before?
KGB-1 has joined #openwrt-devel
<aiyion>
Or tell me whether I'm on the wrong track?
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
huaracheguarache has joined #openwrt-devel
<huaracheguarache>
I'm trying to figure out how hostapd/wpa_supplicant features are advertised and used by luci to only present the relevant options when configuring a network. I looked at how luci finds out whether SAE is supported.
<huaracheguarache>
And I saw this in the code: local has_ap_sae = (os.execute("hostapd -vsae >/dev/null 2>/dev/null") == 0)
<huaracheguarache>
How does the command hostapd -vsae >/dev/null 2>/dev/null actually indicate sae support?
noltari_ has joined #openwrt-devel
noltari has quit [Read error: Connection reset by peer]
noltari has joined #openwrt-devel
noltari_ has quit [Ping timeout: 480 seconds]
<aiyion>
So i got it assmbled the way I intended, using: IMAGE/tftp-recovery.bin := append-string -e '\x00' | pad-to 320k | $$(sysupgrade_bin)
<aiyion>
And yes, I am on the wrong track, as I still need a valid header at the beginning of the file.
<aiyion>
So append-string has to go and make place for something useful.
<aiyion>
is append-uImage-fakehdr useful for this purpose?
Larhzu has quit [Server closed connection]
Larhzu has joined #openwrt-devel
* enyc
meeps
<enyc>
rsalvaterra: how much trouble is there to patch in 5.15 support for various architectures instead of 5.10 , ooi?
mrkiko has quit [Server closed connection]
mrkiko has joined #openwrt-devel
<rsalvaterra>
enyc: Pretty much the same, I guess. There are a lot of changes between five kernel versions (5.10 -> 5.15) and rebasing can become really tricky really fast.
<rsalvaterra>
Especially when it comes to core kernel code.
<huaracheguarache>
Never mind, I figured out that it uses the exit code generated by the command to check whether a given feature is included.
<rsalvaterra>
Or when drivers move from the staging area to the kernel proper. That's one of the problems with the ramips code.
<mangix>
not really. I think the most I did with APK was fixing compilation without deprecated OpenSSL APIs.
<aparcar>
ok
<jow>
aparcar: for which cases is rthe format without arch required?
f12 has quit [Server closed connection]
<aparcar>
are you familiar with "path" issues using Linux vs macOS? Using dirname works fine on macOS but fails in the Ubuntu CI. Now I manually patched those path together and again it works on macoS but fails on Linux...
f12 has joined #openwrt-devel
<aparcar>
jow: The arch is dynamicaly added, however OpenWrt already adds those via feeds.mk
<aparcar>
Always attaching the arch would cause trouble with <target>/packages/ since it would become <target>/packages/<arch>/
<aparcar>
so I patched it away and now work on a "upstream" friendly implementation
<jow>
for target/packages we could introduce a symlink <target>/packages/<arch> -> ..
<jow>
the patch you linked mentions dirname but does not actually use dirname(3)
<aparcar>
jow: we can just patch it away, upstream is already interested in it. The index format changes anyway away from APKINDEX.tar.gz to something called .adb (flatbuffer database)
<aparcar>
jow: outdated commit message, some APK dev suggested to use the APK internal "blob" format and it's handling. I'm trying to make sense of it but it's... confusing
<aparcar>
e.g. APK_BLOB_STR is a struct of char (ptr) and len (int)
<jow>
you want to attach something?
<jow>
*append
<aparcar>
I want to rsplit the repository and append the package path. <url>/packages.adb becomes <url>/package_name.apk
<aparcar>
jow: this does the trick but I don't think it pretty right.len = PATH_MAX - strlen(uri.ptr);
<jow>
aparcar: no it touches internals
<aparcar>
yea I don't mean to say it any good
<jow>
aparcar: the design idea of those blobs appears to be that the size is immutable
eduardo010174 has quit [Remote host closed the connection]
<jow>
so you have to create a new blob, which means allocating it on the heap most likely and freeing it
<jow>
so you have to 1) rsplit and take left
<jow>
2) figure out the length of the filename
<aparcar>
I'll give upstream a day to comment, I'm sure there is a single command meant to do this stuff which I just don't know about
<jow>
allocate a char * of size (length(left) + strlen("/") + length(filename) + 1)
<aparcar>
filename doesn't support strlen since it's some macro magic
<aparcar>
at least that's how I understad it
<jow>
wrap that into a blob using APK_BLOB_PTR_LEN(allocated_char, calculated_size)
<jow>
then push the left part onto that new blob
<jow>
then push the filename onto that new blob
<jow>
then use the result
<jow>
then free it
<aparcar>
all right I'll try that
<aparcar>
I gotta go now but will be back in some 3 hours to figure things out
<aparcar>
thank you for looking into it, I may develop a taste for this pointer magic
<Habbie>
it is better to develop a taste against the pointer magic, but a skill for it ;)
<jow>
aparcar: other parts of apk simply use to work with char buf[PATH_MAX]; buffers
<jow>
so you should do the same
<jow>
the internal blob stuff will ensure that its never overflowed
<jow>
and you need to hope that no URL is ever longer than 4096 byte or so
<hauke>
aparcar: pong
<jow>
so basically use the approach outlined above but skip the size caluclation and initialize the new blob using APK_BLOB_BUF(buf)
<mangix>
Habbie: OTOH C++ references are quite nice
<jow>
which will set the size to sizeof(buf) internally
<Habbie>
mangix, oh yes
<enick_479>
jow: thanks, will report later
<jow>
enick_479: uhm, report what?
<jow>
ah, matrix broken nickname
philipp64 has quit [Quit: philipp64]
<enick_479>
jow: yea sorry for that, on mobile it’s matrix only
<olmari>
Sorry to intervene, but what are aparcar / jow talking about? =) (I'm generally very interested improving matrix, while context here is "nothing much")
<enick_479>
Sami Olmari: please help people to fix the oftc bridge
<stintel>
:P
<olmari>
mm... nodejs... something I've learned to hate :D
<olmari>
While at same time, THIS I can relate into
<Borromini>
:P
<aiyion>
is it possible, tftp would be configured to run an image with an offset?
<aiyion>
or is it more probable the image starts with a second uboot, which then tells the process to go on at the offset?
<olmari>
..I mean.. I love matrix while I know not perfect.. I also can understand some peeps still liking irc for their own reasons.. I absolutely love generally the matrix-irc bridge what it aims to be.. but I absolutely hate the thing failing in these kind of ways
philipp64 has joined #openwrt-devel
shibboleth has joined #openwrt-devel
<enick_479>
hauke: just wanted to cheeck in on octeon but stintel responded already
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<stintel>
I'm about to give up on Matrix, they managed to completely kill federation in dendrite somehow
<olmari>
stintel: I'd love "reference" to change to "not python" (well there'd be plenty not-nodejs style too, but anyway), while they don't care to speak about reference server anymore... while I can very well see individual nerd to homeserver admin/user to give up, at the moment I see best level is "hackerspace" or some otehr "non-profit" or simial sized homeservers to be practical
<olmari>
The deepest thing for me is that the protocol itself is just so damn killer, server implementations is then what they are
<olmari>
...but yeah... sorry about offtopic :)
<rsalvaterra>
mangix: Sorry, AFK, beer o'clock with the lady. I gave the rebasing a rest for the weekend. :)
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
dedeckeh has quit [Remote host closed the connection]