lmore377 has quit [Read error: Connection reset by peer]
lmore377 has joined #openwrt-devel
danitool_ has quit [Ping timeout: 480 seconds]
lmore377 has quit [Read error: Connection reset by peer]
lmore377 has joined #openwrt-devel
lmore377 has quit [Read error: Connection reset by peer]
lmore377 has joined #openwrt-devel
Tapper has joined #openwrt-devel
gladiac has quit [Ping timeout: 480 seconds]
lmore377 has quit [Read error: Connection reset by peer]
lmore377 has joined #openwrt-devel
philipp64 has joined #openwrt-devel
valku has quit [Quit: valku]
gladiac has joined #openwrt-devel
goliath has joined #openwrt-devel
indy has quit []
indy has joined #openwrt-devel
indy has quit []
indy has joined #openwrt-devel
indy has quit []
indy has joined #openwrt-devel
indy has quit [Remote host closed the connection]
indy has joined #openwrt-devel
<fpsusername[m]>
<Harm_> "fpsusername: so there could..." <- Or if openwrt can modify it
<Harm_>
It is just another mtd partition
goliath has quit [Quit: SIGSEGV]
srslypascal has quit [Ping timeout: 480 seconds]
agentcasey has joined #openwrt-devel
nixuser has joined #openwrt-devel
gladiac is now known as Guest6166
gladiac has joined #openwrt-devel
srslypascal has joined #openwrt-devel
Guest6166 has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
<nixuser>
Hi, I need to edit an article in the wiki because it's outdated. The webpage tells me to ask for access on IRC.
<nixuser>
The issue is simple. The https://openwrt.org/docs/guide-developer/toolchain/install-buildsystem article is missing the "musl-obstack-dev fts-dev musl-libintl" dependencies on the Alpine Linux section, without them installed tools/elfutils will fail to compile with an OpenWRT master tree.
ptudor has quit [Quit: Strict-Transport-Security: max-age=48211200; preload]
ptudor has joined #openwrt-devel
ekathva has joined #openwrt-devel
ekathva has quit []
<PaulFertser>
nixuser: hi. Please send me your desired nick and e-mail.
robimarko has joined #openwrt-devel
danitool_ has joined #openwrt-devel
HIil has joined #openwrt-devel
<HIil>
Hello everyone~
HIil has quit [Quit: Page closed]
noltari has quit [Quit: Bye ~ Happy Hacking!]
noltari has joined #openwrt-devel
<mrkiko>
is it me, or an incredibly low number of commits is happening these days? Or am I missing something?
<robimarko>
There is a ton of PR-s though
<mrkiko>
robimarko: ehehe, yes; but i was thinking there could be also some technical issue or maybe the github mirro is no loger updated or who knows
<robimarko>
Its vacation season in europe
<mrkiko>
:D eheh yess, I am in europe BTW so
MaxSoniX has joined #openwrt-devel
<mrkiko>
robimarko: how is going with the newer IPQ platforms hacking?
<robimarko>
mrkiko: well, finally managed to get some stuff upstream for 5.20
<robimarko>
Some stuff got reviewed, found way better solutions to reusing existing stuff
<robimarko>
Fixing some completely broken stuff that QCA upstreamed etc
<robimarko>
And maintainer who merged an outdated DTS patch despite me pointing out that its superseeded
<robimarko>
So, I am gonna need to fix that up
<f00b4r0>
*sigh*
<robimarko>
Dude reviewed the whole v6 series weeks after v8 was up and reviewed except for DTS
<robimarko>
And it was way better, but he replies like once a month
<robimarko>
Thats the biggest issue, getting anything reviewed, it takes ages
<robimarko>
But some new people joined to reviewing stuff, but there is just a single QCA tree maintainer
<robimarko>
So, other subsystems started merging their stuff directly from patchsets
<robimarko>
That is how I got regulators and their GPIO-s merged
<mrkiko>
:D
<hanetzer>
woo.
<robimarko>
Gotta backport all of that stuff to 5.15 which is not fun
<mrkiko>
In any case I'll be happy the day I see ipq4xx dsa transition patches merged in openwrt. :D
<mrkiko>
I know - less exciting but ...
<robimarko>
Well, that is gonna be a mess
<robimarko>
Cause, I already see MAC adresses being completely broken
fhbc has joined #openwrt-devel
<robimarko>
As I cannot validate all of the conversions, try to ask and confirm that MAC-s are the same
<mrkiko>
robimarko: don't remember how it went with the GL-B2200
<f00b4r0>
robimarko: btw, any update on that dynamic nvmem patch? I haven't been following ;)
<robimarko>
f00b4r0: none, Bootling will just get started on it mid august
<robimarko>
I am already mad at them for not sorting the IPQ40xx ethernet driver v3
<robimarko>
Its been over a month after v2
<f00b4r0>
heh
<fhbc>
Hi there, I'm trying to upgrade from an older kernel (3.18) to 5.10. In the older kernel we were able to use gpio pins for ATH79 as extra chip selects with a driver patch, but I'm wondering if I need to write a patch or if I need to do this in the device tree.
<f00b4r0>
the kernel has gotten so big, now there's a ton of inertia ;P
<robimarko>
Well, inertia is mostly on QCA folks
<robimarko>
As they are heavily prioritizing patches from QCA and/or Linaro
<fhbc>
(extra chip-selects for an SPI bus, the controller of the SOC is limited to 3 CS-pins on its bus, we need 6)
<aiyion>
Is somebody motivated to review my cleaning-up around the UniFi AP LR?
<aiyion>
It's been there for half a month now and really is not *that* big :)
fhbc has quit [Remote host closed the connection]
MaxSoniX has quit [Quit: Konversation terminated!]
lmore377_ has joined #openwrt-devel
<\x>
been using pr-4721 november last year all good for me ;)
ptudor_ has joined #openwrt-devel
lmore377 has quit [Ping timeout: 480 seconds]
<f00b4r0>
aiyion: I'm not sure I see the point. These are the exact same devices.
<f00b4r0>
(from software pov)
Misanthropos has quit [Ping timeout: 480 seconds]
<aiyion>
true.
<aiyion>
The Antenna gains differ though, and it's pretty annoying to keep track what variant is installed where.
ptudor has quit [Ping timeout: 480 seconds]
<f00b4r0>
if we start building images for every minute difference there'll be no end to it (and the resources aren't infinite)
<f00b4r0>
see for instance in mt7620 the ex3700 device. It covers both 3700 and 3800, which differ in form factor but are also one and the same device.
<aiyion>
ah, I thought in ath79 each and every device should be its own.
<aiyion>
So the correct way would be to have a script in the UAP image, that tells apart, which variant it is?
<f00b4r0>
I don't know if there's a definitive policy on that topic. My impression is that building identical images that only differ in name is rather absurd and doesn't scale; but others may feel differently.
<robimarko>
I agree
<robimarko>
If its the same HW, no point in multiple devices
<aiyion>
Its not the same hardware, there are different antennas installed.
<aiyion>
But its the same hardware from openwrts perspective for now.
<f00b4r0>
aiyion: in the case of the ex3700 there is no way to differentiate the hardware by looking at sysinfo. If one really must know and cannot physically look at the device, they can check some bits on the flash, but AFAICT we don't care about that in OpenWRT.
<robimarko>
Antenas are not active HW, for the FW it doesnt matter at all
<aiyion>
robimarko: ack
<aiyion>
f00b4r0: huh. okay.
* f00b4r0
notes that he couldn't be bothered to adjust the mikrotik lhg 2 image and runs that on his sxtsq2 :)
<f00b4r0>
same hardware, different antenna.
fhbc has joined #openwrt-devel
<\x>
is there already 6GHz AP capable device that is supported?
<robimarko>
Mikrotik are champs when it comes to reusing HW
<aiyion>
as is UniFi...
<robimarko>
Only the older AP-s
<aiyion>
jep.
<aiyion>
got better that's true.
<f00b4r0>
robimarko: which is exactly why I wish we were a bit cleverer in how we handle it. I'm sure we could more than halve the number of available images for mikrotik devices :)
lmore377_ has quit [Read error: Connection reset by peer]
<f00b4r0>
but that bird has flown
lmore377 has joined #openwrt-devel
<robimarko>
Yeah
<aiyion>
is there something like a board_detect function in ath79, that I could patch with the info from the mtd partition?
Misanthropos has joined #openwrt-devel
<robimarko>
I wish we could take more advantage from the cmdline that RouterBoot passes
<aiyion>
there's a bit that's flipped for the LR variant.
<f00b4r0>
robimarko: technically we could. We don't have to ignore all parameters. Then again all that info comes from the flash, so we can also leverage that.
<robimarko>
Yeah, I am most interested in DRAM size
<robimarko>
Cause we hardcode that in DTS
<f00b4r0>
yeah that definitely needs to be parsed early :)
<f00b4r0>
(i don't think we want to have hotplug RAM on these devices ;)
borek has joined #openwrt-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<robimarko>
I was thinking more along the lines if MikroTik decides to change the RAM size
<f00b4r0>
well they've done that already
<robimarko>
Like they did with hAP ac2 which first shipped with 256MB and then they quickly changed to 128MB
<f00b4r0>
that :)
<robimarko>
But cmdline doesnt work on IPQ40xx Mtik as we are baking the DTB into ELF
<robimarko>
To not be stuck with the broken DTB that bootloader provides
<f00b4r0>
wasn't there a mechanism to still get some bits from cmdline
<robimarko>
Well, its empty on IPQ40xx Mtik devices
<robimarko>
As its not cmdline in the traditional sense but rather bootloader updates the bootargs in DTS
<f00b4r0>
oh
<f00b4r0>
cunning
<robimarko>
Thats what every DT capable platform does
<robimarko>
As old school cmdline is ATAGS based which is depracated
<f00b4r0>
which is all and well as long as you can use the provided DT :P
<robimarko>
Hence why we have the "bootargs-append" hack in OpenWrt
<f00b4r0>
so we're back to parsing from flash, but I don't see how that would work for RAM size which needs to be available very early in the boot process, much before the drivers are loaded
<robimarko>
It wont
<robimarko>
As like you pointed, it needs to happen really early
<f00b4r0>
unless we cook an intermediary loader
<robimarko>
We managed to get rid of it, we have enough of those already
<f00b4r0>
indeed
<f00b4r0>
although there may be a cross-platform use for a very tiny bit of code that extracts relevant data from a bootloader-passed DT, maybe
<f00b4r0>
then again, for some value of "very tiny"
<robimarko>
Until Mtik decides to break that
<f00b4r0>
*nod*
<f00b4r0>
so... we do nothing and live with the status quo? :D
<robimarko>
Sounds like a good plan
<robimarko>
Its not breaking this *"so far"
<robimarko>
BTW, this looks interesting to squeezing some life out of hardcoded kernel size bootloaders
<f00b4r0>
yeah, I gave this PR a shot and unless I'm missing something, it had essentially no effect on the test images I built for ath79. In fact, there were ever so slightly bigger
<f00b4r0>
I'll retest on ath79, maybe I did something stupid
fhbc has quit [Remote host closed the connection]
<f00b4r0>
i'll run distclean between tries, which I didn't do previously.
<robimarko>
Neither did I
<f00b4r0>
ah, ok.
<robimarko>
Just git-am ed the commits
floof58 has joined #openwrt-devel
<f00b4r0>
and ran make again?
<f00b4r0>
that's what I did
<robimarko>
Yeah
<robimarko>
It built the lib and image
SlimeyX has quit [Read error: Connection reset by peer]
<f00b4r0>
ok let me start from a completely clean build of master, then I'll git-am and check again
danitool_ has quit [Remote host closed the connection]
<f00b4r0>
meanwhile I'm ready to submit the mtd variable erase patch upstream. I reworked it quite a bit, split it into functional changes and tidied everything. Hopefully this time it'll get through
<robimarko>
Get ready for waiting game with not feedback
<robimarko>
And then it suddenly gets merged
<f00b4r0>
heh
borek1 has joined #openwrt-devel
SlimeyX has joined #openwrt-devel
borek has quit [Remote host closed the connection]
borek1 is now known as borek
<f00b4r0>
robimarko: hmm. So before after: initramfs is 256 *bytes* smaller, squashfs is exactly the same size. I'm guessing we're not using gzip compression there :P
<robimarko>
Yep
<robimarko>
Squashfs is XZ or LZMA AFAIK
<robimarko>
So it can only squeeze the kernel
<f00b4r0>
but isn't the kernel gzip'd?
<f00b4r0>
i kinda lost track of all that :P
<robimarko>
Depends
<robimarko>
On most devices its gziped, some support LZMA so that is used
<f00b4r0>
KERNEL_NAME := vmlinuz
<f00b4r0>
and routerboot does not support lzma
<f00b4r0>
iirc
<robimarko>
Only kernel-bin is used for Mtik ath79 kernel
<robimarko>
So, it shouldnt be compressed
<robimarko>
Not by buildroot anyway
<f00b4r0>
i thought we were using the self-decompressing kernel?
<fpsusername[m]>
Man I hate the Raspberry gui. Instead of copying it creates shortcuts with drag and drop...
<fpsusername[m]>
So yes, no need to remove the IC from the PCB 😄
<Harm_>
fpsusername[m]: great news :D
MaxSoniX has joined #openwrt-devel
<fpsusername[m]>
<Harm_> "fpsusername: great news :D..." <- By the way, I noticed that the verification still fails when directly flashed to partiton 4, but it does boot openwrt. I can't seem to SSH into it though
<Harm_>
fpsusername[m]: how do you verify?
<fpsusername[m]>
UART
<fpsusername[m]>
I just hold jumper wires on the board, not going to solder now lol
<Harm_>
fpsusername[m]: which verifycation fails? the glbcfg thing?
<fpsusername[m]>
Too bad that they didn't clean up the holes, that makes it easier to stick in wires
<fpsusername[m]>
Harm_: trx verification? The first message after selection 3 to boot
<fpsusername[m]>
Let me check again
<Harm_>
old glbcfg partition is broken, magic=[0xffffffff][0xffffffff]!
<Harm_>
iirc, I got this message on an unmodified device already
<Harm_>
If the trx verification fails, the bootloader switches bootpartition
<fpsusername[m]>
It is verified, no issues. False alarm
<Harm_>
I'm not sure why ssh does not work though. It should be accessible via `ssh root@192.168.1.1`
<Harm_>
Does the webinterface work?
<fpsusername[m]>
All good. I can access LuCi :)
<fpsusername[m]>
But the SSH command you gave me only works once the IP is added temporarily
<fpsusername[m]>
Harm_: I'll try to reboot the unit and disconnect from my home network
<Harm_>
right
<fpsusername[m]>
Because 1.1 is my router. I guess I have to assign for example 1.100 and 1.101 on my router and attach the extenders there?
<fpsusername[m]>
* extenders there, then I could connect directly?
<Harm_>
you can also switch the 'lan' interface to DHCP client
<Harm_>
or assign it manually and turn the DHCP server of OpenWRT off
<Harm_>
(I assigned a hostname to my extenders and set them to DHCP, I just access them by hostname)
<fpsusername[m]>
Harm_: Works. I set DHCP client ID in KDE network settings to 192.168.11.2 for my wired connection
<fpsusername[m]>
I can SSH to 192.168.11.1 now
<Harm_>
fpsusername[m]: nice, it would be more convenient though when you can access them directly in the 192.168.1.1 range
<fpsusername[m]>
But no LuCi oddly enough
<fpsusername[m]>
Harm_: Then I'd have to attach it to my router and not directly to my desktop
<fpsusername[m]>
Attached it to my router now
<Harm_>
Nice, when configuring WiFi, I found that radio0 does list 5GHz as supported frequency but did not work well. Just use that one for 2.4 and radio1 for 5GHz
<fpsusername[m]>
Hmm, router doesn't list the extender. The walk of shame towards the router to check
<Harm_>
So you configured it as DHCP client?
<fpsusername[m]>
I didn't do anything on openwrt
<fpsusername[m]>
Just connect it to my router, see if I can access it
<fpsusername[m]>
But the router itself is a DHCP server of course, so if the extender thinks it's a server as well, it wouldn't work, right?
<Harm_>
They would conflict indeed
<fpsusername[m]>
Okay, will take the extender here again and configure it through my desktop
<fpsusername[m]>
Would make sense to have the default config be a client rather than a server, right?
<fpsusername[m]>
Unless people actually want to use this as a router instead of an access point
<fpsusername[m]>
Oh wait, the luci starts on 192.168.1.1. I guess ethernet has a higher priority. Nice
<Harm_>
I don't know what OpenWRT's opinion is w.r.t. default IPs
<f00b4r0>
apparently that said default has been around for so long and is so "expected" that it's unlikely to ever change.
<fpsusername[m]>
Harm_: Which LAN option do I edit? Lan0, Lan1, br-lan?
<Harm_>
fpsusername[m]: br-lan
<fpsusername[m]>
There's no protocol there to change
<fpsusername[m]>
Wait nvm
<Harm_>
Network -> Interfaces -> Edit
<fpsusername[m]>
I did that but it looked differently
<Harm_>
I guess you were looking in the devices tab on that page
<fpsusername[m]>
The gateway address must not be a local address
<fpsusername[m]>
In most home networks, the old router is the gateway too, and its default address is 192.168.1.1.
<fpsusername[m]>
So how do I solve that?
<fpsusername[m]>
s/The/_The/, s/address/address_/
<fpsusername[m]>
* In most home networks, the old router is the gateway too, and its default address is 192.168.1.1.
<Harm_>
Yeah, so for OpenWRT itself to have internet access you need to configure a gateway, which is in your local network on 192.168.1.1
<Harm_>
Where do you see it must not be a local address?
<fpsusername[m]>
Wait I'll just do step 8 and fix the IP address in my router
robimarko_ has quit [Quit: Leaving]
<fpsusername[m]>
Yay it works :)
<Harm_>
nice :)
goliath has joined #openwrt-devel
<mrnuke>
hurricos: How many of those switches with failing realtek-poe do you have?
<hurricos>
mrnuke: failing ... oh, I see. One model (GS1900-24HPv1). I am testing only against that model. I have two such switches. do you ask RE: something destructive?
<hurricos>
I've only tested against one of the two 24HPv1 implementations.
<hurricos>
Not that they're different. my brain has decided that implementation = instance, they're the same word.
<mrnuke>
hurricos: not thinking destructive. Just that it's somewhat difficult to repro the bad replies this on my engenius
<mrnuke>
We fixed it too good!
<hurricos>
wait, post-merge-#15?
<hurricos>
Oh, no. I see. that's not yet merged. What fixed it, do you reckon -- restructing packets so fewer are sent as per #19
<hurricos>
?
ptudor_ is now known as ptudor
<mrnuke>
Actually, #14 did absolute magic
<mrnuke>
#15 is not the right solution. Out of all the things I was trying, it just happened to be the most succesful
<mrnuke>
hurricos: I'll continue with what I've got, but if there's one you can lend out to an unknown person in Texas who you've met on IRC, that might help speed things up
<mrnuke>
I feel like I'm not getting my point across and if I keep speaking, I end up sounding argumentative
<hurricos>
mrnuke: they're crazy expensive.
<hurricos>
mrnuke: I saw that and agree. Frames are frames, the TCP stack doesn't care about the ethernet implementation except for using any explicitly exported (or implicitly available)standardized mechanisms
<hurricos>
tl;dr yes, layers must be separated, I understand why the other part of the convesration may be missing that, I have NOT looked at the implementation
<hurricos>
but I suspect there's stuff that cares about other stuff it shouldn't in there
<hurricos>
Oh, the async bit too irks me
<hurricos>
we expect the realtek-poe daemon not to block. If that changes, expectations are broken. I don't have a board with which to test.
<hurricos>
but skimming your explanation it was fairly clear why the implementation in #22 would do that
<hurricos>
even though AGAIN I haven't read. I'll add a thing to my calendar to examine and respond, lol
Tapper has joined #openwrt-devel
<hurricos>
mrnuke: OK, added my comments.
<hurricos>
bonus points if you spin up an issue to separate out medium-specific handling from main.c :D
<hurricos>
poemgr does this innately, though its poemgr.c is like, totally hitched to its reference / pd69104 implementation.
<hurricos>
and it's also written totally differently, sync rather than async
<hurricos>
I haven't actually looked at what it'd look like, but if medium handling were separate we could actually potentially start *merging* the two implementations
<mrnuke>
hurricos: Thank you! Hopefully we didn't scare him off
<hurricos>
We have a lot of spare space when it comes to handling stuff with CPU. I don't think it makes sense to break down all the capabs of each implementation into separate commands that are implemented differently, because then you need handling to interpret "what you are trying to do"
<hurricos>
but I think it'd make sense for everything to flow through the same async code path -- the poe daemon maintains a view of state, polls stuff, updates config, even if *what* runs through it differs strongly from implementation to implementation
<hurricos>
I think that ("implementation-unspecific poe manager") was the goal of poemgr, but I have never used it, let alone compiled it
<mrnuke>
poemgr is kind of like a one-shot deal. Configure, and exit. It's super sweet, but you do need to re-read the config and re-initialize the entire context whenever polling the port status
<hurricos>
by "what you are trying to do", I mean -- most of the packets sent are checking the state of all ports. I don't think each implementation needs to check each port. I think the differences in the implementations mean that asserting *what* the software implementation says to the hardware implementation, and *how* the response is parsed, is a bad idea
<hurricos>
because then to make it efficient enoguh to run you have to interpret what is meant: you aren't passing "special super secret single frame command to do the thing you want", you are forcing that to be broken down to be fed through code.
<hurricos>
Hoewver, a realtek-poe covering more than just realtek/broadcom pdu environments could assert *what* state is managed, *how* config is read, and *how* (through what data model) information is sent to and pulled from your hardware poe implementation
<hurricos>
and that's OK.
<mrnuke>
I think you are talking about a generin PoE implementation. realtek-poe could evolve into that. Baby steps though. Get it working for people who want to use it, and get it accepted as a package
ptudor_ has joined #openwrt-devel
<hurricos>
right.
ptudor has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
<fpsusername[m]>
Harm_: Access point works. Range is kinda meh to be honest. The extender is next to the window, HR++ glass. I stood outside at about 4 meter and the signal was kind of playing between 1 and 3 bars on my phone. I've set the power to max for 5GHz
<fpsusername[m]>
Habbie: Guess what, in September I'm going to move to a new house (2018), which is a "0 op de meter" house. It not only has excellent thick walls (I can turn up the volume lol), but it has TRIPLE glass!!
<Habbie>
pity "0 op de meter" is becoming fiscally uninteresting in five years
<Habbie>
but still, nice!
<fpsusername[m]>
Habbie: That for sure, but even though I live at the border of a village, 2.4GHz suuuuuuucks. I mean, it literally slows down surfing the web
<Habbie>
yeah, 5ghz is nice -because- it doesn't go far :)
<fpsusername[m]>
Habbie: Is it? All I know is that the energy harvested won't be sold as high as it is right now
<fpsusername[m]>
But it's still damn nice to not have to pay for your energy bill
<fpsusername[m]>
37.9m^2 solar panels
<Habbie>
indeed, the price you get will go down a lot
<Habbie>
38m^2 is nice, i could also go '0' with such a surface :)
<Habbie>
well, ex heating i guess
<Habbie>
anyway, i see several 5ghz APs in your future, and one for the garden
<fpsusername[m]>
Habbie: I don't need heating. Apparently the house is build in such a way where the indoor temp is always around 20 degrees
<Habbie>
impressive
<fpsusername[m]>
Habbie: Yes hahaha. One on each floor (thankfully, the designers routed Ethernet through the walls), one in the back garden (even though it's a small one) and one in the shed (front garden)
<fpsusername[m]>
I think I might give the other extender to my brother (he has the same house, at the other side of the street lol), and then I'll probably go for ubiquiti stuff in the future
<Harm_>
fpsusername[m]: when you edit your wireless network, which maximum transmit power does it list? When I did not configure the "eeprom" in the device tree it was stuck at max 6dBm.
<fpsusername[m]>
21dB (125mW)
<Harm_>
fpsusername[m]: that should be right. Setting the Country Code might also help (advanced settings tab)
<fpsusername[m]>
Yup, already did that
<fpsusername[m]>
Can we use another country code to get more power?
<fpsusername[m]>
Or is it already maxed?
<Harm_>
I did not try. Doesn't US have more power but less channels?
<Harm_>
Oh and I assume you did reconnect both antennas, right :P?
<fpsusername[m]>
Harm_: I never removed them, there's glue over the connectors
<Harm_>
that glue almost immediately fell off on mine
<fpsusername[m]>
Not here lol
<Harm_>
I also do not know whether using both 2.4 and 5 GHz has any impact on performance. This router has a single WiFi chip while I saw that most other routers have 2
<fpsusername[m]>
I think it's just limited to 21dB, hardware wise
<fpsusername[m]>
Harm_: I have 2.4Ghz disabled. I'd disable it completely if my printer would support 5GHz
<Harm_>
ok, `iw phy` in the shell lists all the available modes with their power
<fpsusername[m]>
2.4Ghz is basically unusable, it's like Ziggo hotspots. Yes it'll do, but you'd rahter not use it
* f00b4r0
happily uses 2.4 all the time :)
<fpsusername[m]>
Harm_: 21 dB up to channel 144. Higher channel 13dB limit
<fpsusername[m]>
Harm_: What if you put 5GHz on both bands?
<Harm_>
fpsusername[m]: not sure what happens
<Harm_>
try it!
<fpsusername[m]>
I guess only more interference though
<fpsusername[m]>
By the way, the bgnac wifi supports 160MHz at 5GHz ac, while the nac one only supports 80MHz
<fpsusername[m]>
* By the way, radio0 supports 160MHz at 5GHz ac, while radio1 only supports 80MHz
<Harm_>
Does it actually work? On https://wikidevi.wi-cat.ru/MediaTek_MT7615 it says that the MT7615D does not support that. We have the MT7615DN (see photos) but OpenWRT says MT7615E
<fpsusername[m]>
Should probably look at Dual Channel Wi-Fi AP Daemon as well
<fpsusername[m]>
Habbie: The picture is quite accurate. House is heated like an oven
<Habbie>
haha
<svanheule>
Habbie: "0 op de meter" sounds like a marketing term to me :P
<fpsusername[m]>
fpsusername[m]: Ah, a quick read on this is that the router/ap switches the device between one of the two networks, depending on which one is better. On my RAX20 router I disabled the feature because it's all too happy to switch me to 2.4GHz, even when I'm 3m away
<Habbie>
svanheule, of course
<fpsusername[m]>
But enabling it for 2x 5GHz might be good, not sure how good the system works
<Habbie>
svanheule, but it seems achievable if you build for it
<svanheule>
Habbie: we only use the term "passiefhuis" or "energieneutrale woning" hier in the south
<Habbie>
the belgian south?
<svanheule>
here in the south** (Dutch is leaking)
<fpsusername[m]>
Habbie: well, in the case of 38m^2 of solar panels, you'd harvest enough energy to supply 3 people in a household (1 child)
<Habbie>
svanheule, hier in de zuid, jongen
<svanheule>
Habbie: yes, that south. :)
<Habbie>
fpsusername[m], mathematically, yes :)
<fpsusername[m]>
Habbie: Flevopolder jonguh!
<Habbie>
fpsusername[m], not a real country, sorry
<Harm_>
:D
<Habbie>
(i just came back from a week camping there, it's very real)
<fpsusername[m]>
Habbie: Indeed, not a country, but part of a country
<minimal>
I think PassivHaus is the German term (and thought it was a trademark/licenced term so only places built to the defined spec could use the term)
<fpsusername[m]>
By the way, wifi scheduling doesn't seem to work. I disabled wifi after 21:00 and it's still detected by my phone
<f00b4r0>
jow: thanks, I'll bookmark that. I'll refrain from making sweeping comments about JSON in the future now :D
<jow>
now increase that number of quirks tenfold and you've got yaml
<f00b4r0>
lol
<stintel>
😂
<f00b4r0>
fascinating quirks in that doc. Screams of poor specification :)
<f00b4r0>
as for yaml, I am of the strong opinion that any language that relies on indentation for structure is utterly daft. that gets me a lot of love from python addicts :)
<jow>
lot of them due to utf-8 ideosyncracies
<f00b4r0>
indeed
MaxSoniX has quit [Quit: Konversation terminated!]
<stintel>
so the upstream Makefile uses CC = g++ which we override and build with gcc, that's one problem, then some extern "C" { .. } magic and fix the type of the size argument