<\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>
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>
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>
[ 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.)
<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…]
<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>
.... 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.