<f00b4r0>
at a point where the CPU seem to be suddenly hogged (the gap shows in all metrics, and loadavg is registering 5+ when the metric recovers)
jeff___m has joined #openwrt-devel
jeff___m has quit [Ping timeout: 480 seconds]
<dhewg>
nbd: since you're active on mdnsd, what's required to bridge interfaces? I'd like to e.g. allow 'lan' to access 'iot', but not the other way around. Do I just do that via fw or do we want rules and an implementation for it?
<theJoker8814>
dhewg: do you got a use case for that only lan -> iot? just restrict the mdnsd resolution or the following ip traffic as well?
<dhewg>
the traffic is already restricted via fw zones
<dhewg>
lan can access iot stuff, bit iot can't initiate connections to lan
<dhewg>
the use case is: don't trust vendor crap :D
<theJoker8814>
that I get. As long as the client in lan initiates the connections and they are trackable/ tcp it should work.
<dhewg>
yeah, and it does
f00b4r0 has quit [Quit: system update]
<theJoker8814>
you just have to configure mdnsd to accept requests on lan and forward them to iot
<stintel>
afaik the only option for that is avahi reflector or something
<stintel>
and there is no way in hell I'm running avahi on my main routers :P
<dhewg>
nope, that's not an option at all :P
<dhewg>
exactly
<theJoker8814>
y not?
<dhewg>
my router has an active wan interface and the attack surface of that avahi pile is just too big
<dhewg>
let alone the dependencies and the sum of the sizes of those
<theJoker8814>
lol don't you drop any incoming packets on wan by default?
<dhewg>
of course I do, but why the hell would I want ubus on my inet connected router
<theJoker8814>
I can give you a sample config where it does not listen to every interface
<stintel>
s/ubus/dbus ;)
<dhewg>
erm, yes dbus, even worse
<dhewg>
and well, we do have umdns, which is nice, small and fits very well into the openwrt eco system
<theJoker8814>
but can it reflect like avahi?
<dhewg>
I don't think that adding that repeater option to it is a huge task
<dhewg>
apparently not, and now we're back to my initial question :)
<theJoker8814>
you could circumvent the use of any mdns daemon at all
<stintel>
if you want to use thread and matter, I really don't believe you can
<dhewg>
yeah, although I think it might work if you have umdns just run on the thread interface (ignoring the fact that otbr doesn't have umdns support atm)
<dhewg>
the thread network might still work, you just don't see its devices via mdns
<dhewg>
(from other interfaces)
<theJoker8814>
just enable routing of Multicast packets, mdns client implementations send their requests to ipv4 224.0.0.251 and IPv6 address ff02::fb
<stintel>
have you ever actually tried that?
<theJoker8814>
3 steps: enable interface multicast on lan, add nftables rule to increase IP TTL by 1, add moulticast route entry to routing table
<theJoker8814>
I have it working here. lan <-> wlan
<stintel>
interesting approach
<stintel>
thanks for the hint
f00b4r0 has joined #openwrt-devel
<mrkiko>
robimarko: seen your PR 14555, maybe nbd is interested in it?
<stintel>
theJoker8814: do you have an example snippet for /etc/nftables.d/ ? </lazy>
<robimarko>
mrkiko: He already saw it
<mrkiko>
robimarko: great :D
<theJoker8814>
use it for AirPlay, mdns, SSDP
<theJoker8814>
I can pack you all 3 parts
<dhewg>
nice, I haven't actually tried that, I wasn't sure if it would work
<theJoker8814>
after my next/ first offical owrt package, that's next on my agenda. for now it's manual configuration
<theJoker8814>
it does. very well
<dhewg>
but if that indeed works, why does avahi have a reflection implementation?
<theJoker8814>
because it requires kernel access
<theJoker8814>
so in big deployments / software projects not an option
<dhewg>
sure, but doesn't it run as uid=0 anyway?
<dhewg>
sorry, I've always avoided avahi :P
<theJoker8814>
avahi runs the reflection code in userspace. no kernel multicast routes needed
<theJoker8814>
also is has ABI/ API's
<theJoker8814>
it just offers more features and is designed for big deployments. that's why Cisco for examples implemented it in their Wireless products ;)
madwoota has quit [Ping timeout: 480 seconds]
madwoota has joined #openwrt-devel
<stintel>
heh someone on twitter is asking if I can install OpenWrt on their Firebox M300
<stintel>
maybe it's time to make qoriq target not source-only
<Habbie>
i solved this by not having twitter any more
<Habbie>
way less work
<stintel>
LOL
<f00b4r0>
lol
jeff___m has joined #openwrt-devel
jeff___m has quit [Ping timeout: 480 seconds]
Borromini has quit [Ping timeout: 480 seconds]
theJoker8814 has quit [Ping timeout: 480 seconds]
* f00b4r0
notices that miniupnpd seems to be broken on 22.03
<stintel>
was it ever not broken? :P
<f00b4r0>
heh :)
<dhewg>
f00b4r0: going by that screenshot I assume you're feeding grafana with the lua node-exporter?
<f00b4r0>
dhewg: no
<f00b4r0>
it's pure collectd
<stintel>
there's also prometheus-node-exporter-ucode
<dhewg>
ah, okay
<f00b4r0>
I try to run lean
<stintel>
but I've been having major issues with that
<dhewg>
stintel: yeah, which is why I asked, I feel alone with it :)
<f00b4r0>
and I know how to avoid collectd's leaking tendencies
<dhewg>
what's the issue?
<stintel>
like multiple uhttpd processes
<stintel>
for a single node-exporter
<stintel>
eating all CPU
<stintel>
so bad that even my wifi clients can no longer assoc
<dhewg>
oh? the lua version sets it up that way too though
<stintel>
killed my streak on flightaware.com :(
<f00b4r0>
so it's not miniupnpd but rather its init script. Seems it has trouble coping with non-standard internal lan devices
<f00b4r0>
hmm another case of bloated script and non-luci-exposed settings that result in broken config
<f00b4r0>
sigh
bluew has quit [Ping timeout: 480 seconds]
<dhewg>
stintel: any idea which collector eats cpu? it works just fine here
<dhewg>
it has one process, but spawns one upon a request
<dhewg>
it's not as fast as I'd like, I've tried but haven't found the bottleneck. My suspicion is that it recompiles/reinterprets/whatever the ucode upon each request
<stintel>
dhewg: dunno, it happens after some uptime
<stintel>
I stopped the process because it was making my network extremely flaky
<KanjiMonster>
looks like some script that doesn't check if the list already contains an entry before adding it
<stintel>
but that's a different uhttpd instance so shouldn't impact the prometheus stuff
<stintel>
KanjiMonster: yeah, it's some experimental thing I made when I was doing some OpenWrt stuff at Meta
xback has quit [Ping timeout: 480 seconds]
<dhewg>
well scrape interval obviously isn't that nice with the ucode scrape duration, but I guess the device starts evicting pages if it has an effect on other stuff?
<dhewg>
while it won't fix leaks, throw zram-lz4 at it?
<dhewg>
my uhttp ucode node process has a VSZ of 1484
<dhewg>
not tiny, but far from bloat
<dhewg>
the uhttp luci one has 2140 atm, procd 1512
<schmars[m]>
this toh entry https://openwrt.org/toh/gl.inet/gl-xe300 gives me "Error: Call to undefined method syntax_plugin_data_table::_buildSQL() An unforeseen error has occured. This is most likely a bug somewhere. It might be a problem in the datatemplate plugin"