<neggles>
like even if you enable it, you get... a tiny example kernel module that does a printk()
<neggles>
slh: I don't think it's a good idea for rust to end up any deeper than device drivers, but IMO there are an awful lot of compelling arguments for those... plus it's going to be necessary for Apple Silicon GPU support, so it's basically inevitable...
<Ansuel_>
also linus love rust...
<neggles>
rust is very cool and good for device drivers, especially from a maintainer point of view
<Ansuel_>
rust for mm
<Ansuel_>
:D
<slh>
makes the kernel lighter (on arch support) ;)
<neggles>
for now - one of gcc-rs or rust-codegen-gcc will solve that problem
<Ansuel_>
btw still trying to understand why bpf packages fail here
<dhewg>
neggles: alright, will try, thanks for the info!
<neggles>
np :)
<neggles>
tbh most simple stick-type wifi antennas are basically just a slightly-carefully-chosen length of wire >.>
<dhewg>
hehe
<dhewg>
is there a noticably reception/quality difference when not using those simple ones?
<dhewg>
as in "is it worth it?"
cbeznea has joined #openwrt-devel
<Znevna>
wee fixed kernel panic
<mrkiko>
woow!! IPQ807X, VDSL support for the IPQ4xx 7530... lots of nice things
robimarko has joined #openwrt-devel
<jow>
anybody knows github codespace?
<jow>
I thought it's a kind ofg web based IDE but apparently it can compile things
<jow>
got a LuCI bug report that turned out to be broken rootfs permissions and the OPenWrt image was allegedly built using GitHub CodeSpace
<oliv3r[m]>
afaik, codespaces uses a docker container in the background, which you need to have defined. Then it should be able to compile and do things. Something big like openwrt though; idk :)
<robimarko>
Yes, you need to define a docker container for the repository
<robimarko>
They have some default ones
danitool has joined #openwrt-devel
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
bluew has quit [Quit: Leaving]
<neggles>
dhewg: not really
<neggles>
it makes a big difference if you're using a directional patch antenna
<neggles>
but when it comes to dumb mostly-omnidirectional antennas, there's... not a great deal of difference beyond a certain point
<robimarko>
Those are probably the most untweaked antennas you can get
<neggles>
yeah, i mean you'll get better performance out of the 20cm long ones than the 5cm long ones
<neggles>
and sometimes the "2.4/5ghz" antenna you were sold turns out to actually be a 900mhz 1/4-wave antenna so you get massive piles of return loss
<robimarko>
You know its "close enough"
EqUaTe has joined #openwrt-devel
<neggles>
yeah. stick antennas basically come in "works" and "doesn't work"
<neggles>
beyond that you have to either get directional, or start doing voodoo magicks with MIMO
<neggles>
it's kinda funny when you see people with those 60-90cm long antennas hanging off a usb wifi dongle
bluew has joined #openwrt-devel
<robimarko>
Cause, the bigger the better
<robimarko>
Like TX power, I had like dozen+ questions how to fake the regulatory domain to get 30dBm TX power working
<robimarko>
Cause that is the solution to every problem
<neggles>
ugh
<neggles>
turning up TX power often makes things *worse*!
<robimarko>
Yes, cause your noise floor also goes crazy
<neggles>
and it doesn't matter how loud your AP is if it can't hear your client!
<neggles>
plus no current-gen wifi chipset can hit max TX power at max MCS anyway...
<robimarko>
Yeah, but try explaining that
<dhewg>
it's like "Router foo AX$(HUGENUMBER)", where the bigger the better
<dhewg>
the sad thing is that I think it works, as in more sales
<neggles>
"If I'm having trouble hearing you from across the room, will it help if I yell louder at you?"
<neggles>
dhewg: oh it does, I don't really have a problem with that, I have a problem with the fact that it means everything comes set to 40mhz wide on 2.4ghz out of the box
<dhewg>
I guess I don't point you to my vht 2g branch then? :P
<neggles>
it's COMPLETELY POINTLESS
<neggles>
"if it's not set to 40mhz wide out of the box we'll get sued for false advertising because it's not capable of hitting that speed!!!!"
<robimarko>
40MHz on 2.4GHz, forget about it
<neggles>
never mind that not a single person on the face of the earth has ever exceeded 200mbps on 2.4GHz outside of a test lab
<neggles>
one of my friends lives in an apartment building in the city 15 floors up; the noise floor - *noise floor* - is -71dBm
<neggles>
(in 2.4ghz)
<neggles>
stuff coming out of the box set to 160mhz on 5GHz is just as bad - oh sure lets just go right ahead and throw away 3-6dBm of TX power for no reason
<f00b4r0>
neggles: well, the root cause of the problem is here: wire/less/
* f00b4r0
hides
<neggles>
i've lost count of the number of times i've "fixed" a friend's wifi problems by changing to 2.4 to 20mhz on whichever of 1/6/11 is the least fucked, and 5.8 to 40mhz wide on a DFS channel
<neggles>
f00b4r0: I mean root cause is "bigger number more better", no? :P
borek has joined #openwrt-devel
<neggles>
ought to be illegal. IMO if you want to market a router as being capable of X Mbps, you should be prepared to back it up with "speed achieved using X client device with Y AP settings in X conditions"
<neggles>
bit late for that now though.
<f00b4r0>
where "X conditions" are never met in real life scenario
<neggles>
I mean even better would be to define a "reference client", or restrict it to 2x2 client devices
<neggles>
this insane cambium could theoretically achieve uhhhh...
<neggles>
what's the alleged maximum for 6E 1x1 in a 20mhz channel? "150mbps"?
<robimarko>
Think its 143 or something like that on AX
<robimarko>
But 6E is gonna be the same
<dhewg>
neggles: do you have some link that explains all that? something to pass around
<robimarko>
Of course only achievable on 1024-QAM with MCS-11
<f00b4r0>
of course.
<neggles>
I *have* managed to hit MCS11 on a 2x2 client
<neggles>
...at 10 feet distance from the AP, with both of them being the only thing for miles capable of 6GHz
<dhewg>
or here's an idea: add some hints and comments to luci to help users setting it up in a sane way
<robimarko>
Yeah, those are gonna be followed for sure instead of use US as reg domain and max TX power
<f00b4r0>
dhewg: that'll never work. What you need is a two-button radio choice: "fast" and "insane"
<f00b4r0>
and everyone will click on "insane".
<robimarko>
And insane needs to actually be sane in the background
<dhewg>
I like it, ship it!
<f00b4r0>
robimarko: exactly ;)
<neggles>
australia actually has a nicer and higher-tx-power frequency plan than the US :D
<robimarko>
No, dont share it on the internet
<neggles>
well the good news is, it doesn't matter worth a damn since the linux regdb ignores half the rules
<neggles>
but for 5500-5700, with the exception of 5600-5650, you can run 1000mW EIRP with DFS and TPC
<f00b4r0>
what I really long for tbh is an "outdoor" knob that would prevent hostapd from hoping to non-outdoor allowed DFS channels
<neggles>
that's already a thing
<neggles>
it's even in luci???
<f00b4r0>
rephrasing: non-outdoor allowed channels during DFS changeover
<neggles>
does the "installation type: indoor/outdoor" not do what it says on the box
<f00b4r0>
dhewg: nice
<dhewg>
there is no in/outdoor knob yet as far as uci/luci is concerned
<f00b4r0>
^
<neggles>
h-uh. where's my cursed AP330 gone...
<f00b4r0>
right now I'm cheating by setting the channel to "auto" and then restricting the "channels" setting. But that can only be done in uci, not luci.
<f00b4r0>
i suspect a huge number of devices running openwrt outdoors are unknowingly breaking radio emission rules
<neggles>
h-uh. I could've sworn there was an "indoor" / "outdoor" / "unknown" switch in here, but I guess i'm thinking of mikrotiks
<neggles>
dhewg: as for a guide/explainer, i've not really come across one :/ it's not all that easy to condense into a simple little thing
<neggles>
there's a lot of trial and error involved, the rules of thumb don't always apply
<Ansuel>
but not useful... build log also don't display the error since V=s is not used
<robimarko>
Well, that is useless as its not verbose
<Ansuel>
so i hope to repro on my system but it's strange since builbot is not broken... but could be that they use llvm sdk
<\x>
and ah yeah, I replaced the psu dhewg 12V 1.5A -> 12V 2.5A, else the usb wont cooperate with me but it might be a device specific thing
<robimarko>
Ansuel: Its gonna be impossible to reproduce without having their exact env
<oliv3r[m]>
Ansuel: can you explain me (and rosen) how this 'tools-core' thing works in (in the libdeflate PR). I took that change from his 'fix'. So is it right or wrong to have there? Does it not need to be 'added' to "something" (tools-y, tools-core)?
<\x>
only gripe on this one is no reboot, i cannot reboot, i have to cut power then boot, so in the days i was setting and tuning things it was kinda yeaaaaah its something
<robimarko>
Ansuel: Thing is that that is not that bad of an idea
<robimarko>
Cause, it would avoid a lot of duplication
<robimarko>
As ipq60xx is pretty much ipq807x lite
<\x>
i guess reboot and cpu scaling above 1.5ghz but thats it, thing werks well
<robimarko>
\x: Its lacking CPR
<robimarko>
And those upstream OPP points are broken by default
<Ansuel>
i would focus on correct upstream of ipq807x and then move to ipq60xx
<robimarko>
Trust me, I am fully ignoring ipq60xx for the time being
<\x>
i installed that mhz util yeah robimarko, 1.5GHz max only
<Ansuel>
pc is so confused by compiling llvm that the space left is actually growing o.O
<robimarko>
Though, I might send some patches that I have for DTS so they dont rot
<neggles>
ipq6xxx is the new ipq4xxx
<neggles>
it will haunt us for a decade
<Ansuel>
ipq9564 is the new ipq807x
borek has quit [Quit: borek]
<robimarko>
With Dynalink being 70 EUR its not
<robimarko>
GL-Inets AX1800 toy is 100 EUR
<\x>
cpu wise its equal imo, radios are worse (less streams)
<robimarko>
Nope
<neggles>
ipq4000 wasn't $5 and 8 cereal box tops when it was new either
<neggles>
give it time
<robimarko>
My point is that its not cheap enough compared to ipq807x
<robimarko>
And HW-vise is way worse
<\x>
also, i think theres a lack of devices
<robimarko>
GL-Inet is charging 100 EUR for the bottom of the pile IPQ6000
<neggles>
half of ubiquiti's current lineup
<robimarko>
And they saved money on not even providing a damn programmable voltage regulator for the CPU
<\x>
ill say something evil
<\x>
hap ax2, hap ax3
<neggles>
yeup
<robimarko>
Honestly, those are too expensive for what they offer
<neggles>
between ubiq and mikrotik and tp-link and edimax and <long list of firewall vendor branded APs>
<neggles>
i'm not saying they're *good*
borek has joined #openwrt-devel
<robimarko>
Not to mention, good luck to anybody trying to port anything to them
<neggles>
nor am i saying they're worth buying
<neggles>
just that plenty of things are going to show up with ipq6k in them, and The People Will Want Support Because They're In Upstream Which Means You Can Support Them Right
<neggles>
</s>
<\x>
if theyre cheap enough I guess, but seeing that dynalink is only 70, just go with that one
<robimarko>
I am imune to those requests by now
<\x>
I guess I bought early
<Ansuel>
robimarko can i keep the tested by tag for the series?
Ansuel has quit [Read error: Connection reset by peer]
<robimarko>
Yeah
<neggles>
eh
<neggles>
is ipq6k really that bad? if they're that similar to 807x it can't be *that* hard to support them, can it?
* neggles
prepares his flame shield
Ansuel has joined #openwrt-devel
<\x>
it does work, but you see, 807x is becoming cheap nowadays and much more supported
<neggles>
and fwiw sophos at least have a long history of providing really nice GPL dumps and AIUI their soon-to-be-released APs are a mix of ipq6k and I guess ipq9k? the wifi 7 ones
<\x>
if you just want something to toy with then maybe its fineeee, just dont spend too much, imo even mediatek's lower end offering is better (mt7981)
<neggles>
eh; will be grabbing one or two once they land, nfr 70% off
<neggles>
can probably persuade them to "loan" me one and never ask for it back
<jow>
iirc the very same thing was already disabled i nthe past
<jow>
crept back up
<Znevna>
same thing happens with nmbm?
<Znevna>
my devices don't have bad blocks yet
<Znevna>
:<
<Znevna>
to test :p
<f00b4r0>
so let me get this straight, in order to fix a bug that may soft-brick devices, this proposes to disable bbm, which could eventually lead to hard bricks. Interesting ;P
<Ansuel>
the thing i don't understand is how this entire thing is not handled transparently...
<gch981213>
Znevna: I don't understand what's going on there. I remember BMT can't be disabled with that old bootchain.
<f00b4r0>
Ansuel: indeed.
<robimarko>
Was that thing ever upstreamed
minimal has joined #openwrt-devel
<robimarko>
Cause, MTK seems that they are not giving up on it
<gch981213>
robimarko: That's impossible.
<dhewg>
iirc mainline has an incompatible solution?
<gch981213>
ubi does what MTK wants in a far better way.
<robimarko>
Well, that is just fantastic
<robimarko>
So its gonna be an issue forever
<gch981213>
The BMT/NMBM is used because the NAND flash programmer used in mass-production usually can only write a single image. When it encounters a bad block, it skips that block and shifts the content back one block.
<robimarko>
Well, then the question is how the hell does every other vendor not use it and still flashes NAND-s just fine?
<gch981213>
so BMT/NMBM is used to shift everything forward.
<gch981213>
UBI can handle the skipped bad blocks. If they can put factory into UBI and add some logic to handle skipped bad blocks in preloader, they shouldn't need BMT.
<gch981213>
However, back in the mt7622 days they want JFFS2 on nand...
<gch981213>
robimarko: I don't know what other router SoC vendors' solution to this. Phone SoCs don't use NAND programmer in mass production, they use recovery mode in bootrom instead, and several images are written to the correct offsets separatedly.
<gch981213>
so a skipped bad block in one mtd partition won't cause contents in other partitions to shift.
<robimarko>
Well, that is my point
<robimarko>
A lot of BCM and QCA routers use NAND and only NAND and they are all using UBI just fine even from factroy
<gch981213>
I just asked someone. QCA doesn't provide a solution to this problem at all.
<Znevna>
hmm
<gch981213>
My assumption: Since they use UBI for main data area and the odds that a factory bad block appears at the front boot chain area is low, vendors could probably throw away nand chips with bad blocks at the front.
<robimarko>
Well, that is great for us
<Znevna>
think I can mark a block as bad and see what happens
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
<Ansuel>
well it seems buildbot almost finished
<Ansuel>
aaand he failed... SAD
<Ansuel>
ERROR: target/imagebuilder failed to build.
goliath has joined #openwrt-devel
bluew has joined #openwrt-devel
<robimarko>
Ugh, error is weird
<ynezz>
Ansuel: indeed, it's misbehaving build worker, should be fixed soon
<ynezz>
its OOM killer, there are 2 build workers running from the same host
<robimarko>
Ok, cause it said Killed and then tar failed
<ynezz>
its a docker container, so the OOM from the host is not visible
<hurricos>
stintel: The second BDI2000 is headed with hmartin
<hurricos>
It'll be in the EU by the end of the month as he returns. Let me know if you'd like to share a mailing address, or you can reach out to him for one
srslypascal is now known as Guest1631
srslypascal has joined #openwrt-devel
<robimarko>
ynezz: ok, thanks
Ansuel has quit [Ping timeout: 480 seconds]
Guest1631 has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
<Ansuel>
ynezz probably caused by the forced run ?
<robimarko>
Ansuel: Can that libdeflate PR be merged?
<robimarko>
First it was oliver that did a PR, then mangix fixed it up
<robimarko>
Then I think it got renamed, so it looks like 2 doing the same
<ynezz>
Ansuel: no, probably server admin (or server reboot) has started that 2nd build worker which was disabled previously due to exactly those OOM issues
soxrok2212 has quit [Quit: Who ate my gummy worms?]
<Znevna>
the numbers of those PRs say otherwise ;P
soxrok2212 has joined #openwrt-devel
<Znevna>
what' will I ever need 32GB of RAM for, that's too much. Me starting an extra VM today > nope.
soxrok2212 has quit [Quit: Who ate my gummy worms?]
Ansuel has quit [Quit: Probably my PC decided to sleep or I decided to sleep.]
Ansuel has joined #openwrt-devel
cbeznea1 has quit [Quit: Leaving.]
Borromini has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
<jayk>
d'oh, why is bison-3.8.2 (latest) bad..
<jayk>
checking for bison 2.4 or newer... 3.8.2, bad
<jow>
jayk: likely a broken detection script
Borromini has quit [Ping timeout: 480 seconds]
<jayk>
jow: ah
svanheule has joined #openwrt-devel
Borromini has joined #openwrt-devel
svanheule has quit [Quit: svanheule]
svanheule has joined #openwrt-devel
bluew has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<Znevna>
robimarko: in RouterOS / RB5009 we can see on which physical port a MAC is seen, can we do that in OpenWrt ?
<Znevna>
actual question would be another one though, RouterOS queries the switch for that data and it uses a lot of CPU, just curious if that was the case in OpenWrt too x.x
<dangole_>
starting off a clean build directory today, now util-linux (built because of fstools build-depending on it) tries to link against /lib/libncursesw.so (ie. the host library) which can't work for obvious reasons. has anyone else seen this and/or any idea what may be happening in the meson/ninja rabbit hole?
<stintel>
ip neigh or bridge fdb
<stintel>
Znevna: ^
<Znevna>
thanks ^^
<stintel>
yw
<Ansuel>
dangole_ fun thing... i would first start from the config log
<dangole_>
Ansuel: if it was autotools and there'd hence be config.log, then i'd very well know how to help myself
<dangole_>
Ansuel: unfortunately it's "a modern build system", which implies hiding all it's internal workings somehow, hence there aren't any log files or even contant non-self-replacing console output which could be used to investigate this kind of issue
<dhewg>
worked for me yesterday, and I'm always rebuilding everything clean since tmpfs
<dhewg>
was some used library updated today?
<dangole_>
dhweg: i don't think so. could be that it's somehow related to being the first time i build anything for risc-v...
cmonroe_ has quit [Remote host closed the connection]
cmonroe has joined #openwrt-devel
<Borromini>
Znevna: on RouterOS you mean, or are those spikes on OpenWrt as well?
<dangole_>
dhewg: ncursesw.pc looks innocent, no idea where that seemingly hard-coded path makes it into LDFLAGS when using meson to build util-linux...
<Ansuel>
did we checked if the culprit is util-linux itself that is hardcoding stuff?