<neggles>
nick[m]1234: you're Doing It Wrong(tm) - you have a fixed-link defined when what you want is a PHY
<neggles>
ah wait you worked that bit out already
GNUmoon has quit [Ping timeout: 480 seconds]
dannyAAM has quit [Server closed connection]
dannyAAM has joined #openwrt-devel
Grommish has joined #openwrt-devel
<neggles>
what you're probably missing is 'phy-mode = "rgmii-id";' in the ð0, and your PHY is on MDIO address 1 according to the oem bootlog, not 10, there is no address 10 :P
<neggles>
the phy-mask of 0xf means it can only have an address of 0, 1, 2, 3 anyway
<nick[m]1234>
okay, thanks!
<neggles>
hmm
<neggles>
ah
<nick[m]1234>
maybe I should have flashed the factory
<nick[m]1234>
ah shit, I have to leave (no time anymore). thanks for your help!!! I will continue later.
<neggles>
load address and entrypoint don't match, but i am not sure
<neggles>
it's a very old u-boot
<neggles>
nick[m]1234: no worries, it'll be something to do with how you're generating the bin and/or how you flashed it
<neggles>
you should be rambooting the initrd image, then using `sysupgrade -n -p` (I think, the 'don't keep config' and 'ignore partition mismatch'/don't check compatibility flags) to flash the sysupgrade.bin, if that doesn't work it's an image generation issue
csharper2005 has joined #openwrt-devel
danitool has joined #openwrt-devel
<aparcar[m]>
jow: thoughts on tagging ucode?
<jow>
nbd: ping
<jow>
aparcar[m]: not yet
<jow>
nbd: I have a question regarding the intent of the uloop_run_timeout() api. Is the (positive) timeout passed there meant to be a hard limit on how long the uloop will run in total?
<jow>
nbd: because the timeout argument appears to have no effect on a uloop only managing fds or processes and not timeouts
<jow>
nbd: if the timeout is not meant to control the overall runtime limit of the uloop, what is its purpose exactly then? Ensure to prematurely interrupt uloop_timeouts?
<nbd>
i don't really remember, it was too long ago
<nbd>
from reading the code the behavior seems a bit weird
<nbd>
i think we should probably change it to try to limit the loop runtime from the time the function is called + timeout
Tapper has joined #openwrt-devel
<jow>
right, so uloop_run_timeout(2000) would mean that the function returns after roughly 2000ms
<jow>
(or if a signal was received)
<nbd>
yes
<kabel>
is somebody working on upgrading kernel to 5.15 on openwrt?
<slh>
Ansuel has been working kernel 5.15, for ipq806x (and presumably x86), taken up by robimarko for ipq40xx and ipq807x
<kabel>
there have been tons of patches for DSA and backporting them is a great pain in the ass
<kabel>
I am thinking about working on 5.15 for mvebu
<slh>
kernel 5.15.30 works well for me on ipq8071a
xback has quit [Remote host closed the connection]
<aparcar[m]>
jow: since the ucode CLI refactoring my tempalte no longer works, I now execute it via `ucode -T -- index.html` but it no longer finds the `fs` module
<enyc>
AIUI OpenWRT has fun contributing to upstreaming or patching-in support for devices/architectures, and backporting newer wifi features to older LTS kernels, or so.
robimarko has joined #openwrt-devel
<jow>
aparcar[m]: do you load it via require?
<jow>
whats in your template?
<robimarko>
kabel: I did port the A72 to 5.15 for RB5009
<jow>
aparcar[m]: maybe run under strace to see where it looks for the module
<aparcar[m]>
I'm just trying to rework the downloads page using ucode
<jow>
if its not installed in the standard /usr/local/lib/ucode/ location, you might need to apss the path via -L
<aparcar[m]>
jow the argument parsing seems a bit off. `../ucode/build/ucode -L ../ucode/build/ -T -- index.html` does the trick. `-T` seems to always want a flag, making it non optional
<aparcar[m]>
Unrecognized -T flag "--", ignoring
<robimarko>
slh: I eventually got the Dynalink from that ebay posting
<robimarko>
With forwarding under 80 EUR, so I had to get it
<jow>
aparcar[m]: macos?
<slh>
robimarko: hey, good price - especially including the shipping.
<robimarko>
slh: Yeah, made and offer so it was reduced to 66 with DE shipping and then 13 EUR for MailboxDE
<robimarko>
We will see if its usable or Askey are enforcing signed FW
<slh>
:)
<aparcar[m]>
jow: yes
<\x>
robimarko: i remember that youve tried qca6391 on ipq40xx, how much of bottleneck it is? seems that card's availability is getting better now on taobao atleast
<robimarko>
You mean the card or CPU power?
<jow>
aparcar[m]: then it's a macos specific getopt() issue. macos does not understand optional arguments
<\x>
well, the cpu I guess
<aparcar[m]>
jow: yikes
<robimarko>
\x: To be honest I did not really benchmark that but it shouldnt be a bottleneck
<robimarko>
Its just a basic 2x2 card
<slh>
\x: given the CPU/ IRQ usage, I wouldn't expect a PCIe qca6391 card on a ipq40xx SOC to be much faster than the stock 2x2 wireless (I mean ipq4019 is often coupled with qca9884 for mesh devices)
<robimarko>
Plus the threaded NAPI does wonders in ath11k
<aparcar[m]>
jow: maybe you could add a "none" flag as a workaround?
<\x>
175 cny currently on taobao, its going lower and lower every month i check
<\x>
but yeah ill prolly order one once ath11k works and doesnt it need 5.15?
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<rsalvaterra>
Oh, speaking of threaded NAPI, robimarko… nbd, I'm running my ath10k-ct driver with your experimental threaded NAPI patches and they seem to be working just fine.
<\x>
currently i just stuck on an 8260AC on my gateway as an extra radio for random things, so that would be nice to be replaced sometime
<robimarko>
Yeah, it currently needs 5.15
<robimarko>
Somebody was doing the backporting to wireless-backports for QRTR and MHI
<robimarko>
No idea whats the status of that
<jow>
aparcar[m]: you can use a sole comma (",") as "none"
<aparcar[m]>
works, thank
<aparcar[m]>
yo
<aparcar[m]>
jow: does ucode support sorted dicts?
<aparcar[m]>
so if the input contains a sorted object, is there a way to access the "nth" element?
<jow>
dict[keys(dict)[n]]
Tapper has quit [Ping timeout: 480 seconds]
<nbd>
robimarko: how well is ath11k working for you?
<nbd>
rsalvaterra: cool, i think we should push the patch soon
<aparcar[m]>
jow: excellent
<robimarko>
nbd: Well, it seems to working quite well for IPQ807x
<aparcar[m]>
btw did you consider to rename it again? ucode is some intel/amd specific foobar which ruins search results. it's the same as for apk
<robimarko>
I did backport everything from ath-next though and am keeping it in sync cause there is a lot of work on the driver
<robimarko>
Its been months now with a decent group using it
<nbd>
cool
<nbd>
have you done any throughput tests under decent conditions?
<\x>
nbd: is mt7921k getting ap mode or still nah?
srslypascal has quit [Ping timeout: 480 seconds]
<jow>
aparcar[m]: not yet, maybe in the future
<jow>
aparcar[m]: btw, you can pass in that releases JSON via the cli too and avoid the json parsing block, just do -F releases=releases.json
<robimarko>
nbd: Yeah, the last one when we were discussing threaded NAPI and testing that.
<robimarko>
With my Poco F2 Pro on HE80, I got around 720Mbps and the load is spread on the CPU
<robimarko>
This includes WAN to LAN routing overhead as well
<aiyion>
urgh. building openwrt does not work -.-' my bison is linked against a libraray its dependency gettext no longer includes ...
<nbd>
robimarko: is that 2x2
<nbd>
?
<robimarko>
It should be, I doubt my phone can do 4x4
srslypascal has joined #openwrt-devel
srslypascal is now known as Guest2715
srslypascal has joined #openwrt-devel
<aparcar[m]>
jow: beautiful
Guest2715 has quit [Ping timeout: 480 seconds]
<nbd>
robimarko: would be interesting to know how well it holds up on 4x4
<robimarko>
Only 4x4 devices would be other IPQ807x boards I have
<robimarko>
I dont have any other 4x4 AX clients
<russell-->
aiyion: make dirclean fixed it for me
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
gleb has joined #openwrt-devel
<gleb>
Hello, does someone know how are generated the last two bytes of a firmware image (crc16 checksum I think)? What part of the code this cheksum is calculated?
<aiyion>
russell--: thank you.
gladiac has quit [Quit: k thx bye]
<PaulFertser>
gleb: what image?
<gleb>
Openwrt
GNUmoon has quit [Ping timeout: 480 seconds]
gladiac has joined #openwrt-devel
<PaulFertser>
gleb: sysupgrade images?
<PaulFertser>
gleb: that's the Build/append-metadata step, you can see it in include/image-commands.mk
<gleb>
Ok, thanks
<aparcar[m]>
jow: thoughts on using ucode within fastcgi?
<PaulFertser>
gleb: so the last two bytes are part of 4 bytes which contain the size of the appended data.
GNUmoon has joined #openwrt-devel
<PaulFertser>
gleb: what do you need it for?
srslypascal is now known as Guest2726
srslypascal has joined #openwrt-devel
Guest2726 has quit [Ping timeout: 480 seconds]
<rsalvaterra>
OMG, 5.4 is dead, woohoo! \o/
srslypascal has quit [Ping timeout: 480 seconds]
<robimarko>
Its had a long and productive life
<f00b4r0>
question for the network/mt76 experts, I've tried duplicating a network configuration that works for QCA devices and it doesn't here. Specifically, I have a wlan interface enslaved to a VLAN bridge, and a server (CoovaChilli) sending DHCP OFFER to a client DHCP DISCOVER. When I tcpdump wlan on the mt76 device I "see" the DISCOVER/OFFER coming in/out of the interface, but tcpdump on the client shows the OFFER never coming, instead the
<f00b4r0>
trace only shows an unknown LLC DSAP supervisory packet coming back in lieu of the OFFER. Any idea what could be happening? This is running 21.02.2, the mt76 is DSA enabled.
srslypascal has joined #openwrt-devel
srslypascal is now known as Guest2728
srslypascal has joined #openwrt-devel
Guest2728 has quit [Ping timeout: 480 seconds]
csharper2005 has quit [Remote host closed the connection]
<f00b4r0>
hmm the ethertype seems incorrect, the rest of the packet is good. /me scratches head
tohojo has quit [Quit: Bridge terminating on SIGTERM]
Forst has quit [Remote host closed the connection]
tohojo has joined #openwrt-devel
<jow>
aparcar[m]: could you add some CI that builds .deb artifacts automatically on pushes?
<f00b4r0>
hmm this makes no sense. The packet is correct except for the ethertype which is 0x0158 instead of 0x8000. And this only happens when talking through the vlan bridge, not when using the wlan directly
<f00b4r0>
there's some consistency. ARP 0x0806 consistently becomes 0x001c. IPv4 0x0800 (not 0x8000 as I said earlier) is always 0x0158
<jow>
not a simple shift then
<f00b4r0>
no. And it seems I spoke too soon. I do see some variations based on packet length
<jow>
this is without reverting that memset patch, right?
<f00b4r0>
yes; I'm still waiting for the build to complete
<f00b4r0>
actually, still wiating for my build system to boot. It's taking an awfully long time. Murphy's law may be striking here :P
lynxis has quit [Remote host closed the connection]
csharper2005 has joined #openwrt-devel
<f00b4r0>
here we go
lynxis has joined #openwrt-devel
<f00b4r0>
oh
<f00b4r0>
that invalid ethertype *is* the data length + 4
<ynezz>
off-by-length
<f00b4r0>
4 is the size of a vlan tag if I'm not mistaken
<aparcar[m]>
jow: yes
<karlp>
f00b4r0:yup
<Pepes>
robimarko: What is your opinion to update mvebu u-boot in the stable branch?
<karlp>
you get a new "ethertype" 16bit, then vlan.
<f00b4r0>
karlp: *nod*. Although I can't figure what could cause the ethertype to be swapped with payload length. Unless it's 802.2 LLC (as tcpdump believes) but I'm not sure how that makes sense
<f00b4r0>
about to boot with the reverted patch
<karlp>
it just length by coinciddence?
* karlp
shrugs. been a few years since I've looked at that stuff.
<f00b4r0>
doesn't look like it. It *is* length (+4)
* f00b4r0
notes that wikipedia mentions that LLC is used on 802.11
<robimarko>
Pepes: I am really not a fan of that
<f00b4r0>
no dice.
<karlp>
f00b4r0: iirc, there's ethernet II, that is len instead of ethertype?
<karlp>
but ... that would be weird, it's not very compatible.
<f00b4r0>
jow: reverting didn't fix.
<Pepes>
robimarko: :-( Too bad. I would appreciate that since it will help us to test fewer things and be able to use the version, which is in upstream and users might enjoy new features, which they wanted to enable in defconfigs. And fixes a lot of issues for A3720 together with A38x.
<f00b4r0>
and I just checked it doesn't affect an ethernet interface bound to the vlan bridge.
<f00b4r0>
it's only the wireless interface that goes nuts.
<ynezz>
Pepes: what is preventing to use that version in your project?
<robimarko>
Pepes: But what is the point of a stable version then?
<f00b4r0>
and it appears to be specific to mt76 because I have the exact same setup running just fine on QCA9533
* f00b4r0
starts looking at patches, not completely sure where to hunt
csharper2005 has quit [Quit: Page closed]
csharper2005 has joined #openwrt-devel
Tapper has joined #openwrt-devel
<f00b4r0>
ha. it's chilli-related somehow. In a similar setup without chilli running, the packets are normal.
<f00b4r0>
why am i not surprised :P
<jow>
any tunnel stuff involved?
<f00b4r0>
yes
<jow>
hmm
<f00b4r0>
chilli tunnels through a tun device to segregate authorized/non-authorized devices
<jow>
right, I remember
<jow>
its a tap device I suppose?
<f00b4r0>
tun
<f00b4r0>
jow: any idea?
<jow>
nope, sorry
<f00b4r0>
ok. I thought you were onto somethign when you asked about tunnel :)
<f00b4r0>
what boggles the mind is that according to tcpdump, the packets go out on the wlan interface with the correct ethertype
<f00b4r0>
and they arrive on the other side with the wrong one.
<f00b4r0>
why must I always hit those obscure bugs nobody else experiences. *sigh* ;P
<f00b4r0>
i was wrong, the length isn't +4, it's the actual length. I was confused because as the packet is partly decoded as LLC, the first 4 bytes of the payload are decoded separately.
<f00b4r0>
so somewhere between the linux interface and the radio, something decides that ethernet frame should be treated as 802.3
ekathva has quit [Remote host closed the connection]
<ynezz>
f00b4r0: can't you simply remove the coova-chilli from the equation?
<f00b4r0>
ynezz: sure, except the point is to have coova-chilli running
<f00b4r0>
and I can't quite figure what this software could do that would cause the mt76 wireless driver to do what it appears to be doing
<f00b4r0>
so somewhere in there lies a bug.
<f00b4r0>
but I'm a bit out of my depth here ;P
<ynezz>
we call it printf afternoon
<PaulFertser>
I wonder if you can probably make a pcap of that packet and replay it with "aireplay-ng -r <file>".
<f00b4r0>
that's an idea
<f00b4r0>
ynezz: *sigh*
<PaulFertser>
If that reproduces the issue it would be quite handy for whomever cares enough about mt76. It would also remove bridging code etc from equation.
srslypascal is now known as Guest2737
srslypascal has joined #openwrt-devel
Guest2737 has quit [Ping timeout: 480 seconds]
mva_ has joined #openwrt-devel
mva has quit [Read error: Connection reset by peer]
f00b4r0 has quit [Quit: brb]
<kabel>
ynezz: I have backported some more DSA patches that fix stuff. Do I need first to create PR for master, and only after that for stable branch?
f00b4r0 has joined #openwrt-devel
mva has joined #openwrt-devel
<ynezz>
kabel: yes, I usually prefer to first push changes into master, wait some time (3-7 days for a feedback) and then push them into stable branch
<kabel>
ynezz: very well, I shall create PR for master first
<ynezz>
but in this case it's rather tricky as master is on 5.10 and 21.02 is on 5.4
mva_ has quit [Ping timeout: 480 seconds]
<ynezz>
so completely different environment
<kabel>
some of those patches I backport are in 5.10 but some are not, so a patch for 5.10 is needed as well
<kabel>
I am thinking about create a WIP PR for 21.02 where we can discuss this
<ynezz>
are those fixes going through stable@ as well?
<kabel>
no
<ynezz>
and why is that?
<kabel>
some of the patches are API changes. I guess we could try to send it to stable, but it is a great pain in the ass to backport DSA patches from modern kernels
<ynezz>
but rebasing/maintaining them is usually PITA multiplied by number of kernel bumps
<kabel>
in fact 5.4 kernel DSA has a ton of issues that were solved later but to backport all of them would make one go mad
<ynezz>
so other projects don't need those fixes?
<kabel>
ynezz: yes, well, it will still be less work (I guess much less)
<kabel>
ynezz: well for one thing the DSA roaming issue is sovled in 21.02 (and in master as well for now) in a way different from upstream kernel
<kabel>
ynezz: and my fixes are working with that
<kabel>
ynezz: the best solution for other projects is either to use newer kernel or don't try to use the unsupported things. The fact is that DSA is still under development
<kabel>
there are still things being worked on in net-next
<kabel>
in an email discussion about this Vladimir Oltean said to me "In any case, as somebody who has tried and failed to backport DSA stuff to kernel 5.10 and earlier, my advice is to abandon ship."
<kabel>
ynezz: I am also thinking about whether it wouldn't be better to use openwrt 21.02 but with kernel from master in new TurrisOS
<ynezz>
or just move to 22.03
<kabel>
that is still 5.10, the idea is to wait for 5.15 in master and then do it
<kabel>
the DSA forwarding/roaming was developed between 5.10 and 5.15
<kabel>
and is still being worked on but backporting from 5.18 to 5.15 is going to be easier
<kabel>
also LAG and other stuff is in 5.15, which will make it possible to finally implement multi-CPU DSA in upstream
minimal has joined #openwrt-devel
<robimarko>
kabel: Can we finally get rid of the nasty mv88e6xxx roaming fixes that were done in 5.4 days forcing VLAN1?
<robimarko>
Cause I think upstream sorted it out with some kind of offloading
csharper2005 has quit [Remote host closed the connection]
<kabel>
robimarko: for 5.4? I am not doing it :)
<robimarko>
No, I meant in 5.15
<kabel>
robimarko: yes, in 5.15 yes
<robimarko>
Sorry, did not really make it clear
<robimarko>
Trying to port that to 5.4 is just plain insanity
<kabel>
robimarko: but keep in mind that multi-CPU DSA won't work and the current implementtaion we have cannot be ported to 5.15
<kabel>
robimarko: it needs to be implemented differently on top of the forward offloading
<[florian]>
aparcar[m]: I did but have not have found a solution yet
<kabel>
is deng qinggang here on irc?
<robimarko>
kabel: I did not really play with multi-CPU
<robimarko>
Targets I use dont use it
<robimarko>
Though ATH79 and IPQ806x kind of need some kind of multi-CPU implementations
<kabel>
ynezz: the reason is to fix creating vlan interface. Currently the command `ip link add link lan1 name lan1.1 type vlan id 1` fails on 21.02 with "RTNETLINK answers: Resource busy"
<kabel>
ynezz: on master the creation of the interface should work, but fdb database will get mixed because of the hack that PR 9530 removes
Borromini has joined #openwrt-devel
<Pepes>
ynezz: Well, that's interesting idea. I hope that you would not ask, but I can play on our playground until it arrives in the upstream. I hope that sending stuff to upstream makes sense for both sides. It is PITA for users, who flashed OpenWrt and does not have opinion on this one. Maintaining at least 3/4 versions of U-boot, because of DDR patches for A38x is not good idea and
<Pepes>
we at least in Turris OS wants to force U-boot update to everyone soon in the stable branch. And that's what we will do and users, who are using OpenWrt will be on its own. That's fine, too.
<Pepes>
robimarko: I understand your reasoning, but it makes things easier for everyone, but since in the stable version, it gets support for new devices, new features by updating packages. It should be tested and also bug fixes goes into the stable branch as well.
<Pepes>
and in the past w/o LOCALVERSION, it was really pain in the ass to troubleshoot all various U-boot versions, which users might or might not have.
Tapper has quit [Ping timeout: 480 seconds]
<Pepes>
and backporting so many patches results in heavily patched U-boot and that's not what I want, though
<ynezz>
correct, we can't please everyone
<robimarko>
Pepes: There really isnt manpower for what you are suggesting
<robimarko>
I personally dont understand the use of a stable branch while simultaneously wanting new stuff
<Pepes>
You don't want to force to your customers some devel version of OpenWrt and support it. You want to keep the same and many users asking at least for Turris Omnia if they can use U-boot and if we are going to update U-boot versions across different revisions, so yes. We want to use the latest U-boot version for that or at least wait for 2022.04 since there are another
<Pepes>
improvements for Turris devices in the stable branch.
<kabel>
robimarko: the problem is that regarding DSA, new stuff means working stuff, while stable means broken
<Pepes>
and the same applies for fixed security vulnerabilities in LTS kernel as kabel started discussion about kernel. :D
<Pepes>
Some kernel developers explicitly stated that somebody needs to be proactive and backport security fixes for older LTS kernel even though they are supported
<robimarko>
kabel: I understand, I personally dont use stable versions at all
<robimarko>
They just dont suit my needs
<ynezz>
now I'm quite confused, are we still talking about your proposal to update u-boot for mvebu in 21.02?
<robimarko>
Pepes: Again, you want new stuff but somehow stable version
<Pepes>
Well, I was and then we moved to kernel stuff.
<robimarko>
Only way to have that is to release more often
<robimarko>
Which I dont see happening, there just isnt the manpower for it
<Pepes>
Yes, but OpenWrt releases happens once per year, but yes. releasing more often is a way
<robimarko>
Cause, I feel your pain
<robimarko>
I have products that are tied to the stable version as well
<robimarko>
And that is just a pain to support 5.4 kernels in 2022
<robimarko>
While your customers want new stuff that exists upstream
<Pepes>
Our kernel developers are saying the same, though.
<Pepes>
were fixed there. But since we all agreed that it should not be pushed to the stable branch, I will create within Turris OS folder rejected and if someone complains that we are not cooperating or at least trying is that we have reference. That works, too.
goliath has quit [Quit: SIGSEGV]
Tapper has joined #openwrt-devel
goliath has joined #openwrt-devel
danitool has joined #openwrt-devel
ptudor has joined #openwrt-devel
<robimarko>
Pepes: I am the first one to jump on a new kernel, I really hate working on old kernels
<robimarko>
OpenWrt runs on a large variety of targets with varying states of being upstream
<robimarko>
And thus every kernel bump is a major pain, hence using only LTS
<robimarko>
That leaves you with max 1 kernel bump per year
<robimarko>
Then you also dont want to move to a new kernel before next stable branches
<robimarko>
You asked my opion on U-boot versions in stable, and that is just my opion
<robimarko>
I would personally like more releases and shorter support cycles so that releases are kind of fresh
clayface has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
<shibboleth>
robimarko, that would mean dropping 1907 and 95% of all mikrotik devices that were previously supported
cmonroe has quit [Ping timeout: 480 seconds]
<robimarko_>
shibboleth: As far as I know, there will be a 19.07.10 soonish and thats it for 19.07 release cycle
<robimarko_>
As far as Mikrotik ath79 NAND support goes, I am sure you are aware why they were dropped
<shibboleth>
i mean NOR
<shibboleth>
and patches for the erase issue has been PR for months
<shibboleth>
so, dropping generic images dropped support for most mikrotik devices and people trying to add support for them get "dicked around" for years and just give up
<shibboleth>
which is unfortunate, mikrotik make some of the best non-consumer devices that are owrt-compatible
<shibboleth>
ok, so these device support PRs are still open due to them referencing a diff but identical erase PR
<aparcar[m]>
rsalvaterra: do you plan to merge "kernel/kmod-lib-lzo: include the lzo-rle kmod in the package"
<robimarko>
shibboleth: Dropping ar71xx was kind of inevitable
<robimarko>
And as far as I know just forcing 4K sectors isnt really a viable solution
<f00b4r0>
shibboleth: I did review #3348 and there was no further comment from submitter. I might eventually take over as I did with the map lite, but I'd rather submitter fixed what I asked instead.
<robimarko>
Only downside to now having 4K support is not being able to write to hard_config
<shibboleth>
but dropping 98% of mikrotik is?
<f00b4r0>
as for shorter support cycles, that would condemn a lot of devices to end up in landfill, which is one thing openwrt really helps avoiding.
<robimarko>
Yeah, that would be the unfortunate reality
<f00b4r0>
not to mention that I'm not quite sure what's the point of running bleeding edge software on older devices - I'd rather have one old, security-supported release than a gazillon bleeding edge (likely buggy) ones. But that's just me :)
<robimarko>
Well, thats the thing
<robimarko>
You are not only running it on old devices
<f00b4r0>
as for 4K erase, I wish it moved forward yes. But IMHO BDF dynamic loading is far more important
<robimarko>
I agree, without 4K erase it will work
<robimarko>
But dynamic BDF is kind of stuck
<robimarko>
And mandatory
<robimarko>
Upstream ath10k is dead effectively, Kalle just looks to be merging bugfixes
<robimarko>
And there have not been any new comments
<f00b4r0>
*sigh*
<robimarko>
Tried to bump it few times, but nothing
<f00b4r0>
I fail to see what's the problem with carrying this in tree. It's self-contained and harmless. But well, I rest my case now.
<robimarko>
The thing is that I dont see a way around it
Tapper has quit [Ping timeout: 480 seconds]
<f00b4r0>
shibboleth: another issue that may soon plague ath79 mikrotik devices is kernel too large to netboot. See #4176. That will eventually hamper the ability to install owrt.
<shibboleth>
robimarko, and ath11?
<f00b4r0>
then again, mikrotik is making it purposely hard to run anything other than their OS.
<shibboleth>
was leaking like a sieve last time i heard
<robimarko>
shibboleth: I dont see what does ath11k have to do with Mikrotik, there is a decently sized community running ath11k on forum
<robimarko>
TIP is using it as well over the propriatery driver
<shibboleth>
nothing, but you mentioned ath10
<robimarko>
Cause of the dynamic BDF loading
<robimarko>
That is required for all of the MikroTik ac devices
<robimarko>
f00b4r0: They have stepped it up with RB5009
<f00b4r0>
indeed.
<robimarko>
Now, they made sure that UART was disabled in the RouterBoot regardless of config
cbeznea has quit [Quit: Leaving.]
<f00b4r0>
at the end of the day I'll vote with my wallet and I'll stop buying their products. But I know I'm not the intended audience anyway.
<robimarko>
And not to mention YAFFS again, but this time it looks a custom version
<rsalvaterra>
aparcar[m]: Yes, please. It just doesn't make sense otherwise.
<Borromini>
robimarko: second is sumo's experience with the 2,5G port, but that post is from 14/2 and adron backported 5.15 QCA8081 support on 15/2, so his experience might not apply anymore.
<Borromini>
i've been holding out so long for a 5800X (or its 3D 'upgrade') that I'll basically be getting the 5700X. Lower TDP and 0,1 GHx boost clock won't make that much of a difference under load
<robimarko>
Had mine for a year
<mangix>
is interesting. looks like i need a new build
<robimarko>
Best thing for compiling ever
<mangix>
robimarko: better than ccache?
<robimarko>
Well, you cant beat ccache
<Habbie>
reminds me of a story about malloc
<Habbie>
the best way to make malloc fast is to avoid using it
<Habbie>
ccache is like that too :)
<aparcar[m]>
rsalvaterra: pardon what?
cmonroe_ has joined #openwrt-devel
<robimarko>
I usually dont use ccache
<robimarko>
Been burned by it
* Borromini
has been bitten by ccache a few times as well
<robimarko>
mangix: I can tell you that threaded NAPI does wonders for WLAN
<robimarko>
I suppose it can do it for wired as well
<robimarko>
Not hogging only one CPU core does wonders
Darkmatter66 has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<mangix>
robimarko: it reminds me of a conversation I had with neil brown about the effects of moving affinity away from core 0
<robimarko>
Well, it kind of has the same effect
<robimarko>
Cause thats usually the biggest bottleneck, just proecssing IRQ-s on one core
<shibboleth>
robimarko, oh, i'm not saying they're not thinking with their knees
<shibboleth>
"sure, let's throw in poe, but make sure it's the kind no one actually uses"
<robimarko_>
Proper PoE costs cause you cant just use passive components for it
<shibboleth>
yeah, and it's not like people are paying them for "not consumer grade"-shizzle
<russell-->
what does the "<" mean in, e.g. "select PACKAGE_iptables-legacy if PACKAGE_iptables-nft<PACKAGE_fwknopd" from tmp/.config-package.in?
Borromini has quit [Quit: Lost terminal]
robimarko_ has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
GNUmoon has joined #openwrt-devel
<zorun>
is anybody aware of lightweight alternatives to node-exporter? Go is not an option on many platforms
<Habbie>
i recall there being a lua one
<zorun>
ah, interesting
<Habbie>
prometheus-node-exporter-lua - 2021.02.15-1 - Provides node metrics as Prometheus scraping endpoint. This service is a lightweight rewrite in LUA of the offical Prometheus node_exporter.