danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
hexa- has joined #openwrt-devel
ldir has joined #openwrt-devel
ldir has quit []
ashkan has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
ashkan has quit [Quit: Konversation terminated!]
GNUmoon has quit [Remote host closed the connection]
PtitGNU has joined #openwrt-devel
mitome has quit [Read error: Connection reset by peer]
mitome_ has joined #openwrt-devel
rua has quit [Quit: Leaving.]
<neggles>
shorter version of the whole DSA discussion above - a DSA bridge is functionally equivalent to an L2+ managed switch. you can tag/untag VLANs per port, you get independent MAC learning, hw-accel if the driver supports it, and the `br.X` interfaces are functionally identical to a switch VIF (`interface vlan X` in cisco terms)
<neggles>
there's also the ability to do some really fun nice things like daisychain more dsa-capable devices and make those ports appear as if they're *also* directly connected to your CPU even though they might be 2,3,4 switch hops away
<neggles>
felt like that merited a summary for future log readers :P
<Grommish>
neggles: ping.. This device has been up for nearly 12 hours, and RAM has gone from 57mb to 366mb with almost no traffic on the WAN (18Mb Rx) and no LAN connections :(
<neggles>
Grommish: lets see here...
<Grommish>
neggles: 51584 is the used at fresh boot
<neggles>
it does intermittently throw packet RX errors
<Grommish>
neggles: It's already up to 52mb and climbing, but again, I don't even have anything physically plugged into the LAN.. and, I don't see the octeon_ethernet modules in lsmod when I set them to M ;/
<neggles>
i added collectd in this boot so i could track mem usage
<neggles>
it's gone up a bit since boot, but only because of buffers allocated by iperf/iperf3 which are still cached
<neggles>
(might just be the actual binaries themselves)
<Grommish>
I'll check back on it in an hour or so
<neggles>
Grommish: fair enough
<neggles>
i wonder if it has to do with running octeonplus on octeon3
valku has quit [Quit: valku]
<Grommish>
neggles: 1:22 uptime, went from 53044->87632 and 2.6MiB RX on the WAN
<Grommish>
neggles: I can build out a -march=octeon3 build easy enough.. I usually don't for testing purposes.. I can do a -mtune first then a straight -march maybe
<mangix>
Grommish: set up scoop under windows and install busybox and iperf
<neggles>
it's also available thru winget
<neggles>
oh. apparently not
<neggles>
winget doesn't do .zip packages? microsoft. MICROSOFT. Get your shit together.
<mangix>
neggles: scoop > winget
<neggles>
from a functionality perspective on my own personal machine, this is true
<neggles>
however from an ease of deployment / ability to use it to push packages out to 200 client machines perspective, winget is an absolute godsend
<Grommish>
176046 now used, but 3.5Gib/1.GiB on the interface now
<neggles>
This seems to happen when the Windows Package Manager is unable to disambiguate more than one entry in Apps & Features as they correlate to different architectures (and possibly other properties). There are some other scenarios that manifest the same way in terms of ambiguity.
<neggles>
*sigh*
<mangix>
hillarious
<mangix>
meanwhile scoop works fine
<neggles>
i mean i install all the vc redistributables with the techpowerup .zip/.bat anyway
<Grommish>
mangix: I'll look at it, thanks! For now, just using iperf vs iperf3 worked
<neggles>
most of what i've used winget for is pushing custom .msixbundles
<mangix>
i just run scoop install vcredist
<mangix>
installs all of them
<neggles>
scoop and intune don't get along :P
<mangix>
what's intune?
<Grommish>
mangix: You wouldn't know who to talk to about the mips64 reported abi, would you? I need to figure out if it's a mistake or a shortcut
<neggles>
now known as Microsoft Endpoint Manager
<mangix>
Grommish: what?
<neggles>
the tuple reported/chosen for octeonplus is possibly-not-right
<neggles>
you don't need to specify port :P 5201 is default
<Grommish>
LLVM wants a muslabi64 on the Mips64 tuple.. OpenWrt uses musl
<Grommish>
LLVM technically doesn't support Mips64 muslabi64, so it converts it back to musl interally for future proofing
<neggles>
mangix: it's MDM/cloud enterprise device management - scoop is great for individual machines, but it does not play nicely in enterprise, and across all our clients i've got a few thousand PCs I need to push stuff out to here n there.
<neggles>
anyway
<neggles>
hopefully it gets better, and at least it's not friggin chocolatey.
<mangix>
Grommish: there is no 64 abi. there is N64
<neggles>
(N64 is what we build)
<mangix>
right
<neggles>
and it's the equivalent of aarch64 afaik
<Grommish>
I need to know if Mips64 should be musl because while its -m64 (thus reporting correctly as mips64-openwrt-musl) or needs to actually be muslabi64
<Grommish>
Or rather, should/will/etc
<Grommish>
and since REAL_TARGET_GNU_NAME is set via rules.mk, it was coded internally
<neggles>
ie it's actual-64-bit, while N32 is halfway there
<Grommish>
I just need to know what to tell the rust-lang devs *shrug* I don't know the arch
<Grommish>
and there is a discrepancy between what Openwrt reports, and what other projects think it should be
<Grommish>
So, Technically OpenWrt is reporting correctly in terms of what LLVm eventually will *want*, but not what it *should* be by rights? Again, dunno
mangix has quit [Read error: Connection reset by peer]
<neggles>
i would say it should be reporting muslabi64 as it's full 64-bit userspace/kernel with appropriately-sized types - 32bit int, 64bit long/longlong/pointer/reg
mangix has joined #openwrt-devel
<Grommish>
I don't know enough to have an opinion, I just have been trying to find someone who can give an authoritative answer:D
<Grommish>
and either update the rules.mk to report properly, or take the justification back to rust-lang
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
<neggles>
welp, gnu reports gnuabi64 for all the N64 targets... it would stand to reason
<neggles>
they attempted to upstream a whole separate driver for oct3
<Grommish>
neggles: I wonder what else was needed..
<neggles>
I think this was part of their initial attempts to break off mainline support from all the CVMX code
<neggles>
then marvell bought 'em and, well...
<Grommish>
Indeed
<dwmw2_gone>
So, I upgraded a different box (Lantiq XRX200), and had a similar experience with DSA. Force-upgraded it and it came back up with wireless and VDSL, but the Ethernet ports were all unconfigured, which is fair enough.
<dwmw2_gone>
When I logged in to luci to see the network configuration it told me *twice* that some config bits needed to be upgraded, and did so.
<dwmw2_gone>
But we never did write something to parse the pre-DSA switch config and translate that into adding the `lan1 lan2 lan3 lan4` devices to br-lan in even the *default* case, right?
<dwmw2_gone>
Which is a bit of an oversight.
<dwmw2_gone>
But I think it does mean that for my *production* router I can just add the non-existent lan[1234] devices to br-lan while it's still running 19.07, then sysupgrade and it should be fine.
<f00b4r0>
keyword: should :)
<russell-->
not claiming everyone else should do this, but i just bake my desired configuration into the built firmware (usually as a custom uci-defaults script)
<dwmw2_gone>
I'm severely tempted to do so
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
pmelange has joined #openwrt-devel
pmelange has quit [Ping timeout: 480 seconds]
Misanthropos has quit [Ping timeout: 480 seconds]
rsalvaterra has quit [Quit: rsalvaterra]
rsalvaterra has joined #openwrt-devel
Tapper has joined #openwrt-devel
Tapper has quit [Quit: Tapper]
<f00b4r0>
hmm. disabled services show status "running" when queried, that's counter intuitive
<jow>
it is indeed
<f00b4r0>
I'd say it's brain damaged, but I'm trying to behave myself ;)
<stintel>
you just failed :D
<f00b4r0>
damn. Where are my pills. :D
<jow>
hm, for me it is fine actually
<jow>
a service can be disabled, yet running
<jow>
since /e/i/whatever disable only disables autostart, it does not terminate
<f00b4r0>
true. But in the present case the service was disabled when the device booted, so it was never started
<jow>
only after /e/i/wahtever disable *and* /e/i/whatever stop I get disabled / stopped
<jow>
ah okay
<f00b4r0>
hence my surprise
<jow>
on a first glance, the logic looks fine to me though
<f00b4r0>
well. The service clearly isn't "running"
<f00b4r0>
so I don't know about the logic, but the output is actually wrong :)
<jow>
see /etc/shinit
<jow>
for it to report running, the procd service output must show at least one instance with running: true
<jow>
what's the output of `ubus call service list | jsonfilter -e '@.affected_service_name'` ?
<f00b4r0>
let me reboot the device for a clean state
<jow>
sorry, the output of `ubus call service list '{ "verbose": true, "name": "affected_service_name" }'`
<neggles>
it's falling through to the `echo "running"; return 0`
<neggles>
for... some reason
<neggles>
i cannot help but notice that at no point is this function actually checking the "running" key
<f00b4r0>
i was about to say
<neggles>
just checks for instance existing or not
<neggles>
technically it's *kind of* running, since there's an interface trigger?
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
<jow>
should probably be "active not running"
<jow>
or maybe "passive" :P
<f00b4r0>
heh ;P
<neggles>
"enabled, inactive"
<f00b4r0>
neggles: you have a point and it puzzles me: I'm not sure why the trigger would be active with a disabled service
<f00b4r0>
clearly if I disable a service, I don't expect it to pop back into life just because a trigger fired
<f00b4r0>
neggles: precisely, it's not enabled.
<neggles>
maybe you don't want it to start on boot, only on-trigger?
<f00b4r0>
ah
<jow>
I wonder why it is registered in the first place if it is disabled
<f00b4r0>
^
<neggles>
jow: trigger?
<neggles>
or should disabled be hard-down
<jow>
triggers are onyl installed if the init script runs
<jow>
which shouldn't run if it is disabled
<neggles>
ah, true
<neggles>
is there a symlink in rc.d?
<jow>
but maybe it is incorrectly written, like performing service registration outside of the proper procedures, so not merely invoking it (e.g. for status quierying) is also registering the service
<f00b4r0>
neggles: no
<jow>
s/not //
<neggles>
that would make sense, it has to parse the service file to check status
<f00b4r0>
as I said, it's a very slightly amended version of the packaged one
<neggles>
but you would expect that parsing a disabled initscript would not cause a trigger to load
<jow>
no, the file looks fine
srslypascal is now known as Guest647
srslypascal has joined #openwrt-devel
<f00b4r0>
even better: if I run "stop" and then query status again, it now says "inactive"
<f00b4r0>
and the ubus call is empty
<neggles>
interesting
<neggles>
so the trigger was getting loaded when it shouldn't?
<jow>
so maybe something is simply starting it
<jow>
is the chilli package shipping other things? hotplug handlers maybe?
<f00b4r0>
the service was not running (confirmed with ps)
<neggles>
no sign of it starting then stopping in logread/etc?
<jow>
it is a common implementation error to ship hotplug handlers that trigger init script actions without actually checking that the init script is enabled
<f00b4r0>
oh
<f00b4r0>
/etc/hotplug.d/iface/30-chilli
<neggles>
oh hey
<neggles>
yep
<neggles>
that's uh
<neggles>
ifup on wan = trigger restart
srslypascal has quit [Remote host closed the connection]
<neggles>
zero checking to determine whether the service is enabled or not
<neggles>
oof
<jow>
of whether tzhe wan is called wan
<jow>
or whether wan is the upstream to begin with
<f00b4r0>
indeed. That thing is so utterly wrong I thing the best fix is simply to remove it from package :P
<jow>
so at the very least it should bail out if ! /etc/init.d/chilli enabled
<jow>
and actually it shoudl check the config for the effective usptream interface
Guest647 has quit [Ping timeout: 480 seconds]
<jow>
but yeah, since the init script registers an interface trigger, the hotplug thing is completely redudnant most likely
<f00b4r0>
yeah the iface trigger is my addition
<f00b4r0>
i completely missed the hotplug trigger
<f00b4r0>
sorry for wasting everybody's time :P
<neggles>
not a time waste
<jow>
would be good if you got propose a PR though which is adding triggers and rmeoving the hotplug handler
<neggles>
troubleshooting!
<neggles>
but, yes, that
<neggles>
upstream thy fix
<f00b4r0>
I'll try to cook up something decent
<f00b4r0>
my version hardcodes "wan" in trigger because well, that's what I need :)
<neggles>
uci config line?
<f00b4r0>
I don't use uci at all for configuring chilli, but otherwise yes it would make sense
<f00b4r0>
that being said, I still think the procd behaviour is incorrect. But I don't think I'm tall enough to touch that code :)
srslypascal has quit [Quit: Leaving]
<jow>
You mean that the "disable" state should be more thorough and also prevent "start", "restart", "reload" etc?
<f00b4r0>
no
<jow>
what is incorrect then?
<f00b4r0>
well it would be nice, but no, I was referring to the incorrect "running" status when the service is actually not running and ubus shows "running: false"
<jow>
ah, well yeah. I'd say it was "registered" (or "loaded") but not "running"
<f00b4r0>
*nod*
<jow>
so that final "running fallback should probably evaluate the "autostart" state(s) of the instance(s)
<stintel>
the error is a bit confusing. "No such file or directory" lead me to initial conclusion that it's about /lib/bpf/qosify-bpf.o but that file exists
eduardo010174 has joined #openwrt-devel
<stintel>
and renaming that file changes the error
Misanthropos has joined #openwrt-devel
<nbd>
stintel: what platform/kernel version is this?
<stintel>
nbd: this is on openwifi edgecore eap101 with qdsk 4.4.60 kernel
<nbd>
great. which llvm version do you have on your build host?
<stintel>
nbd: 13.0.0
<stintel>
nbd: mind you that the images I used were TIP built, not by me
<stintel>
so only your fix was tested with llvm 13.0.0
<nbd>
did you verify that you had the same issue without my fix?
<stintel>
let me try that
<stintel>
nbd: looks like it works fine without your fix too
<stintel>
nbd: would it be possible to add an option to qosify that shows the LLVM version used to build it ?
<Slimey>
yawns
minimal has joined #openwrt-devel
<stintel>
nbd: built with llvm-12, also fine
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
<Slimey>
prob the last batch before the 6040's :P QorIQ SDK (FSL Reference Distro) 1.9 bsap3040 /dev/ttyS0
<stintel>
nbd: apparently Ubuntu 20.04 requires the use of -12 suffix to LLVM commands to use version 12
<stintel>
nbd: so everything is built with LLVM 10 most likely
rsalvaterra has quit [Quit: rsalvaterra]
rsalvaterra has joined #openwrt-devel
vchrizz has joined #openwrt-devel
ldir has joined #openwrt-devel
ldir has quit []
a_a has joined #openwrt-devel
a_a has quit []
mitome_ has quit [Quit: Leaving]
<stintel>
nbd: removing the llvm package on ubuntu 20.04 and installing llvm-12: LLVM 12 is detected, but then not used. so the detection needs improvement too
Gaspare has joined #openwrt-devel
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
Luke-Jr has quit [Ping timeout: 480 seconds]
<f00b4r0>
would there be interest in a patch to provide a way to tell sysupgrade NOT to reboot after execution?
<f00b4r0>
interesting, I was wondering what made firstboot so slow on this device (TL-WDR3600) and apparently jffs2_scan_eraseblock() takes 100s to complete
<PaulFertser>
What would that patch be useful for, what usecase?
<PaulFertser>
Yes, some SPI flashes are just very slow to erase.
<f00b4r0>
PaulFertser: it's not the erase that slow. It's the scan. If I read this correctly
<f00b4r0>
PaulFertser: the use case is e.g. when you're flashing several devices in a batch; or a device with a very specific configuration that you only want to activate upon powerup at location.
<PaulFertser>
f00b4r0: I was fairly sure it's the erase part that slows it down, that is, it scans, sees a non-erased block and erases it, and does for the whole jffs2_data partition. I might be wrong though.
<PaulFertser>
f00b4r0: I see, and it looks surprising too.
<PaulFertser>
f00b4r0: especially because OpenWrt embeds end of filesystem marker right after squashfs.
<PaulFertser>
So no time scanning for it can be spent.
<f00b4r0>
indeed
mitome_ has quit [Quit: Leaving]
Luke-Jr has joined #openwrt-devel
Gaspare has quit [Read error: Connection reset by peer]
<champtar>
ip6tables and ip6tables-nft are just providing symlinks, what do you thing about getting rid of them ? Trying to clean the iptables{,-nft} jungle
<aparcar>
champtar: any WIP I can look at?
<champtar>
Building and testing, I might push something in 1 or 2h
<aparcar>
champtar: okay thank you, I'll stall my WIP until then
<champtar>
I hesitate between having iptables-legacy / iptables-nft provide the binaries + "named" symlink + bin, and having iptables-legacy-link / iptables-nft-link really provide the iptables symlink
<champtar>
or just directly conflict between iptables-legacy and iptables-nft
<champtar>
not sure there is a use case having both legacy and nft on the system
<aparcar>
champtar: I'd do it like Debian: have iptables-legacy and iptables-nft and use alternatives
<aparcar>
[florian]: news on the toolchain?
<aparcar>
[florian]: also you're a openwrt project member right?
pmelange has joined #openwrt-devel
<champtar>
aparcar: we don't have alternatives or have I missed something ?
<aparcar>
you missed something
<aparcar>
check out... dropbear for example
<champtar>
thanks, I will have a look
<champtar>
first trying to have iptables-nft work without iptables dependency
<champtar>
root@OpenWrt:/# iptables-nft -A OUTPUT -d 8.8.8.8 -j DROP
<champtar>
iptables v1.8.7 (nf_tables): Chain 'DROP' does not exist
<champtar>
:)
<champtar>
almost ...
danitool has joined #openwrt-devel
Borromini has joined #openwrt-devel
<aparcar>
champtar: thanks for working on it
Misanthr- has joined #openwrt-devel
Misanthropos has quit [Read error: Connection reset by peer]
Misanthr- has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
aiyion_ is now known as aiyion
dorf has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
madwoota has quit [Read error: Connection reset by peer]
madwoota has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
Misanthropos has joined #openwrt-devel
dorf has joined #openwrt-devel
GNUmoon has quit [Ping timeout: 480 seconds]
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
dorf has quit [Remote host closed the connection]
<jow>
champtar: iptables-legacy and libiptables-nft with ALTERNATIVES
<jow>
would be the best imhop
rua has quit [Ping timeout: 480 seconds]
<champtar>
renaming iptables to iptables-legacy and then having the iptables-mod-* depends on iptables-legacy creates a ton of recursive dependencies :(
<champtar>
exemple qos-scripts depends on "+iptables +iptables-mod-ipopt +iptables-mod-conntrack-extra"
mitome_ has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
<rsalvaterra>
champtar: This is no solution, of course, but given the existence of sqm-scripts and qosify, does it make sense to keep qos-scripts around?
<champtar>
it triggers tens of circular dependencies
<champtar>
any packages that has +iptables +iptables-mod-*
<champtar>
I think packages maintainer will need to switch manually to iptables-nft after testing
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<jow>
champtar: so on a high level, the issue is that iptables-nft does not have iptables-mod-ipopt?
<jow>
because it directly translates syntax to nft bytecode
<jow>
Grommish: uhm, no idea. I fear there might be nobody at all who can give you an answer to that
<champtar>
jow: I'm not convinced iptables-nft will make many packages work transparently
<champtar>
but still good to clean dependencies
<jow>
champtar: because of dependencies or because you think it cannot properly translate iptables calls?
<Grommish>
jow: Ok, thank you! :)
<champtar>
not sure it'll translate all the advanced stuff
<champtar>
but we will see
<jow>
Grommish: from a very cursory look it appears that we're manually assembling REAL_TARGET_GNU_NAME, it is entirely possible that we don't implement a bunch of secret GNU conventions nobody knows about
<jow>
or LLVM convetions
<Grommish>
jow: the issue is that Openwrt reports musl, which technically is what LLVM will use because it doesn't support muslabi64 ... yet.. but the convention says it should still be muslabi64 and I don't know enough to have an opinion
<jow>
me neither
<jow>
if I google "muslabi64" the only hits I find are rust related and the PR you opened
<jow>
so it seems to be something the rust guys invented?
<jow>
it does not appear to be a widespread... thing
<Grommish>
Good enough for me then. i think they are concerned over LLVM formatting
<jow>
the powerpc64 targets don't have any abi suffix
<jow>
i686 vs. x86_64 neither
<jow>
nor aarch64 vs. arm*
<jow>
so not sure why mips vs. mips64
<jow>
should have one
<jow>
apart from the fact that there's two existing ones
<jow>
(this is a totally uninformed interpretation based on random data found on the internet, I might be completely missing some deeply technical considerations)
<Grommish>
Dunno. I just justified their question by saying since LLVM doesn't support muslabi64 and they get around it themselves with re-stringing the target internally, musl seems to be the most appropriate
<Grommish>
I can always change it later if it ever gets fixed