danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
ptudor_ has joined #openwrt-devel
ptudor has quit [Ping timeout: 480 seconds]
GNUmoon2 has quit [Read error: Connection reset by peer]
GNUmoon2 has joined #openwrt-devel
valku has joined #openwrt-devel
valku has quit []
<Znevna>
yeah it has nothing to do with the leds >.>
cbeznea has joined #openwrt-devel
<Znevna>
ok, I had no country set for the 2.4GHz radio, weird that it was only causing issues if the interface was in a disabled state at boot
<slh>
probably related to 802.11d
<Znevna>
yeah I had channel 13 selected
<Znevna>
but it the interfaces were enabled before a reboot everything was fine x.x
<Znevna>
but if*
<dhewg>
jow: talking about invalid hostapd configs, have you looked at the luci+iwinfo pr? I haven't seen any fires due to the iwinfo bump, and there's a "don't offer unsupported wireless hwmodes" in there which prevents one possible invalid config
<Znevna>
can't stop the interfaces from transmitting
<dhewg>
only the last commit required the iwinfo abi changes
<dhewg>
*requires
<jow>
ah that LuCI PR depends on an ABI change (band property in chanlist)
<dhewg>
yeah that's the last commit there
<dhewg>
and there's a TODO left wrt offered encryption modes on 6g, see the comments. Can be done after merging it i guess. I was hoping you can look into that due to omg js
<jow>
hmm, struct iwinfo_freqlist_entry has uint8_t channel; uint32_t mhz; ...
<jow>
there's likely three bytes of padding between channel and mhz
<jow>
if we do uint8_t channel; uin8_t band; uint32_t mhz; we might be able to add band info without abi change
bluew has quit [Ping timeout: 480 seconds]
csrf has quit [Quit: Leaving]
<dhewg>
the padding won't change, but is that really something we should consider?
<dhewg>
I mean, I can do that, np. But the package has a ABI setting anyway, and consumers just need to be recompiled without src changes
<dhewg>
what do we gain?
<dhewg>
all this is just master material anyway, right?
<jow>
you're probably right. I just want to ensure that all 22.03 eliglible fixes are pushed before we bump the abi, so that we can cherry pick them yet
<dhewg>
okay. Well if there's something else in the future that needs to be backported we can just add a patch to the 22.03 package if maintaining another branch isn't worth it
<jow>
for packages hosted on git.o.o we sometimes simply branch upstream
<jow>
so there'll be an openwrt-22.03 branch in iwinfo.git
<jow>
anyhow, need to run now. bbl
Borromini has joined #openwrt-devel
robimarko has joined #openwrt-devel
<robimarko>
Now that mvebu is fixed, can it be switched to 5.15 again?
<dhewg>
jow: rebased #11280 (with the NOHT/20 patch dropped) and luci #6104
lamikr has quit []
<Borromini>
jow: if the mbedtls wpad were to replace the wolfssl flavour, would it be difficult to make LuCI use mbedTLS as well?
danitool has joined #openwrt-devel
<robimarko>
To LuCI its the same
<Borromini>
ok :)
<Znevna>
I haz leds!
<Borromini>
weee
<Znevna>
but I've lost one of the tiny rubber feet x.x
<Borromini>
did you check other DTSes for naming conventions?
<Znevna>
didn't find a consistent pattern
<Znevna>
it's wild wild west
<Znevna>
the only one that was a little more consistent was the power led, since you have to add it like led_power: something(power usualy) { ... }
<Znevna>
because you use led_power for the aliases above
<Borromini>
ok. I agree about the lanX naming though, makes more sense to me without the dashes
<Znevna>
but he defined them without the dash in the dts, then in uci tries to add them with dash, don't know if that works
<\x>
&rubber_feet { status="disabled"; };
<Znevna>
rofl
<Borromini>
5.15 seems to be the final nail in the coffin for my 4 MB ath79 stuff, even with wpad-mbedtls
<Borromini>
(although wpad-mbedtls is a stretch already)
srslypascal has quit [Ping timeout: 480 seconds]
<Borromini>
can I use DEFAULT_PACKAGES += to remove default packages? Like dnsmasq and firewall e.g. for stuff that can only serve as an AP anyway
<Znevna>
unselect them in menuconfig/
<Borromini>
:-/ I guess they're only enforced when building for multiple targets
srslypascal has joined #openwrt-devel
borek has joined #openwrt-devel
borek has quit [Remote host closed the connection]
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
chuck48 has joined #openwrt-devel
shibboleth has joined #openwrt-devel
<shibboleth>
stintel, any progress re amnesiac wpa8630? as things stand you invariably end up locking yourself out by sysupgrading
<shibboleth>
which is unfortunate, because now you're no longer doing vlans on the powerline interface and all kinds of stuff end up where it doesn't belong. shit, meet fan
borek has joined #openwrt-devel
<stintel>
shibboleth: unfortunately no, have almost not touched my computer for 5 days, but your issue is on my internal tracker, I've not forgotten about it
<stintel>
I'd be tempted to merge one of those if it turns out to solve my problem but like an expert opinion ;)
<aiyion>
stintel: I commited mine, and linked his, but proposed to merge them.
<aiyion>
So use UUIDs, but use his anymmc, so that I can guarantee nothing else breaks.
<dangole>
stintel: to me this is all a mess, FAT filesystem for uEnv and kernel, half-way like DOS in the 1980s... but ok, that's how they like sunxi to be.... the easiest way to have mmc devices enumerated in a deterministic way is to add aliases for them in DTS. this is how i solved it for BPi-R2 and BPi-R64 which also come with two mmc host controllers.
Borromini has quit [Ping timeout: 480 seconds]
<stintel>
dangole: yeah I know what you think about the fat stuff, I've been looking into u-boot a bit to understand how to do it with GPT partitions but didn't get that far yet
<stintel>
dangole: does the DTS aliases way make it possible to have a single image that can be flashed to either of the mmc devices?
<dangole>
stintel: using only a single image (like i did for those BPi devboards) is possible but requires the bootloader to communicate the device to use for rootfs. then everything else (sysupgrade, uboot-env, ...) can be determined based on that in userspace.
<dangole>
stintel: here is the commit fixing the problem mentioned before for BPi-R3: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/patches-5.15/161-dts-mt7623-bpi-r2-mmc-device-order.patch;h=d1bafc1526090356217143453ee7776918e8c8cd;hb=HEAD
<stintel>
dangole: thanks, much appreciated!
<aiyion>
stintel: Just as a heads up: 22.03 does have the same issue as master.
<stintel>
maybe to fix the problem for now, we can go with both solutions in that thread combined, until someone takes the time to redo sunxi in a more modern way
<stintel>
I was looking into that for meson, I'd like to figure out how to do it properly there before I have another attempt at getting that new target in OpenWrt
<aiyion>
Alrigth. I'd then prepare v2 with the merged approach?
<stintel>
so once I understand how that works, I could have a go at sunxi also, as I have hardware to test on
<stintel>
aiyion: sounds good
<aiyion>
thanks for looking into this
<stintel>
well coincidentally I ordered 2 sunxi devices earlier this year
<stintel>
so sheer luck ;)
<aiyion>
Thought I'd add stable macs for the deve "real quick"... And stumbled across this :/
<stintel>
yeah I haven't spent much time with these devices since some things weren't very clear and I didn't want to go yak shaving
<aiyion>
karlp: Do you want me to add your etactica-egm400 to anymmc as well? As you did in your patch?
<aiyion>
weird. its absent. nvmd
<aiyion>
stintel: which device did you want this for? Or do you add it yourself?
<stintel>
I'll add it
<stintel>
if it works ;p
<stintel>
I tried your patch from the ML and it doesn't help though
<stintel>
guess I'll be yak shaving anyway
<aiyion>
o.o
<aiyion>
For me it booted 20 times in a row without problems :/
<stintel>
wait, I didn't rebuild the correct image
<stintel>
but it fails too early for this u-boot env stuff to fix it is my gut feeling
<stintel>
yeah, it doesn't load u-boot, it just hangs after SPL
<aiyion>
huh, yeah thats earlier than where mine crashes
<stintel>
same problem when I flash the emmc image
<stintel>
sigh
* stintel
tries the olimex image
<stintel>
sigh, .7z
<stintel>
whhyyyyyyy
<stintel>
yeah that works finer
borek has joined #openwrt-devel
Tapper has joined #openwrt-devel
<stintel>
git bisect time
floof58 has quit [Read error: No route to host]
floof58 has joined #openwrt-devel
<aiyion>
stintel: recompiled and tested: booted another 10 times without problems. I renamed the uEnv file to anymmc, restored the default and added the missing line in the Makefile. I think this is good to go.
<hgl>
I'm trying to make some major contribution to a package, but its maintainer is probably very busy with life and not very responsive. It has been almost a month since I opened the PR, but the progress doesn't look promising. I might be unavailiable for a while after a month or so, but would like to see the changes get accepted before that. I wonder in this case is there any way
<hgl>
to expedite the process?
tlj has joined #openwrt-devel
Borromini has joined #openwrt-devel
tlj_ has quit [Remote host closed the connection]
borek has quit [Ping timeout: 480 seconds]
borek has joined #openwrt-devel
chuck48 has quit [Remote host closed the connection]
borek has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
Luke-Jr has quit [Ping timeout: 480 seconds]
Luke-Jr has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
<Strykar>
might start with a link to the PR?
<stintel>
I'm gonna have to revert that dmarc change
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<f00b4r0>
stintel: I didn't dare suggest you do ;D
<stintel>
or I could just stop using ML and go full github /s
<f00b4r0>
😅
<Borromini>
xD
<Habbie>
stintel, did not, might do it tonight :)
<jow>
stintel: dmarc change?
<f00b4r0>
jow: see how stintel's emails are "prefixed" on the m-l
<f00b4r0>
s/prefixed/wrapped/
<stintel>
wrapped
<stintel>
;)
<f00b4r0>
;)
<jow>
don't see any
<robimarko_>
Contents are wrapped in DMARC warning
<jow>
I see
<stintel>
or I could add the mailing list server as allowed mta ...
<f00b4r0>
jow: btw since you're here, I'm guessing you won't have time to do buildbot tests before next year, am I right? :}
* f00b4r0
apologizes for being annoying^Wpersistent
<jow>
unlikely. due to family issues I am severely time constrained and can't spend more than 10-15 minutes at a time to actually work on things
<f00b4r0>
np. at least my expectations are set now
<f00b4r0>
i hope we'll be able to make progress next year, I'd really hate to see this work bitrot
<jow>
don't think it'll bitrot, we're not touching the runnign system either
<f00b4r0>
never using it is also a form of bitrot ;P
<Habbie>
stintel, remind me, is there a trick to just pick a device, without first having to pick the right target system?
<jow>
... hmmm we keep getting complaint notifications from outlook.com
<jow>
this time people report their forum mail digests as spem
<jow>
*spam
<stintel>
Habbie: don't think so ?
<f00b4r0>
outlook/hotmail tend to treat anything and everything as spam. I've seen it elsewhere
<stintel>
I'd prefer an ack on that one before merging though :)
<f00b4r0>
stintel: fwiw, you can have a restrictive SPF record, while setting DMARC policy to "none", which results in no wrapping by the mailing list (unless things changed since I last emailed it)
<f00b4r0>
(that's what I do)
<stintel>
f00b4r0: yeah, I changed from none to reject to not have the aggregate reports which are XML that requires some parsing tool to be meaningful - instead I wanted to get instant forensic report for every message that violates the dmarc policy
<f00b4r0>
*nod*
<stintel>
but then I read something that this could be a privacy issue
<stintel>
which probably explains why I've yet to see such report
<f00b4r0>
when I played with DMARC reports, the only ones I would receive were for gmail, and they were the basic statistics ones. I never got anything remotely useful otherwise.
<stintel>
and thanks to gdpr ... companies decide: ok, we don't send forensic reports
<f00b4r0>
yeah that's it. I only ever received RUAs. Not a single RUF.
<f00b4r0>
that's when I decided I had wasted enough time with this nonsense ;)
<stintel>
but wasn't a problem back in september ...
<stintel>
iirc
* stintel
wipes {build,staging}_dir
gch981213 has quit [Ping timeout: 480 seconds]
jlsalvador has quit [Quit: jlsalvador]
<karlp>
aiyion: it's missing because it's not ready yet :) like I said, that's from my stack of things that are in progress, I just thought it might help you :)
<aiyion>
stintel: I recognize your bug is different from mine, but mine was effectlively a race condition. Yours isn't, is it?
<aiyion>
karlp: I misunderstood you in the first place. I thought you had the bugfix on you stack of in-progress-topics, not the whole device :)
<stintel>
aiyion: something is wrong with u-boot or arm-trusted-firmware is my gut feeling
<karlp>
stintel: how "recent" a master build for sunxi do you mean? I'm on holidays now, so I'm not building new stuff to test right now, but my master build tree is currently at aa12a0fdd1
tlj has joined #openwrt-devel
<karlp>
oh, you just have mmmc0/mmc1 issues, nvm, I'm just in the crollback
<stintel>
no no
<stintel>
I get 3 lines of serial output and done
<stintel>
it doesn't even load u-boot
<karlp>
dangole's aliases solution is fine, but requires modifying all the DTS's and was "not allowed" in the past, til the right flavoured greybeard got it through.
<karlp>
I've got on my list of things to do to look at moving sunxi to FIT images, but that's pretty low on my list I'm afraid...
tlj_ has quit [Remote host closed the connection]
jlsalvador has joined #openwrt-devel
borek has quit [Quit: borek]
borek has joined #openwrt-devel
<stintel>
karlp: FIT on its own is not that much work, unless you want external-static-with-rootfs ;)
gromero_ has quit [Ping timeout: 480 seconds]
<karlp>
f00b4r0: I think you are quite wildly underestimating how many outlook users are foss people. and certainly how many potentials..
<Habbie>
+100 to that
<stintel>
the problem is that even huge corporations use o365
<stintel>
so many of the people being paid to work on open source ...
<Habbie>
indeed
borek has quit [Quit: borek]
MAbeeTT2 has joined #openwrt-devel
<stintel>
sigh. even after nuking {build,staging}_dir/ and tmp/ completely my sunxi image still doesn't boot
<stintel>
already tried different, brand new SD card to exclude that
MAbeeTT has quit [Ping timeout: 480 seconds]
<karlp>
you're on aarch64 right?
<karlp>
I'm only on "arm" sorry, no ATF /BL3x woes for me ...
<stintel>
karlp: yes a53 - but downloads.openwrt.org snapshot boots, locally built doesn't
<stintel>
so there is probably some host thing used causing this
MAbeeTT has joined #openwrt-devel
<karlp>
urh, that sounds unfun. I'm going to close this window for a w hile instead :)
<stintel>
;p
<f00b4r0>
karlp: if the problem is on their side and they can't operate effectively, surely they'll be heard?
<stintel>
trying some random things but I'll probably end up putting the sunxi devices in a drawer and use something else for playing with OpenThread
<stintel>
I was approved for the Eve Early Access Program to test Matter firmware on the otherwise homekit only stuff
<stintel>
but I can't upgrade to that firmware because the app looks for a thread network
<stintel>
so I figured I'd use those olinuxinos as I'm not using them for anything else atm
<stintel>
but yeah
<stintel>
yak shaving ¯\_(ツ)_/¯
<f00b4r0>
stintel: don't shave yaks during winter ;)
<Habbie>
oh speaking of yak shaving, i have several, so instead i'll go sysupgrade this ERL
MAbeeTT2 has quit [Ping timeout: 480 seconds]
<stintel>
f00b4r0: well ... I'm travelling on Friday and I might try to actually stay away from computers for a while then
<Habbie>
stintel, sysupgrade or sysupgrade -n?
<stintel>
Habbie: -n shouldn't be needed
<Habbie>
cool
<Habbie>
Linux (none) 5.15.84 #0 SMP Tue Dec 20 13:57:34 2022 mips64 GNU/Linux
<Habbie>
any questions?
<Habbie>
(ssh works to it too)
<stintel>
just use it for a bit :)
<stintel>
but I guess if it's not actually routing ... might not easily spot bugs
<Habbie>
there are no routes pointed at it
<Habbie>
but i could change that, later
<stintel>
I actually noticed horrible network performance on the SNIC10e but that might well be due to all the messing around I've done in the phy driver
<Habbie>
right
<Habbie>
i can iperf
<Habbie>
if you happen to have commandlines
<stintel>
iperf -s / iperf -c IP ?
<Habbie>
ok!
<Habbie>
iperf3?
torv has quit [Remote host closed the connection]
<Habbie>
hmm, opkg list | grep iperf is empty
torv has joined #openwrt-devel
<stintel>
if you run on the device itself. iperf (v2) is better
<Habbie>
ack, turns out i got no versions
<stintel>
iperf3 is heavier on CPU (can't generate as much traffic)
<Habbie>
no but, the other end is a pi4, i thought it was a pi3
<stintel>
give it -t 1200 and see if it survives ;p
<Habbie>
ok!
<Habbie>
is half a gigabit expected?
<stintel>
aiyion: could I ask you to build 9ed1830bdc1e58efb3e5b17c0e484e1a2655b550 for the olinuxino a64 emmc and send me the sha512sum of ./staging_dir/target-aarch64_cortex-a53_musl/image/olimex_a64-olinuxino-emmc-u-boot-with-spl.bin afterwards ?
<stintel>
Habbie: yes
<Habbie>
ok
robimarko_ has quit [Quit: Leaving]
<stintel>
Habbie: thats with iperf -s on the erl and iperf -c on the pi4 ?
gromero_ has quit [Read error: Connection reset by peer]
<stintel>
I'm tempted to switch octeon to 5.15 by default then
cbeznea has quit [Quit: Leaving.]
<Habbie>
i have no objections to offer :)
<stintel>
I've been running that on 2 SNIC10e also for almost 6 days now, and ok they don't route, but they do get multicast traffic all the time, and I've done some iperf between them and no crashes
<stintel>
Habbie: do you have the other one running 5.10 still ?
<Habbie>
Linux OpenWrt 5.10.146 #0 SMP Fri Oct 14 22:44:41 2022 mips64 GNU/Linux
<stintel>
Habbie: could you do the same iperf tests and compare speed?
<stintel>
doesn't need to be -t1200
<Habbie>
thinking
<Habbie>
oh yes i also have a pi4 there
<Habbie>
will do
<stintel>
thanks!
<Habbie>
wonder if that switch is gbit, but we'll find out, and otherwise i'll fix it later