guerby has quit [Remote host closed the connection]
FLD has joined #openwrt-devel
guerby has joined #openwrt-devel
amaumene has quit [Ping timeout: 480 seconds]
amaumene has joined #openwrt-devel
FLD has quit [Read error: Connection reset by peer]
John[m]12345678 has quit [Server closed connection]
John[m]12345678 has joined #openwrt-devel
bluse-blue[m] has quit [Server closed connection]
bluse-blue[m] has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
FLD has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
rua has joined #openwrt-devel
wulfy23 has quit [Quit: Page closed]
FLD has quit [Remote host closed the connection]
FLD has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
FLD has quit [Ping timeout: 480 seconds]
minimal has quit []
amaumene has quit [Read error: Connection reset by peer]
amaumene has joined #openwrt-devel
wulfy23 has joined #openwrt-devel
<wulfy23>
silly me... looks like that was placebo as left graphs running in background
wulfy23 has quit []
amaumene has quit [Read error: Connection reset by peer]
amaumene has joined #openwrt-devel
<Namidairo>
"As a result, things are working fine now on MT7622+MT7531 as well"
kb1sph has joined #openwrt-devel
<Namidairo>
I actually wouldn't have noticed if it was broken
amaumene has quit [Read error: Connection reset by peer]
amaumene has joined #openwrt-devel
bluew has joined #openwrt-devel
Lechu has quit [Server closed connection]
Lechu has joined #openwrt-devel
amaumene has quit [Quit: amaumene]
Tapper has quit [Quit: Tapper]
Tapper has joined #openwrt-devel
amaumene has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
Tapper has quit [Quit: Tapper]
rua has joined #openwrt-devel
rsalvaterra has quit [Quit: No Ping reply in 180 seconds.]
rsalvaterra has joined #openwrt-devel
amaumene has quit [Read error: Connection reset by peer]
amaumene has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Slimey has quit [Remote host closed the connection]
rua has quit [Ping timeout: 480 seconds]
<kerneltoast>
nbd: hi! i noticed that my mt7915's (unifi 6 lr) hw rate control algo makes awful decisions; even with -30 dBm signal on a channel without interference, the hw rc algo refuses to use the highest link rate (most evident on my phone that only has 802.11ac), and i barely ever see short GI used either. I ended up hex-patching mt7915e.ko to stop the HAS_RATE_CONTROL bit from being set so that minstrel_ht could be used
<kerneltoast>
instead, and the rate control behavior is much better now, but it looks like minstrel_ht ideally wants some knowledge about the hardware's capabilities that i'm not sure how to find, like `struct ieee80211_hw::max_rates` which refers to... rate chains? and `struct ieee80211_hw::max_rate_tries`
rua has joined #openwrt-devel
valku has quit [Quit: valku]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
GNUmoon has quit [Ping timeout: 480 seconds]
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #openwrt-devel
<dansan>
I'm getting an interesting warning in luci-app-snmpd when I apply changes. I briefly get "Apply request failed with status Permission Denied" and the json call to /cgi-bin/luci/admin/uci/apply_rollback is returning HTTP 403, but it still commits the changes
<dansan>
I get the same thing with a custom luci-app- that uses the old lua model (and not a javascript one)
<dansan>
This sounds like what's addressed in e927a11d in LuCI (luci-app-openvpn: fix stray uci permission warning), but I'm new to LuCI and not sure how to apply this one
Tapper has quit [Read error: Connection reset by peer]
swegener has quit [Quit: leaving]
guidosarducci_ has joined #openwrt-devel
Tapper has joined #openwrt-devel
embargo has quit [Ping timeout: 480 seconds]
guidosarducci has quit []
goliath has joined #openwrt-devel
nitroshift has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
swegener has joined #openwrt-devel
<Namidairo>
kerneltoast: it's documented in include/net/mac80211.h
<kerneltoast>
Namidairo: those descriptions are quite vague, or maybe only really understood by domain experts
<kerneltoast>
i can't find any relevant info on google using those descriptions
<Namidairo>
probably just set it similarly to the other devices
<zorun>
aparcar: definitely not, the APU1 has a much slower CPU
<Namidairo>
kerneltoast: I guess just set it similarly to the other devices at the start of mt7915_init_wiphy, see how you go
<kerneltoast>
Namidairo: it's also difficult to tell how these influence minstrel_ht because without setting any of those values, minstrel_ht seems to work alright
<kerneltoast>
so I'm not sure of what subtle effects i should look for
<Namidairo>
well it's only going to accept 1-4 sooo
<kerneltoast>
yeah, but the altered behavior in minstrel_ht is unclear
<kerneltoast>
there's a lot of voodoo that goes into rate control that I'm not versed in (:
FLD has quit [Read error: Connection reset by peer]
FLD has joined #openwrt-devel
FLD has quit [Read error: Connection reset by peer]
FLD has joined #openwrt-devel
eduardo010174 has quit [Remote host closed the connection]
eduardo010174 has joined #openwrt-devel
<rsalvaterra>
Namidairo: Reverting the second patch has no effect at all.
<rsalvaterra>
That's the first thing I tried. ;)
<stintel>
isn't that patch just cosmetic ?
dangole has joined #openwrt-devel
<rsalvaterra>
stintel: No idea, but the fact is that something broke the RAM sizing on my Redmi AC2100. :/
<stintel>
rsalvaterra: git bisect ;)
<rsalvaterra>
I'd *really* like those 256 MiB to be real, though. :P
<rsalvaterra>
*sigh*
<stintel>
LOL
* rsalvaterra
still has those 'nam-like flashbacks from the 5.16-5.17-rc1 bisection…
<stintel>
I had to bisect stuff between 5.4 and 5.15 :P
<stintel>
not on OpenWrt fortunately
<rsalvaterra>
That's fine. Now try to bisect kernel problems *in OpenWrt*. :P
<rsalvaterra>
I've never done it, but come to think of it… git-src pointing to a kernel repo would likely be the solution.
<stintel>
if that kernel boots on your device :)
<stintel>
but for the kernel it's a bit different than git-src too, iirc
<stintel>
CONFIG_EXTERNAL_KERNEL_TREE
<rsalvaterra>
Ah, it's special, I see.
<rsalvaterra>
Before bisecting, I should rule out being a .98/.99 kernel issue and just do a build from pristine master…
<stintel>
as for octeon ... I've been running various kernel 5.10 kernel versions built with different gcc versions, based of my erl config but on snic10e, moved my media player to a VLAN routed by an snic10e, threw quite some traffic over the thing and I cannot reproduce the leak
<stintel>
I've seen it more than once on the ERL, I've seen it once on the SNIC10E, but cannot reproduce it now, even with older versions
<stintel>
so I'm going to conclude it's very rare to hit it and switch octeon to 5.10
<rsalvaterra>
Probably some hard to track down corner case…?
<stintel>
probably
<rsalvaterra>
Your network configuration is too complex for Octeon. :P
<stintel>
config on the snic is not 100% as the erl, that's going to be hard to pull that off, so maybe it's macvlan related
<stintel>
I will probably give that a try still, but for the moment I've had a bit enough of trying to reproduce it
clayface_ has joined #openwrt-devel
clayface has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
eduardo010174 has quit [Remote host closed the connection]
<rsalvaterra>
Whiskey.
<rsalvaterra>
Tango.
<rsalvaterra>
Foxtrot.
<rsalvaterra>
I reenabled KERNEL_PRINTK.
<rsalvaterra>
And now it detected 128 MiB.
<rsalvaterra>
How? Why?
<aparcar>
zorun: looks like APU4 got a lead time of 52 weeks, can I buy your old APU2 please?
<aiyion>
I've found a 10n and a 3.3n capacitor apparently their direction does not matter.
<aiyion>
I'd connect vcc and vss (pin 8 and pin 4)
<aiyion>
any objections?
<PaulFertser>
aiyion: 10n is like almost nothing, it's probably not going to change at hing.
<aiyion>
Ah, going to look for uF then.
<aiyion>
pins are fine though?
<PaulFertser>
aiyion: yes
<aiyion>
25V 100uF?
<aiyion>
Is that like an upper limit?
<rsalvaterra>
\x: I'm interested in recovery features, not overclocking, to be honest. The factory u-boot only installs signed images, which is a pain to recover when something breaks in OpenWrt.
<aiyion>
"a capacitor's voltage rating is not the voltage that the capacitor will charge up to, but only the maximum amount of voltage that a capacitor should be exposed to and can store safely."
<PaulFertser>
aiyion: I'd try it, why not
<aiyion>
this one does have short and long legs; the long was + iirc...
<PaulFertser>
aiyion: it should have big minus sign near one of the legs
<aiyion>
which marks the leg I'll hook up with vss.
<aiyion>
on it.
pmelange1 has joined #openwrt-devel
pmelange1 has left #openwrt-devel [#openwrt-devel]
<rsalvaterra>
gch981213: Building a new image with your patch and once again disabling CONFIG_PRINTK…
<aiyion>
PaulFertser: thx for electrical engineering 101. Same image twice in a row.
<rsalvaterra>
gch981213: So far, so good! 128 MiB detected. :)
goliath has joined #openwrt-devel
pmelange has joined #openwrt-devel
FLD has quit [Ping timeout: 480 seconds]
FLD has joined #openwrt-devel
<PaulFertser>
aiyion: :) glad to hear :)
pmelange has left #openwrt-devel [#openwrt-devel]
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
<mangix>
rsalvaterra: do it
<hurricos>
kerneltoast: thank you for telling me how software rate control can be achieved in mediatek's most recent mt76 chips :^) I was wondering about this for a while
<hurricos>
with minstrel-bleues being mainlined very soon this is very promising ....!
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Slimey>
ah
<Slimey>
ready to submit pr soon
<hurricos>
aiyion: vbindiff helps. You can also script something pretty simple; read the file 10 times, chunk it into 4k blocks with e.g. split, then pick the most frequent 4k block out of all 10 for each chunk adn stitch thsoe together
<aiyion>
hurricos: thanks, got it working about two hours ago :)
<aiyion>
Using 1k chunks and a small python script worked as you just described.
<aiyion>
The better solution (which will help me reliably flashing the stock image back onto the router as well) was to add a capacitor between vc and ground..
<hurricos>
aiyion: `for file in $list; do hexdump $file | sed 's/ /\t/' | tr -d ' ' | sed "s/^/$file\t/" ; done | sqwrap -o test.db -d '\t' -n chunks`
<hurricos>
(for a copy of sqwrap, it's just sqlite .import with clearer flags)
<hurricos>
oh
<hurricos>
lol
<aiyion>
^^
<hurricos>
or you could use Python :D
<hurricos>
I should learn Python ._>
<hurricos>
I think the Unix way may be ah, less relevant these days.
<hurricos>
lol
<aiyion>
pft ^^
<hurricos>
otoh I do medical data conversions using those two tools in the .tar.gz linked
<hurricos>
nothing like ingesting 60GB of Allscripts encounter XMLs into a SQLite database and parsing >1K/second of them with `parallel` :D
<aiyion>
:D
<hurricos>
but :coughs: kind of overkill.
<hurricos>
oh and I forgot a header for the table anyhow.
<hurricos>
not to mention the statistical issues of using 16B chunks rather than 1024B ones. There's probably a way to get hexdump to format that correctly
<hurricos>
.... anyways,.
rua has quit [Ping timeout: 480 seconds]
<hurricos>
I dream of the day that by some magic
<hurricos>
OpenWrt becomes the only serious distribution to target manycore SPARC machines
<hurricos>
radiation somehow kills most computers
<hurricos>
but I still need to do data conversions and I end up ...
<hurricos>
nah, semaphores would kill that off before I even start
rua has joined #openwrt-devel
<kerneltoast>
hurricos: huh, minstrel-bleues changes tx power too... is it for environments with lots of neighboring interference?
<hurricos>
it should be for any environment. It just gives the rate control algorithm another variable to play with
<hurricos>
ath9k chips already decrease power at higher rates.
<hurricos>
However, they only have a fixed number of tx power buckets, and they don't allow the rate control algorithm to manage tx power
<hurricos>
or, sorry. The *driver* doesn't enable that I should say
<hurricos>
the closest thing you can do to minstrel-bleues right now is to manage the correspondence between MCS index and txpower
<kerneltoast>
but you still can't change the AP's tx power to each individual station
<hurricos>
I'm not sure whether capping tx power in wireless.wifi-device caps the whole curve or just limits the maximum
<hurricos>
right
<hurricos>
not with that correspondance anyhow
<hurricos>
you should be able to with minstrel-bleues. Although I'm still not 100% sure there
<hurricos>
I'd think the PAs would need a little more time to modulate.
<hurricos>
But I guess they already do modulate when they swich rates?
<hurricos>
(for different stations).
<hurricos>
I'm not an RF engineer ;^)
<kerneltoast>
rate control really is a lot of voodoo
<hurricos>
I also can't find the source I saw minstrel-bleues getting mainlined ._.
<kerneltoast>
hurricos: btw, if you're in the US and you use DFS, you can get access to a little higher tx power by updating your regulatory database to the latest master
<hurricos>
oh I don't need high tx power :D
<hurricos>
the MR16 tx chain for 5GHz is pretty weak -- after hacking in some changes using rsa9000/atheepmgr, the tx got pretty badly warped by higher transmit power at fastest rates
<hurricos>
(For our outdoor mesh)
<hurricos>
and for indoors, we already have great density in our big concrete building, which we're going to be dramatically improving soon anyways.
<hurricos>
I have half a mind to dig through and see if I can *reduce* tx power. I'll probably set up 11r and limit the lowest rate
<kerneltoast>
wow, i didn't know 802.11n APs were still sold
<hurricos>
thanks, though. Because of how nice auc is, we do plan on sticking very close to openwrt snapshot
<hurricos>
They're not.
<hurricos>
They are, however, recycled.
<PaulFertser>
kerneltoast: belkin rt3200 is 802.11n on 2.4 GHz.
<kerneltoast>
$30 for MR16 off amazon
<hurricos>
we pay ~$2
<hurricos>
we'll be upgrading as soon as we can do thorough testing on ath10k, but until then, we get decent rates
<hurricos>
we pay closer to $15 per unit for the outdoor enclosure versions (MR62 / MR66)
<hurricos>
MR16 is EOL, MR62 and MR66 will be EOL in 2 years as far as I know
<hurricos>
they all share
<kerneltoast>
PaulFertser: seems like it's 802.11ax
<hurricos>
... they all share a motherboard footprint, sorry.
<PaulFertser>
kerneltoast: on 5 GHz it is. On 2.4 GHz it is not.
<kerneltoast>
but only 2.4 GHz is quite cruel
<kerneltoast>
ah it has 5 GHz
<kerneltoast>
i was thinking of APs that only had 2.4 GHz with 802.11n
<hurricos>
we find that at long distances, 11ax / 11ac don't really make a difference unless you're using directional antennas; and that when your only access is through wireless, ath9k stability trumps all
<hurricos>
still, the tx power on these radios is kind of sad ;(
<kerneltoast>
ath9k was from the golden age of wireless eh
<kerneltoast>
meanwhile ath10k has been quite unstable in my experience
<hurricos>
Yeah. I guess, whenever I feel impatient with the folks working on the bleeding edge with the next set of drivers to carry the torch -- mt76 -- I remember how long it took ath9k to get where it is.
<kerneltoast>
mt76 works alright-ish OOTB for me, but I've been finding and trying to slowly chip away at issues
<hurricos>
it's unfortunate otoh that mediatek isn't moving as quickly as atheros did w.r.t. getting client vendors to use mainline
<hurricos>
though maybe I'm misremembering / wasn't around for that type of thing.
<kerneltoast>
i guess hardware these days is complex enough that getting everything perfect in the driver is a bit of hopeful thinking
<hurricos>
perhaps. Still, ath9k did everything without firmware
<slh>
aparcar: also have a look at the Velocloud EDGE 5x0 series and the roqos core rc10
<slh>
all of those should be x86_64 and faster than the APU2, some with more ports, some with mini-PCIe slots (e.g. the sophos ones)
<aparcar>
slh: thanks
<aparcar>
APUs are just something I used in the past and they are reasonably cheap, I'll check out the alternatives you mentioned
<aparcar>
thank you
<aparcar>
test
shibboleth has joined #openwrt-devel
<slh>
some of the small form factor business PCs might also be an alternative (haswell or newer, for power consumption reasons), e.g. Lenovo ThinkCentre E73 SFF or corresponding Dell/ HP stuff
<slh>
especially the velocloud stuff can be cheap, as afaik the cloud stuff went bust and the devices are 'useless' now (but x86_64)
<mrkiko>
hurricos: but 11ax can also be used at 2.4 ghz or am I wrong? Did you try it out? What's the experience?
<slh>
mrkiko: 11ax also improves and covers 2.4 GHz, the speedup is noticable, but obviously more limited than on the 5/ 6 GHz bands (interference) - still, it's the first significant improvement sonce 802.11n
<mrkiko>
slh: what speeds can you reach in general, approximately? I can't try since I do not have AX devices to use as clients. Unless I use a router as client
<slh>
that depends a lot on your environment, but 300-400 MBit/s netto bandwidth is achievable
<Grommish>
rsalvaterra: ping
<rsalvaterra>
Grommish: Pong
<Grommish>
rsalvaterra: Any experience with UEFI bios hacking?
Borromini has joined #openwrt-devel
<rsalvaterra>
Not really… what do you want to do?
<mrkiko>
slh: thanks!!
<Grommish>
rsalvaterra: I've unpacked and exported a efi body, made the changes I need to in the hex (removing a wifi mpcie whitelist on a lenovo).. but, I'm not sure how to re-insert it and then repackage the .ROM :) I figure, the chances of someone here knowing something is pretty good,and you in particular, go into the obscure :D
<mrkiko>
dangole: trying out the new mt7530 setup on the RT3200 :D
<rsalvaterra>
Grommish: You know Lenovo firmware is usually signed, right? :/
<mrkiko>
Grommish: if ony you could use the trick available with some Sierra Wireless modules where you can kinda convince the module to enumerate later, if I understoodthings right
<Grommish>
rsalvaterra: Well.. It's for a buddy of mine, and the levono forums are full of poeple saying I can do it,and when I checked the file, it popped 100/100 on virustotal and any.run laughed at it
<Grommish>
err saying THEY could do it.. and sent him a file
<Grommish>
I really don't want to do the SPI flashing route because he's 2000 miles away :D
<rsalvaterra>
Grommish: My dad's laptop is a B51-80 and I'm stuck with exactly two possible Wi-Fi cards for it (Intel and Realtek). You can imagine how pissed off I was when I found out about it.
<Grommish>
mrkiko: The sad thing is, the Whitelist can be turned completely off by changing two 01 to 00's.. it's arbitrary and in a bios from 2015, it's stupid to have
<Grommish>
rsalvaterra: I can show you HOW to turn it off, if you could tell me how to get it back onto the chip
<Grommish>
rsalvaterra: It removes the whitelists completely
<dangole>
rsalvaterra: lol, i just popped an Intel AX200 into my 10 years old Dell Latitude E4310 laptop my gf is now using, and it works nice :)
<rsalvaterra>
dangole: I can pop in whatever I want in my mom's 11-year-old laptop too, as long as it's mini-PCIe… :)
<Borromini>
dangole: how's the battery on that one? :P
<rsalvaterra>
Grommish: Right, the problem is getting the data back into the chip. You need to program it externally. :(
<dangole>
rsalvaterra: power consumption being higher than what is provided on the socket may still be an issue, the MT7915E module didn't work in the Latitude for that reason...
<rsalvaterra>
An MT7921 might… ;)
<dangole>
Borromini: i've replaced it about a year ago (with noname replacement from ebay) and now it's good now for 2-3 hours when fully charged. not bad for a EUR 15 investment.
<Grommish>
rsalvaterra: Bugger all...
<Borromini>
dangole: nope. always a bit of a lottery with replacement batteries... my XPS 13 one gave up after like 4 years
<rsalvaterra>
Even my Eee PC 901 has an 802.11ac card (crappy RTL8821AE, but works fine). Ironic, considering its Ethernet connection is 100Base-T. :)
<dangole>
Borromini: i'm not expecting that one to get as old as the original one ;)
<Borromini>
:D
<Borromini>
i called Dell, figured they'd be able to sell me one still since the device was from 2016... nope.
<Borromini>
'aftermarket solutions are available sir'
<Borromini>
o_O
<Borromini>
consumer stuff eh...
<mrkiko>
Grommish: I can understand the frustration. Sorry about it. Things like SIM locks. Don't make me think about it.
<rsalvaterra>
Grommish: That link hygiene, though… :P
<Borromini>
*and* a TL-WR1043ND v2
<Grommish>
rsalvaterra: I fixed it
<Borromini>
what has been seen...
<rsalvaterra>
Ah, noticed now. :)
<Grommish>
rsalvaterra: and I felt the right amount of sham
<Grommish>
I promise!
<Grommish>
*shame
<mrkiko>
dangole: what do you think about the new Bana PI R3?
* enyc
meeps
<mrkiko>
enyc: what does "meep"ing mean?
<mrkiko>
sorry if the question is stupid, I'm not native speaker
* Borromini
feeds enyc
<Habbie>
mrkiko, it's just a sound that enyc makes whenever they appear
<rsalvaterra>
mrkiko: Oh, no. Another A53 design.
<mrkiko>
Habbie: :D :D
<mrkiko>
rsalvaterra: what's wrong with them? Honest question...
<dangole>
mrkiko: re R3: i haven't seen the pricetag yet. but the platform looks good enough for routing 2.5G to the two built-in 4T4R 6E MACs plus gigE switch connected via 2.5G like it has already been on the MT7622.
<dangole>
mrkiko: the SoC mostly looks like an MT7622 with updated wifi
<rsalvaterra>
mrkiko: State-of-2012-art. In-order CPU. Not exactly fast, these days.
<Borromini>
i suppose it will be rather affordable though for those wanting multigig?
<rsalvaterra>
dangole: Do you have any performance numbers for the MT7622 doing SQM with cake?
pmelange has joined #openwrt-devel
<dangole>
rsalvaterra: i remember people in forums testing that on the RT3200 getting something around 550MBit/s throughput with sqm-scripts. not sure if that was already with packet steering and/or irqbalance or not
<rsalvaterra>
That's about twice the performance of my Omnia, not bad. Still a bit on the tight side to manage my current connection, though.
<mrkiko>
dangole: thanks!
<mrkiko>
rsalvaterra: thanks!
<mrkiko>
rsalvaterra: what do you use in general then?
<rsalvaterra>
mrkiko: Heh. My setup is suboptimal, at the moment. I'm not doing SQM (because I don't have any device able to cope with 500 Mb/s), so I'm just using my Redmi AC2100 with hardware flow offloading.
<mrkiko>
I am then seeing some "possible DNS-rebind attack" from dnsmasq. Why I see messages from PID 1 and then from dnsmasq PID? I see all of them duplicated. Is it because dnsmasq outputs things to stdout?
<rsalvaterra>
Fortunately my connection isn't terribly bloated.
<Grommish>
mrkiko: Are you running Plex?
<mrkiko>
Grommish: no, kinda plain dumb AP setup
<rsalvaterra>
mrkiko: That hapens when dnsmasq forwards a DNS query and the reply is an address a private range, if I'm not mistaken.
<rsalvaterra>
*happens
<Grommish>
I only ask because I see that from my Plex server it it attempts to set a plex.tv dns on my local address for ease of use
<Grommish>
rsalvaterra: *nod* Yep
<rsalvaterra>
Like "I sent a query to a public DNS server and the reply is a private address, WTF?!"
<Grommish>
That is an opion in dnsmasq I believe to allow rebinding private range
<Grommish>
If you need it
<rsalvaterra>
That, however, *could* be valid. For example, if you use AdGuard DNS. Replies from blocked hosts are 0.0.0.0.
philipp64 has quit [Quit: philipp64]
<Grommish>
mrkiko: I looked up an example: Tue Feb 8 21:51:18 2022 daemon.warn dnsmasq[7016]: possible DNS-rebind attack detected: 192-168-200-190.abcdefghijklmnopqrstuvwxyz012345.plex.direct I've always been told it can be safely ignored
<rsalvaterra>
There was even a recent change to dnsmasq to consider :: and 0.0.0.0 valid when --rebind-localhost-ok is specified.
<mrkiko>
thanks a lot Grommish and rsalvaterra ; actually wondering why I see them twice
<mrkiko>
any time, the same message both from pid 1 and from dnsmasq pid itself I guess
<Grommish>
I only ever see one line in my System logs, and that's the one I just pasted.. Maybe you have 2 services trying to rebind?
<rsalvaterra>
mrkiko: Perhaps adding list rebind_domain '/plex.direct/' to your /etc/config/dhcp configuration…?
<Grommish>
rsalvaterra: They aren't using Plex, but it was the example I had handy
<rsalvaterra>
OH.
* rsalvaterra
doesn't even know what Plex is.
<Grommish>
Not sure what service is causing the rebind attempt, or that it sounds like ther are two them since they are trigging on the reload
<Grommish>
Plex is a media server
<mkresin>
Grommish: context?
<rsalvaterra>
Grommish: Ah… I use NFS. :P
<Grommish>
mkresin: You got mis-tagged, I apologize :) It was for mrkiko and somehow you got tagged :/
<mkresin>
Grommish: mkay
<Grommish>
rsalvaterra: Plex allows me to stream to devices and transcode in real time though and do it outside the local network
<rsalvaterra>
It's… closed source!
<Grommish>
rsalvaterra: BUT! I bought into the ecosystem and paid for a lifetime pass a few years ago when it was cheap
<Grommish>
rsalvaterra: So are the movies I pirated, doesn't bother me ;p
<rsalvaterra>
Grommish: Movies are data. It's the code that worries me. :P
<Grommish>
rsalvaterra: See, people say that, and I can agree, except even opensource, I can't go every line.. You've not gone over every line in OpenWrt, you can't have, but we run it anyway
<Grommish>
So, practically, I don't worry about it
<Grommish>
When possible, I use OpenSource, don't get me wrong, but I don't get hung up on it.. I paid $80 for a lifetime Plex pass a few years ago and I'm happy with it
<rsalvaterra>
I'm pretty sure nobody understands every single line of code of any large project. However, I like to read the ones I *do* understand. And maybe even learn about the ones I don't… ;)
<Grommish>
rsalvaterra: Hard-agree, when practical hehe
<Grommish>
But, sometimes, Close is better.. Look at Unraid vs FreeNAS/TruNAS
<Grommish>
While Free/TruNAS is great, it can't compare to Unraid
<rsalvaterra>
I don't do *BSD. :P
<rsalvaterra>
What about OpenMediaVault?
<Grommish>
Dunno.. I've not looked at anything else TBH.. Once I paid, I wasn't going to change.. At the time, Plex was about what there was unless you were doing VLC over SMB
<Grommish>
I've got a QNAP TS-328 and it works decent enough on such a POS machine hheheh
GNUmoon has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
<rsalvaterra>
Holy smokes…!
<rsalvaterra>
I just did wget -q -O - <raw patch mail url> | git am
<rsalvaterra>
This is so neat! :D
Guest135 is now known as xdarklight
danitool has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
eduardo010174 has quit [Remote host closed the connection]
<Slimey>
Grommish what about xigmanas
<Grommish>
Slimey: Never heard of it.. Any good? I'm going to eventually have to replace the firmware on the QNAP device.. I was wondering about OpenWrt hehe
<Grommish>
But I don't have the raw storage to move the data off in order to do that yet
<Grommish>
Slimey: I'll check into it.. It looks interesting! Thanks!
* enyc
meeps
<enyc>
wrong window
<enyc>
mrkiko: see pm ;p
<dangole>
rsalvaterra: Jellyfin is exactly what I was looking for in terms of a good example to use uxc/uvol on OpenWrt: It's C#. Never going to end up in packages feed. but still useful to run on a router. and not too big (40MB xz squashfs).
<Grommish>
dangole: Why wouldn't it end up in packages?
<dangole>
Grommish: because we'd need the complete MONO build stack to generate it from source. and the binary release is linked against glibc (with the exception of x86_64 which is also offered for musl).
<dangole>
Grommish: but with uxc you can just export the container on a buildhost and then run it on OpenWrt as-is, even on a system with limited storage where you couldn't roll-out Docker.
<Grommish>
dangole: My rust-lang package builds out the entire LLVM for a given target, libc and clang
kb1sph has quit [Ping timeout: 480 seconds]
<Grommish>
dangole: I figure I"ll need to split it off eventually into its own package, but for now, it's all baked in
<rsalvaterra>
dangole: I'm starting to think we should stop calling them "routers" altogether. :P
<dangole>
Grommish: that's rust. you and others are putting lots of effort into that and yet, one day we may have it in packages feed. but MONO? i don't think anyone will invest a similar amount of work (if not much worse) into that.
<Grommish>
rsalvaterra: I think of OpenWrt as embedded OS
<jow>
network appliance
<Grommish>
dangole: You could :D If I listened to tell me how unfeasible rust is, I'd have saved a year and a half
<Grommish>
but it wouldn't have been so fun
* rsalvaterra
is having a blast backporting the multigenerational LRU patches to Linux 5.10…
<Grommish>
I will need to package up Intel's hyperlib for Suricata and that's x86_64 only. It doesn't have to be for every target
<Grommish>
I think I'm just exhausted at people thinking something can't or shouldn't be done because someone else thinks it is a bad idea, is all
<dangole>
Grommish: yeah right. so true, maybe some day someone will come along and contribute support for C#/Mono toolchain, just for the fun of it...
<jow>
I think things like suricata, squid, samba etc. should all be containers
<Grommish>
dangole: I don't know rust or any other language
<Grommish>
dangole: I did it because I waented suricata 6, which I';ve also never used
<jow>
on the one hand to ffer better isolation and protection, on the other hand to get rid of the need to maintain dependencies
<Grommish>
Odder things have happened
<Grommish>
jow: I'm game for whatever after I actually get it to work..
<Grommish>
Doesn't matter to me, I don't know enough to have an opinion on it
<jow>
the basic reasoning is just that it probably makes sense to reuse other distro's package ecosystems (alpine, debian, ...)
<dangole>
jow: and with upcoming support for container packages in APK it can even be seamlessly integrated, so doesn't matter if suricata, pihole or Jellyfin are containers or regular packages, for the users it can be the same once we drop OPKG in favor of APK (which I hope we will)
<jow>
instead of redoing all that work yet again
<Grommish>
I've got rust toolchain integration in place for mips64 targets, though I'm still trying to deal with the toolchain settings, then I can upstream the other openwrt tuples
<jow>
to basically serve the niche of the niche
<Grommish>
I don't know if OpenWrt will ever use rust IN the build system itself, but it'll be available.. it has full rustc/cargo support now
<dangole>
jow, Grommish: I can see that in a not too remote future Rust would still make sense to have in OpenWrt core as it's not just high-level bloat like Java, Golang or C#...
<Grommish>
for the native Openwrt tuples (mips64-openwrt-linux-musl)
<dangole>
ie. we may have packages in core written in Rust in future
<jow>
dangole: I'm the wait and see kind of guy
<jow>
I'll probably won't touch rust for another two or three years
<dangole>
jow: you just came up with a language of your own, I'm not surprised you won't touch any additional new languages in the near future ;)
<Grommish>
jow: Assuming I actually get rust-lang complete. Would it be feasible to have the build system generate the toolchaind distros for a given arch that can just be downloaded? Someone asked me about it and I had no answer. Or should it be delegated to on-device?
<Grommish>
err on-build system
<dangole>
Grommish: as it is huge and takes a long time to build LLVM, it may make sense to allow building a separate toolchain tarball which can then be used by the buildbots instead of having to build the Rust toolchain from source every time. we did the same for LLVM/eBPF.
<jow>
dangole: well, I tried to be as close as possible to ecmascript as possible, syntax and behaviour wise
<jow>
not exactly something new, just a useful subset of something existing
<jow>
think of it as a micronode.js
<jow>
while rust establishes entirely new programming and memory management concepts
<Grommish>
dangole: It is and it does :D
<Grommish>
and the way I have it setup it generates distro archives that are installed via an install script
<Grommish>
dangole: 749M Feb 9 14:52 dl/rust-1.58.1-x86_64-unknown-linux-gnu-install.tar.xz <- Host Distro
<Grommish>
43M Feb 9 14:44 dl/rust-1.58.1-mips64-openwrt-linux-musl-install.tar.xz <- Target
<Grommish>
I made it as modular as I could
KGB-1 has quit [Remote host closed the connection]
<dangole>
jow: I started playing with ucode and was wondering if there is a way to read/write to fds from a command somehow. my goal would be to replace uvol (currently shell) with mostly ucode, and for that i have to call lvm and parse the (json) output (currently jshn...)
<dangole>
jow: so system() only gives you the return code.... another way would be to write bindings for libdevmapper, but that's overkill given that systems using that are not that space-constrained and lvm already has a quite nice json API.
<dangole>
Grommish: I'll take a look at the PR in it's current form now, I hope we'll find a way to represent all the different cpu types (esp. 32-bit arm) we support in rust tuples somehow...
<Grommish>
dangole: Oh, easy, I just upstream the tuples
<Grommish>
I may never get them to Tier 2, but Tier 3 is easy enough
<Grommish>
I went that route rather than trying to figure out which openwrt tuple went to which rust internal one
<Grommish>
and I need to update the PR.. I've been slow about it. And, it only supports mips64 and maybe mips
<Grommish>
I don't have anything to test other arches against
<dangole>
Grommish: that's good enough for us, I suppose. We just need some way to build for all 14 ARM 32-bit variants we currently support...
<Grommish>
dangole: Biggest issue with the ARM targets is that OpenWrt doesn't split out ARM/armv5/arvm6/armv7. It's all lumped under 'arm-openwrt-linux-musl'
<Grommish>
I'm hoping to be able to splt them out with rust flags for like vfp and neon support
<dangole>
Grommish: yes, and then we got CPU_TYPE in our target Makefiles and those somehow translate into GCC arguments in include/target.mk...
<Grommish>
dangole: It also pulls FEATURES
<Grommish>
dangole: and CONFIG_ flags are mixed in as well
<Grommish>
it's a right mess
<dangole>
Grommish: i agree :/
<Grommish>
But, if I'm making the tuple defines, I should be able to create it how it needs to be, even if it has to be selective down the line. I'm not sure how that system works yet, and I'm not going to until I get there :D I'll get distracted and mips64 is being a PITA
<Grommish>
but, rust-lang has been receptive to me upstreaming openwrt tuples
<dangole>
Grommish: that's pretty nice and I hope they'll keep helping us getting this to life
<Grommish>
dangole: The first tuple is already in, so the others should be smoother
<dangole>
Grommish: regarding the chaotic situation in include/target.mk: I guess when the first ARM targets hit the tree, nobody really care for them as back then the real thing used to be MIPS or PPC platforms... and compared to MIPS24kc with equal clock those ARMv5/6 variants were really slow... only with bcm27xx it became something you couldn't really ignore any more, just because of it's popularity....
<Grommish>
I will just need poeple to test it, at least the output.., I want to find a rust helloworld with fp instructions to put as a test package, then I can just pump out test opks
<Grommish>
dangole: I can imagine. and I know the chaos it would take to actually fix it properly
<dangole>
Grommish: I have plenty of different ARM boards flying around to test, ranging from ARMv6 (ARM11MPcore) up to ARMv7a, and AArch64 Cortex-A53 and Cortex-A72. Allwinner, Marvell, MediaTek, Rockchip, ...
rua has quit [Ping timeout: 480 seconds]
<dangole>
Grommish: the only MIPS I still got is RBM11G with MT7621 (1004Kc) and they are not doing anything
<mangix>
rsalvaterra: for the omnia, maybe play around with turning off hardware buffers, enabling XDP, and using qosify
<mangix>
maybe that results in faster traffic shaping. Who knows.
<rsalvaterra>
mangix: But, but… I *fixed* the hardware buffers on the Omnia! :P
<mangix>
TBH I don't understand XDP and the interaction with eBPF
<mangix>
speeds it up I guess?
<rsalvaterra>
I think the idea is to be able to run eBPF programs on XDP hooks, but I could be entirely wrong.
<Grommish>
dangole: I will certainly keep that in mind! Thanks :)
rua has joined #openwrt-devel
<Grommish>
the 4 hour compile time slows things down a bit :D