<neggles>
\x / hurricos: the siflower seems to meet or exceed the perf of the MT7621 in my own low-effort testing
<neggles>
it does immediately hang when i try to set 1200mhz though :P runs fine at 1000, haven't tried 1100
<neggles>
also hurricos I can confirm your u-boot patching method for the AP370 works on the AP330, the regex needs to be changed because the default boot command is different but that's it
<NewbNeedsHelp>
Hi all, searching for someone who might be willing to help make a small modification and recompiling a package for me? Thanks
victhor has quit [Remote host closed the connection]
minimal has quit []
rua has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
GNUmoon has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
valku has quit [Quit: valku]
<dhewg>
nbd: yes, that fixed it, thanks!
<dhewg>
but does that mean that qosify didn't work at all before? Because that one "NOT YET" log line was the only visible issue before, qosify itself didn't complain at all
NewbNeedsHelp has quit [Remote host closed the connection]
nitroshift has joined #openwrt-devel
hanetzer has quit [Quit: WeeChat 3.3]
dedeckeh has joined #openwrt-devel
hanetzer has joined #openwrt-devel
<nitroshift>
rsalvaterra, o/
goliath has joined #openwrt-devel
aleksander has joined #openwrt-devel
rmilecki has joined #openwrt-devel
kenny has quit [Quit: WeeChat 3.1]
f00b4r0 has quit [Remote host closed the connection]
<rmilecki>
anyone around with device with U-Boot and working printenv cmd?
<rmilecki>
i'm looking for a binary dump of environment variables partition
mangix has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
pmelange has joined #openwrt-devel
mangix has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
danitool has joined #openwrt-devel
mangix has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
victhor has joined #openwrt-devel
<nbd>
dhewg: it did work, just not with JIT
<nbd>
so it had to run the BPF through the slower interpreter
<rsalvaterra>
nitroshift: \o
<nitroshift>
rsalvaterra, mt7915 cards available on asiarf
<nitroshift>
or was it mt7616?
<nitroshift>
*7916
<rsalvaterra>
Now that I know MT7916 exists, I'd rather wait for them. ;)
<nbd>
MT7916 is dual-band 2x2 though
<nbd>
not 4x4 like 7915
<nbd>
dhewg: pushed the fix, thanks for testing
<nitroshift>
nbd, i've built a x64 router from an old i3 pc, atm using a rtl8822ce wifi card in ap mode. should i get the mt7615 or mt7915 card to upgrade it? no ax clients in the foreseeable future
<Namidairo>
nobody tell him about 7921 /s
<Namidairo>
i wonder if those rz608's would do dbdc
<nbd>
nitroshift: how well is that realtek thing working for you?
<nitroshift>
or should i get an atheros card since these are more common in my country?
<nitroshift>
nbd, it locked up wifi just once in over a week
<nitroshift>
using 21.02.1
<nitroshift>
the rig is still in tests, will build my own firmware to flash it
<nbd>
i think both 7615 and 7915 are fine, so i'd check costs and availability...
<nitroshift>
nbd, unfortunately i could only find them on asiarf
<nitroshift>
that's why i asked about atheros-based cards
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
<nbd>
i'm not very fond of qualcomm chips...
<stintel>
I was going to suggest: if possible, stay away :P
<stintel>
even went for a samsung smartphone to not be sponsoring qca
mva has quit [Ping timeout: 480 seconds]
<Namidairo>
assuming that you're not in a us market then sure that would work
<nitroshift>
Namidairo, i'm in europe
<rsalvaterra>
nbd: I'm mostly fine with 2x2. I mean, I don't have any devices wider than 2x2, anyway… :)
<stintel>
considering anything with the upcoming mediatek flagship smartphone soc, as samsung is a total disaster
<rsalvaterra>
nitroshift: QCA chips are terrible. A lot of effort has been spent to make them "work" reliably, but they're still horrible. There's only so much thrust you can apply to the pig.
<nitroshift>
rsalvaterra, thanks for the imput
<nitroshift>
*input
<stintel>
> With this, all my QCA hardware has been retired to where it belongs: the trash can.
<rsalvaterra>
nbd: And come to think of it, I could just slap two MT7916 cards inside the Omnia and have a 4x4-ish setup. ;)
<rsalvaterra>
(And less PCIe bandwidth-constrained.)
<rsalvaterra>
Is the M7916 dual-concurrent?
<rsalvaterra>
*MT7916
<rsalvaterra>
From this comment in the code, I'd say "yes"… :) /* mt7916 dbdc with 2g 2x2 bw40 and 5g 2x2 bw160c */
<neggles>
nbd: MT7915 comes in 2x2 DBDC and 4x4 SB
<neggles>
from asiarf
<neggles>
different frontend chips, *technically* different baseband but i'd put money on the difference being a handful of efuses and the marking on the package
<neggles>
MT7915AN/MT7975AN (4x4 switchable band) vs MT7915DAN/MT7975DAN (2x2 DBDC)
<neggles>
i'm... sorely tempted to get two of the DBDC cards and shove them in an aerohive AP330. You know, for Science.
<rsalvaterra>
neggles: Me too, for the Omnia. And they already have embedded diplexers, which means less signal loss.
<nitroshift>
unfortunately the transport fee is more expensive than the card itself
hitech95 has joined #openwrt-devel
<hitech95>
jow: ping
<rsalvaterra>
Speaking of which… what's the status of DBDC support in the kernel/hostapd? The wiki says it's unstable (from Q1 this year).
dedeckeh has quit [Remote host closed the connection]
<nbd>
rsalvaterra: 7916 is dual-concurrent, yes
<nbd>
please keep in mind that i have not done any testing with it yet
<nbd>
so i don't know how well it works
<neggles>
DBDC is not exclusive to the 7916 :P though i see 7916 is 3x3:2 which is interesting
<neggles>
that'd fit better in these old 3x3 N APs with dual minipcie cards
<nbd>
it's 3x receive, 2x transmit
<nbd>
so effectively 2x2
<nbd>
only supports 2 spatial streams for receiving, i think
<neggles>
yeah, hence 3x3:2. an interesting decision
<neggles>
seems more aimed at client than AP
<nbd>
well, 7915 has an extra rx chain as well
<nbd>
for zero-wait dfs
<neggles>
h-uh interesting
<nbd>
that feature will soon be supported in openwrt as well
<neggles>
has anyone actually implemented AX on 2.4GHz yet? outside of qualcomm stuff?
<neggles>
where is my cross-band channel bonding dangit
<nbd>
7915 supports AX on 2.4 ghz
<neggles>
not in DBDC mode though
<neggles>
"2x2n+2x2ax DBDC"
<nbd>
cross-band channel bonding is coming with wifi 7
<nbd>
i will be working on mtk wifi7 stuff next year
<neggles>
h-uh. I swear the earlier standards docs for 6/6E were talking about cross-band and discontinuous channel bonding
<rsalvaterra>
Interesting. How does a DBDC card present itself to the OS? Does it expose two PHYs?
<nbd>
yes
<rsalvaterra>
Nice. Makes sense, yes.
rua has quit [Ping timeout: 480 seconds]
ashkan has joined #openwrt-devel
rua has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
rua1 has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
rua1 has quit [Ping timeout: 480 seconds]
mva has joined #openwrt-devel
<arnd>
nbd, blogic: what is your plan for the mainline EN7523 series? I see you post new versions and you have soc@kernel.org on Cc for one of the patches but I did not get any of the others. Do you still plan to have matthias_bgg pick up the series once it's been reviewed?
rua has joined #openwrt-devel
castiel652 has quit [Ping timeout: 480 seconds]
castiel652 has joined #openwrt-devel
rua has quit [Ping timeout: 480 seconds]
castiel652 has quit []
<hitech95>
nbd: sorry to ing you. Any idea about a possible effort in implementing ipv6 for mtk ppe? Original implementation was from blogic, I've tried to understand how it works but its out of my league.
arifre has joined #openwrt-devel
<nbd>
arnd: i don't have a specific plan. i was just asked to pick up bert's work and complete it
<nbd>
what do you recommend?
<nbd>
hitech95: i don't know when i will have time for it
<arnd>
nbd: I would prefer if you work with matthias_bgg to integrate it through his mediatek tree, as he's already familiar with the process of merging code through my soc tree, and the code is closely related. If that doesn't work for matthias or you, I can also take the patches as a series through the soc tree
<hitech95>
nbd: does you think that implementing it would also improve the performance of nat46? I dont actually know if there is a way to process the snat part in HW and the translation in SW. Here in italy Sky have implemented ipv4aas. So far omnly x86 hw can give good throughput... The lack of documentation and the mess of the original BSP make really hard figure out what the ppe is capable of.
<arnd>
the normal process is to have all drivers go through the respective subsystem maintainers (irqchip, clocksource, clk, pinctrl, serial, gpio, ...), but for a new SoC, we have a shortcut that you can collect Acks from the maintainers and I merge it all in a separate branch. For 5.17 there is currently one new SoC family, while the rest of the support gets split up according to subsystems
<arnd>
nbd: if you end up with the split by subsystem for the initial merge, that would mean you need to send all contents for arch/{arm,arm64} to soc@kernel.org, and the rest to other maintainers
<arnd>
and the soc contents would then get split up further to match the cross-platform pull requests I do: dt, defconfig, drivers (drivers/soc, drivers/bus, ...) and soc (the rest of arch/*)
<nbd>
ok. last time i sent everything to linux-arm-kernel and let the to/cc list get filled in by get_maintainer
<nbd>
i will contact matthias brugger
<arnd>
ok
<arnd>
nbd: do you have Acks from the driver subsystem maintainers already?
<nbd>
not for all patches
<arnd>
nbd: ok, then we should target 5.18 I guess, some maintainers are already on vacation, and I'll be gone until Jan 8 myself
<nbd>
i have reviewed-by for the DT stuff and gpio
<arnd>
olofj is going to handle the soc tree while I'm gone, and he can still merge it in the meantime
<nbd>
arm stuff still needs acks
<nbd>
hitech95: need to look that up, i don't remember
<nbd>
bbl
rua has joined #openwrt-devel
decke has joined #openwrt-devel
<arnd>
nbd: I can take all of the arch/arm/ stuff without further Acks, but please add me to Cc to the whole series when you repost (as arnd@arndb.de, not the soc@kernel.org alias)
<arnd>
I think the only thing that needs an explicit ack is the clk driver
<arnd>
I'll just take the oneline drivers/pci/ change without an Ack
<arnd>
nbd: your drivers/gpio patch does not include a Reviewed-by tag, maybe you forgot to add it after the review?
<arnd>
(looking at v8)
<arnd>
nbd: I would also suggest you join #armlinux on libera.chat in case there are additional questions from either side
<rsalvaterra>
aparcar[m]: It's been working for months on my TL-WDR3600 and Archer C6 v2. Even with Ansuel's preliminary DSA work.
<aparcar[m]>
is Adrian here lately?
<rsalvaterra>
I haven't seen him in a while, but I too haven't been here as often as some months ago.
snh has quit [Read error: Connection reset by peer]
<aparcar[m]>
ok
snh has joined #openwrt-devel
snh_ has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
<rsalvaterra>
aparcar[m]: There, my 0.02 €. :)
<aparcar[m]>
thank you
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<rsalvaterra>
stintel: Can't really review the other patches, since they're so specific to the Qoriq target. But they should cause no impact to other targets, for that very same reason, so feel free to add my acked-by, fwiw.
<hitech95>
I've finally managed to create a per protocol renderer in luci for the interface status: https://i.ibb.co/3NhX9pZ/immagine.png Next step is a custom NetDevice to properly show TX and RX data using the firewall stats.
<hitech95>
jow: with the tips you gave me some months ago I finally succedeed, no wI have to figuro out how to render a promose in a modal...
fda has quit [Ping timeout: 480 seconds]
fda has joined #openwrt-devel
fda^ has joined #openwrt-devel
fda- has quit [Ping timeout: 480 seconds]
fda| has quit [Ping timeout: 480 seconds]
fda has quit [Ping timeout: 480 seconds]
<stintel>
rsalvaterra: math emulation is required, neither e5500 nor e6500 have fsqrt for example, musl hardcodes that in asm for ppc64 and causes sigill in e.g. chrony
<rsalvaterra>
stintel: Hm. I thought only the older 32-bit SoCs were missing the fsqrt.
<stintel>
I was just looking into the e5500 vs e6500 kernel config option
<stintel>
the m300 is e6500, m200 is e5500
<stintel>
I downgraded to e5500 for CPU_TYPE forgot the kernel part
<stintel>
I want to avoid requiring 2 different toolchain version if this is ever changed from being source-only
<rsalvaterra>
Right, but do we want to dumb down the M300 to e5500?
<rsalvaterra>
We should probably have two subtargets in the qoriq target, no?
<stintel>
only if really needed
<stintel>
as I explained in cover letter (iirc), the only diff is altivec
<stintel>
and this is checked with hwcap
<stintel>
so I doubt there is going to be a any performance difference
<rsalvaterra>
Yeah, simpler is better. Let's go like this and benchmark later. :P
<rsalvaterra>
Hopefully it won't be such a disappointment as the Cortex-A9 was.
<stintel>
yeah, I'll check your other remarks, downgrade kernel to e5500 like CPU_TYPE and then just push this thing
<stintel>
I'll be travelling soon and want this thing over with before that
<stintel>
lots of m200 on ebay btw
<stintel>
even sub-100 EUR
<stintel>
and someone contacted me off-list, he will focus on getting the musl asm fix right, and the m200
<stintel>
so I can focus on the bsap-3040 afterwards
<rsalvaterra>
<3
<stintel>
but maybe first firewall4 :)
<stintel>
and maybe another shot at the oc200 too
<stintel>
found some more info by diffing 2 different NOR dumps
<stintel>
maybe I can pull of the "patch RSA pubkey in NOR" after all
<stintel>
and I'm actually considering sending the m300 dts upstream to get flamed for doing horrible things :P
<Habbie>
"i couldn't figure out how to patch the key so i bought another one of this device I can't run openwrt on yet" vendors love this one trick
<stintel>
:P
<stintel>
actually, I'm going to leave CONFIG_E6500_CPU, this boots fine on E6500 and if I read the code correctly, using CONFIG_E5500_CPU would result in -mcpu=powerpc64
<stintel>
not -mcpu=e5500
<stintel>
I will improve the commit message
aleksander has quit [Quit: Leaving]
hanetzer has quit [Read error: Connection reset by peer]
goliath has quit [Quit: SIGSEGV]
fda has joined #openwrt-devel
fda^ has quit [Ping timeout: 480 seconds]
yrrips has joined #openwrt-devel
<hurricos>
neggles: great
<hurricos>
neggles: would you mind writing up a function for it and sending me a patch with the function included in the filesystem in the same way as with the ap370's port? :^)
<hurricos>
I'm lazy. >_>
<yrrips>
I bought Ubiquiti's new EA product, UDR (Unifi dream router), their new cheaper trashcan-like router for only $79 with Wifi 6 yada yada. Does anyone know if any progress/attempts has been made at getting OpenWRT running on the device or if there's anything I can do to get it running? Internal photos can be found here; https://fccid.io/SWX-UDR/Internal-Photos/Internal-Photos-5542414.pdf
<yrrips>
Its running some Mediatek chipsets, MT7975AN, MT7915AN, MT7622AV according to the internal photos. I guess the CPU is MT7622
<yrrips>
It's running an ancient kernel from ubnt though ugh
<stintel>
like usual :)
<dwfreed>
those chips aren't uncommon, so porting shouldn't be *too* difficult
<stintel>
mt7622 -> mediatek target, sounds like it should be supportable, I'd check the forum and ML archive to see if anyone mentioned it already
<stintel>
but did they again do 2.4 GHz wifi 4 and 5 GHz wifi 6 ? :/
<yrrips>
So, i'm completely new at this. Tried to read the wiki but I only got more confused. /proc/mtd doesn't have any kernel partitions. it seems to be loaded from a complete squashfs rootfs somehow
<yrrips>
Ops, sorry, used to multiline chat these days
<dwfreed>
I mean the output itself
<dwfreed>
not your failure to multiline
<yrrips>
The recovery is also different from any other ubnt device i've used in the past so, not sure if they messed with that somehow or how they get that to boot
<yrrips>
But recovery is located at 192.168.1.30 (instead of .20) and is a webgui rather than a tftp target
<yrrips>
But I did get the GPL archive from them, which wasnt helpful
<Habbie>
it can be many things but it's never inetd
<Habbie>
oh, did you mean ifnetd?
<hurricos>
Yes, sorry :^)
<Habbie>
ok
<Habbie>
then ignore all i said
<Habbie>
ifnetd certainly contains code to write it
<hurricos>
I was guessing, too. DNS is very important so I'm trying to wrangle down this chain of snakes until I can use dnsmasq for local DNS proxying without risking becoming an open DNS server
<hurricos>
nALtaLEN points out in their final post (https://forum.openwrt.org/t/wiki-dumb-ap-dns-proxy-local/95657/16) that even when following the article, due to the `--bind-dynamic` default dnsmasq option you will still get dnsmasq serving on interfaces / addresses you didn't ask for
<hurricos>
so I just want to follow the chain to get either a locked-down dnsmasq through uci, or to find a way other than /etc/config/dhcp (read: uci-exposed dnsmasq conf options) to control the resolv file
<hurricos>
since I frankly don't want or need dnsmasq running on a dumb AP at all
<hurricos>
I also know editing /etc/resolv.conf is fragile, so
<hurricos>
perhaps the answer is simply to disable dnsmasq then set `ln -sf /tmp/resolv.conf.d/resolv.conf.auto /etc/resolv.conf`.
srslypascal is now known as Guest9071
srslypascal has joined #openwrt-devel
<hurricos>
/etc/resolv.conf's symlink isn't actually changed by anything as far as I can tell
<hurricos>
just the content of the file pointed to by the symlink
<hurricos>
I suppose I already do have a T1042-based thing coming soon :)
<slh>
a m200 sold for 32 EUR a few weeks ago, I was very close to hitting the trigger, but feared the noise factor (and to some extent the power consumption)
<blocktrron1>
rsalvaterra: I'll push the ath79 k5.10 update later
<rsalvaterra>
blocktrron1: Great, thanks! Another one bites the dust! \o/
<blocktrron1>
i couldnt care less about jboot, redboot or whatever boot
<rsalvaterra>
Too many bootloaders… :)
<blocktrron1>
stuff like that is the reason nobody wants to touch device-PRs that touch more than a DTS and two usterspace scripts
<stintel>
slh: I'll measure the M200 for you
<slh>
thanks, always interesting - just got an old ivy-bridge celeron 1037u with 2* e1000e ethernet today (no fan, ~15 watts idle, ~20 watts with the HDD being busy - still testing how far that will go)
<hurricos>
slh: after IVB, celeron TDP drops steeply
<hurricos>
SNB / IVB are notoriously hot
<stintel>
power-up with fan @ max RPM on the M200: 31.3W
<slh>
hurricos: yeah, I know - but that's what I got for now
<stintel>
this is using a Club3D 700W Gold PSU as the PSU that came with the M200 is dead
<slh>
thanks
<hurricos>
I imagine the PSU is sucking at least 5-10W of that
<scappylappy>
stintel knows this already that I have two M200 in Uk. Bought them a few months ago for 20 EUR each. Some recycling firm flooded ebay with no reserve!
<stintel>
wow 20
<stintel>
geez
<scappylappy>
the fan on the m200 is noisy for a domestic environment. Ihave mine with the lid off and the chassis fan disconnected
<scappylappy>
Yep 20 EUR - I have receipts!
pmelange has quit [Read error: Connection reset by peer]
<stintel>
it's now idle at 26.6W
<stintel>
I got 2x M300 for 205GBP
<scappylappy>
the M200 has a heatsink thats way too big for its powerdraw - probably scaled for its bigger sisters
<stintel>
my M200 has a small heatsink
pmelange has joined #openwrt-devel
<stintel>
40x40mm or so
<stintel>
the one on the M300 is 90x90
<stintel>
the 26.6W seems to stick
<scappylappy>
yes - most sellers want three figures but There are a couple of M200 on today for 50 GBP BUY-NOW
<stintel>
this is with cpufreq enabled using schedutil governor
<scappylappy>
I used watchguards when I was in work
<stintel>
I asked for the retired M200's at work but was against policy
<Habbie>
what do they do with them inside policy?
<stintel>
so I bought an M200 off ebay for EUR 150 in May 2020
<stintel>
and 2x M300 for ~ EUR 240 in September 2020 - one of these came with broken PSU
<stintel>
so I took the PSU of the M200 and put it in the M300 with broken PSU
<stintel>
got a partial refund for the broken PSU
<stintel>
oh it was also 50GBP shipping
<stintel>
oh well
<scappylappy>
aghh - thats how you have an M200 - clever
<stintel>
Habbie: there is a partner that takes all retired hardware, ensures the data is destroyed and then sells 2nd hand
<stintel>
anyway they paid me well so in a way they paid for my M200 and M300s ;p
<scappylappy>
If you are time rich like me (being semi-retired) I can afford to lurk on ebay all day bidding at the bottom and hoping nobody notices
<scappylappy>
quite right too that you got a refund
<stintel>
not that great a refund though
<stintel>
but the alternative was to return both M300 :P
<hurricos>
very nice presentation by Marcel Ziswiler about how porting DSA is going.
<stintel>
o_O
<hurricos>
Yes, I know, I know, the closest any vendors will be using is switchdev
<scappylappy>
at work they threw out two M500s before I had a chance to grab them. (They would have been recycled though so someone else got a bargain)
<scappylappy>
actually using DSA properly then
<hurricos>
right, is what I meant :^)
<stintel>
hurricos: damn that presentation is interesting. marvell stuff ...
<hurricos>
almost all switching fabrics are doomed because they were never meant to 'use DSA properly'
<hurricos>
yes, and recent! Sept 2021
<stintel>
I think I would prefer Marvell over Realtek :P
<hurricos>
I can dream of the day VSC75xx starts making its way into real switches
<hurricos>
stintel: <sweating, angsting over decision between two buttons>
* hurricos
stares at "prestera", then stares at "octeontx"
<hurricos>
"can I choose neither, please?"
* stintel
keeps looking for switch with 10GbE PoE-PD uplink
<stintel>
and PoE-PT would also be nice :P
<rsalvaterra>
stintel: I still have my mind set on that ZyXEL. :D
<stintel>
slh: the M300 with original PSU settled down to 23.2W idle - this is without cpufreq as there's an erratum disabling it on the e6500
<hurricos>
stintel: perhaps worth subtargeting
<stintel>
hurricos: nah, I want to avoid that
<hurricos>
ah
<slh>
ipq8074 already takes 20-25 watts doing nothing, so not bad
<stintel>
hurricos: qoriq/generic as pushed to master works fine on both M200 and M300, OpenWrt has CPU_TYPE e5500, kernel e6500, explanation in the commit message that adds the qoriq target, cpufreq is enabled, works on m200, erratum disables it on the m300
<hurricos>
oh
<hurricos>
I completely misread, I thought you said M200 in that most recent message
GNUmoon has quit [Ping timeout: 480 seconds]
<hurricos>
yes, I'd read that bit, that was my (flimsy) understanding that was broken by misreading M200 :^)
<stintel>
once scappylappy or me ends up with an acceptable altivec asm fix for musl ppc64, m200 and bsap-3040 can be added
<hurricos>
ok, good
<hurricos>
thank you
<stintel>
but I needed to get my main router supported in master
<scappylappy>
yep
<hurricos>
:P
<Habbie>
dwfreed, asking this here to not meddle in the #openwrt conversation - uci export network (which is not show, i see that) is as good as pastebinning the file, right? or am i missing something?
<stintel>
also working on firewall4 and every time having to create a build-m300 branch from qoriq + firewall4 branches was really annoying and error prone
<stintel>
yes, my main router is also doing firewall4 ;P
<dwfreed>
Habbie: that is actually fine, yeah
<Habbie>
dwfreed, thanks
<dwfreed>
export is good, show is not so much
<Habbie>
dwfreed, ah, but 'show' (and export, etc.) would show uncommitted, while files show what's active, right?
<stintel>
that's probably my next work, address jow's outstanding comments push to master, bump in openwrt and then push firewall4 support to luci-app-firewall
<stintel>
once that is done, we can switch to firewall4 by default
<Habbie>
dwfreed, i misphrased that maybe, but feel free to answer as phrased :)
guidosarducci has quit []
<stintel>
that and some targets that are not yet on 5.10, are the blockers for branching a new release iirc
guidosarducci has joined #openwrt-devel
<stintel>
so I'll probably work on firewall4 and maybe the octeon memleak now
<dwfreed>
Habbie: yeah, show and export would show uncommitted changes, whereas the files show what's been committed (but not necessarily what's been applied)
<Habbie>
dwfreed, right
<Habbie>
dwfreed, so does that mean that if i uci set a few things and restart some service, it'll honour the -uncommitted- things?
<stintel>
I submitted a patch to nftables this morning I think
<dwfreed>
Habbie: it won't
<stintel>
the devices in the flowtable for flow offloading, cannot start with a digit :/
<Habbie>
dwfreed, ok, the interface used by the helper scripts takes committed stuff?
<dwfreed>
yeah
<Habbie>
ok
<Habbie>
so scripts never use 'uci get', we hope
<stintel>
some do
<Habbie>
ah
<stintel>
git grep "uci get"
<Habbie>
and they would get uncommitted, then
ashkan has quit [Ping timeout: 480 seconds]
<hurricos>
In other news about open-source network operating systems ... anyone hear about Marvell's DENT? https://dent.dev/
<hurricos>
or, sorry. Not Marvell's, it's a Linux Foundation project, but I found them via a Marvell press release about getting Prestera working there.
<blocktrron1>
I'd say marvells image in this channel is pretty DENTed
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openwrt-devel
hitech95 has quit [Remote host closed the connection]
pmelange has left #openwrt-devel [#openwrt-devel]
hanetzer has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
<yrrips>
hurricos: sorry to poke you, but do you have any idea where to start, any resoruces or stuff i could get my hands on to perhaps get openwrt booting?
gladiac is now known as Guest9080
gladiac has joined #openwrt-devel
<will[m]>
hurricos: one thing i've learned from digging into openwrt/linux internals on these sorts of topics is, it doesn't need to reflect reality as long as it works. there's so many drivers out there for example that just look for some magic bits and decide it's all gravy without having any resemblance to the underlying hardware. "this here's a realtek wifi chip!" "no, it just LOOKS like a realtek wifi chip to the kernel..."
Guest9080 has quit [Ping timeout: 480 seconds]
<clayface>
yrrips: looks like three unpopulated UART headers on the board. Might be a good place to start
Luke-Jr has quit [Ping timeout: 480 seconds]
<neggles>
hurricos: I guess I can do that yeah :P in my local tree i've also rearranged the partitions (since this is now effectively a one-way operation) - there was a 14.75MB chunk of flash left unused thanks to the really weird OEM flash layout
<neggles>
yrrips: first thing you'll wanna do is just dump the flash
<neggles>
but yes it's an MT7622AN + MT9715, the ethernet switch is an MT753x-compatible, 2GB of RAM, 128GB M.2 SATA SSD, 16GB of eMMC
<neggles>
and the LCD module is another one of ubiquiti's favourites, one of those 160x80 LCDs hooked up to a USB-equipped STM32
<neggles>
hurricos: the AS4600-54T is a Broadcom Apollo2 (BCM56540) per the Cumulus Linux HCL