01:27 <darkxst> I have a PR that fixes Edgerouter-X for kernels > 3MB and thus brings back snapshot builds. Are any ramips maintainers able to take a look at this? so far it has been reviewed by DragonBluep. https://github.com/openwrt/openwrt/pull/15194

02:24 <jeffsf> Chasing down why WiFi stations aren't authenticating with ipq40xx on main branch

02:24 <jeffsf> Everything worked as expected at commit 37ff916af7 Author: Rafał Miłecki <rafal@milecki.pl> Date: Fri Jul 14 12:35:26 2023 +0200

02:25 <jeffsf> It works on v23.05.3

02:25 <jeffsf> It fails on main with no evidence that I see in the logs

02:26 <jeffsf> So far I've backed up to commit c42b915af0 Author: Daniel Golle <daniel@makrotopia.org> Date: Tue Feb 20 21:14:03 2024 +0000 without regaining WiFi connectivity

02:26 <jeffsf> Does this ring a bell with anyone?

02:40 <jeffsf> Probably more helpful to say "connecting" and not "authenticating" as it doesn't seem that the connection progresses to any kind of log message from wpad

06:24 <dwfreed> jeffsf: you would probably find it faster using git bisect instead of just working linearly backwards

06:24 <dwfreed> bisect uses a binary search tree

07:06 <enyc> FWIW: I think the Wifi Security dropdown list in OpenWRT needs updating; in terms of PSK -- basically WEP and WPA need to be marked (legacy), WPA2-only (compatibility) should default to Cipher AES/CCMP only, WPA3-only (new devices only), WPA2+WPA3 mixed mode creating problems even with new equipment; I really think this needs labelling/warning in some way more realistic to current situations.

07:07 <enyc> Seems you ''have to know'' that WPA2-AES-only is often what is really needed and defauling to allowing TKIP there is problematic, too.

07:08 <enyc> Basically security risks with TKIP and seemingly ubiquitious support for AES-CCMP are such that it makes more sense to put that in the 'legacy' category.

07:09 <dwfreed> if you're running openwrt, you probably know this already

07:09 <dwfreed> but feel free to make a patch

07:12 <enyc> dwfreed: well; it depends, see theres lots of newbies and techie-interested but not all knowing etc, it varies

07:12 <enyc> dwfreed: so I don't think the interface should be making this needlessly problematic

07:12 <enyc> dwfreed: indeed, whats the best ways 'into' git and patching and access and so-on ?

07:12 <dwfreed> github

07:13 <enyc> dwfreed: in a sense I'm a "newbie to joining development"

07:13 <dwfreed> you can edit the file and make a PR without leaving your browser

07:13 <enyc> dwfreed: right, though i'd want to test interactions with any logic changes to defaults for cipher and exiting config, but fine.

07:13 <dwfreed> it's just text

07:14 <dwfreed> like, there's a separate part for the actual "value" of the selection

07:14 <enyc> dwfreed: not quite, part of this is text, other is change in defaults for cipher on separate bit

07:14 <enyc> dwfreed: for new config builds etc

07:14 <dwfreed> also you don't need to hilight me in every line

07:15 <enyc> (not hilighted) hrrm; just standard practice replying in irc; not 'going out of my way to higlight you'

07:15 <dwfreed> no, standard practice is *once*, if that, generally only when the person you're replying to does not appear to be around at the moment

07:15 <dwfreed> otherwise, every hilight is a beep, and I don't need 7 beeps in 2 minutes

07:16 <enyc> curious, enver come across that beep config before; what IRC client is that?

07:17 <dwfreed> irssi, which by default beeps if you're not looking at the window that hilighted you at that second

07:17 <dwfreed> most clients give some form of notification or sound on a hilight

07:18 <f00b4r0> sorry for OT, but I'm looking for a *reliable* alternative to Seafile, if anyone has a first-hand-tried suggestion

07:18 <dwfreed> I'm in approximately 170 channels; I'm not necessarily looking at a specific one for longer than 30 seconds, but I can jump back to it quickly

07:19 <dwfreed> f00b4r0: nextcloud, though it's probably a bit heavy

07:20 <f00b4r0> yeah I'm told it's very slow

07:21 <dwfreed> are you using seafile as a full dropbox/google drive replacement? as in, sharing and such would be useful to you?

07:21 <enyc> Aah my irssi in screen + terminal that don't seem to be passing bells thourgh hrrm

07:22 <f00b4r0> dwfreed: yeah, basically I'm using seafile to 1) share between multiple devices I own (with r/w access) and 2) share read-only (mainly via web interface) with 3rd party

07:22 <dwfreed> does the screen flash instead?

07:23 <f00b4r0> it worked well, until I noticed a catastrophic data corruption that resulted in partial data loss. Which is a total deal breaker.

07:25 <dwfreed> a search found https://github.com/pydio/cells

07:27 <f00b4r0> thx, I'll look, but I was hoping for some "I use this and it works well" kind of happy feedback :)

07:38 <f00b4r0> dwfreed: it looks promising, thanks. Also they're French, which is a plus for me :D

07:38 <dwfreed> heh

07:46 <f00b4r0> though sadly the free version is seriously crippled. It doesn't even offer MFA. *sigh*

07:47 <f00b4r0> we can't have nice things.

07:49 <dwfreed> yeah, I thought that was a bit odd

10:02 <ynezz> f00b4r0: min.io

10:19 <f00b4r0> ynezz: thanks but it looks vastly overwhelming for what I need

17:09 <Ansuel> nbd can you check the wps pr? I made the ucode conversion (sorry for being annoying)

17:19 <nbd> took a quick look

17:20 <nbd> aside from some minor typos (hostpad vs hostapd), i think storing psk data in a file named after the ifname is problematic

17:21 <nbd> let's say you have two ap interfaces, phy0-ap0 and phy0-ap1

17:21 <nbd> delete the first one, and the second one will inherit the first one's psk entries

17:21 <nbd> we probably need to store wps entries in uci

17:22 <nbd> for that we should have a ucode based listener on ubus which takes psk entries and writes them to uci

17:22 <nbd> so that we don't have to give hostapd access to the uci config directly

17:33 <Ansuel> nbd jow already said that storing the thing in uci is a no go...

17:33 <Ansuel> commiting the data might cause unintended effects like committing pending changes, reorder or dropping stuff

17:34 <Ansuel> i wanted to use the file since as you can see it's easy to append stuff to it... but we can put everything in one file and add more data... parsing function will be less optimized but it's still a thing done once

17:35 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (96.8% images and 100.0% packages reproducible in our current test framework.)

17:39 <nbd> okay, different idea:

17:40 <nbd> for permanent wps psk storage, a filename needs to be explicitly provided via uci

17:40 <nbd> that has the extra advantage of allowing using a single file for multiple wifi-ifaces

17:41 <nbd> and after writing a file, psk reload should be done on all interfaces

17:41 <nbd> agreed?

17:48 <Ansuel> with filename you mean a custom one and not the one that hostapd use to store psk (for vlan for example) correct?

17:48 <nbd> yes

17:49 <Ansuel> single file is totally ok my concern is what info to put inside ifname? ap name?

17:49 <Ansuel> (aside from the mac addr of the station and the key)

17:49 <Ansuel> wifi-station uci also use ifname so i think using ifname should be O.K.

17:50 <Ansuel> also reload is not needed, hostapd already save the new entry in the .psk file (by chown the .psk file in /var)

17:50 <nbd> well, the generated .psk files are still per-ifname

17:51 <nbd> i mean the generated-at-startup files

17:51 <nbd> but the file being written to should not have to be per-ifname

17:51 <nbd> it should be a path referenced from the wifi-iface section

17:52 <Ansuel> do we have a way to exactly reference the uci section ?

17:52 <nbd> no

17:52 <nbd> we should not reference the section

17:52 <nbd> the section should reference the file

17:52 <Ansuel> oh ok so each section should have the option like wps_psk_file

17:53 <nbd> yes

17:54 <Ansuel> ok now the only remaining problem is how to add this option to the already existing config...

17:54 <nbd> and if you specify the same file using wps_psk_file from multiple sections, then appended psks should be shared across those interfaces

17:55 <nbd> if you move the file writing outside of the hostapd process (e.g. via ubus, as i suggested), you have more flexibility in writing to such files on the filesystem

17:56 <nbd> and then we should make sure that the script-generated .psk files get rewritten and reload gets called

17:57 <nbd> in order to ensure that added wps psk entries propagate when shared across interfaces

17:57 <Ansuel> main problem of giving user this freedom is that the custom file might be dropped with a sysupgrade... that is why i would put everything in /etc/hostapd so that hostapd.uc can just use file operation (the directory owner will be network and hostapd will have permission to write there)

17:58 <nbd> we already have support for specifying files directly from config files

17:58 <nbd> maybe we should just fix the underlying issue by having appropriate sysupgrade hooks

18:01 <Ansuel> oh didn't know we could preserve file specificied in uci config. Anyway still missing how to handle configuration where wps is already enabled or a default option... cause even with the option supported, WPS will still be broken (since the user will have to manually set the option) still think some kind of default file name generation logic is needed

18:02 <nbd> i don't think we should add a default

18:03 <nbd> i mean it's broken already now

18:03 <nbd> we shouldn't add more implicit magic that might backfire for the sake of turning the existing configs into working ones

18:03 <nbd> let's just add a way to make it work properly

18:03 <nbd> and document how users need to change their configs

18:04 <nbd> we don't have good unique identifiers that we could use for an implicit default

18:04 <nbd> if we use the section, it gets messed up by option changes / reordering

18:04 <nbd> same for ifname

18:04 <nbd> if we use the SSID, we might violate expectations in other ways

18:05 <nbd> or break stuff when SSIDs get changed in the config a few times

18:06 <Ansuel> and i guess it's ok to have unnaped wifi-iface section

18:06 <Ansuel> unnamed*

18:06 <nbd> yes

18:06 <nbd> many configs have those

18:06 <nbd> including many of my own

18:12 <Ansuel> btw IMHO there is this big problem of base stuff on the iface

18:13 <Ansuel> the wifi-station and wifi-vlan does this... and it's easy to invalidate the iface value (a simple kmod crash cause the phy to be increased)

18:13 <Ansuel> jumping from phy0-ap1 to phy2-ap1

18:14 <nbd> wifi-station and wifi-iface use section references

18:14 <nbd> i mean wifi-station and wifi-vlan

18:20 <Ansuel> oh ok the commit was confused i tought the option iface was just the name of the iface in normal condition. Anyway I guess only way is to add a warning in the wiki + migration in luci + in the changelog of new release... Still think that it's a bit overkill to have a listner to write an arbritary data instead of making the user declaring a filename and put it in a default directory. Seems wasted resource to me (and too much freedom)

18:25 <nbd> i guess an option that does not allow specifying a full path might be okay as well

18:25 <nbd> but simply appending the extra psk to the file is still not enough in case the file is shared across instances

18:25 <nbd> still need to propagate the changes to other interfaces

18:26 <nbd> i think it's a common use case to have the same ssid on 2g + 5g

18:26 <nbd> and an added wps key should work on both

18:26 <nbd> clients likely expect it this way

18:27 <nbd> either way, my kids need sleep now, we can continue this discussion some other time

18:27 <Ansuel> well if i analyzed the code of hostapd correctly it does check the .psk first so we can append the wps entry in that case

18:27 <Ansuel> nbd i will update the pr with the request thanks for the hint

18:29 <jeffsf> In answer to my earlier question, git bisect is suggesting the problem is with 44cd90c49a 2024-02-02 -- openssl: update to 3.0.13

18:30 <jeffsf> Is github the proper place for issues to be filed?

18:30 <Ansuel> yes

18:30 <Ansuel> if you can't use the template open a blank issue please

18:30 <jeffsf> Double checking and then pulling diffconfig and all

20:17 <Mangix> f00b4r0: syncthing

20:18 <Mangix> I'm considering kicking my nextcloud instance to the curb

20:41 <f00b4r0> Mangix: syncthing doesn't really have a web file browser afaict? What's wrong with nextcloud for you, besides it being PHP?

20:41 <f00b4r0> i just ended up using that for now, at least it stores plain files and not object hashes

20:41 <f00b4r0> recovering from broken Seafile turned out to be rather painful

21:12 <Mangix> f00b4r0: thank you for asking. I have an mvebu 32-bit NAS. Nextcloud is glacial on it. Large files cannot sync

21:13 <Mangix> 4GB and above. I don't know if it's because of off_t or the CPU being slow