CN_SZTL has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
goliath has quit [Quit: SIGSEGV]
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_sunxi.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.)
<djfe> \x: probably never, that's non-standard. Upgrade your gear to wifi6 and enjoy HE in addition to VHT on 2.4GHz :)
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
cmonroe has quit [Remote host closed the connection]
cmonroe has joined #openwrt-devel
<\x> djfe: yes, but with 2.4GHz ax its like ax/n/g, not ax/ac/n/g
<djfe> exactly ac stuff for 2.4GHz is non-standard
<\x> I do have an ipq60xx ap here and yeah got VHT over 2.4GHz enabled on it with robi's help
<djfe> even if certain devices do support it
<djfe> I followed the same discussion for MT76 https://github.com/openwrt/mt76/pull/333
<djfe> I don't make any decisions on this project. Just realistically I don't see such a change being merged
<djfe> I know it's a nice thing
<djfe> People who want it, may do the change themselves for now
<djfe> You cannot know for certain, that this change won't break devices, so they cannot connect anymore
<\x> yeah
<djfe> old apple devices are incompatible with the wpa2/wpa3 mode
<djfe> they cannot join even though wpa2 works fine
<djfe> just as an example
<djfe> interesting :)
<djfe> I'm not exactly opposed to changing and allowing VHT btw.
<djfe> But I'm not sure maintainers nor users of openwrt are confident enough that the change won't break anything.
<djfe> users meaning forks that build on top of openwrt like gluon
<\x> maybe can be made opt-in
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
schwicht has joined #openwrt-devel
floof58 is now known as Guest11738
floof58 has joined #openwrt-devel
Guest11738 has quit [Read error: No route to host]
MaxSoniX has joined #openwrt-devel
MaxSoniX has quit [Remote host closed the connection]
MaxSoniX has joined #openwrt-devel
cbeznea has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
valku has quit [Quit: valku]
<KGB-1> https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (11.1% images and 99.9% packages reproducible in our current test framework.)
G10h4ck has joined #openwrt-devel
nixuser has quit [Ping timeout: 480 seconds]
nixuser has joined #openwrt-devel
<PaulFertser> \x: the way it's proposed is already opt-in: https://github.com/dhewg/openwrt/commit/6d306b5cc98c5d4c30677441515973e57d37a7a8
<\x> yeah
<\x> like a checkbox in luci web just like how noscan is opt in
Borromini has joined #openwrt-devel
guidosarducci has quit [Ping timeout: 480 seconds]
guidosarducci has joined #openwrt-devel
<olmari> In the past I've had troubles with a number of random STA having issues to connecting to AP using WPA2/WPA3 mixed mode, always been "not wpa3 compatible ones", while stabdalone wpa2 works fine... I've "resolved" this.by making 2 SSID's, one for each WPA
<olmari> Yet some old wpa2 only sta did work, so it wasn't exactly universal iasue either
<olmari> None apples around =)
Tapper has joined #openwrt-devel
robimarko has joined #openwrt-devel
nixuser has quit [Ping timeout: 480 seconds]
<PaulFertser> btw, do you know some brcmfmac devices are capable of wpa3 but only with iwd, not with wpa_supplicant?
wigyori has joined #openwrt-devel
xback has joined #openwrt-devel
SlimeyX has quit [Ping timeout: 480 seconds]
<xback> f00b4r0: Hi
<f00b4r0> lo :)
<f00b4r0> i edited my last comment; you might want to give that a shot.
<xback> will be easier this way
<xback> f00b4r0: Can you elaborate the plan here?
<xback> I'm more than willing to try, got a board running on my desk
<f00b4r0> xback: I'm thinking all it would take is replacing /lib/upgrade/platform.sh with the new version *before* running sysupgrade
<f00b4r0> that's merely a gut feeling though.
<f00b4r0> and you also need to install yafut
<f00b4r0> of course
<xback> and probably also adding yafut binary manually
<xback> 'll give it a try
<f00b4r0> i don't remember if sysupgrade always wipes settings when upgrading from initramfs
<f00b4r0> I suspect it does
<owrt-snap-builds> Build [#851](https://buildbot.openwrt.org/master/images/#builders/49/builds/851) of `mvebu/cortexa53` failed.
<f00b4r0> xback: hmm that's not going to work
<f00b4r0> see Michal's last comment. You also need the adequate kernel
<f00b4r0> seems simpler to sysupgrade from initramfs
<f00b4r0> meanwhile I need more coffee, obviously ;P
<xback> yeah, but thats impossible with devices 60km from here, running remotely on a wind turbine at sea ;-)
<f00b4r0> why?
<f00b4r0> i mean, I understand this can get tricky, but it's doable.
<f00b4r0> you can set them for initramfs boot
<f00b4r0> push comes to shove, you can save their settings, prepare a suitable initramfs that includes the settings and flash that
<owrt-snap-builds> Build [#87](https://buildbot.openwrt.org/master/images/#builders/81/builds/87) of `ipq807x/generic` failed.
<f00b4r0> alternatively the two-stage update as proposed by Michal is another option, but there's an added element of russian roulette should a badblock occur during stage 1 (not handled by yafut)
<f00b4r0> oh, you're saying you don't have a LAN to run a bootp server there.
<f00b4r0> I *really* need more coffee :P
<f00b4r0> I think the two-stage option is the soundest then, but I might revisit my judgement *after* coffee break ;)
<f00b4r0> xback: it would help having a little more info on the actual setup you're dealing with
<xback> f00b4r0: We are using rb922 in our products
<f00b4r0> i get that :)
<xback> The product is used in offshore markets
<xback> image you are standing on a turbine, 60 km offshore
<xback> so, not possible to have physical access to the devices
<f00b4r0> what I don't get are the specifics of the setup, especially on the network side of things: are these hooked to a GSM modem or do you have a private LAN?
<xback> we have a fiber link to them,
<xback> but
<xback> We now have roughly 500 devices running offshore alone, not counting inland stuff :-)
<f00b4r0> number isn't a problem. Everything can be scripted ;)
<xback> they are all manage with a management platform we wrote, which service people here can access for fw upgrades etc
<xback> managed*
danitool has joined #openwrt-devel
<xback> so I'm looking for the easiest way to keep using todays workflow without any manual or special handling needed
<xback> the current upgraded method backend consists of uploading a tarball which contains a sysupgrade image
<xback> which is then remotely executed using ssh
<f00b4r0> they're running 19.07 or something newer?
<xback> latest master, just before yafut :-)
<f00b4r0> ah!
<f00b4r0> that makes things relatively easier then
<xback> but beware, it's not possible to run a bootp or whatever to service them
<xback> some devices are really running stand-alone
<f00b4r0> yeah
<xback> and the only way of reaching them is ssh hopping through some other devices
<f00b4r0> revert https://github.com/openwrt/openwrt/pull/12225/commits/5264296ce480e46c7cd6228502b48ea944a6459b and build an image with yafut installed. Flash that.
<f00b4r0> then build a normal image without the revert, flash again.
<f00b4r0> I think *voila*
<f00b4r0> but I haven't had my coffee yet :)
<f00b4r0> actually
<f00b4r0> no, you need to split that patch
<f00b4r0> what you want to revert is the target/linux/ath79/image/common-mikrotik.mk hunk, since that's what will format the kernel for the 1st image that you will flash
<f00b4r0> you want that to be old type.
<f00b4r0> but keep the platform.sh change, so that on the second flash, yafut *is* used, with a yafut-ready kernel.
<f00b4r0> am I making sense?
<xback> reading it over and over currently :-p
<f00b4r0> should I prepare a patch for you? :)
<xback> you may .. as you know this stuff a lot better these days :-)
<xback> btw
<xback> Just tried older image, and adding yafut + platofrm.sh upgrade
<xback> results in:
<xback> Tue Jan 31 09:25:18 UTC 2023 upgrade: Sending KILL to remaining processes ...
<xback> Tue Jan 31 09:25:18 UTC 2023 upgrade: Sending signal KILL to Cm2_Main (1971)
<xback> [ 516.200472] stage2 (2504): drop_caches: 3
<xback> Tue Jan 31 09:25:24 UTC 2023 upgrade: Switching to ramdisk...
<xback> [ 520.558210] UBIFS (ubi0:2): background thread "ubifs_bgt0_2" stops
<xback> [ 520.575572] UBIFS (ubi0:2): un-mount UBI device 0
<xback> Tue Jan 31 09:25:29 UTC 2023 upgrade: Performing system upgrade...
<xback> copy.c:252: write_file_to_mtd: unable to open file on MTD for writing: error -28 (No space left on device)
<xback> copy.c:295: copy_file: copying failed: error -28 (No space left on device)
<xback> tar: write error: Broken pipe
<xback> Tue Jan 31 09:25:29 UTC 2023 upgrade: Upgrade completed
<xback> Tue Jan 31 09:25:30 UTC 2023 upgrade: Rebooting system...
<f00b4r0> xback: http://ix.io/4tVm
<f00b4r0> apply on top of current master.
<f00b4r0> flash your old style device with result
<f00b4r0> then delete this patch, flash again with result
<f00b4r0> xback: re your attempt: current master sans-yafut doesn't have the IOCTLs backports from fa4dc86 which yafut needs
<f00b4r0> in between the two flash is "install yafut": i forgot to delete the DEVICE_PACKAGES hunk. Updated patch: http://ix.io/4tVn
<xback> ow great. that was fast
<xback> Trying it right away :-)
<f00b4r0> still coffee-less :)
<xback> amazing!
<xback> (no idea what coffee does actually, I never drink it)
<xback> (I'm a coca-cola guy)
<f00b4r0> same thing, less sugar :)
<f00b4r0> the updated patch was hand edited so it may complain a bit when you apply
<f00b4r0> (i didn't adjust the offsets)
goliath has joined #openwrt-devel
<f00b4r0> actually the updated patch isn't even necessary.
<f00b4r0> i'm clearly not firing on all cylinders.
<f00b4r0> xback: either patch should work. If they don't, wait till after I had lunch please ;)
<xback> the patch didnt complain :-)
<xback> building as we speak
<xback> roughly 10 minutes for a complete build
<xback> i'll probably need to remove the last addition, or it will not generate images :-)
<f00b4r0> which one?
<xback> both :-)
<xback> + DEFAULT := n
<f00b4r0> oh right
<xback> already done :-)
<f00b4r0> 5h of sleep last night doesn't help ;P
<f00b4r0> i should refrain from touching mission critical stuff ;)
<xback> No worries, I really appreciate the efforts (.. again ;-))
<f00b4r0> ;-)
<EqUaTe> f00b4r0: 5 uninterrupted hours?
<f00b4r0> if only.
<EqUaTe> young kids?
<f00b4r0> insomnia.
<EqUaTe> :(
* EqUaTe often gets <5 hours sleep, often uninterrupted, but that's more down to the two small hurricanes i have
<xback> EqUaTe: same here ..
<EqUaTe> s/uninterrupted/interrupted/
* EqUaTe blames the younger of said hurricanes for that one
<xback> f00b4r0: did a test
<xback> [ 4060.676186] stage2 (2545): drop_caches: 3
<xback> Fri Apr 21 11:15:41 UTC 2023 upgrade: Switching to ramdisk...
<xback> [ 4065.167574] UBIFS (ubi0:2): background thread "ubifs_bgt0_2" stops
<xback> [ 4065.184740] UBIFS (ubi0:2): un-mount UBI device 0
<xback> Fri Apr 21 11:15:46 UTC 2023 upgrade: Performing system upgrade...
<xback> copy.c:252: write_file_to_mtd: unable to open file on MTD for writing: error -28 (No space left on device)
<xback> copy.c:295: copy_file: copying failed: error -28 (No space left on device)
<xback> tar: write error: Broken pipe
<xback> Fri Apr 21 11:15:46 UTC 2023 upgrade: Upgrade completed
<xback> Fri Apr 21 11:15:47 UTC 2023 upgrade: Rebooting system...
<f00b4r0> hmm
<f00b4r0> no space left on device looks odd
<f00b4r0> unless your kernel is really too big?
<xback> I'm not adding more stuff than the default openwrt kernel
<f00b4r0> you might want to report back to Michal then. I'm puzzled.
<f00b4r0> one thing you can try first is a clean install from initramfs. If it fails there too, there is a bigger problem
<xback> it was a clean install from initramfs :-)
<f00b4r0> oh
<f00b4r0> hmm
<f00b4r0> the dts suggests that the kernel partition is only ~4MB
<f00b4r0> is that right? That seems awfully low
* EqUaTe remembers the days when 4mb would hold multiple kernels :D
<f00b4r0> heh, tell me about it :)
<xback> f00b4r0: retesting on fresh hardware. just to be sure ..
<f00b4r0> xback: I suspect the message is correct and the kernel is too big
<f00b4r0> although I'm not sure why it would work previously
<xback> f00b4r0: hold on. fresh hardware looks better
<xback> intermediate fw flashed now.
<xback> now trying to upgrade to full yafut
<xback> f00b4r0: it works
<xback> Old -> intermediate -> new
<xback> and from New, I can sysupgrade again to New
<f00b4r0> that'll be 42 internets for you ;)
* f00b4r0 hides
<xback> haha
<xback> Big thanks for the efforts :-)
<f00b4r0> yw
* f00b4r0 should rebrand his company Mission Impossible.
<f00b4r0> even when you think it can't be done, it really can ;^)
<xback> so .. how can I flash back now from New to Old?
* xback hides
<Borromini> xD
<Borromini> is that a necessary usecase? (I suppose so since you would like to roll back if needed)
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
schwicht has joined #openwrt-devel
<f00b4r0> xback: it can be done :) only this time you don't even need an intermediary image, you can just patch local platform.sh to use nandwrite again and sysupgrade the old style image
<f00b4r0> I should start billing my time now xD
<f00b4r0> just bear in mind that nandwrite is a loaded gun. It only needs one badblock and you have a brick.
<hgl> Ansuel: sorry for the discouraging earlier :) but it seems your PR didn't manage to compile, so there is no artifact to download, but no hurry, I'm still busy setting up an environment to try out packages in openwrt snapshot,
hanetzer has quit [Quit: WeeChat 3.8]
<Ansuel> hgl i'm also curious why they fail....
<Ansuel> on my local buildroot they correctly compile
<hgl> looks like a path issue? install: cannot stat '/builder/build_dir/target-x86_64_musl/nginx-ssl/nginx-1.24.0/ipkg-install/usr/lib/nginx/modules/ngx_http_ubus_module.so': No such file or directory
hanetzer has joined #openwrt-devel
<Ansuel> to me it looks like it's not compiled at all...
valku has joined #openwrt-devel
Ryncewynd has joined #openwrt-devel
minimal has joined #openwrt-devel
fakuivan has quit [Remote host closed the connection]
fakuivan has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
<pekster> 1
<Ryncewynd> 2
<jakllsch> buckle my shoe
<Ryncewynd> hahahaha
<pekster> Yes, the leading slash is important as it turns out. Thankfully my IRC client remains AI-free (for now.)
Borromini has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
<PaulFertser> If anyone feels like reviewing a relatively simple patch to add another ramips device, this one is kinda waiting for quite long already: https://github.com/openwrt/openwrt/pull/12361
cmonroe has quit [Ping timeout: 480 seconds]
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
minimal has quit [Quit: Leaving]
schwicht has quit []
cmonroe has joined #openwrt-devel
schwicht has joined #openwrt-devel
sanhun58 has joined #openwrt-devel
sanhun58 has quit [Remote host closed the connection]
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lucenera has quit [Quit: The Lounge - https://thelounge.chat]
lucenera has joined #openwrt-devel
schwicht has joined #openwrt-devel
MaxSoniX has quit [Quit: Konversation terminated!]
<philipp64> Anyone use a VPN like nordvpn (or others) to get around their ISP not handing out static/routable IP's? what's your experience?
<hurricos> AP-135 does map flash into io-space -- 16MiB NOR into 0xf8000000.
schwicht has quit [Quit: Textual IRC Client: www.textualapp.com]
<FLD> philipp64: im in the process of setting such a thing up with protonvpn
<philipp64> and you're in what country?
<FLD> .fi
schwicht has joined #openwrt-devel
<philipp64> scamalytics.com didn't have good things to say about nordvpn...
<philipp64> will they host your A and PTR records, et al?
<philipp64> oh, never mind... if their servers are in .ch then that won't work because the latency on my VoIP will be too high...
<philipp64> unless I can get the peering to work with my dynamic address...
Borromini has quit [Quit: Lost terminal]
nixuser has joined #openwrt-devel
<hurricos> blocktrron: > The AP-135 can self-modify the signature check and use the original wrapper code
<hurricos> I think you're saying there's something you can do to apboot to make its `boot` command accept an unsigned uImage?
<hurricos> It does not do that by default. I did try another route, following the idea from the AP-105, but it crashes immediately if fed a zImage (https://paste.c-net.org/OccasionExtended), which tells me that `go` misses a requirement from https://www.kernel.org/doc/Documentation/arm/Booting
Ryncewynd has quit [Quit: Leaving]
sorinello has quit [Quit: Leaving]
<hurricos> The obvious problem is that zImage and lzma-loader are extremely similar but don't perform identical roles
<hurricos> arch/arm/boot/compressed/head.S != target/linux/ramips/image/lzma-loader/src/head.S
<philipp64> FLD: no, they have servers all over the world. Okay, good. including SLC/UT so the latency shouldn't be more than a handful of miliseconds... Just need to figure out if they do DNS/rDNS...
sorinello has joined #openwrt-devel
<hurricos> Yes. I get this exception https://paste.c-net.org/OccasionExtended because my MMU is running (go does nothing to disable it), and the faulting instruction at offset 0x28 does a `push rdi`, which tries to write to my current $sp from u-boot -- to which I have no access.
<hurricos> and https://www.kernel.org/doc/Documentation/arm/Booting tells me I can't have my MMU running ;(
G10h4ck has quit [Ping timeout: 480 seconds]
<hurricos> OK. I think I see the way through the first option. I think Aruba `boot` command lets you feed a header type not signing the image.
<hurricos> This is assuming I can't just execute the instructions in cleanup_before_linux, then jump to the zImage wrapper
<hurricos> image_verify checks this to see whether to fall through when an image header indicates an image is unsigned: https://github.com/shalzz/aruba-ap-310/blob/master/platform/bootloader/apboot-11n/xyssl-0.9/image_verify.c#L168
<hurricos> even if I satisfy the header requirement from aruba_basic_image_verify: https://github.com/shalzz/aruba-ap-310/blob/master/platform/bootloader/apboot-11n/common/apboot-util.c#L98 ...
<hurricos> .... still, image_verify, the caller of aruba_basic_image_verify, will bail when it sees I do not have a signature.
<hurricos> image_verify is called in the process of the `boot` command.
<hurricos> So, I must either binary patch the code for image_verify to ignore that or accept a signature corresponding to a cert not originally intended, or I must ignore `boot` entirely and perform the ARM `cleanup_before_linux` routine to satisfy the boot ABI per https://www.kernel.org/doc/Documentation/arm/Booting before simply running `go` on the zImage.
<hurricos> Here's the exact instructions I need for cleanup_before_linux: https://github.com/shalzz/aruba-ap-310/blob/master/platform/bootloader/apboot-11n/cpu/arm926ejs/cpu.c#L53
<djfe> hauke: when is the next openwrt meeting and where are they announced? :)
<djfe> I only know of
<hauke[m]> djfe: They are only for OpenWrt committers.
<djfe> I see, still glad you are all transparent about it, about your decisions what's going to happen next. Looking forward to the next protocol
BWhitten has quit [Ping timeout: 480 seconds]
<hurricos> RE: `push rdi`, I was totally misusing r2.
<hurricos> RE: MMU still running, arch/arm/boot/compressed/head-xscale.S takes care of it actually :(
cmonroe has quit [Ping timeout: 480 seconds]
<hurricos> wait, no it doesn't, because we don't compile it in
cmonroe has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
Tapper has quit [Ping timeout: 480 seconds]
cmonroe has joined #openwrt-devel
f00b4r0 has quit [Read error: Connection reset by peer]
f00b4r0 has joined #openwrt-devel