<zorun>
blogic: I think it's safer to just revert the commit before 19.07.5
<nitroshift>
rsalvaterra, o/
<rsalvaterra>
nitroshift: o/
<ynezz>
zorun: anyone can propose patches, right? :)
<rsalvaterra>
Ok, something's wrong in master with DSA.
<rsalvaterra>
I just built an image and…
<rsalvaterra>
Fri Nov 20 09:30:34 WET 2020 upgrade: The device is supported, but the config is incompatible to the new image (1.0->1.1). Please upgrade without keeping config (sysupgrade -n).
<rsalvaterra>
Fri Nov 20 09:30:34 WET 2020 upgrade: Config cannot be migrated from swconfig to DSA
<rsalvaterra>
… WTF? This is already DSA!
<ynezz>
and what's wrong with that?
<mangix>
ynezz: that's an overstatement
<mangix>
rsalvaterra: which device?
<rsalvaterra>
Redmi AC2100 (mt7621).
<mangix>
the story there is interesting
<rsalvaterra>
The MT7530 switch is DSA.
<mangix>
yeah I know. I was partially responsible for it
<ynezz>
mangix: so you expect, that anyone is going to revert that commit in the stable release without any prior discussion?
<rsalvaterra>
I'm all ears (eyes). :P
<mangix>
ynezz: I was responding to your earlier comment
<ynezz>
mangix: ok, didn't get it, which one?
<mangix>
rsalvaterra: the story is that with 19.07, several mt7621 devices have issues with the ethernet driver locking up the device. my suggestion was to replace the openwrt driver with the one used upstream. that necessitated the move to DSA. Some are mad some are happy. Overall, easier maintainability
<ynezz>
rsalvaterra: swconfig to DSA migration is quite complex task, nobody so far was interested in that implementation, so it has to be done manually, so you at least get that notice and can decide yourself
<mangix>
ynezz: patch proposal one. I have 36 patches on the mailing list currently. Proposing != action.
<ynezz>
day has only 48 hours
<zorun>
ynezz: good point ;) will do
<mangix>
actually the ramips 5.4 moved several drivers to the upstream ones, which is quite nice
<mangix>
*5.4 bump
<rsalvaterra>
mangix: Sure, what I don't understand is why sysupgrade complained today about DSA, when it didn't yesterday or the day before. I have this device since Tuesday and the very first image I installed was already DSA-based.
<rsalvaterra>
Actually, I got this Redmi AC2100 for three reasons: a) I wanted to play with MT7621; b) The switch was already DSA-based; c) It's cheap as chips.
<rsalvaterra>
What I wasn't expecting is mt7603e and mt7615e only allowing 4 VIFs, but I can live with that. :P
<mangix>
most mt7621 i've owned had messed up wifi callibration, which ruins the performance of the interface
<mangix>
actually that was only one device
<russell-->
mangix: messed up how?
<mangix>
russell--: not present or all 0s. I don't remember
<russell-->
how did it happen?
<mangix>
indiegogo campaign
<russell-->
ah, lol
<mangix>
the guy didn't pay to get it done i guess
<rsalvaterra>
mangix: If caldata was messed up, the vendor firmware would have the same problem, not just OpenWrt, right?
<mangix>
well, vendor firmware was some weird mediatek SDK based build
<rsalvaterra>
LOL! My only experience with Indiegogo has been wonderful (Turris Omnia). :P
<russell-->
at some point i stumbled across a description of the mediatek factory partition format, but i don't know where it went and haven't found it again after some looking
<mangix>
I have one as well. Unfortunately I spent too much money on it. Now the wifi is ruined. Don't feel like spending money to fix it.
<rsalvaterra>
mangix: You can't ruin Wi-Fi on an Omnia. Just replace the cards, pigtails, antennas, whatever.
<mangix>
well, more like the wifi gets unstable aftet 2 days uptime
<mangix>
rsalvaterra: that's exactly what i did. now I need new pigtails and everything
<rsalvaterra>
(Oh, my…! I just realised the Redmi AC2100 is able to hit 27 dBm in the 2.4 GHz band and 27 dBm in the 5 GHz band.)
<mangix>
in other news, it amuses me how people take OpenWrt patches and apply them to non-OpenWrt platforms
<rsalvaterra>
*26 dBm in the 5 GHz band, I mean.
* mangix
googles
<rsalvaterra>
mangix: I find more amusing receiving emails from patches which I wrote in 2016 being applied to kernel trees I never knew existed, in 2020.
<mangix>
does this seriously not have any ethernet ports?
<mangix>
ah nvm. 4
<mangix>
that's 2 less than the omnia
<mangix>
this reminds me why I hate mt7621
<rsalvaterra>
I never saw anyone complaining about the 3 ports on the APU2C4, for example… :)
<mangix>
mt7621 still is not using the upstream MMC driver. Unfortunate
<mangix>
I remember the OpenWrt one being quite unstable
<mangix>
same with the USB driver
* mangix
finds his bottle of Ouzu
* russell--
has some APU4's coming because the APU2 only has three interfaces ;-)
<russell-->
mangix, my dir860l with mt7621 had a semi-flakey USB (some devices didn't work) a long time ago, i haven't checked recently
<mangix>
there's a local openwrt patch for ramips for the USB. There are reports that it's unnecessary. I don't remember if I tested removing it.
<zorun>
russell--: I was wondering, is the APU4 also using separate NICs like the APU2, or is there a built-in switch?
<russell-->
zorun: seperate nics, although the connectors are all i a block
<zorun>
ah ok, thanks,
<russell-->
so you need a new case :-)
<zorun>
yeah this is why I was wondering :)
<russell-->
apu4d4 = 4 i211AT LAN / AMD GX-412TC CPU / 4 GB DRAM / dual SIM
mangix has quit [Read error: Connection reset by peer]
<russell-->
yeah, the cpu is getting old. i am using mine strictly as a gateway on a gigabit fiber service, and it does that nicely
<russell-->
i have an apu2 now, since 2016-ish, same cpu
<zorun>
yes we also have lots of apu2 (3 ports is enough when you have a switch to untag VLANs)
<zorun>
it's generally fine when doing pure forwarding, but wireguard or even PPPoE will bring it to its knees
<zorun>
actually, PPPoE is slower than wireguard on these devices :-)
<zx2c4>
!? why
<zorun>
mostly because of single-threading vs multi-threaded I guess
<zx2c4>
but pppoe just has to strip 8 bytes off or something
<zx2c4>
unless its a userspace implementation?
<zorun>
well now that I think more about it, we are doing wireguard *on top of* PPPoE
<zx2c4>
ohh
<zorun>
so no wonder it's slower
<zx2c4>
A+B vs B
<zx2c4>
makes sense
<zx2c4>
i switched from orange to bouygues for pretty much the exclusive reason of avoiding pppoe
<zorun>
yes, but the bottleneck clearly seems to be on the pppoe side
<zx2c4>
huh, interesting
<zorun>
not sure if it's userspace or offloaded to kernelspace though
<zorun>
zx2c4: you know that Orange is no longer doing PPPoE for fiber :)
<russell-->
i have pppoe here, but haven't noticed performance problems
<rsalvaterra>
I believe most ISPs around here got rid of PPPoE, fortunately.
<zx2c4>
reaaaaaaaly?
<zorun>
yeah, for several years already
<zx2c4>
wow
<zx2c4>
still vlan 835?
<zorun>
I mean, you can still do it (although at some point they will probably drop support for it)
<zorun>
but DHCP is the default now
<zorun>
yes
<zx2c4>
oh awesome
<zx2c4>
do you have to send funny strings in dhcp or does it work OOTB?
<zorun>
not OOTB of course :)
<zorun>
it requires fiddling with weird ethernet priority flags
<russell-->
depending on which box
<zorun>
see lafibre.info
<zx2c4>
Im running something like `busybox udhcpc -i internet -f -p /run/udhcpc.pid -r 176.123.123.123 -V "BYGTELIAD" -s /bin/true` for bouygues
mangix has joined #openwrt-devel
<zorun>
I don't remember the details but I see things like "vconfig set_egress_map" and "iptables -t mangle -A POSTROUTING -o $IFACE.832 -j CLASSIFY --set-class 0000:0001" in the place where I setup this long ago
<zorun>
and a "rfc3118-authentication" DHCP option
<mrkiko>
zx2c4, zorun: I'll be switching to FWA technology soon, due to no better choice. I'll have to do pppoe on my openwrt router, they bring me their own device that sits between me and the antenna
<mrkiko>
on the ruff
<mrkiko>
I would like so much if I could do a dhcp with a single openwrt based device with no intermediate ones
<mrkiko>
guess I'll have to wait for SFP fiber and FTTH?? Or am I missing something?
<zorun>
I don't know FWA technology
<mrkiko>
zorun: me neither, my ISP seem to use it's own frequency band, 28 ghz, for the link ...
<mrkiko>
will pppoe be a major bottleneck in performance'
<mrkiko>
and wanted to know if there is a way I can discover the optimal MTU - I admit i never explored / understood the MTU thing too much in PPP world.
<zorun>
ah, FWA means "Fixed Wireless Access", I thought it was the name of an ISP
<zorun>
pppoe is generally a bit slow, yes, but you have to test/benchmark
<mrkiko>
zorun: yeah, sorry for not specifying that. FWA is the technology, the provider is EOLO. yeah, I'll try to do my best.
<mrkiko>
zorun: I am blind user, so having an openwrt box is very very nice and useful, let alone all the advantages of openwrt. so I try to minimize what's between openwrt and the ISP, not a easy task you know :D
<zorun>
yes :)
<zorun>
jow: I'm looking at adding persistent connections to opkg downloads, would it be acceptable to depend on libuclient/libustream-ssl?
<zorun>
"libustream-wolfssl20200215 doesn't validate TLS server certificates"
* rsalvaterra
thinks of replacing lzo and deflate with zstd, on ubifs…
victhor has joined #openwrt-devel
victhor has quit [Remote host closed the connection]
victhor has joined #openwrt-devel
* karlp
discovers he has wolf installed again, bah
<karlp>
thanks zorun :)
<zorun>
:D
Borromini has joined #openwrt-devel
<karlp>
curl has openssl, and I have openssl for other things, but still ended up with libustream-wolfssl installed
<rsalvaterra>
karlp: That was one of the reasons I made the {hostapd,wpad}-basic-openssl variants. ;)
<rsalvaterra>
I'm stuck with OpenSSL for Tor… :P
<karlp>
you still need wolf for wpa3 right? are we still in that trainwreck of compatibility?
<rsalvaterra>
karlp: No. I have WPA3 Personal and OWE with hostapd-basic-openssl.
<zorun>
I think the issue was with mbedtls
<rsalvaterra>
Actually, I also wired up support for OWE in the -basic variants.
<karlp>
remind me again why we have "Wireless" and "WirelessAPD" menus?
<karlp>
the indentation of wpad is still all bogus though, that's never imrpoved :)
<karlp>
wolf is still indended under openssl
<rsalvaterra>
karlp: The indentation is… a mess, but I don't know how to untangle it, do I didn't. :P
<karlp>
yeah, i tried once years ago, gave up very quickly .)
<rsalvaterra>
*so
<russell-->
[6~
<rsalvaterra>
I'm trying to find where in the source the filesystem for the overlay created (I believe it could be done at sysupgrade or first boot time). Does anyone know? :P
<rsalvaterra>
*overlay is created
<Borromini>
karlp: i had to use the 'per device image' buildroot option to remove the wolfssl stuff and keep the openssl stuff
<Borromini>
at least, i think i had to. building for multiple devices in a single arch (mt7621, ath79)
nitroshift has quit [Quit: Gone that way --->]
<russell-->
zorun: speaking of apu2's and pppoe, intel says i211at interfaces can do jumbo frames, i haven't figured out how to avoid 1492 byte mtu on the pppoe interface
<zorun>
russell--: I never tried, but the other end also needs to support jumbo frames, it's not obvious it will work
Borromini has quit [Read error: Connection reset by peer]
<zorun>
and by the other end I mean the whole network path that will transport your encapsulated packets...
Borromini has joined #openwrt-devel
Borromini has quit [Ping timeout: 256 seconds]
feriman has joined #openwrt-devel
<damex>
rsalvaterra: but does that {hostapd,wpad}-basic-openssl fit on 4m~ device?
<rsalvaterra>
damex: Did you see the rationale behind it?
<damex>
rsalvaterra: thanks, it is kinda slipped past me and i thought all the way that it is a 4MiB device ;p
adrianschmutzler has joined #openwrt-devel
<damex>
so technically should wpad-openssl on ar71xx device (19.07) be enough to get wpa3?
<rsalvaterra>
damex: Do you need WPA Enterprise?
<damex>
rsalvaterra: nope, just 'personal'
<rsalvaterra>
Ok, in that case, if you only need AP mode and you don't have anything that depends on OpenSSL, I'd recommend hostapd-basic-wolfssl.
<rsalvaterra>
This will give you both WPA3 Personal and OWE.
mangix has quit [Read error: No route to host]
<pavlix>
Is there a way to completely disable the kernel build? Including module packages, that's perfectly fine. I just want a rootfs to be used with externally built kernel.
nitdega has quit [Ping timeout: 260 seconds]
<damex>
rsalvaterra: is it available for current release or have to built from scratch? can't see on mirrors/packages/device itself
<rsalvaterra>
damex: Master only.
<damex>
oh, master have no support for ar71xx anymore :(
<rsalvaterra>
Wait, no.
<rsalvaterra>
I think…
<rsalvaterra>
damex: Hasn't that device been ported to ath79?
<damex>
rsalvaterra: nope ;(
<damex>
make image PROFILE=ubnt-air-gateway-pro PACKAGES="wpad-openssl -wpad-basic luci" results in 4.9M so should be fine i guess
<damex>
in imagebuilder
<rsalvaterra>
Yeah, should be fine.
<PaulFertser>
With your skills damex it shouldn't be too hard to port it to ath79 if there's nothing special about that device (mikrotiks being an example of special here)
heffer has quit [Read error: Connection reset by peer]
daregap has quit [Quit: daregap]
heffer has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
<damex>
PaulFertser: yeah, should be straightforward to port. problem is that it is time consuming to recover device (tftp) since opening device casing for serial access - require sacrificing one of the devices (or most of it). so time it is
<damex>
technically board will be functional but casing will be in a very bad shape or not usable at'all. i find that it is completely glued. sometime even glued to the board
<PaulFertser>
I see. Unless you need it outdoors it's probably not that essential.
<rsalvaterra>
damex: It's a ubnt device. Doesn't the bootloader contain a TFTP server? I recover my AirGrid easily that way.
<rsalvaterra>
Never had to open it, and I've bricked it a couple of times.
<damex>
rsalvaterra: yeah, there is tftp recovery. it just takes time to do things semi-blindly that way :(
<rsalvaterra>
Better than nothing, but I see your point… these devices are assembled once and not mean't to be opened again.
<rsalvaterra>
*meant
<adrianschmutzler>
but we backported wpad-basic-wolfssl to 19.07 in case that helps you
<adrianschmutzler>
this should work with ar71xx unless you have a 4M device
zjason has quit [Quit: ERC (IRC client for Emacs 27.0.50)]
<rsalvaterra>
adrianschmutzler: Speaking of which, we really should treat hostapd and wpa_supplicant as separate daemons, even when building wpad… It doesn't make sense to start wpa_supplicant unconditionally, if the user hasn't configured at least one station (or hostapd, if the user hasn't configured at least one access point).
<adrianschmutzler>
rsalvaterra: That's not my realm, you will need to find somebody else to discuss that.
<rsalvaterra>
I don't know how hard it would be, though. Splitting the init script is trivial.
<rsalvaterra>
adrianschmutzler: Who'd you recommend?
<adrianschmutzler>
Maybe check out the git history of package/network/services/hostapd directory ...
<rsalvaterra>
Ok, dangole, most likely. :)
<karlp>
jow, reflashing 1907 from master, and keeping config (yes yes, not always a good idea) is giving me weird luci errors: /usr/lib/lua/luci/dispatcher.lua:426: /etc/config/luci seems to be corrupt, unable to find section 'main'
<karlp>
but there is a main section there?
<zorun>
this error is misleading, it might mean that rpcd is not started
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ynezz>
or any other issue in that path
<damex>
adrianschmutzler: rsalvaterra: thanks, i see that it works fine on 4 airgateways with wpad-openssl and it has enough free space. i will try to bundle all needed stuff along with wpad-basic-wolfssl later ;p
Nick_Lowe has joined #openwrt-devel
<mrkiko>
so I might try wpa3 as well on R6220?
<rsalvaterra>
mrkiko: I don't see why not.
<mrkiko>
rsalvaterra: :D thanks. No no hardware assistance needed, all the changes are in authentication / hostapd
dangole has joined #openwrt-devel
opal has quit [Ping timeout: 240 seconds]
repulse has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
opal has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
qdel has quit [Ping timeout: 256 seconds]
qdel has joined #openwrt-devel
<dangole>
rsalvaterra: we can hack logic into netifd to tell procd to start either or both instances only if configuration actually requires that.
<PaulFertser>
dangole: it would be really nice because currently it's just a waste of RAM for many people.
<dangole>
rsalvaterra: if using 'wpad', the gains of doing so are minimal, just checked VmPTE: 16 kB, RssAnon: 104 kB for wpa_supplicant ideling on ath79/generic... (and that's all added in case hostapd applet of wpad is running from what i understand)
<dangole>
rsalvaterra: but yet, you are right, not starting them on boot but letting netifd tell procd to start/stop them selectively if needed would be more elegant
<rsalvaterra>
PaulFertser: The amount of RAM saved isn't as much as it seems at first sight. Since the code is only mapped once, it's shared by both instances. It's mostly a matter of efficiency, which I'm a bit obsessed with. :P
<dangole>
rsalvaterra: on the other hand it's also nice to have them always available for performance reasons :)
<rsalvaterra>
dangole: Compromises… ;)
<mrkiko>
but - am I wrong, or when I do "wifi up" after changing config, they are killed and restarted?
<rsalvaterra>
mrkiko: Hmm… I believe that changed recently and the configuration is updated without killing the processes, but I may be wrong.
<rsalvaterra>
(On master, of course.)
<rsalvaterra>
dangole is the hostapd guru, I'm just a n00b. :P
<mrkiko>
rsalvaterra: it would be great!!
<mrkiko>
Seems nice
<mrkiko>
BTW - was looking at Wi-Fi HaLow, wondering if I can find hardware supporting that.
<dangole>
mrkiko, rsalvaterra: currently dynamic reload is still optional. you have to do 'wifi reconf' to take full advantage of the new features.
<rsalvaterra>
Ah, good to know!
<rsalvaterra>
I guess there may still exist bugs to iron out.
<dangole>
otherwise wireless_process_kill_all() is still called and kills the instance, which leads to somewhat similar to the pre-dynamic reload behavior.
<rsalvaterra>
Yeah, wifi reload is *slow*.
* rsalvaterra
still hasn't found where the ubifs overlay partition is created/formatted…
eduardas has quit [Quit: Konversation terminated!]
<rsalvaterra>
Been there, but didn't see it… I was looking for a mkfs.ubifs call…
<mrkiko>
I was expecintg something like ubimkvol
<rsalvaterra>
The thing is, I see the kernel being built with lzo and deflate compression for ubifs, when zstd is already available, which doesn't make sense. If we're compressing, we should be using zstd.
<mrkiko>
but I know nothing about ubi actually
<mrkiko>
rsalvaterra: agree
<rsalvaterra>
mrkiko: I know that ubi exists and what it is. I know that ubifs sits on top of ubi. Don't ask me anything else. :P
<mrkiko>
rsalvaterra: at least in terms of performance / compression ratio. And I would love to be able to select SLOW but very compressive options
<rsalvaterra>
Yeah, lzo is fast, deflate has good compression rato, but zstd is both fast and has good compression ratio. It's the best of both worlds.
<mrkiko>
rsalvaterra: nand_upgrade_prepare_ubi() in nand.sh ??
<rsalvaterra>
mrkiko: Been there too, maybe I missed it…? Let's see…
* mrkiko
thinks one day he may benefit from looking well at the base-files package, lot of acumen here
<rsalvaterra>
It looks like it, but I don't see any compression parameters…
dangole has quit [Ping timeout: 240 seconds]
dangole has joined #openwrt-devel
<mrkiko>
rsalvaterra: maybe we call it at build time and not in the device? include/image.mk
<mrkiko>
rsalvaterra: around line 258
<dangole>
mrkiko, rsalvaterra: you are looking are the compression of ubifs-rootfs. not at the compression parameters of the ubifs overlay which you have on top of squashfs (which provides *much* better compression than ubifs at the cost of being read-only)
<rsalvaterra>
mrkiko: I think that's for ubifs rootfs, not overlay…
<rsalvaterra>
dangole: Right.
<mrkiko>
rsalvaterra, dangole: sorry, you're right guys
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<mrkiko>
but now I'm curious :D
<dangole>
we should enable CONFIG_UBIFS_FS_ZSTD by default imho
nitdega has joined #openwrt-devel
<rsalvaterra>
dangole: And disable the others. *However*: mtd-utils needs to be linked against libzstd, I believe.
<rsalvaterra>
(At least I tried to manually mkfs.ubifs --comp=zstd from our staging_dir, and it told me to sod off.)
<mrkiko>
ok guys, but in nand.sh, around line 189
<dangole>
rsalvaterra: ...on host in order to generate zstd compressed ubifs rootfs images. for ubifs overlay i don't think anything is needed in userspace, all work done by the kernel, just give it the right mount options
<mrkiko>
i can find only the mkvol call.
<rsalvaterra>
dangole: If it's only for the rootfs case, perfect. But I still haven't found where the overlay ubifs volume is created, and with what compression options. :)
<dangole>
you could even try something crazy like `mount /dev/ubiX_X /overlay -t ubifs -o remount,compr=zlib`
<rsalvaterra>
I like that craziness.
<dangole>
overlay is implicitely created by mounting the rootfs_data ubi volume. compression in per-file in ubifs, you can always decompress whatever your kernel supports and right now we just use the default (?) compression for newly written files as no mount option 'compr=...' is passed when procd mounts the overlay
<dangole>
hence i was wondering if remounting could simply work to switch the compression used for files created of modified from then on
Borromini has joined #openwrt-devel
<rsalvaterra>
dangole: In that case, the default is lzo, for sure.
Grommish[M] has quit [Ping timeout: 260 seconds]
feriman has quit [Quit: WeeChat 3.0]
<rsalvaterra>
Aww… the MT7621 PCIe bus only supports a 128 byte payload size… :P
<rsalvaterra>
… but the mt76 chips only support 128 bytes too. Fine, I guess.
MichaelOF has quit [Quit: Konversation terminated!]
linzst has quit [Quit: Leaving]
<dangole>
rsalvaterra: remount of overlay to change compression worked for me on my ubifs testing device:
<dangole>
mount /dev/ubi0_1 /overlay/ -o remount,compr=zstd
<aparcar[m]>
ynezz: ping
<aparcar[m]>
dangole: rsalvaterra morning
novski__ has joined #openwrt-devel
KGB-1 has quit [Quit: KGB-1]
KGB-1 has joined #openwrt-devel
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aparcar[m]>
jow: at which point is `luci` or `luci-ssl` selected? It only happens on the buildbots right?
Borromini has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
Nick_Lowe has quit [Client Quit]
<philipp64>
anyone able to run openwrt on KVM for x86_64? what profile do you use? I have a C8 KVM server with cores to spare…
<zorun>
yes, the x86_64 image runs just fine
<zorun>
I haven't tested in a while though
<philipp64>
can you pastebin the .xml you’re using?
<philipp64>
I was having issues with the secure boot ROM stuff…
<aparcar[m]>
zorun: do you still have the opkg size missmatch issue? I tried to fix it "upstream" to make packages reproducible, so ideally this patch wouldn't even be required
<zorun>
you mean libvirt profile? I don't use libvirt
<zorun>
aparcar[m]: it's still an issue in 19.07.4 yes, and it seems unfeasible to have 100% reproducible packages
linzst has joined #openwrt-devel
<philipp64>
zorun: yes, libvirt/virsh… okay, how do you set it up?
<aparcar[m]>
great this fixes a major annoyance with my upgrade server. I'll give it a try
Acrisor has joined #openwrt-devel
Acrisor has quit [Read error: Connection reset by peer]
Acrisor has joined #openwrt-devel
linzst has quit [Quit: Leaving]
heffer has quit [Read error: Connection reset by peer]
<jow>
aparcar[m]: luci is selected by the buildbot seedconfig
<jow>
we never did a build with luci-ssl by default
<jow>
(which appears to be quite broken on master btw.)
<jow>
overall the ustream-wolfssl backend seems to be in a very deranged shape, certainly not stable release material
<SAn>
jow: Great! Thank you!
feriman has quit [Ping timeout: 264 seconds]
<jow>
hm, switching to another ustream-ssl provider is also a huge hassle because it requires removing ustream-wolfssl which then breaks opkg due to the https requirement
<jow>
the certs generated by /etc/init.d/uhttpd are not readable by ustream-mbedtls either
<jow>
even which changing key type from ec to rsa
<jow>
that all feels very brittle and untested
<aparcar[m]>
excellent, solid argumentation against having it in the next release ;P
<jow>
ustream-wolfssl in its current shape, is a desaster
<jow>
as reported in the bugs, it also fails to actually verify tls certificates
<aparcar[m]>
I'm btw in favor to disable https per default again now that imagebuilders have signature checks
<jow>
so the stated goal of preventing MITM for package installs is missed
<jow>
therfore we can ditch https:// again
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<aparcar[m]>
please go ahead
<jow>
uhttpd is broken as well with ustream-wolfssl as backend, spurious http 400 errors. ustream-openssl and ustream-mbedtls work fine
<aparcar[m]>
so we wait for mbedtls wpa3 support?
<jow>
or fix all the other wolfssl related regressions
<aparcar[m]>
isn't wolfssl < mbedtls?
<jow>
no idea, I didn't follow the whole crypto craze
<jow>
at the very least - if we decide to release something with ustream-wolfssl by default - we should ensure that it verifies certiifcates as a minimum
<aparcar[m]>
dangole: please join
<jow>
and that luci-ssl works
<jow>
or uhttpd w/ ssl rather, regardless of lucoi
girth has quit [Read error: Connection reset by peer]
girth has joined #openwrt-devel
<dangole>
aparcar[m]: pong
<aparcar[m]>
for 20.xx I'm against ssl support per default. While it first looked like we "just" need some LuCI UX we now have to fix actual crypto
Redfoxmoon has quit [Read error: Connection reset by peer]
ivanich has quit [Quit: Konversation terminated!]
gch9812133806 has joined #openwrt-devel
<jow>
I agree. I'd rather ship without "crypto" than shipping broken crypto
<ynezz>
or just say, that we're aiming at 21.06 so there is plenty time to fix it
Redfoxmoon has joined #openwrt-devel
<jow>
would work for me as well
gch981213380 has quit [Ping timeout: 240 seconds]
gch9812133806 is now known as gch981213380
<aparcar[m]>
but withouth skipping 20.xx please
<ynezz>
the main blocker here is dsa anyway
dangole has quit [Quit: Leaving]
<jow>
the netifd side seems to be mostly settled
<jow>
defualt configs for dsa targets need to be adjusted yet and luci support merged and completed
<ynezz>
yeah, the luci part is probably essential for wider adoption and testing, then people will actually start using it, report corner cases aka release blockers and we've april behind the doors :)
norris has quit [Ping timeout: 260 seconds]
norris has joined #openwrt-devel
lynxis has quit [Remote host closed the connection]
zaolin has quit [Read error: Connection reset by peer]
dangole has joined #openwrt-devel
<jow>
I can probably finish the LuCI DSA part until mid of december
<jow>
its 70-80% done
<jow>
only need to add wireless bridge-vlan support which is intentionally omitted atm because netifd didn't implement all required features until recently
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dedeckeh has quit [Ping timeout: 245 seconds]
Nick_Lowe has joined #openwrt-devel
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 256 seconds]
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aparcar[m]>
jow: so parts of it are already testable or nothing at all?