<Tusker>
thanks for the offer of assistance, I am assuming you picked one up ? :)
<hurricos>
Tusker: My AP370s will be arriving in a few days, yes.
<Tusker>
what timezone are you in ?
<hurricos>
I have had some serious issues with the embedded wmac in my IPQ8064-based WAP.
<hurricos>
So, looking for a broad replacement strategy.
<hurricos>
GMT-5
<hurricos>
(EDT)
<Tusker>
ah ok, I'm GMT+11, so it works out OK
Tapper has quit [Ping timeout: 480 seconds]
<hurricos>
Quite a distance.
<Tusker>
yeah, but I can log in to IRC during my working hours, which co-incide with your evening
<Tusker>
Adrian also seems to want some of the functionality split out into different commits/PRs - see comments on https://github.com/openwrt/openwrt/pull/4697 which has the "dtb" / "ramdisk" sysupgrade-tar functionality too
<hurricos>
Tusker: Unfortunately I have not thoroughly read your AP370 merge request. I spoke with riptidewave93 (who did the AP330 port), and it's now my understanding that the ideal thing to do is to throw away OEM partitioning -- and bootcmd -- entirely.
<hurricos>
So I'm wondering whether your MR / PR does that. Haven't looked close enough at e.g. the DTS to know. Let me review.
<Tusker>
it uses the same partitioning scheme and leaves the bootcmd alone
<Tusker>
introduces a fake ramdisk, and a separate dtb, written in the same locations as bootcmd
<Tusker>
ap370, i couldn't seem to override the bootcmd
<hurricos>
Yeah, that may be a source of issues. I have to confirm, but I think in order to boot ever-growing kernel .gz's and prevent a cascade of incompatible fixes, we need to ...
<Tusker>
it seemed that the location was hardcoded
<hurricos>
*Really?*
<hurricos>
Would you be able to give me `printenv` output? Do you have one on hand?
<Tusker>
it has bootcmd in printenv, but when it switches between primary and secondary image, it updates the locations
<hurricos>
I see, it does A/B partitioning. I would guess, though, that the way it updates locations is encoded as a string in u-boot?
<Tusker>
if it's QCA9880 in the HP J9846A (HP 560), someone is selling 5 pieces for $49, then maybe worth the gamble
slingamn has quit [Quit: leaving]
<hurricos>
Tusker: You can purchase WS-AP3825i's for 7.99 USD apiece.
<hurricos>
Those contain QCA9890
<Tusker>
yeah, not in AU :)
<hurricos>
Gotcha.
slingamn has joined #openwrt-devel
rua1 has quit [Quit: Leaving.]
<Tusker>
I have an WS-AP3935i that I paid $40 AUD for, which is ipq
<Tusker>
i don't really need any more access points... I have a big stack already, it's just for fun
KGB-1 has quit [Ping timeout: 480 seconds]
<hurricos>
Tusker: You said it a/b boots?
<hurricos>
Looks like it might not necessarily a/b boot U-boot.
<Tusker>
yeah
<hurricos>
But that's fine, don't think I've ever seen a decently replaceable bootloader
<Tusker>
yeah, I tried to put in a replacement uboot, and it bricked it... it didn't even show up on JTAG anymore, and I even tried to write the old uboot back, and it still failed to boot
KGB-1 has joined #openwrt-devel
<Tusker>
so maybe some kind of efuse...
<hurricos>
No e-fuse on the P1020.
<Tusker>
then maybe I shorted it accidentally while swapping the NAND
<hurricos>
That's more likely I bet. If you physically removed the NAND chip ...
<hurricos>
yeah.
<hurricos>
I don't know off the top of my head how the bootrom does its init on the P1020, I'm babied by like Feroceon chips which support kwboot :(
<Tusker>
there seems to be a number of modes, where it can read from NAND, NOR, sdcard, etc, using some kind of register
<hurricos>
it looks like the bootargs get set around 0x4b988, 0x4b87c.
<hurricos>
Tusker: Might be one of the pins that's ordinarily a DIP switch
<Tusker>
could be
<hurricos>
(of mtd1_U-boot.backup)
<hurricos>
What's the offset of the nand when U-boot originally loads, I wonder? On the AP370, is NAND the only storage?
<hurricos>
I mean to say, in memory. I'm looking to a reference to the address where the string is stored.
<Tusker>
hmm... trying to remember when I had JTAG on it...
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
madwoota has quit [Read error: Connection reset by peer]
madwoota- is now known as madwoota
T-Bone has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
nitroshift has quit [Quit: Gone that way --->]
f00b4r0 has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
genuser1 has joined #openwrt-devel
<genuser1>
is it possible to do a sysupgrade through luci on an x86_64 openwrt build running inside a container?
kenny has quit [Quit: WeeChat 3.3]
<dangole_>
genuser1: as containers come without a kernel the detection of the boot device (which is based on parsing kernel cmdline) will not work and hence I'm 95% sure sysupgrade also would not work inside containers. in case your container runtime doesn't limit device access it could even lead to installing OpenWrt on the **host** system instead...
<genuser1>
dangole thanks. I wanted to get an opinion like yours since I have only been using owrt in a container for a couple of months now and it has been stable but was curious on the possible upgrade path
<jow>
if only there was a way to do package based upgrades
dangole has joined #openwrt-devel
genuser1 has quit [Remote host closed the connection]
dangole_ has quit [Remote host closed the connection]
<karlp>
why do we use curl's --insecure and wget's --no-check-certificate? it's been like that since 65fad864 in 2010, but no description there, is this because some hosts have busted certs, and we're trusting package hashes implicitly?
<lemmi>
not enough space on some devices
<jow>
karlp: yes, it is because of that
<karlp>
ok, thanks.
genuser1 has joined #openwrt-devel
genuser1 has quit []
dangole_ has joined #openwrt-devel
dangole has quit [Ping timeout: 480 seconds]
marinelli has joined #openwrt-devel
dangole_ has quit [Remote host closed the connection]
floof58 has quit [Ping timeout: 480 seconds]
hitech95 has joined #openwrt-devel
Andi_ has quit [Read error: Connection reset by peer]
Andi_ has joined #openwrt-devel
<stintel>
is it normal that the Unifi 6LR claims 2.5GbE link while connected to a GbE switch? [ 38.874469] mtk_soc_eth 1b100000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control off
<felix>
stintel: eth0 on the 6LR is connected to a PHY that isn't hooked up to a proper driver yet. So the kernel doesn't read what rate it negotiates. But the link to the PHY is fixed to 2500Base-X so that's what you see.
<stintel>
I see
<hitech95>
dumb question, what is the avg time that requires to get a patch reviewed?
<stintel>
that varies greatly, and depends on several things, e.g. complexity, how known is the part of openwrt the patch touches, availability / free time of reviewers, etc
<hitech95>
stintel: just wanted to know my previus one was merged really quickly. This time I get back once a week.
<hitech95>
Any info on when AR8229 chips will be moved to DSA?
<mangix>
That work is still WIP.
<mangix>
I have a feeling qca8k won’t land either. Oh well.
<hitech95>
mangix: I just wanted to know what is in the working :)
goliath has joined #openwrt-devel
<Tapper>
mangix What's rong with qca8k I thought it was neely ready
<mangix>
Tapper: let’s put it this way. It took more than a year to get musl 1.2. Probably a similar amount of time for qca8k.
<mangix>
It being ready or not is irrelevant.
<Tapper>
mangix I don't get what you meen sorry.
<mangix>
What I’m saying is even if a PR exists, there is no guarantee that it will ever be merged. Doesn’t matter if it’s ready or not.
<jow>
musl 1.2 took more than a year to prepare and still failed to take abi breakage into account
<jow>
so apparently it was not reviewed long enough yet
<mangix>
I’m assuming that’s la reference to rrdtool
<jow>
no, it's a reference to most binaries now linking against time64 symbols in musl libc.so
<jow>
rendering them unusuable on older builds
<jow>
such a break should've been reflected in an abi version change on libc
<jow>
this way opkg would've prevented installing binaries that were linked against a newer musl libc
<jow>
now it happily installs them but they will fail to run
<jow>
this affects all core software, like uci, libuci, netifd etc.
<mangix>
Why would binaries be mixed and matched like that?
<jow>
which conveniently also got updates recently
<jow>
why not? run a three months old snapshot, opkg install stuff
<jow>
if I'd need to guess I'd say it's objtool related
<mangix>
Broken x86 SDK. I think all kernel modules fail
<jow>
which in turn is probably broken due to libelf changes
<jow>
I think I fixed this instance of the bug twice already
<jow>
people keep breaking it
<Habbie>
doesn't CI catch that?
<jow>
no
<philipp64>
hmm...
<philipp64>
make[5]: *** No rule to make target '/home/build/openwrt/build_dir/target-x86_64_musl/linux-x86_64/cryptodev-linux-cryptodev-linux-1.12/ioctl.o', needed by '/home/build/openwrt/build_dir/target-x86_64_musl/linux-x86_64/cryptodev-linux-cryptodev-linux-1.12/cryptodev.o'. Stop.
<jow>
I think our bundled libelf recently got dropped
<philipp64>
strace also looks broken... there's an instance of @CODE_COVERAGE_RULES@ left unsubstituted in the output strace-5.10/Makefile ...
<stintel>
strace problem is known, suggested solutions on gh and pw
<philipp64>
But that's not changed since January, so... very weird.
<mangix>
strace problem is due to autoconf-macros update
<stintel>
all this bloody autowhatever shit is so fragile
<mangix>
Yes. That’s why there’s cmake and meson
<mangix>
But not enough people that transition.
<philipp64>
I like Rosen's fix better than Stijn's... it's more surgical.
<philipp64>
Sorry, stintel
<stintel>
philipp64: if it's accepted by upstream I'd agree
<stintel>
if not I prefer disabling a fixup over carrying a custom patch
<mangix>
It’s a hack more or less. Proper solution would be to fix upstream’s m4 file.
<stintel>
but honestly I'll just keep
<stintel>
my patch locally until it's no longer needed
<mangix>
too much patching
<philipp64>
I'm concerned about files not being refreshed properly if we skip the autoreconf step...
<jow>
me too
<mangix>
What files?
<stintel>
well then someone who knows how to fix it should report it upstream and ideally submit a patch
<jow>
ideally the one who broke it in thje first place :)
<stintel>
we can talk about it in here for days but that's not going to get us anywhere
<mangix>
Don’t look at me :)
<stintel>
I haven't the slightest clue how this autoshite voodoo black magic works
<jow>
treat it like cancer
<jow>
delete as much of it as possible
<jow>
usually improves the situation
rua has quit [Remote host closed the connection]
<philipp64>
Someone want to add "CONFIG_KEXEC_SIG=y" to target/linux/x86/config-5.10?
rua has joined #openwrt-devel
<jow>
so as expected, the SDK / out of tree kmod issue is once again caused by a broken/missing objtool in the SDK
<jow>
build_dir/target-x86_64_musl/linux-x86_64/linux-5.10.75/tools/objtool/objtool is not bundled into the SDK
<stintel>
jow: in this case, maybe write a big fat comment wherever people keep breaking it?
<philipp64>
The problem with not running autoreconf is if you update automake or autoconf and it includes improved recipes, your package won't benefit from them unless autoreconf gets run... especially if the project has both a configure.ac and a configure file...
<jow>
still trying to figure out why it isn't bundled
<hitech95>
did something changed in last week in hostapd? SAme config just updated my local branch lo latest trunk. Now I get a Command failed: Invalid argument and wireless does not go up.
marinelli has quit [Remote host closed the connection]
marinelli has joined #openwrt-devel
<jow>
unable to build stack validation enabled kmods with the SDK is not acceptable
<jow>
ah, no I think you're right
<jow>
in case the *SDK* got built by a host system which had no libelf support, then stack validation support must be forcibly disabled in the SDK in order to prevent the SDK from picking up the host libelf from wahtever system it is executed on
<jow>
since it will ship without a working kernel objtool
<jow>
however I do not like the way it silently fails
<jow>
if CONFIG_STACK_VALIDATION is enabled then kbuild should simply die if the prereqs are not satisfied
<philipp64>
I know what the problem is... the fix is a lot more subtle.
<Habbie>
hmm
<Habbie>
this surprises me
Luke-Jr has joined #openwrt-devel
<Habbie>
as i know bind, it won't listen on 127.0.0.2 even if i tell it to, because it has seen that only 127.0.0.1 exists
<Habbie>
and it picks up interface changes
<Habbie>
it has a ton of code for that
<philipp64>
In a nutshell, if an interface comes up after named is started and it needs to be listening on it, the only way to get it to do so is to manually restart named. How do other services handle interfaces changing state?
<noahm>
philipp64: hi
<Habbie>
most services expect to be told what to do explicitly, or listen on 0.0.0.0 and ::
<philipp64>
Habbie: and in the case of named, it knows what subnets to listen on... based on options { allow-query { ... }; };
<Habbie>
oh, it filters by allow-query? that i did not know
<noahm>
named drops privileges, so once it's running as non-root, it can't bind to port 53 on a new interface
<philipp64>
I'm looking at ./lib/ns/interfacemgr.c and the handling of RTM_NEWADDR... if the address is present on a down interface that subsequently comes up, I don't believe an RTM_NEWADDR will be generated... hence it gets missed...
<Habbie>
noahm, ah yes
<philipp64>
so... can procd restart it when interfaces change state?
<philipp64>
I forget if Linux supports this, but some Unixes allow an exterior process to open a socket and then send the FD to that process and then the process now has access to it... that could be a workaround to the lowered privileges if procd supported such functionality...
<stintel>
great, wifi completely shat itself here, perfect timing (working on the VM hosting the wiki)
<stintel>
and I'm in secondary location, old xps13 is all I have
<philipp64>
Yeah, seems you can, with a msg.msg_accrights containing the FD.
<stintel>
wow ok, my Unifi 6 Lite went completely offline
<jow>
stintel: the wiki vm is shut down, are you working on it?
<stintel>
jow: see -adm
goliath has quit [Quit: SIGSEGV]
Luke-Jr has quit [Ping timeout: 480 seconds]
mva has joined #openwrt-devel
Borromini has left #openwrt-devel [#openwrt-devel]
mva_ has quit [Read error: Connection reset by peer]
<philipp64>
noahm: well, obviously procd can restart named if interfaces flap... what's a good example of a service that does this properly?
<stintel>
anyone using Unifi 6 Lite seen it go offline completely? was unreachable via wired ethernet too, remote syslog shows nothing
Luke-Jr has joined #openwrt-devel
<noahm>
philipp64: chrony might do what you're thinking of
<noahm>
or something close enough to it
Luke-Jr has quit [Ping timeout: 480 seconds]
<aparcar[m]>
can I start a openwrt vm via libvirt in terminal? so I have a tty directly?
<stintel>
that's probably more a libvirt question ;)
<aparcar[m]>
yea nevermind, it's as simple as virsh console vm_name
<slh>
-nographics should do that with plain qemu (never worked much with libvirt)
<dhewg>
philipp64: procd_add_reload_trigger
<dhewg>
erm, no, I meant procd_add_reload_interface_trigger ;)
<aparcar[m]>
slh: I had that in mind but then I have to setup the network manually, this way it somewhat "just works"
Tusker has joined #openwrt-devel
<aparcar[m]>
jow: do you see a way that luci-app-firewall would accept either firewall (fw3) or firewall4 AND iptables-nft?
<aparcar[m]>
the transparent nft wrapper should allow luci to work as before
<stintel>
aparcar[m]: I have some work planned for that based on what jow suggested me, but I prefer to do that when I'm at home (as of next week)
<aparcar[m]>
I looked at the dependency and it looks like @(PACKAGE_firewall||(PACKAGE_firewall4&&PACKAGE_iptables-nft)) could do the trick
<aparcar[m]>
but that doesn't autoselect anything
<stintel>
aparcar[m]: no, check my firewall4 branch on git.openwrt.org
<aparcar[m]>
stintel: I appreciate you do this massive openwrt.org maintainance ooh
<aparcar[m]>
nice, I thought of PROVIDES:=firewall for fw4 but that was lacking one step
<aparcar[m]>
okay I'll leave things to you, please keep me posted
<stintel>
aparcar[m]: well, do ping me as of next week ;)
<slh>
aparcar[m]: I'm using small scripts around qemu to start my VMs (hooking into pre-defined tap interfaces), including the desired networking setup. libvirt wasn't really inviting to me for short-lived VMs - and when I first looked at it, all access needed to happen as root (that has been resolved now), which is why I never really much deeper into it. it's still a rather heavy-handed approach for my taste
<aparcar[m]>
slh: agree, I'm just lazy... If you have a blog post or something describing your script please let me know
<slh>
with a couple of tap-br-lan%d and tap-br-jail%d preconfigured to be access by my uid
Luke-Jr has joined #openwrt-devel
Tapper has joined #openwrt-devel
goliath has joined #openwrt-devel
<stintel>
nice, Unifi 6 Lite offline again
<shibboleth>
speaking of unify and kinda-offtopic but since it was mentioned and reminded. never actually used any of their products, that... "controller"-thing ppl seem to have to install to be able to use the web interface on their ubq-gear?
<shibboleth>
short version: "why"?
hitech95 has quit [Remote host closed the connection]
<slh>
not talking about the ubqt stuff (haven't played with that, yet), a wifi controller (be it a program on a PC/ phone or a webinterface) 'can' be useful to manage larger fleets of devices as one. Configuring the fleet as a whole, changing credentials, SSIDs, PSKs, etc. centrally, once for all devices. in advanced setups also client-steering, data caps, 8021x backend integration, etc.
<slh>
I'd still want that to be implemented as webinterface running on one of the device (to the extent of voting with my wallet in favour of that), but...
genuser1 has joined #openwrt-devel
genuser1 has quit [Quit: Page closed]
<stintel>
wtf, unifi 6 lite died again after few minutes uptime
<stintel>
and sysupgrade is complaining config is incompatible to the new image (1.0->1.1)
<stintel>
what nonsense is that, the initial image I flashed was DSA already
<stintel>
yep, -F'd it and came back fine ¯\_(ツ)_/¯
<slh>
the setting is recorded in /etc/config/system, so if you synced that file from some other backup, you might have overwritten it (there was a short time of mt7621 already being on DSA before the image format was introduced, but I don't think that's the case here)
<stintel>
not seeing that on 3 other DSA devices I just checked :/