<Ansuel_>
done full support Linux version 6.0-rc5 (ansuel@Ansuel-xps) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 11.2.0 r18107-db34b93331) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 SMP Sat Aug 13 12:05:29 2022
<stintel>
wait we haven't even decided on 22.10 with 5.15 and you're already doing 6.0? :P
<stintel>
is it going to be LTS ?
<Ansuel_>
no 6.1 will probably be LTS but having 6.0 ready = 6.1 will be a joke to port
<Ansuel_>
(also indirectly found 2 regression for ipq806x and sent fix so for 6.1 they will be fixed :D)
<slh>
6.0-rc5 or 6.1-rc5?
<slh>
I hope to get my hands on my ASRock g10 again 'soon' (1-2 weeks), to recover/ test it again. sadly there doesn't seem to be any non-invasive recovery method
csrf has quit [Ping timeout: 480 seconds]
csrf has joined #openwrt-devel
dangole has joined #openwrt-devel
<dwfreed>
slh: 6.0-rc5
<dwfreed>
was released on the 11th
goliath has quit [Quit: SIGSEGV]
<slh>
dwfreed: grrr, yeah, head --> sand
slh has quit [Read error: No route to host]
slh64 has quit [Read error: No route to host]
slh has joined #openwrt-devel
tlj has quit [Remote host closed the connection]
tlj has joined #openwrt-devel
slh has quit [Quit: leaving]
minimal has quit [Quit: Leaving]
csrf has quit [Remote host closed the connection]
csrf has joined #openwrt-devel
slate has quit [Quit: quit]
slate has joined #openwrt-devel
Ansuel_ has quit [Ping timeout: 480 seconds]
slh has joined #openwrt-devel
Ansuel has joined #openwrt-devel
cmonroe has joined #openwrt-devel
slh64 has joined #openwrt-devel
cmonroe_ has quit [Ping timeout: 480 seconds]
Ansuel has quit [Ping timeout: 480 seconds]
MatrixTravelerbot[m]1 has quit []
Q__ has quit [Quit: Client limit exceeded: 20000]
cmonroe has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
Slimey has quit [Remote host closed the connection]
Ansuel has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest664
srslypascal has joined #openwrt-devel
Guest664 has quit [Ping timeout: 480 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
swalker has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest667
srslypascal has joined #openwrt-devel
Guest667 has quit [Ping timeout: 480 seconds]
Ansuel has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
valku has quit [Remote host closed the connection]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
SlimeyX has quit [Read error: Connection reset by peer]
SlimeyX has joined #openwrt-devel
hanetzer has quit [Quit: WeeChat 3.5]
cmonroe has joined #openwrt-devel
Ansuel has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
cmonroe has quit [Ping timeout: 480 seconds]
cmonroe has joined #openwrt-devel
Ansuel has joined #openwrt-devel
csrf has quit [Read error: Connection reset by peer]
<ynezz>
arnd: hi, I apologize if my memory is rusty, but IIRC it was you helping us fixing Y2038, could you please check https://github.com/openwrt/openwrt/issues/10738 ([22.03] busybox ntpd is not Y2036-ready) ?
<arnd>
hi ynezz, I'll see what I can do. If I remember correctly, there are multiple problems with busybox ntpd, which was forked from some other implementation a long time ago. I need to dig into this one again to see what it actually does
<arnd>
ynezz: on the topic of y2038, there is another issue that came up recently: if any of the openwrt supported systems have a battery backed RTC and rely on CONFIG_RTC_HCTOSYS in the kernel to set the time, rather than using NTP, this won't work either, and the RTC has to be read in userspace
<jow>
we could also consider using another ntpd implementation
<jow>
busybox ntpd just was an attractive choice due to its small footprint
<arnd>
I suppose someone should fix busybox ntp anyway
<jow>
you're right
<ynezz>
arnd: if not done yet, it would be nice to get this RTC issue written down in the form of a new issue on GH issue tracker
<ynezz>
there is still plenty of time ahead to fix it all :P
<arnd>
the kernel patch is safe for openwrt as long as all userspace is time64 enabled
<ynezz>
ok, thanks
<arnd>
ynezz: I tend to disagree wtih the "plenty of time". While official openwrt support for the current release ends way before y2038, I'm sure there will be plenty of people running old forks of 22.03 or earlier then
<arnd>
ynezz: so the proposed fix for busybox/ntpd.c looks reasonable to me as a minimum to address the immediate problem. I still have to look up how others do it, because I think there is a protocol change in ntp that is meant to deal with it in a more reliable way (and past y2106).
<arnd>
the other problem I see is that the internal representation of time as a 'double' type in C is fundamentally flawed and causes loss of precision
<arnd>
but changing that would mean a rewrite of the entire thing
<jow>
untpd ? :P
danitool has joined #openwrt-devel
<arnd>
https://en.wikipedia.org/wiki/Network_Time_Protocol#Timestamps tells me that NTPv4 uses 64-bit timestamps to deal with the y2036 overflow. I don't know how that handles backwards compatibility. If everyone is expected to migrate to v4 before 2036, then changing the busybox ntpv3 implementation won't help
<arnd>
it's similar to the approach proposed by Miroslav Lichvar for busybox, but differs in the cut-off point: Miroslav's patch treats all timestamps before 1970-01-01 as post-2036, upstream only does this for times before early 1968 (with bit representations lower than 0x8000000)
<arnd>
the difference probably doesn't matter, unless we expect to have to deal with broken timestamps that are just before 1970 (from a broken server that reverts to Unix time 0 *and* uses the incorrect timezone conversion). I also see that upstream openntpd still has the 'double' representation
<arnd>
ynezz: to conclude this: the proposed busybox patch looks good enough to me for adding to openwrt, someone should get that upstream, and ideally there should be some regression testing to ensure this is actually sufficient\
aleksander has quit [Quit: Leaving]
Ansuel has joined #openwrt-devel
aparcar[m] has quit [Quit: Bridge terminating on SIGTERM]
tohojo has quit [Quit: Bridge terminating on SIGTERM]
ctdvqgg445[m] has quit [Quit: Bridge terminating on SIGTERM]
t4h4[m] has quit []
mkg20001 has quit [Quit: Bridge terminating on SIGTERM]
gnustomp[m] has quit []
pavlix has quit []
oliv3r[m] has quit []
evils[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Kiste has quit [Quit: Bridge terminating on SIGTERM]
barhom has quit [Quit: Bridge terminating on SIGTERM]
dfceaef[m] has quit [Quit: Bridge terminating on SIGTERM]
John[m]123456 has quit [Quit: Bridge terminating on SIGTERM]
decke[m] has quit [Quit: Bridge terminating on SIGTERM]
bluse-blue[m] has quit [Quit: Bridge terminating on SIGTERM]
lipnitsk has quit [Quit: Bridge terminating on SIGTERM]
MatMaul[m] has quit [Quit: Bridge terminating on SIGTERM]
fieryeagle954[m] has quit [Quit: Bridge terminating on SIGTERM]
nick[m]1 has quit [Quit: Bridge terminating on SIGTERM]
domon has quit []
Jonny[m] has quit [Quit: Bridge terminating on SIGTERM]
will[m]1 has quit [Quit: Bridge terminating on SIGTERM]
olmari has quit [Quit: Bridge terminating on SIGTERM]
hexagonwin[m] has quit [Quit: Bridge terminating on SIGTERM]
JuniorJPDJ has quit []
Movedtomkg20001mkg20001io[m] has quit [Quit: Bridge terminating on SIGTERM]
znullptr[m] has quit []
whatevs111[m] has quit [Quit: Bridge terminating on SIGTERM]
schmars[m] has quit [Quit: Bridge terminating on SIGTERM]
fpsusername[m] has quit [Quit: Bridge terminating on SIGTERM]
cbeznea has quit [Quit: Leaving.]
Ansuel has quit [Ping timeout: 480 seconds]
aparcar[m] has joined #openwrt-devel
cbeznea has joined #openwrt-devel
bluew has quit [Remote host closed the connection]
bluew has joined #openwrt-devel
<rmilecki>
jow: thnaks
Ansuel has joined #openwrt-devel
swalker has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
<ynezz>
arnd: thanks, would you like to add your Rewieved-by tag to that busybox fix?
cbeznea has quit [Read error: Connection reset by peer]
<ynezz>
I'm going to digest all this information later and would create the ticket for that another RTC flaw
<arnd>
sure, please add that
cbeznea has joined #openwrt-devel
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<f00b4r0>
is blogic around on irc still?
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
gladiac has joined #openwrt-devel
Ansuel has joined #openwrt-devel
<neggles>
I have acquired a ludicrous access point
<neggles>
with five 4x4 radios
<neggles>
and a UART header you can access without taking it apart
<Ansuel>
you should put something to better understand the size
<Ansuel>
like a pen
<neggles>
sure
<Ansuel>
ok that thing is BIG o.o
<f00b4r0>
the usb connector on the upper left corner of the last pic gives a good clue
<Ansuel>
wonder if we can find the fcc id so we have free internal photo
<f00b4r0>
that thing is humongous ;P
<neggles>
it has not been listed on fccid yet
<neggles>
i don't think it's approved for the USA?
<neggles>
4x4:4 on 2.4, 2x 4x4:4 5GHz which can be merged into one 8x8 5GHz, and two more 4x4:4 which are switchable between 5GHz and 6GHz and can do 160MHz
<Ansuel>
i think it's a miracle if it's approved for home use... that thing is compared to a tower station ahahah
<Ansuel>
Part Number(s): IPQ8074A, IPQ8078A, QCN9074
<Ansuel>
well
<Ansuel>
...
<neggles>
I did not pay anything *close* to sticker price for either of these
<Ansuel>
ipq8078a
<neggles>
wait
<neggles>
8074A *and* 8078A?
<Ansuel>
ipq8074a it's the generic name for the soc
<Ansuel>
it's probably ipq8078a for the top tier of that family
<neggles>
the lower tier ones have different platform/series names though
<Ansuel>
or it's 2 soc interconnected LOL
<Ansuel>
considering the amount of stuff it's probably 2 soc on the same pcb
<neggles>
welp
<neggles>
i'm going to have to open this up aren't i
<Ansuel>
we should ask robimarko for some LULZ
<Ansuel>
neggles should be pro sumer stuff so nothing like xiaomi shit where you have to destroy your arm to open it
<neggles>
nah
<nbd>
yay, for the first time i managed to connect two unetd instances to each other which are both behind NAT, in different networks and without using any centralized service aside from STUN
<Ansuel>
just a few screw under the rubber pads
<neggles>
no rubber pads
<Ansuel>
rip stickers
<neggles>
the screws are philips, and they go into threaded inserts
<nbd>
only put in the auth key on both sides, no configured ip addresses
<nbd>
aside from having a stun server in the network data
<nbd>
but i only put in the network data on one side, so the other one had to use DHT for peer discovery, then download the network data, then use the stun server from the list to open up a direct connection on the wg data port
<Ansuel>
nbd my concern with all of that is when one of the piece go down and the connection doesn't autorecover
<Ansuel>
example had many problem with wireguard about not autorecovering
<nbd>
unetd uses keepalive and explicitly tells wireguard to retry establishing connections
<nbd>
it also pings its peers on a side protocol which it uses to distribute network data updates
<nbd>
and uses that to detect endpoint changes
<nbd>
so it should handle autorecovery well, including ip address changes, nodes going down for a while, etc.
<jow>
pepes: I don't think the average PR quality is good enough for that
<jow>
also raises a lot of security questions
<neggles>
Ansuel: from the bottom of that pic to the top it appears to be RX TX 3V3 GND
<jow>
pepes: since whatever is merged ends up on the package mirrors automatically, so people could simply submit malware as PR and have it end up on downloads.openwrt.org a few days later
<jow>
it just has to pass the fmorality and compile test CI checks
<Habbie>
jow, i'd assume this would include one approving review
<Ansuel>
agree sadly, also we enforce kernel rules with sob and other stuff... automerge is good for some project but nope for us IMHO
<Habbie>
jow, (i, personally, also would not enable it, though)
<Ansuel>
jow in theory we can set that to wait for approval of our members but that would take ages
<jow>
Habbie: ah, but that is currently the bottleneck, not the green button :)
<pepes>
Well, what I just wanted is to have possibility as it is on GitLab. Whoever has commit access, can approve PR & hit the button that it will be merged automatically when CI success.
<Habbie>
that maintainer can already make that choice per-PR today, to be clear
indy has quit [Ping timeout: 480 seconds]
<neggles>
16MiB of SPI NOR, 256MiB of parallel NAND, 2GB of RAM... quallity
gladiac has quit [Quit: k thx bye]
<neggles>
on monday I shall upset our partner rep by demanding GPL sources >:D
gladiac has joined #openwrt-devel
gladiac has quit []
<Ansuel>
4.4 ...
<pepes>
Habbie: I can not see it there, that's why I was asking. I think it is disabled in repository's Settings, which I dont have access.
<neggles>
Ansuel: QSDK :P
<Habbie>
pepes, ah, right - per-PR choice can indeed be enabled by a repo owner
<Ansuel>
neggles qsdk is at 5.4 tho
<pepes>
But yeah, I agree that automerging otherwise should not be allowed, but I think per-PR choice can be handy.
<neggles>
Ansuel: yeah but cambium like to stay a bit back from the bleeding edge
<neggles>
for the sake of stability
<neggles>
unlike *some* vendors...
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
noltari_ has quit [Read error: Connection reset by peer]
noltari has joined #openwrt-devel
barhom has joined #openwrt-devel
bluse-blue[m] has joined #openwrt-devel
ctdvqgg445[m] has joined #openwrt-devel
decke[m] has joined #openwrt-devel
dfceaef[m] has joined #openwrt-devel
domon has joined #openwrt-devel
evils[m]1 has joined #openwrt-devel
fieryeagle954[m] has joined #openwrt-devel
fpsusername[m] has joined #openwrt-devel
gnustomp[m] has joined #openwrt-devel
hexagonwin[m] has joined #openwrt-devel
John[m]123456 has joined #openwrt-devel
Jonny[m] has joined #openwrt-devel
JuniorJPDJ has joined #openwrt-devel
Kiste has joined #openwrt-devel
Q__ has joined #openwrt-devel
lipnitsk has joined #openwrt-devel
MatMaul[m] has joined #openwrt-devel
Movedtomkg20001mkg20001io[m] has joined #openwrt-devel
mkg20001 has joined #openwrt-devel
nick[m]12 has joined #openwrt-devel
oliv3r[m] has joined #openwrt-devel
olmari has joined #openwrt-devel
pavlix has joined #openwrt-devel
schmars[m] has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
tohojo has joined #openwrt-devel
MatrixTravelerbot[m]1 has joined #openwrt-devel
whatevs111[m] has joined #openwrt-devel
will[m]1 has joined #openwrt-devel
znullptr[m] has joined #openwrt-devel
Slimey has joined #openwrt-devel
MAbeeTT5 has quit [Ping timeout: 480 seconds]
dangole_ has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
dangole_ is now known as dangole
indy has joined #openwrt-devel
minimal has joined #openwrt-devel
valku has joined #openwrt-devel
dohnuts_ has joined #openwrt-devel
<dohnuts_>
Hello
<dohnuts_>
PaulFerster: are you around ?
<dohnuts_>
PaulFertser: ?
<dohnuts_>
Hello, i am currently testing 22.03 on official YunCore ax820 and it doesnt work, the fdt is missing important clock entry i think, but so far i cannot get a kernel layout that the bootloader can jump into ( it is reconized ) , last try was to wrap the offical kernel with my own mkimage and it booted ( and got sutck in ) Calibrating delay loop
cbeznea1 has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
<f00b4r0>
dohnuts_: 22.03 works on AX820, I'm not sure what you mean.
<dohnuts_>
hello FOOBAR
<dohnuts_>
did you erase the bootloader ?
<dohnuts_>
because my ax820 is exploding when switching from uboot to kernel
<dohnuts_>
f00b4r0:
<f00b4r0>
i didn't touch the bootloader
<dohnuts_>
and booting the 22.03 DTB with offical kernel hang at `Calibrating delay loop`
<f00b4r0>
what is "official kernel"?
<dohnuts_>
so maybe theyr are not the same ax820 ??
<dohnuts_>
"official kernel" is the one you get when you recieve the board, from YunCore
<f00b4r0>
why do you try to boot a non-openwrt kernel with an openwrt DTB?
<ynezz>
IMO the install step is wrong/racy, it should probably prepare the new installation in some scratch directory and move it to the destination in one atomic step
gladiac has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
valku has quit [Remote host closed the connection]
starhunter has joined #openwrt-devel
<starhunter>
Hi
<starhunter>
one quick question
<starhunter>
in build config file, what happens when a config entry is marked as "xyz is not set"
<starhunter>
does that mean, default setting gets applied to xyz?
Borromini has joined #openwrt-devel
<starhunter>
i m bit not clear on marking a config entry as not set vs skipping that config entry all together
<Ansuel>
is not set = apply the default option
<Ansuel>
skipping the config entry = apply the default option
<f00b4r0>
hmm, are you sure?
<f00b4r0>
is not set = "N"
<f00b4r0>
skipping = default if defconfig, ask otherwise
<starhunter>
@Ansuel thanks, was confused since both look same.
<Ansuel>
actually i'm wrong... internet say that is not set = option is disabled
<f00b4r0>
that's what I wrote
<Ansuel>
yep you are right
<starhunter>
@00b4r0 just want to know for .config, defconfig i agree
<starhunter>
@f00b4r0 @Ansuel great, understood now, thanks for the quick help
<f00b4r0>
starhunter: the comments apply to .config. "defconfig" is a make option. Apply default would also happen in menuconfig mode
<f00b4r0>
:)
bluew has joined #openwrt-devel
csrf has quit [Ping timeout: 480 seconds]
gladiac has quit [Quit: k thx bye]
<Ansuel>
ls
<Borromini>
hentai/
<Ansuel>
homework/
<Borromini>
:P
starhunter has quit [Quit: Page closed]
Borromini has quit [Quit: Lost terminal]
<schmars[m]>
anyone aware of any work towards 802.11.ay? have this pair of mikrotik 60ghz cubes here and am wondering. has a qca6438 for 60ghz
<aparcar[m]>
schmars: I'd be interested, too. I think robimarko got some insights
<schmars[m]>
i'll happily get you two if you think it's feasibly - doesn't look like there's any driver yet, have only found the wil6210 driver for 802.11ad