danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
bluew_ has quit [Quit: Leaving]
bluew has joined #openwrt-devel
nixuser has quit [Quit: leaving]
<Grommish>
neggles: Any suggestions on if the Itus would be salvagable? My enitre spare test platform, and teh reason I was working rust, has poofed :D
<neggles>
um
<neggles>
maybe?
<Grommish>
But not worth it would be my assumption
<Grommish>
I don't already have jtag gear or a eeprom programmer
<neggles>
pull the microSD out
<Grommish>
There isn't one
<Grommish>
It's onboard, though terhe is a slot
<neggles>
oh
<neggles>
try loading an SD and putting that in then
<Grommish>
for a pull sized SD
<neggles>
i dunno if it will auto detect it though
<Grommish>
It was "Type USB .." uboot stuff
<Grommish>
whcih is the issue
<neggles>
I could probably restore it to working order depending on what's broke but I doubt you have the equipment
<neggles>
you don't get anything from u-boot at all?
<Grommish>
You saw the console output.. if I had any console, I could fix it no matter what because I could stage 1 and just reload everythng :(
<Grommish>
I've got the backups for the stage2/3 uboot
<Grommish>
and can tftp.. if I had console
<Grommish>
All I end up seeing is "▒▒▒▒▒" slowly crawl the screen
<neggles>
and you're sure you don't have a dodgy ground/uart connection?
<neggles>
ah right it's a cisco rj45-style
<neggles>
no flow control or anythin' ? checked the console cable you're using with another device just in case?
<Grommish>
Right.. I popped it into the 10x and it was fine
<Grommish>
I had to drop the speed from 115200 to 57600 for the 10x, but otherwise it's the same
<neggles>
dang.
<Grommish>
neggles: Suggestions on how to move an image to an SD Card that would potentially work? Just exfat like the /dev/mmcblk1p1 and drop the initramfs to it?
<Grommish>
I seriously doubt it will auot-detect, but worth a shot
minimal has quit [Quit: Leaving]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
Tapper has joined #openwrt-devel
<Grommish>
Whoops.. And it won't even power up now, so I think it's a moot point :D
<slh>
that almost sounds 'good'
<slh>
hinting that there might be 'just' an issue with the power supply
<slh>
which should be much easier to fix than the other alternatives
<Grommish>
Maybe, but I'll need to find a power supply that would work.. I'll need to test the brick and see if it's dead or something else
<slh>
ideally start measuring voltages
<Grommish>
*nod* Time for the Fliuke
<Grommish>
So, if I match teh barrel connector @ 12vdc, the amps shouldn't matter if it isn't the same, as long as it's able to match the old one?
<Grommish>
I don't do much in electronics
<slh>
yes, voltage and polarity must match, amps at least as much as the old one (or at the very least close to)
<Grommish>
Existing is 12vdc@800mA with the standard + internal/ - external
<slh>
that makes it easy
<Grommish>
In theory :D
<Grommish>
I need to find a box of wall warts, but it'll give me something to do before I decide to junk it!
<slh>
yeah, still different diameters for the barrel plugs, but at least bog standard voltages and most PSU have more than just 0.8A
<Grommish>
I'll spice the barrel with a quick connect if it comes down to it..
<Grommish>
Striped/Dashed wire marking on the sheath has a significance?
mattytap_ has joined #openwrt-devel
mattytap__ has quit [Read error: Connection reset by peer]
lelux_ has quit [Read error: Connection reset by peer]
robimarko has joined #openwrt-devel
Vavooon has joined #openwrt-devel
ecloud_ has quit [Ping timeout: 480 seconds]
<Vavooon>
Looks like there is an issue with musl 1.2 in 22.03: Some GLib functions like `g_cond_wait_until` pass `time_t` variables directly to kernel. It was all fine on 32-bit platforms while time_t was 32-bit, but since musl 1.2 they use 64-bit time_t, introducing errors in already written code.
<Vavooon>
I spoke to musl devs and they tell that GLib devs should fix it on their side, and even if they agree to do it, there might be other hard-to-find issues with musl 1.2 (I spent my weekend to localize the issue from `gst-rtsp-server` to `glib-2` and then to `musl`)
<arnd>
Vavooon: I think the easiest workaround for glib is to conditionally pass __NR_futex or __NR_futex_time64 depending on (sizeof(time_t) == sizeof(__kernel_ulong_t)), which is something that can be checked at compile time
AtomiclyCursed has quit [Ping timeout: 480 seconds]
<arnd>
Vavooon: fwiw, it's not just broken with musl-1.2, but also on riscv32 with any libc
<Habbie>
why specifically riscv32?
<arnd>
Habbie: riscv32 only has the futex_time64 syscall, because it was added after we added time64 support to the kernel
<arnd>
so __NR_futex does not point to an actual syscall any more
<Habbie>
ah!
<Habbie>
and presumably it's also broken on 32 bit systems with a sufficiently recent glibc that 64 bit time is available (which depends on a few defines, but people are using those)
<arnd>
glibc doesn't use any time64 syscalls by default, unless you pass -D_TIME_BITS=64
<arnd>
but if you do that, then it's also broken here
<arnd>
Habbie: do you have any pointers to users of time64 with glibc?
<arnd>
My impression was that it was added way too late. We had plans for doing the conversion for arm32 in Debian 10 a few years ago, but of course that never happened because there was no glibc support at the time, and now there is not enough developer interest to pull off a full distro build any more
<Habbie>
same
<Habbie>
this is a gentoo user, unsurprisingly
<Habbie>
(by which i mean, a rolling distro user, not a debian-like-distro user)
<arnd>
changing individual packages is completely pointless IMHO
<Habbie>
well, this individual package otherwise aborts at configure time :)
<arnd>
the only way to actually get a y2038-safe system is to do a full bootstrap, forcing the flag on in the toolchain for every package
<Habbie>
(the openwrt packages for it patch that test out - as the problem is gone in openwrt once 21.02 goes EOL)
<Habbie>
yes, indeed
<Habbie>
it's a lot less work to wait for 32 bit to die out
<dwfreed>
arnd: which is something Gentoo is very capable of doing :)
<arnd>
I do expect a lot of code running 32-bit arm with musl past y2038, even if the hardware is no longer made then. Probably not much on other architectures, and hard to tell if someone cares enough about glibc on arm32
<arnd>
dwfreed: sure, and that's great, but it appears that it's not what this person was doing
ecloud_ has joined #openwrt-devel
<arnd>
fwiw, there is actually a chance of rv32 userland gaining some traction now that there are rv64 cores with support for compat mode, but probably most of that will also be musl based, not glibc, as this is only done on memory constrained systems (64MB or so)
<Habbie>
arnd, right, let me rephrase - wait for 32 bit systems to die out or all be running recent musl :)
<dwfreed>
arnd: in part because on a distro level, there will need to remain support for generic binaries (think discord, ms teams, skype, et al) which are going to have 32 bit time_t on x86; but an end user could certainly force the flag on their own systems if they don't have any need for outside binaries
<arnd>
x86 is of course a different story, at least for the proprietary software there is usually a way forward once they get around to providing 64-bit versions
<arnd>
I think it's mostly a problem for software that doesn't have any Linux version at all, only win32 binaries running in wine
<arnd>
I would expect those to be solved once there is a statically linked time64 build of wine, but I'm sure there are lots of details to be worked out for that, and applications may still have their own time32 bugs
<arnd>
win32 itself seems to default to time64
<dwfreed>
the issue is that you can't mix a time64 binary with a time32 library
<dwfreed>
they are not ABI compatible
mattytap_ has quit [Ping timeout: 480 seconds]
<arnd>
that's why I said 'statically linked time64 build of wine'
<dwfreed>
I mean for the general proprietary software, not wine
<dwfreed>
distro packaging of general proprietary software tends to unbundle libs as much as possible, for security reasons
dgcampea has quit [Remote host closed the connection]
Tapper has quit [Ping timeout: 480 seconds]
dgcampea has joined #openwrt-devel
<rsalvaterra>
nbd: Hm… does the build time string itself contain a newline…? I looked at the relevant part do the code (mt7615/mcu.c) and didn't notice any stray \n there. https://paste.debian.net/1238360/
<Vavooon>
Just to make sure, should I just sit and wait for 32 bit to die out? :) Speaking seriously, what is better solution for my current case: try to roll back to musl 1.1 on 22.03 or just compile it with `glibc` instead?
<Vavooon>
Also, is there any reason to fill a bug report on OpenWRT?
<dwfreed>
Vavooon: patch glib in openwrt to fix the bug; file a bug in glib upstream about it
<Vavooon>
Ok, thanks
Vavooon has quit [Remote host closed the connection]
dedeckeh has joined #openwrt-devel
<Grommish>
Is there a way to specify the archive name that is saved in dl/ when downloading the archive from github without overriding the Download define?
<Grommish>
Somehow, I don't think "dl/fd336816c3a6d228dcef22171c43140f6fa7656f.zip" is going to fly with the package Gods
<Grommish>
jow: Any suggestions you might be able to offer?
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
<dwfreed>
Grommish: did you look at the default Download define?
<Grommish>
dwfreed: I did, and I can defien FILE but that seems to insert what file to download in download.pl
KGB-1 has quit [Remote host closed the connection]
<Grommish>
Whoops
<Grommish>
The issue is I need to rename it so it isn't just a commit head hash :(
<Grommish>
Which is how github names it.. the alternative is to use git clone on the commit head, but thats a 2Gb download vs 218mb because it won't be compressed until after it clones out
<Grommish>
the file is called fd336816c3a6d228dcef22171c43140f6fa7656f.zip on Github
<tmn505>
You should set PKG_SOURCE_VERSION as the hash You want
<Grommish>
and while I don't mind, I don't think it will be acceptable to have a file called dl/fd336816c3a6d228dcef22171c43140f6fa7656f.zip
rua has quit [Ping timeout: 480 seconds]
<Grommish>
I'm not cloning ther repo tmn505, so PKG_SOURCE_VERSION doesn't apply. I'm grabbing the archive
<Grommish>
So, you see the issue I"m having :) I CAN call git clone and the source has, but it's a 2Gb download before it .xz's.. or.. I can pull the .zip archive and only download 220mb
<Grommish>
but Github calls it fd336816c3a6d228dcef22171c43140f6fa7656f.zip
rua has joined #openwrt-devel
<tmn505>
but does that archive has the same checksum on each download
<tmn505>
?
<tmn505>
otherwise You can't do that
<Grommish>
I've not gotten that far yet since that filename would have been a non-starter. I can check
<Grommish>
Right.. I may jsut be stuck with cloning
<Grommish>
Seems to be
<Grommish>
Screw it.. I can't have a grey area like that.. I'll just set it to clone and be done with it
<tmn505>
well, that's the name it downloads, so no wonder it is called that. I vaguely remember (or missremember) there was something to rename downloaded files, need to check it.
<Grommish>
tmn505: *nod* That's what I was looking for and I couldn't find a PKG_xxx to do it
<ynezz>
f00b4r0: shouldn't that "PATCH 21.02 v2] mac80211: fix QCA9561 PA bias" of yours bump as well PKG_RELEASE so folks could get fixed driver update without flashing complete firmware image?
<f00b4r0>
ynezz: I honestly have no idea about this
lynxis_ has joined #openwrt-devel
lynxis has quit [Read error: Connection reset by peer]
<f00b4r0>
tbh it didn't occur to me one could upgrade the kernel without flashing a new image, but I suppose that's a valid scenario
aiyion_ has joined #openwrt-devel
minimal has joined #openwrt-devel
aiyion has quit [Remote host closed the connection]
<ynezz>
AFAIK kmod-ath9k is a kernel module, so one could just update that particular kernel module
<robimarko_>
Will that work as kernel hash wont match the one it was built against?
<f00b4r0>
^
<dwfreed>
definitely won't work
<f00b4r0>
i'm not completely clear on how package/kernel works tbh. e.g. the version is 5.15.33 but the patches are applied to the current stable (5.10) kernel as well. That's why I avoided touching version info
<hurricos>
mangix: 3x3 APs using standard mPCIe slots? Absolutely, everything P1020-based is like that. External RS232-via-RJ45 serial + ethernet ports + u-boot + mPCIe slots on Aerohive HiveAP 330, 370; WS-AP3825i, WS-AP3710i, WS-AP3715i, and the P1010-based Adtran BSAP-2030
<f00b4r0>
god my head hurts. I've been digging through mt76 and net/core code for hours and I still don't know where to begin looking for this packet corruption :(
<hurricos>
there are some exceptions but like ....
<f00b4r0>
(and I'm learning way more than I ever wanted about the gory inner details of linux networking ;P)
<hurricos>
f00b4r0: I have the same issue at times; I've given up and just installed haveged.
Borromini has joined #openwrt-devel
<hurricos>
Borromini: RE: realtek: I'm going to need to chase down this realtek-poe bug soon, but bear with me until then ...
<f00b4r0>
hurricos: oh. urngd. Had forgotten about this :) Seems something is draining the entropy on the device, I don't know what is (nothing obvious). I suspect that's why urngd is going nuts. Will investigate later (or update and pray it doesn't happen again). Focused on mt76 now
<hurricos>
neat.
<Borromini>
hurricos: no hurry. i'm very grateful you want to look at it. no idea what's up with it.
srslypascal is now known as Guest2317
srslypascal has joined #openwrt-devel
<hurricos>
I'd ideally like to get something working for BCM591xx controllers out there under poemgr, but first I need to know why the very simple codee we *do* have doesn't work.
<Borromini>
poemgr is the program blocktrron wrote right?
<hurricos>
Correct.
<Borromini>
:)
<hurricos>
It has been merged. If I'm not mistaken it just pokes from userspace into the sysfs exported by the driver blocktrron ported?
<hurricos>
specifically works iwth things that use that TI PoE controller.
<schmars[m]>
ah looking into poemgr? i've fixed a bug or two there recently. but it was only timing-related, sprinkled a usleep here and there
<hurricos>
Yeah, I'm going to put some effort porting realtek-poe stuff that has been refused from mainline into there
<schmars[m]>
poemgr is so far only for that Microsemi PD69104B1 chip
<hurricos>
Microsemi
<schmars[m]>
nice
<hurricos>
etc
<hurricos>
same difference
<hurricos>
I only care because it's accepted.
<schmars[m]>
hey and thanks for the testing stuff link, i'll check it out!
<hurricos>
Yep!
<hurricos>
All things considered I'd just really like to have a standard accepted interface for how to turn PoE stuff on and off and monitor state.
<Borromini>
oh is it in master already, poemgr?
<hurricos>
I thought so?
<Borromini>
i haven't seen it in the commit logs so far
<schmars[m]>
the poemgr package is in the packages feed, or does that have other bits separate from it that i've overlooked so far?
<Borromini>
but i might easily be mistaken. let me check.
<Borromini>
schmars[m]: cool!
<Borromini>
i don't keep an eye on the packages feed
<Borromini>
just the main repo
Guest2317 has quit [Ping timeout: 480 seconds]
<schmars[m]>
i only found it because i got myself that exact supported device (Unifi Switch Flex) because it's got such a nice case
<Borromini>
:)
<hurricos>
shrug. All I know is that I need to be able to reboot APs that decide to die
<Borromini>
yeah a few people seem to have gotten them
<Borromini>
hurricos: OpenWrt supported ones?
<schmars[m]>
the nice thing about an actual poe chip instead of just passive poe, is that downstream devices stay powered while the switch reboots
<hurricos>
Yes.
<Borromini>
schmars[m]: i should check with my GS1900-8HP, but at least on OpenWrt the clients go down as well if the switch reboots.
<Borromini>
but i haven't checked OEM behaviour on that point yet
<schmars[m]>
not with that poemgr package on the unifi switch flex. dunno what your GS1900 does
<Borromini>
ok. the GS1900 uses realtek-poe, another tool
<schmars[m]>
got it, yeah, maybe their chip gets reset during boot, or something like that
<hurricos>
I'd like a good standard way to generalize PoE switch interaction
<hurricos>
poemgr seems more general and more likely to be accepted long-term
<schmars[m]>
hurricos: i think poemgr could be that standard interfaces for poe things? might have to adjust a few interface things for other types of poe chips, but at least on the usw-flex it's been pretty pleasant so far
<schmars[m]>
yeah!
<hurricos>
in the end if I have to bolt something on that works with PD-9012G over the network, it's going to be on poemgr and not on realtek-poe
<hurricos>
or I could just give up and use SNMP like a normal person.
<Borromini>
:)
<f00b4r0>
nbd: I sent you a short email, if what I describe here rings any bell please let me know. I'm in over my head tbh :)
ekathva has quit [Remote host closed the connection]
ekathva has joined #openwrt-devel
ekathva has quit []
<felix>
svanheule: I think there's something up with EAP245v3's TFTP recovery. I am too seeing the phenomenon that I cannot recover to a factory image once OpenWrt had been installed. US labeled model, CA region locked. Just loads the file (HTTP or TFTP, doesn't matter) and then does nothing.
<svanheule>
felix: I don't recall seeing any recovery method (TFTP or HTTP) documented by TP-Link, so maybe it's just some half-functional development thing they left in there?
<felix>
Oh well, probably time to whip out the soldering iron. Or send the thing back to Amazon.
<svanheule>
OpenWrt have 0.0.0 as version number, maybe that's confusing the bootloader's recovery
<svanheule>
felix: hard to tell anyway why the bootloader is refusing the image without UART access
<svanheule>
felix: so getting your soldering iron heated up is probably a good idea anyway :)
valku has joined #openwrt-devel
<felix>
Will do
<svanheule>
otherwise that AP will probably end up in reclycing (best case) or a landfill, and that would be a bit wasteful (others would disagree what the best location for ath10k hardware is though)
goliath has quit [Quit: SIGSEGV]
<Borromini>
the shredder!
* Borromini
ducks
<felix>
They don't build em like they used to (ath9k) :P
goliath has joined #openwrt-devel
cbeznea1 has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
<Borromini>
:P
cbeznea has quit []
Vavooon has joined #openwrt-devel
Borromini has quit [Quit: leaving]
bookworm_ has quit []
bookworm has joined #openwrt-devel
Vavooon_ has joined #openwrt-devel
<Vavooon_>
Is there a way to force build system to use different compiler just for current build task? I was trying to use something `CC=$(which gcc-8) CXX=$(which g++-8) make -j7` which helped to pass initial checks but then it failed to compile some old code probably because it still used latest avaialble gcc
Vavooon has quit [Quit: Page closed]
<mirko>
what's the way to make dnsmasq only provide dhcp on one port/vlan and leave the rest (of the system) - mainly /etc/resolv.conf - alone?
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
<karlp>
I don't know baout uci, but dnsmasq.conf it's just listen interface iirc.
<karlp>
it's the way it's used by all teh kvm virt stuff.
robimarko_ has quit [Quit: Leaving]
<mirko>
i'd like /etc/resolv.conf not to be exclusively claimed by dnsmasq, the system's dns resolving not going via dnsmasq but directly via what was provided as dnsserver via dhcp
<mirko>
but something appears to be off either way: with dnsmasq running locally (default config) it doesn't seem to (correctly) forward queries to the via dhcp aquired upstream dns server: https://pb.nanl.de/show.php?id=45477&hash=04034951
<mirko>
this is basically a default snapshot image
<hurricos>
mirko: dnsmasq (or its procd wrapper) do not appear to appropriately undo its modifications to `/etc/resolv.conf`.
<hurricos>
I've had this happen myself.
<hurricos>
This -- https://paste.c-net.org/ValiantProtects -- is the ansible-openwrt playbook task I use to fix this once; there is a dnsmasq setting you can use to prevent it from modifying /etc/resolv.conf upon reload later on
<hurricos>
s/reload/restart/
<hurricos>
mirko: have you disabled dnsmasq here?
<hurricos>
If so, just `ln -sf /tmp/resolv.conf.d/resolv.conf.auto /etc/resolv.conf`.
KGB-0 has quit [Ping timeout: 480 seconds]
<mirko>
hurricos: yeah, that's probably the way to go, hopefully without shooting one's foot in another scenario down the road
<mirko>
i'm calling it a day (or rather night) for the moment