<damex>
mrnuke: thanks for adding sg2210p support but i am going to keep my last running sg2210p out of experiments for now. hope it will get some web installation support or something more reliable in the future.
<damex>
i will try to get ews-2910p shipped to vietnam or maybe some Zyxel as Borromini suggested
<Znevna>
why did you order a device with such a risky install method in the first place?
<damex>
Znevna: nothing else is available locally. just tplinks
<Znevna>
is the oem firmware that bad?
<damex>
i didn't think that it would brick on tftp load >_>
<Znevna>
i know it's bad on the lower end stuff, but..
<damex>
Znevna: it is a matter of control and personal preference
<Znevna>
ok
<damex>
i am all for libreboot/coreboot/openwrt/etc on my devices :)
<Znevna>
I'd rather have them functional
<damex>
Znevna: btw stock firmware is pretty decent. functional as you say :)
<damex>
i somehow got one switch locked up on stp configuration but that's pretty much all problems i have had :0
<Znevna>
if you restore the flash content will they run again? :)
<damex>
Znevna: well, yeah. i think so
<Znevna>
but you don't have backups I presume
<slh>
the zyxel OEM firmware for the gs1900 series isn't bad either, although OpenWrt is imho a better option (easy to install as well); only drawback of the gs1900 series is the rather usable small flash size 6976k, but at least there are no different h/w revisions to take care of
<slh>
even rtl839x is a bit for the experimental type of semi-developers, rtl93xx is quite a bit beyond that
<damex>
Znevna: i don't have flash backups but can get a dump from working switch and from a dead one. i thought about building openwrt and installing using soic clip :)
<damex>
comparing zones and overwriting regions on 'dead' should be fine. i wonder if i can get uart output with a customly built uboot
<Znevna>
you have a soic16 clip?
<damex>
Znevna: not yet, waiting for it to arrive
rmilecki has joined #openwrt-devel
<Znevna>
clips are unreliable
<Znevna>
oh well :P
<damex>
Znevna: they seemed to be pretty reliable for libreboot/coreboot installations :)
<damex>
although i got lucky and all of them use soic8
<damex>
all of the devices that use libre/coreboot
<damex>
slh: oh well, so gs1900 it is. i will try to see if i can get some supported hardware
goliath has joined #openwrt-devel
lmore377 has quit [Remote host closed the connection]
<slh>
everything up to the gs1900-24/ gs1900-24e/ gs1900-24hp (not gs1900-24EP!) should be covered and 'easy' by now
lmore377 has joined #openwrt-devel
cbeznea has joined #openwrt-devel
Backhand4630 has joined #openwrt-devel
robimarko has joined #openwrt-devel
<f00b4r0>
slh: any performance "impact" of running openwrt that one should be aware of?
<slh>
f00b4r0: none gs1900 specific, rtl838x works pretty well - but has rather little offloading beyond L2, and not all of the little there is would be implemented right now (particularly I wouldn't vouch for LAG, but I didn't test either); rtl839x and rtl93xx have considerably faster CPUs and more offloading (but only very little implemented right now either)
<f00b4r0>
ok thanks. I have a gs1900, might toy with it then, I'll see
<slh>
the realtek codebase still needs a lot of work, the newer the SOC, the more - but it nevertheless works quite well for the simple cases
<f00b4r0>
my main workhorse is a gs2210 though, and AIUI this is a different beast
<slh>
f00b4r0: the D-Link DGS-1210 revF/ revG have more flash (which helps a lot), but there you have to be really careful to get the right revision (revA/ revB are Marvell, revC/ revD are Broadcom)
<robimarko>
Considering they are pretty much reverse engineering magic writes all over the place its working fin
<f00b4r0>
lol
<slh>
...and I have seen that D-Link seems to push new firmwares this year which might make flashing harder (encryption, etc.)
<f00b4r0>
have to say I don't feel much "pressure" to replace my switche's onboard software: "if it ain't broke don't fix it" is pretty strong there
<robimarko>
You can use the same argument for everything
<f00b4r0>
no
<f00b4r0>
for a router the rationale is quite different
<robimarko>
But once you see the level of "security" on these D-Link switches its crazy
<f00b4r0>
heh, I know. But I don't use my switches in a "hostile" environment, so that's that :)
<slh>
the ZyXEL gs1900 are easy, because you know what you get - and it's supported. the DGS-1210 revF/G are better, but much harder to spot (and I won't couch at all what happens if they got migrated to the latest OEM firmware)
<robimarko>
slh: I would guess that bootloader replacement might be needed
<slh>
the ZyXEL OEM firmware is quite decent, the D-Link one is... well... last century, and not in a good way
<slh>
robimarko: no reason why the upgrade might not change the bootloader - I just stopped looking any further, as the update info made me very concerned
<f00b4r0>
slh: I agree. D-Link is abysmal
<robimarko>
slh: Cant be sure, but I think I upgraded my F2 revision to that FW that claimed to encrypt stuff
<robimarko>
And then flashed OpenWrt without an issue
<robimarko>
It wasnt through the WEB UI though
<slh>
robimarko: Fw 7.30.xxx from early March 2022 is the one that concerns me
<slh>
7.20.xxx should be fine
<robimarko>
slh: Wait, where are you finding the v7 FW
<robimarko>
And they have provided 2 binaries, one old .hex
<slh>
and yes, 7.30.xxx updates the boot code from 1.01.001 to 1.02.001
<robimarko>
Same here
<robimarko>
You must flash it using the non encrypted and then later version will be encrypted only
<mrkiko>
robimarko: hi!!
<robimarko>
mrkiko: Hi
danitool has joined #openwrt-devel
<rmilecki>
Znevna: hey, I'm here (IRC) too, please ping me about TRX next week
<rmilecki>
Znevna: i've few more really busy days this week
<Znevna>
rmilecki: thank you!
<Znevna>
I'm trying to add stuff from the other targets in mt7621.mk but I don't know very well what I'm doing there :P
<stintel>
aiyion: sorry, I don't, didn't try very hard either, iirc the u-boot is password protected
<aiyion>
good day everyone
<aiyion>
stintel: a passowrd you do not know either?
<aiyion>
*password
<stintel>
nope
<stintel>
as it's only 4 screws to reach the SD, that was the easier option
<robimarko>
Any chance U-boot source is provided?
<stintel>
I'd have to check the dump
<stintel>
the link should be somewhere in the channel logs if people are impatient :P
vicencb has joined #openwrt-devel
<aiyion>
I've got one other problem to solve, before I can get back to the m300.
<aiyion>
In our package Makefiles we have spaces in before e.g. the fields `TITLE` and `DEPENDS`. Most makefiles I've seen are tab indented, and I don't get it, why are tabs invalid there?
<oliv3r[m]>
If I want to change the loadaddress and entry adddress, what many magical places is this being configured in? I see it in the target specific image/Makefile and the Platform file, but there must be more, because if I change them (in sync) it does not work at all :(
<karlp>
aiyion: tabs are for rules, not definitions, aiui. "just accept it"
<aiyion>
mhm, got it.
<aiyion>
So if one wre eager to get rid of mixed indentation in makefiles that would only work by omitting the spaces alltogether, as indenting with tab is always a recipe-line
<aiyion>
But removing the spaces would likely impair readability.
<karlp>
... how I learned to stop worrying and love the [insert wonky thing of the day] basically... :)
seer has quit [Read error: Connection reset by peer]
<aiyion>
Well then. Back to the m300's u-boot disaster -.-
<mrkiko>
aiyion: sorry if I already asked and maybe lost your reply - was curious if you had any progress with the MT3000
<mrkiko>
*MT2500, sorry*
<aiyion>
mrkiko: I've been pretty busy at work the last days, sorry. Cleaning up gluons codebase was about all I've done for related projects in the last days.
dangole has joined #openwrt-devel
<aiyion>
stintel: with both screen and minicom I run into trouble setting wgBootSysA
<aiyion>
pasting spaces appears to introduce problems, but I do not understand how.
<aiyion>
e.g. pasting setenv OpenWrt_kernel watchguard_firebox-m300-fit-uImage.itb
<aiyion>
after chaning console cables, I changed laptops, now it works flawlessly.
<mrkiko>
aiyion: is the console an RJ45-style, RS232 or soldered otherwise?
<aiyion>
rj45 to usb
gladiac has joined #openwrt-devel
<aiyion>
the m300 has an rj45 jack as console port.
<aiyion>
stintel: there were quite some fixes for the m300 in the past months, but nothing was backported to 22.03, rendering the device quite useless on that release; how much pain would it be to backport changes there?
<stintel>
aiyion: ehm, afair most changes were backported
<aiyion>
mh. maybe I'm jsut reading github wrong
<aiyion>
maybe github just fails to detect, which were backported.
<stintel>
that frm fi is irrelevant because 5.15 is not used in 22.03
<aiyion>
mhm
<stintel>
same for the 5.15 support and later switch to that by default
<dwfreed>
github won't show tags on commits on master because the backport commits are different IDs because they're cherry-picked
<aiyion>
one sec, found an interesting error, I think.
<aiyion>
dwfreed: +1
<stintel>
led, button, watchdog backported
<stintel>
etc
<dwfreed>
did not continue messing with it; need to get a microSD card for it, and won't have time this week
<aiyion>
When I send mesh traffic to the ports I hit a bunch of error message
<robimarko>
Did procd ever get support for multiple watchdogs?
<mrkiko>
robimarko: not as far as I can tell
<stintel>
aiyion: problem is that fman userspace requires the fsl kernel, doesn't work with the fman driver in mainline
<dwfreed>
oof
<stintel>
maybe we can change that warning to notice or info
<stintel>
because as said it appears harmless
<aiyion>
and that is just an unrelated sideeffect, or the reason why meshing via batman-adv does not work?
<stintel>
I'm running dual M300 for >1y
<aiyion>
meshing does not work with the device (at least in OpenWrt 22.03)
<aiyion>
and I can trigger these fsl_dpaa_mac Error messages by plugging the cable that connects another mesh router.
<stintel>
never used batman-adv
<stintel>
but seeing the amount of messages you get and what you just wrote suggests it is related
<stintel>
reading again what I wrote in the cover letter, it also makes sense, fman probably has no clue what those batman-adv frames are
<aiyion>
Except I understood, fman warns a lot about frames whose headers it does not recognize, but I do not understand why that would have an impact on meshing, yet.
<stintel>
maybe it drops those frames entirely
<robimarko>
Does fman use some kind of FW?
<stintel>
yes
<aiyion>
mhm
<stintel>
mtd8: 00010000 00010000 "qoriq-fman"
<robimarko>
Well, that would explain it
<aiyion>
can I tell it to leave stuff alone, it does not understand?
<robimarko>
Also, I would expect that they made the FW board specific?
<stintel>
04|14:41:36 < stintel> aiyion: problem is that fman userspace requires the fsl kernel, doesn't work with the fman driver in mainline
<aiyion>
I think it was referenced in your linux patch.
<oliv3r[m]>
<slh> "/v-e-r-y/ experimental for now" <- RTL83xx is quite experimental, but also works quite well :) I have the xgs1010-12/xgs1210-12 (which is rtl930x based) and overal I can make it work. I'm currently using it as development platform to improve things though, which is a lot tougher :)
<stintel>
oliv3r[m]: did you test routing performance by chance?
<robimarko>
stintel: You arent gonna want to use it for routing
<robimarko>
Perf is quite low
<oliv3r[m]>
the hardware supports L3 routing afaik; but with software routing, we're at 170Mbit potentially
<oliv3r[m]>
but not all L3 routing stuff has been implemented, so right now, it's a L2 switch; where L3 could be added in the future, the hardware suports it
<robimarko>
Thats on RTL930x?
<oliv3r[m]>
yeah
<robimarko>
Ok, cause RTL83xx aint going near that
<oliv3r[m]>
master sits at ~143MiB/s in iperf3 tests, but with my wip branch (broken atm) i can get 173 MiB now :)
<stintel>
aiyion: so the code suggests it's actually a receive error, so yeah probably the packet doesn't go further up the network stack
<aiyion>
wireshark says the router is capable of sending batman frames.
<oliv3r[m]>
btw, robimarko I figured out the instability/lack of output during load. Musashino's patches are not atomic, so genmips uses different load addreses, and that patch sits somewhere later in his queue. Only spotted it by going over it 1 patch at a time too see if/where his branch would break :S
<aiyion>
stintel: any idea how I would mitigate that?
<stintel>
aiyion: nope, sorry
<stintel>
well, aside from messing with the fman userspace utility but as I said that doesn't work with the vanilla driver
<aiyion>
I don't fmans role yet. It appears like a door bouncer that does not leave packets thorugh because it does not recognize them properly, but I can not tell it to either go away, or tell it what expected packets look like, from mainline linux.
<aiyion>
*don't understand fmans role
<stintel>
fman is rather vital for having network connectivity on this device, you can't tell it to go away
<aiyion>
So fman is not the bouncer, but the door packets get through.
<aiyion>
wo fman has somewhere a hardcoded list of recognized headers it knows how to work with?
<aiyion>
or would that be configurable by the userspace tool
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<f00b4r0>
aiyion: fwiw I'm running 22.03 on my m300 so I do ensure that relevant patches *are* backported :)
valku has joined #openwrt-devel
<stintel>
aiyion: my guess is that it would be configurable via the userspace tool, but as it doesn't work with the mainline driver, I cannot confirm that
<robimarko>
So, they upstreamed a driver
<robimarko>
That works if you are lucky that your protocol type is supported
<robimarko>
stintel: You remember the error you had with userspace?
<damex>
is there a way we could add something with RTL8370N as in managed entry level tplinks?
<damex>
or there is usually not enough ram/storage to do so?
<oliv3r[m]>
robimarko: where I'm stuck on right now, is with the opposite, I want to migrate our current setup to the new addresses, (see https://github.com/openwrt/openwrt/pull/11689) but it doesn't work; but I don't understand why. Must be stored somewhere not-obvious/duplicated, but grep isn't finding it ...
<stintel>
robimarko: it doesn't build :)
<stintel>
I actually did manage to get it to build by adding a bunch of defines via kernel patch, but not finding the branch I kept this work in
<Znevna>
damex: RTL8370N has a tiny 8051 MCU
<robimarko>
stintel: Now that would a fun exercise to get working
<oliv3r[m]>
I have an RTL8370N as a switch right now actually :) I use it to do POE of my wifi; wanna replace with with a RTL838x one once it drops to ~€100 tp-link-jetstream-tl-sg2210mp specifically :)
<robimarko>
stintel: What HW is in M200?
<stintel>
robimarko: t1042 iirc
<Znevna>
oliv3r[m]: maybe you want to stay away from tp-link switches, damex bricked two trying to flash them
<aiyion>
robimarko, stintel I've got a device here we could test on if we were to try fix it.
* mrkiko
wonders why on the google onhub device, booting secondary cpu(s) fails...
* aiyion
is afk for 2h
* f00b4r0
has a google onhub lying around somewhere
<f00b4r0>
was given to me for hacking purpose, but the whole "switching to dev mode" shebang gave me pause
<oliv3r[m]>
@damex
<oliv3r[m]>
damex: ohh that's very cool; as I'm after the 'mp' variant :) Why do you think it's bricked? Did you try a flash programmer?
<oliv3r[m]>
damex: is u-boot still functional? My first bet would be to try to replace the bootloader with a source-based one. I've built one for the rtl930x and removed/fixed some stuff. I wonder if we can use the same source-code to build for your switch...
<stintel>
seems to suggest you can define custom protocols
<stintel>
etc
<mrkiko>
f00b4r0: :D :D is this device better in performance term than the Netgear R7800?
<f00b4r0>
mrkiko: which, the onhub? I have no idea. It's supposed to be quite capable and has zigbee connectivity (even though it was never used / advertised AIUI), which may interest some
<damex>
oliv3r[m]: for now it is bricked. u-boot should be functional but it is not outputting anything while working 'kernel' could not be loaded. currently if one load initramfs or sysupgrade image from tftp as described in commit - you get errors about not being able to find kernel image or bad header checksum https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/2223?u=damex
<damex>
i don't have soic16 clip to recover (it is on the way) so there has to be a better way to do installs on that tplink devices
<damex>
maybe me or someone else could cookup some image build to flash over soic16 clip :)
<damex>
or maybe someone find a way to flash over webgui
<damex>
oliv3r[m]: is it patched up vendor u-boot or is it upstream u-boot that you did use for rtl930x ?
<oliv3r[m]>
damex: it's gpl drop from realtek (I don't think zylinx modified it) long term goal, is to migrate to upstream, but for that, I need my SOIC socket that I still have to order. I will also get the same switch you had, but the MP (PoE) variant, to replace my dlink rtl8370n based switch :) so i deff. have interest in all of this. BUT, nearly no time :(
<robimarko>
mrkiko: I would guess same thing as on the ipq40xx chrome subtarget
<robimarko>
They used some ancient/broken SCM implementation
<damex>
oliv3r[m]: better get that tplink 'while it is hot' and they didn't start to cheapen out on component :) i notice that 3.20 'lacks' some components on board compared to 3.0 :)
<Znevna>
so not better
<Znevna>
:<
floof58 is now known as Guest248
<robimarko>
Its TP-Link, you never know whats the actual revision
floof58 has joined #openwrt-devel
<robimarko>
Let alone if revisions even use the same HW
<damex>
robimarko: well, they were consistent with tl-sg2210p and use realtek (same?) exclusively :)
<robimarko>
I am talking in general about TP-Link
<damex>
well, sure :)
<robimarko>
They have some nice HW, but they have started to put encrypted FW
<robimarko>
Bootloaders that are stripped and only boot signed FW etc
Guest248 has quit [Ping timeout: 480 seconds]
<f00b4r0>
which brings the question of "who to turn to to consistently get openwrt-friendly hw" ;P
<Znevna>
asus! :P
<robimarko>
Pretty much nobody is consistent
<robimarko>
But yeah, Asus and Netgear appear to avoid pulling crazy stuff
<robimarko>
Linksys/Belkin also are usually reasonable
<Znevna>
If we can figure out the trx file for ax53u I think it will be flashable via webui
<Znevna>
as I don't think the fw is signed on ramips targets
goliath has quit [Quit: SIGSEGV]
<damex>
robimarko: gl.inet ? :)
<damex>
or that is bad too ?
<robimarko>
Used to be easy when they used all of the platforms that were already supported
<robimarko>
No idea how their new stuff is
<damex>
robimarko: does encrypted part happen only for wireless-enabled products?
<robimarko>
Looks like it so far
<f00b4r0>
my understanding is that we have the FTC to thank for that?
<robimarko>
They are doing it on CN only stuff as well
<robimarko>
Just look at the Filogic router they have
<f00b4r0>
well I guess it's easier to do it for everyone
<robimarko>
They had to completely replace ATF+U-boot just to be able to boot custom stuff
<damex>
more devices to test the same configuration on - easier to maintain provision :)
<stintel>
aiyion: I'm tempted to have a go at implementing what's needed for fmlib/fmc to work with the vanilla kernel fman driver, but I'm forcing myself away from the computer for my 2w holiday
<stintel>
I broke that after xmas and this resulted in some kiddie impersonating me (and others) on irc, mailing list
<stintel>
so I'm gonna try not breaking that again :P
<aiyion>
Take all the time you need, I won't be running away and neither is the m300.
<stintel>
pretty soon it's going to be back to 80+h per week behind the computer so yeah, taking some rest this time ;)
wigyori has joined #openwrt-devel
<stintel>
wigyori: hey what's holding back the risc-v target?
<stintel>
I now have aside hifive unmatched also visionfive starfive 2
<stintel>
would be nice to see that land before we branch a new release (which iirc from last meeting we want to do relatively soon)
<stintel>
right
* stintel
away from computer lol
<aiyion>
^^
<Slimey>
a lot of risc-v talk these days :P
<wigyori>
stintel: about a day to finish it off - definitely want to do that before fosdem
<wigyori>
and talking about visionfive, there is a target for that too, with my vf2 at the post office ;)
<wigyori>
so essentially, "not much", just need to clean up things
<robimarko>
It opened up an interesting MAC assigment discussion
floof58 is now known as Guest259
floof58 has joined #openwrt-devel
<Znevna>
which will obviously be declined
<robimarko>
I agree
<robimarko>
Allowing to assing MAC-s or generate them opens a whole new can of worms
<Znevna>
yup
<robimarko>
I get his issue, this has only floated post DSA conversion but we cant go and assing MAC-s that are maybe already assigned to other devices
Guest259 has quit [Ping timeout: 480 seconds]
<dwfreed>
robimarko: he's using LA MACs, though
<dwfreed>
so the odds of collision are on the order of 2^-40, and in practical applications actually 0
<robimarko>
I get that in this case
<robimarko>
But, that really opens a door for all kinds of PR-s
<robimarko>
Cause, what is special about this board?
<Znevna>
i'm gonna open PRs for all my devices :P
<robimarko>
Whole target is the same, only MTik AFAIK actually assigns per port MAC-s
<Znevna>
not on OpenWrt sadly
<Znevna>
ah wait
<robimarko>
Cause, it wasnt possible when the devices were added
<Znevna>
i didn't check ipq40xx
<robimarko>
As far as I remember, hAP ac2 and ac3 had per port individual MAC-s
<robimarko>
Let me power up hAP ac2 that I have on PoE switch to see
<Znevna>
probably easier to check the dts file
<robimarko>
Nope
<robimarko>
As MAC-s are read from hard_config during runtime
<dwfreed>
robimarko: a similar approach can (and honestly probably should) be used for all devices that support it
<robimarko>
dwfreed: Thats at least any ipq40xx device that has more than 2 ports
<robimarko>
Znevna: Yeah, in ROS ports have ascending MAC-s
<robimarko>
blogic: As long as they dont catch you
<blogic>
robimarko: lol
<blogic>
dunno if I can run that fast
<robimarko>
blogic: Since you are here, did you ever get that reboot issue sorted
<blogic>
yes
<blogic>
CONFIG_QTI_CTXT_SAVE
<robimarko>
That sounds vaguely familiar
<blogic>
so basically when the qsdk oopses, it gathers data and puts it into smem
<robimarko>
Oh that
<blogic>
then uboot will try to tftp the crash to some magic IP inside the qca internl network
<robimarko>
BTW, I have been harrasing Kalle to make the regdb.bin public
<blogic>
however if the uboot was built without that feature enabled it breaks reboot
<robimarko>
That is a classic QCA move
<blogic>
/* no comment */ ;)
<hauke>
I do not think the StarFive SoC is intended for mass production, I think they want to sell IP cores to other SoC vendors and this is just a demo to show that their IP core works
<robimarko>
And I guess that defconfig enables is only in certain QSDK versions of U-boot
<blogic>
yes
cbeznea has quit [Quit: Leaving.]
<blogic>
so basically if you run a QSDK X on uboot from Y it will break
<robimarko>
Whenever I think they just cannot mess something up
<blogic>
and reflashing uboot is not an option
<robimarko>
My personal favorite is OSI mode being advertised on IPQ6018 and then when kernel tries to use it your board just hangs until WDT kicks in
<blogic>
robimarko: in their infinite wizdom the are good at finding new ways to break the matrix
<hauke>
I am not working with QSDK, but these stories sound familiar ;-)
<robimarko>
They fixed in newer TZ versions, but there are millions of routers with old TZ
<blogic>
yup
<robimarko>
So, I just add a compatible check to return false as a hack
<zorun>
hauke: interesting
<robimarko>
hauke: Luckily neither am I
<hauke>
zorun: at least SiFive wants to sell IP cores and not chips
<robimarko>
Not at least in a sense of making or maintaing products on it
<zorun>
yes, that is clear (they even sold IP cores to Intel from what I understand)
<hauke>
SiFive is a direct competitor to ARM
<robimarko>
blogic: ansul and me have ilusion that we can rewrite NSS-DRV into a as simple as possible driver
<robimarko>
To just serve as dummy netdev as it offers significant routing improvements
floof58 is now known as Guest262
<blogic>
yup
floof58 has joined #openwrt-devel
<blogic>
NSS is gone in alder
<dwfreed>
would love nss support on my nbg6817
<blogic>
maple was the last silicon with the ubicom32 cores
<robimarko>
What are they using now?
<blogic>
nothing
<blogic>
its all sw path
<robimarko>
dwfreed: NSS-DRV is just the core driver loading the FW and registering a dummy netdev on top
<blogic>
alder has a new DP for traffic
<robimarko>
blogic: So they buffed the CPU
<blogic>
yup
<robimarko>
And implemented a proper networking driver
<blogic>
correct
<robimarko>
Instead of this EDMA v1 crap without checksum offloading
<blogic>
ath12.1 with alder foss support will drop in jan
<robimarko>
Thats nice
<blogic>
no more NSS ... finally
<hauke>
are they able to do 10G with small packets on their CPU?
<blogic>
yes
<blogic>
alder can shift 39.2g over wifi in a chamber under lab conditions
<hauke>
is there no HW QoS or NATengine in the SoC?
<blogic>
those would be MTU frames
<blogic>
hauke: dunno, yet, not seen the code yet
<hauke>
is adler the wifi 7 SoC?
<blogic>
correct
<robimarko>
Its IPQ9574 AFAIK
<blogic>
yup
<blogic>
and eats 500W or whatever
<robimarko>
I am eyeing that Xiaomi 10G router
<robimarko>
Its using IPQ9570
<blogic>
BOM is like 300$ +
Guest262 has quit [Ping timeout: 480 seconds]
<robimarko>
But unobtanium
<blogic>
fun story ...
<robimarko>
Anyway, I am still fighting with upstreaming ipq807x
<blogic>
my neighbours rang the doorbell, they went from DSL to GPON
<blogic>
laptop maxes out at 30mbit but the gpon claims 10
<blogic>
*100
<blogic>
yeah laptop was 10 years old and had 54g
<blogic>
still dont know what joe avg needs 39,2gbit for but hey
<robimarko>
30Mbits out of that is quite good
<dwfreed>
so 30mbit is pretty good for 54g
<blogic>
haha
<Znevna>
30mbit is badass on 54g
<robimarko>
Since theoretically you can get 54Mbits, 30 is great
<robimarko>
blogic: I like how they are all jumping to BE
<hauke>
the US ISPs are corrently compeeting on bandwith, they are all offering 8G and so on. This is a good marekt for sillicon vendors ;-)
<blogic>
robimarko: I have the ath12 qsdk on my network
<robimarko>
Which is still in draft state
<blogic>
I can push 650mbit over a batman mesh using eap101
<robimarko>
I know
<blogic>
its insane
<robimarko>
If its NSS offloaded it just flies
<blogic>
without NSS that is
<robimarko>
So far I got around 700-ish without offloading
<blogic>
as shitty as the qsdk code is, it is really solid
<blogic>
robimarko: yeah on a direct link
<robimarko>
Yeah
<blogic>
I am on a 2 hop 11s mesh
<robimarko>
Thats awesome
<robimarko>
Currently, routing perf is crap without offloading
<blogic>
yeah
<blogic>
upstream support for qca sucks
<blogic>
MTK is way better in that regard
<blogic>
problem is getting decent mtk HW
<robimarko>
Upstream support is me and 2 other guys
<blogic>
yup
<robimarko>
Even when QCA upstreams, they tend to break more stuff than they add
<blogic>
I was not talking about your work, which is awesome
<blogic>
I meant the vendoe involvement
<blogic>
correct
<robimarko>
No, I get your point
<robimarko>
They do jack shit in terms of upstreaming
<robimarko>
On a good day you will get pinctrl and clocks
<blogic>
consider qca a tanker
<blogic>
for it to change course will take years
<robimarko>
And then I will spend 2 years chasing various broken clocks
<blogic>
and bit errors, WDS being broken, ... ...
<robimarko>
Hehe
<blogic>
11s being broken in HW
<robimarko>
WDS is only broken if you enable encap/decap offloading
<robimarko>
"only"
<blogic>
breaking their own dts ABI between qsdk drops
<robimarko>
There aint no ABI
<blogic>
yeah
<blogic>
I know
<blogic>
its funny
<robimarko>
I have seen more DTS reworks that pull in 3 generations of patches than I want to ever see
<robimarko>
I just dream of getting some docs
<blogic>
different topic
<robimarko>
Like, if they just provided the docs they wouldnt have to actually do anything
<Borromini>
Znevna: congratulations on completing your quest ;)
<Znevna>
it's not completed yet
<Znevna>
but thank you :P
<Znevna>
it's a few steps closer
<Borromini>
:P
<Borromini>
because of the switch LEDs,
<Borromini>
?
<Znevna>
ah, no
<Znevna>
the mt76 pr needs to get merged and version bump to openwrt
<Znevna>
and I wanna try adding trx support for it sometime next week :P
<Borromini>
:P
<Borromini>
brave man
<Znevna>
I've reached out to the brave man that added trx support for asus devices in the first place :P
<Borromini>
:P
<Borromini>
gotta go, good luck.
<Znevna>
^^ cheers
Borromini has quit [Quit: leaving]
ptudor_ has joined #openwrt-devel
ptudor has quit [Ping timeout: 480 seconds]
wigyori has quit [Ping timeout: 480 seconds]
<nick[m]12>
is rmilecki here in irc?
<hauke>
nick[m]12: yes he was saying something about 2 hours ago, he is probably asleep now
<Znevna>
and also mentioned a few busy days
<nick[m]12>
ah okay, thanks. I just wanted to ask him if he plans to add 5.15 testing support for the brcm47xx. This target has some downstream patches that need to be ported to 5.15.