<rsalvaterra>
aparcar[m]: I just updated your dnsmasq branch (more backported patches). Also rebased on current master.
<jow>
rsalvaterra: speaking on dnsmasq... what's the status of nftset support?
<jow>
*of
<rsalvaterra>
jow: It should be working, although I haven't been able to test it, since I'm still using iptables in my systems. aparcar[m]'s branch includes the necessary commit.
<jow>
great, I'll give it a spin here
<rsalvaterra>
jow: Do you have aparcar[m]'s dnsmasq branch?
<jow>
just unboxing a fresh rb750gr3
<jow>
no, can you point me to it? Goimng to do a new build anyway
<rsalvaterra>
Well, that's a per-host approach, yes.
<rsalvaterra>
But if people want to filter A/AAAA records globally, for some reason…
<jow>
yep
<rsalvaterra>
I personally don't see a lot of value in this option, but I thought I should UCIfy it, in case anyone cares.
<rsalvaterra>
If I'm filtering out all AAAA records, I might as well just disable IPv6 altogether.
borek has joined #openwrt-devel
shibboleth has joined #openwrt-devel
robimarko has joined #openwrt-devel
arinc9 has joined #openwrt-devel
arinc9_ has joined #openwrt-devel
arinc9 has quit []
arinc9 has joined #openwrt-devel
arinc9 has quit []
arinc9 has joined #openwrt-devel
arinc9 has quit []
arinc9_ has quit []
arinc9_ has joined #openwrt-devel
arinc9_ has quit []
arinc9 has joined #openwrt-devel
arinc9__ has joined #openwrt-devel
arinc9 has quit []
arinc9__ is now known as arinc9
arinc9 is now known as arinc9test
arinc9test is now known as arinc9
arinc9_ has joined #openwrt-devel
bprfh has joined #openwrt-devel
arinc9 has quit []
arinc9 has joined #openwrt-devel
<neggles>
welp
arinc9 has quit []
<neggles>
i guess i'm going to be proposing a new target in the foreseeable future
<neggles>
`alpine`
arinc9 has joined #openwrt-devel
arinc9_ has quit []
<neggles>
since someone just dropped half a dozen checkpoints that use the Amazon/Annapurna Alpine AL21200/21400 (dual/quad A15) in my lap, and I've got a few mikrotiks that use them and their cortex-A57/cortex-A72 successors
<neggles>
mainline support is not terrible, i have some gpl dumps, hopefully won't be terrible :P
<jow>
alpine would be a very confusing target name though
<neggles>
alpine is what they're called in the kernel
<jow>
thought you refer to the alpine musl distribution
<neggles>
jow: i'm happy to use any of amazon/annapurna/alpine
<neggles>
seem like generally targets follow kernel mach- name and config symbol name where practical though?
<jow>
neggles: don't put too much weight on my opinion, I don't have any stake in this after all
<neggles>
tbh I just don't want to use `amazon`
<jow>
al21xxx ?
<robimarko>
How is the upstream support?
<neggles>
it's pretty solid for the aarch64 chips
<robimarko>
First gen ones are non-existant upstream
<neggles>
the first-gens aren't anything particularly fancy
<neggles>
nothing stops them being upstreamed, it's just not a priority for their corporate overlords
<robimarko>
Yeah, those are before Amazon-s time
<robimarko>
They just started upstreaming them when Amazon bought the company and that was it
<neggles>
the 5-digit-part-number chips seem like they shouldn't be too difficult to support
<neggles>
this netgear gpl tree for 4.4.218 doesn't have much in the way of hackery
<neggles>
just drivers
<neggles>
jow: problem is i need that for subtargets
<neggles>
though probably cortex-a15 / cortex-a57 / cortex-a72 would work there
<robimarko>
Those are way too ambigous
<neggles>
you're right
<neggles>
but, i'm not sure the alpine2 and alpine3 need to even be split
<neggles>
and, look at mvebu :P
<robimarko>
Probably dont
<robimarko>
Since they are AARCh64 both
<neggles>
yah, 21xxx are not though
<robimarko>
Well, you woult want to split them probably
<robimarko>
Depending on the performance loss from not optimizing for the exact core
<neggles>
on the AL7xxx it's probably significant
<robimarko>
And/or any other optional features one CPU has while the other doesnt
<jow>
I prefer solid, broad baseline support over micro-optimized subtargets only covering one device each
<jow>
those people finding the most optimal set of compiler flags for their target platforms tend to do their own builds anyway
<neggles>
so the AL21xxx are a dual/quad A15 and it's pretty run of the mill. it's used in a huge number of devices, mostly NASes and firewalls
<rsalvaterra>
jow: -funroll-loops -Omg
<neggles>
the AL32400 is a quad-A57, "alpine-v2", and found in several mikrotiks. the AL52400 is one of those as well, the AL73xxx is a 16-core A72
<neggles>
the 52400 is the only one likely to need Weird Shit on the kernel front
* rsalvaterra
still believes naming it -Ofast instead of -Omg is a missed opportunity.
<neggles>
rsalvaterra: you're right and you should say it
<rsalvaterra>
:)
<neggles>
i'm going to work on the theory of "one 32-bit target, one 64-bit target" for the time being
<neggles>
s/target/subtarget
<robimarko>
Honestly, just start with the mainline 64 bit CPU-s
<neggles>
but i have a stack of seven 32-bit ones :P
<robimarko>
Yeah, but then you will be stuck with porting the wonderfull GPL kernel
<karlp>
is there any canonical solution to this "process starting before networking is available" problem? https://paste.jvnv.net/view/nSoT1
<karlp>
I know there's been lots of attempts with changing start numbers, but those all sound pretty flaky.
<karlp>
the process in question is already at S60, with network at S20.
<jow>
karlp: since procd, those start numbers are essentially meaningless
<jow>
some services even stopped bothering, made boot() a no-op and rely on hotplug invocation
<jow>
which should also be the way for anything network related
<jow>
problem is defining a reliable/suitable event source
<karlp>
yeah
<jow>
ifup loopback is too early, ifup wan might never happen, ifup lan might not happen eithe if the user renamed his interfaces
<karlp>
right. joy in all directions then :)
<jow>
reacting on any ifup + defualt route being present
<jow>
but might be before DNS is there
<T-Bone>
there may not always be a default route
<karlp>
I've worked around one of them for my own apps by just doing a hard "/etc/init.d/blah restart" on the ntp stratum hotplug event,
T-Bone is now known as f00b4r0
<jow>
probably needs an eventual timeout to start anyway after waiting 60s for connectivity
<jow>
yeah, ntp stratum is actually idea
<karlp>
eventualyl we end up rebuilding systemd like this.
<jow>
it proves wan connecitvity and dns availability
<jow>
but users might decide to opt out of ntp
<f00b4r0>
would be nice if there were an "all configured ifaces up" event
<jow>
what's needed is probably some kind of "event aggregation" mechanism which gathers various kinds of hotplug events and employs some sort of heuristics to eventually synthesize a "network available" event
<karlp>
f00b4r0: I don't want to have to configure my interfaces explicitly though :)
<jow>
f00b4r0: what if interfaces never come up? think of e.g. the preconfigured wan6 in conjunction with an ISP simply not offering any IPv6
<f00b4r0>
ah right
<f00b4r0>
well I guess it's an NP-complex problem then :)
<jow>
it is, one can only find some sort of sane approximation
rua has quit [Quit: Leaving.]
<f00b4r0>
reacting to ifup events + check on default route seems like the path of least effort
<f00b4r0>
assuming one wants to confirm wan access
<jow>
an algorithm like: wait 120s, then claim network up; if ntp stratum received abort sleep and signal immediately; on ifup wan + default route, do ping test and signal immediately, ...
<jow>
in the end, the only reliable way is actually testing connectivity (check an http ressource, ping a well known domain). But this has its own issues (upstream might employ firewall policies, load increase on 3rd party services, ...)
<jow>
karlp: so tldr; no canonical solution.
<karlp>
right. I think _monit_ the package could perhaps be tweaked to just wait for a network on loopback,
<karlp>
as that's what it needs to open it's admin interface, but yeah, no general solution.
<karlp>
what I've got happening is monit running, and monitoring what it knew about when it started, but unable to respond to any other requests to unmonitor/change any new services.
* f00b4r0
notices that sysupgrading while preserving config from ar71xx to ath79 on mikrotik breaks MAC assignment due to MAC being now set in network config
<f00b4r0>
hmm this is going to be painful
<neggles>
karlp: for monit you can probably wait for loopback yeah
<neggles>
since it's trying to bind to loopback
<grift>
karlp: bind to 0:0:0:0
<neggles>
that doesn't help with the 'doesn't pick up new interfaces after it was started' though - does it have a reload option or does it have to be restarted to refresh?
<karlp>
grift: ... no :)
<neggles>
you could always invoke a restart in rc.local :P
<karlp>
what makesyou think there's any guarantee things are ready then? :)
<neggles>
lo0 should be up at least :P
<neggles>
ah, it does have a reload action
<neggles>
soooo... invoke a reload whenever the config file changes?
<karlp>
neggles: sticking it in my current ntp stratum "fix things" hook is fine locally, if I'm going to try and fix monit in packages, I'd say just doing a null boot and starting it on netifd hotplug for loopback is best.
<karlp>
the config file isn't changing?
<neggles>
ah, then why would it not respond to requests to change stuff?
<karlp>
it's literally just stuck running, but deaf, no admin interface.
<neggles>
oh right
<neggles>
because no lo0
<karlp>
yup
<neggles>
yeah, starting on lo0 up is the way to go then
<neggles>
or
<neggles>
bind to /run/monit.sock
<grift>
even better
<neggles>
it looks like you can set it to bind to both a socket and to localhost
<neggles>
so bind to socket, then use socket interface to reload on interface up
<karlp>
that soundsd vatly more complicated for ~zero gain :)
<grift>
or just use a unix stream socket and be done
<f00b4r0>
so I made a small mistake and renamed the "eth" led to "lan" in the ath79 dts. Maybe I should fix this to ease transition
<karlp>
no? this is a nice http admin interface as well...
<karlp>
I'm not rewriting monit here...
<neggles>
if you have nginx you can reverse proxy to a unix socket
<neggles>
but it looks like uhttpd won't do that, not surprisingly
<karlp>
you're just making up solutions to problems I don't have now :)
<neggles>
jow: that only works if the daemon has a functional socket bound somewhere, though
<neggles>
so would require unix socket to exist
<jow>
neggles: how so?
<jow>
it instructs procd to relauch the init procedore if an event on the logical loopback interface occuras
<jow>
*occurs
<neggles>
jow: so the way monit works is you spawn the daemon, which binds to 127.0.0.1:2812 by default, then future calls to `monit` (with params) talk to the daemon over that socket
bluew has quit [Quit: Leaving]
<neggles>
you'd hope that sending SIGHUP would trigger a reload too though.
<neggles>
ah, it does!
<neggles>
cool. never mind then
<jow>
note that I specified /etc/init.d/monit reload as action
<jow>
which, if no specific reload logic is implemented by the init script, defaults to restart
<jow>
it recalculates the desired service state, sends it to procd. It compares with the current effective state. If there's a delta, the process gets killed and reexecuted
<neggles>
fair enough. i'm sure there's boilerplate to turn reload into 'send SIGHUP' as well, for something less hammer-y
<neggles>
karlp: there's your fix then :P thanks jow
<karlp>
yup, snagging that for now into a local ticket, will deal with it next time I'm updating shits.
<karlp>
thanks jow!
<grift>
o now i think i get it.. was already wondering why would you want a web interface on openwrt when binding sockets to 127.0.0.1 but i guess its for luci, kind of like how luci-app-tinyproxy display the tinyproxy stats page in luci
<jow>
grift: as I understood, in the monit case it also serves as command socket
<karlp>
(I ~never _use_ the web interface, buf if/when I do, I use it via ssh port forwarding and from a local browser)
<grift>
o yes i guess i overlooked that too
<grift>
i agree its a bit annoying though, especially with bind sockets to ip6 nodes
<grift>
which tend to take the longest in my experiencce
<grift>
i usually just bind to unspecified node and deal with it else where to get around that
ekathva has quit [Remote host closed the connection]
<karlp>
you can click into each item and stop/start/change monitoring sort of thing too.
arinc9 has quit [Ping timeout: 480 seconds]
nagma has joined #openwrt-devel
<nagma>
Hi , I am trying to install kmod-ipt-tproxy , iptables-mod-troxy in openwrt 19.07 snapshot arm_cortex-a7_neon-vfpv4 but i cannot find the package in both opkg and index root . can someone help me installing this packages
shibboleth has quit [Quit: shibboleth]
<karlp>
jow: that interface trigger should work in ~21.02 era right? (it's from a little before 21.02 final was released iirc would have to check)
<karlp>
I've got one that is doing this reliably every boot right now, so thought I'd try and test it out properly.
Tapper has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
Tapper has joined #openwrt-devel
robimarko has quit [Ping timeout: 480 seconds]
ekathva has joined #openwrt-devel
rua has joined #openwrt-devel
nagma has quit [Quit: Page closed]
csrf has joined #openwrt-devel
<robimarko_>
hauke: Anything against including the QMI helpers in backports as well?
<robimarko_>
They are required by ath11k, and usually selected by the driver
<robimarko_>
But currently, we are patching the KConfig entry to allow it to be selectable and packaged in OpenWrt
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
bprfh has joined #openwrt-devel
<neggles>
robimarko_: netgear have very kindly supplied me with individual patch files for the alpine-v1 changes to 4.4.42 so that's a start
<robimarko_>
Yeah, and thats fine for short-term
<robimarko_>
But upstreaming is gonna take a long time
<neggles>
yeah
<robimarko_>
Dont ask me how I know
<neggles>
oh i know how you know
<neggles>
I don't really mind not upstreaming, though that would be nice - there's a *lot* of these out there
<neggles>
and i don't expect to get official support in OpenWrt without at least getting some positive feedback from the various maintainers about support
<robimarko_>
Well, thats the bare-bones UART stuff they added before Amazon killed that
<neggles>
yes, but it's a start
<robimarko_>
I dont know whats the requirment for a target in OpenWrt, hopefully it requires that basic stuff is upstream at least
<hauke>
robimarko_: I have no problem with including it in backports too
<robimarko_>
Cause, otherwise we are gonna end up with maintaing it indefinitively
<robimarko_>
hauke: Great, gonna give it a go over the weekend
<robimarko_>
Havent tried doing anything to backports so far
<neggles>
yeah, and if that's the route it goes down, i'll probably do it in a fork
<hauke>
for backports it would be nice if the PCIe ath11k devices would work out of the box, if we need some kernel patching for integrated devices it is ok
<robimarko_>
hauke: Yeah, I agree
<hauke>
like for the boradcom b43 driver backports includes ssb and bcma which does the bus abstraction
<robimarko_>
QMI helpers are needed for both
<hauke>
in OpenWrt we remove it again becasue we need it in kernel
<neggles>
might email one or two of the amazonnapurna devs who've sent patches upstream and see if they'd be interested in helping
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
bprfh has quit [Quit: Leaving.]
arinc9 has joined #openwrt-devel
minimal has quit [Quit: Leaving]
<mrkiko>
robimarko_: any news on the ipq40x-dsa progress? Not wanting to pressure, I am just curious :D
matteo| has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
matteo has joined #openwrt-devel
valku has joined #openwrt-devel
arinc10 has joined #openwrt-devel
arinc10 has quit []
arinc10 has joined #openwrt-devel
arinc9 has quit [Quit: Leaving]
arinc10 is now known as arinc9
rua has quit [Ping timeout: 480 seconds]
floof58 is now known as Guest186
floof58 has joined #openwrt-devel
Guest186 has quit [Ping timeout: 480 seconds]
arinc9 has quit [Quit: arinc9]
arinc9 has joined #openwrt-devel
arinc9 has quit []
ekathva has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
minimal has joined #openwrt-devel
<hurricos>
neggles: :o
<hurricos>
alpine looks to me like one of those compute/storage heavy platforms with less serious networking support. But I can't find any documentation on what's already on each of the many silicons
<hurricos>
not that that's a problem, but it makes it more interesting, downstream vendors may be using it for more expandable applications as was sort of the case with mvebu
<robimarko_>
mrkiko: None, its gonna have to wait at least until the weekend
ekathva has joined #openwrt-devel
Tapper has joined #openwrt-devel
<robimarko_>
hurricos: I know that at least Mikrotik uses it for networking really heavily
decke has quit [Quit: Leaving.]
mattytap has joined #openwrt-devel
bprfh has joined #openwrt-devel
bprfh has quit []
ekathva has quit [Ping timeout: 480 seconds]
<neggles>
hurricos: so alpine is used in a few places
<neggles>
1) AWS Graviton, Graviton2, Graviton3
<neggles>
2) AWS Nitro cards. All of them. Literally all of them. The MikroTik CCR2004-1G-2XS-PCIe uses an AL52400, which is the SoC used in the 2x25G Nitro accelerated networking cards (which are a couple generations old now, but still in use)
<neggles>
(source: US CSRC cryptographic module validation report for FIPS support on the AWS Nitro Card)
<neggles>
they're also found in a whole bunch of NASes, the Ubiquiti UDM-P/UDM-SE, UNVR-4, and UXG-Pro
<neggles>
mikrotik CCR2116 is an AL73400, which is literally the first gen AWS Graviton downclocked 200MHz and probably also the same as the 2x100G Nitro card
<neggles>
(and yes, the SNIC10e was the first-gen nitro NIC, then amazon bought annapurna and made their own ARM ones :P)
jlsalvador has quit [Quit: jlsalvador]
mattytap has quit [Read error: Connection reset by peer]