<mangix>
Ansuel: found a way to get some of the LED colors. ar71xx has some of them in 01_led
Ansuel has quit [Ping timeout: 480 seconds]
Tusker has quit [Remote host closed the connection]
Tapper has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
dangole has quit [Ping timeout: 480 seconds]
nitroshift has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rmilecki has joined #openwrt-devel
robin_ has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
decke has joined #openwrt-devel
Ansuel has joined #openwrt-devel
Ansuel has quit [Ping timeout: 480 seconds]
felix has quit [Ping timeout: 480 seconds]
Dgrey has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<aparcar[m]>
jow: could we set firewall4 to PROVIDE firewall so luci doesn't go bananas?
danitool has joined #openwrt-devel
rua has joined #openwrt-devel
<jow>
aparcar[m]: luci-app-firewall still requires changes before this can be done
<jow>
luci-mod-status as well
rua has quit []
<aparcar[m]>
even with iptables-nft?
<jow>
didn't check
<jow>
but I'd rather utilize nft's native JSON output if available to give structured rule status output instead of pretending that we're doing iptables still, which would be confusing
<jow>
also arguments like "option extra" should be disabled/hidden when fw4 is detected
<aparcar[m]>
jow: just to check you're overall down to move forward with fw4 or think it's a terrible idea as a goal within the next 6 month?
<jow>
I guess it's doable
<aparcar[m]>
I'll be building some binaries so people can test it
<jow>
there's some missing stuff yet
<jow>
someone noted that the flow offloading stuff is not yet integrated
<jow>
which should be easy to add
<jow>
and https://git.openwrt.org/?p=project/firewall3.git;a=commitdiff;h=61db17edddb1f05e8107f0dbef6f7d060ce67483 needs to be ported to fw4
<aparcar[m]>
noted
<aparcar[m]>
do you plan to work on the json luci bridge?
<aparcar[m]>
nbd: do you have an opinion on moving the UML target to archive.git?
gladiac has quit [Read error: No route to host]
gladiac has joined #openwrt-devel
<nbd>
i don't have an opinion on that
<aparcar[m]>
it's broken so I'd just remove it...
<aparcar[m]>
and succeeded via qemu
gladiac has quit [Read error: No route to host]
<nbd>
technically, uml can do things for testing that qemu targets can't
gladiac has joined #openwrt-devel
<nbd>
e.g. the so-called 'time travel' mode
<nbd>
but i don't think anybody is using that or cares about it at the moment
<aparcar[m]>
time travel sounds like something many people want
<aparcar[m]>
can you elaborate
<nbd>
you can make it move time forward quickly whenever the system is idle
<nbd>
so for testing you can quickly simulate things that usually would need more time due to scheduled timers, waiting, etc.
<ldir>
I need to hire someone who can port https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/hack-5.10/645-netfilter-connmark-introduce-set-dscpmark.patch;h=2d3fe01a755b9eb0a0b2bc0494bb002d735c4390;hb=HEAD to nftables
<nbd>
fyi, i'm currently working on an ebpf module that can be used as classifier for cake to set dscp based on ports, ip addresses, ip protocols and flow packet size behavior
<nbd>
which would make it possible build some qos stuff without involving netfilter at all
<ldir>
that sounds fun.
<ldir>
I still would like a way to mark/store/restore a DSCP for a flow - so the DSCP can traverse links that otherwise lose it.
<nbd>
can you give a specific example?
<ldir>
last time I tried anything nft, Pablo wanted me to re-write the parser - which is bigger and beyond my ability.
<nbd>
i'd like to see an example of where exactly connections get marked and by what kind of rules in order to get them set on egress
<nbd>
i want to see if it's something that i can incorporate into my own solution
<nbd>
so that netfilter is needed for fewer qos related things
<ldir>
if you look at sqm-script ctinfo-layercake.qot you'll see the sort of thing I do.
<nbd>
i'm not very familiar with the sqm scripts
<ldir>
it can be summed up as 'use iptables rules on egress to set a DSCP on the packet (eg ipset matches, port matches etc) store the decided DSCP into the conntrack mark along with a 'set' flag.
goliath has joined #openwrt-devel
<ldir>
use tc actions act_ctinfo on the ingress path to store DSCP into ingress packet, just before the qdisc gets to see it. qdisc eg. CAKE then uses DSCP to filter packets into priority/bandwith tins.
<nbd>
ah
<ldir>
there's a further trick on the egress path that uses act_ctinfo to restore the decided DSCP into all egress packets for a flow/connection - that means you can run the expensive iptables 'classification decision' once and then have that decision applied to every packet without it hitting extensive iptables rules every time.
<stintel>
rsalvaterra: re CONFIG_PPC_QUEUED_SPINLOCKS .. "large SMP and NUMA" .. does 4c/8t really qualify for that? and also, do you have numbers?
<nbd>
ldir: here's how i think it could work with my module:
<nbd>
so my ebpf module replaces the ipset/port matches with ebpf maps that can be filled from user space
<nbd>
i could make it set a specific mark to indicate if a packet was matched by the ip map or the port map
<nbd>
act_ctinfo could be extended to allow saving the connmark
<nbd>
so on egress, you'd run my module as sched classifier, it would set the mark where the ips matched
<nbd>
you use that as trigger to fill dscp into the connmark
<nbd>
and on ingress, ctinfo would restore it
<nbd>
no netfilter involved
<nbd>
right now, if i remember correctly, dnsmasq is being used in some cases to fill the ipset
<nbd>
i'd replace that functionality in a slightly different way
<nbd>
instead of dnsmasq filling the set, my user space counterpart to the ebpf module would snoop on dns responses from dnsmasq via ubus
<nbd>
and fill the ebpf maps in a similar way
<ldir>
dnsmasq is filling ipsets. I'm also using netify to fill in ipsets as well.
<ldir>
ultimately if something like (made up syntax ahead) 'ct mark set ip dscp' and 'ct mark set ct mark lshift 26 or 0x200000' would work in nft land then I would be happy.
pmelange has joined #openwrt-devel
<nbd>
how does netify integrate with ipset?
<ldir>
ah, there's a netify-fwa that talks to netifyd and it fills in some ip/port ipsets for matching/required flows
<nbd>
it's a set of python scripts, right?
<ldir>
yes!
<nbd>
ok, so it wouldn't be too hard to modify that to do ubus calls instead of ipset updates
<ldir>
they listen to a socket from netifyd that spews out json about flows
<nbd>
i took a quick look, and from what i can tell, it simply runs the ipset command line tool for updates
<ldir>
I have to caveat that what I have and am playing with/running is a total hack in every way possible.
<nbd>
that's fine
<karlp>
what are the two devices here normally doing? you're marking egress in one place and then filtering on ingress elsewhere?
<karlp>
is this APs connected to a router?
<nbd>
if i undestood the use case correctly, it's all happening on the same device
<nbd>
but it's doing ingress and egress shaping
<ldir>
but for me, the fundamental enabler is that everything is 'keyed' off DSCP and that DSCP is stored in the connmark so tc act_ctinfo can get at it to stuff it back onto 'ingress' packets so CAKE gets to see the wanted DSCP and 'tin' correctly.
<ldir>
karlp: all one device - an APU2 - one interface WAN, one interface LAN.
<nbd>
ldir: it would be the same with my solution, the ebpf maps have ip->dscp hashmaps and port->dscp arrays (separate for tcp and udp)
<ldir>
I decide on a connection's 'priority' based on WAN egress packets, where iptables can see it (you can't iptables before the qdisc on ingress)
limbo_ has joined #openwrt-devel
<nbd>
so after my module is done, we only need to extend ctinfo to set the connmark as well, then combine ctinfo with my module, and replace the uses of ipset with something that talks to my user space daemon
<nbd>
then this should theoretically be able to cover your use case properly
<ldir>
I stuff the decided DSCP classification in conntrack connmark
<nbd>
for all packets?
<karlp>
so egress on wan once a flow has started is used to start policing ingress on lan? or do you mean egress to mean coming in from wan?
<ldir>
karlp: the egress on wan is used to police the ingress from wan
<ldir>
2 instances of CAKE, one of wan egress, one on wan ingress.
<ldir>
There's an IFB interface involved as per the normal sqm-scripts setup, that's where the 'ingress' instance of tc act_ctinfo and CAKE are setup
<limbo_>
Hi! is there a currently supported dlan/powerline/PLC hardware like adapter/AP/etc.?
<ldir>
nbd: no not for all packets, BUT I do have an instance of act_ctinfo on the egress interface so it writes the stored DSCP onto egress packets (conditionally on a flag) - this avoids having to run all the iptables classification rules for every egress packet.
<limbo_>
ah and yes, I saw the ToH, but it's not clear if PLC has stable or current support.
<ldir>
the idea is to classify once and then forget out it.
pmelange has left #openwrt-devel [#openwrt-devel]
<ldir>
I have an exception for 'best effort' in that if BE traffic goes over a certain traffic threshold then the flow gets set to bulk and then it's forgotten about by the iptables rules.
<ldir>
a sort of 'dynamic de-prioritisation'
<ldir>
karlp: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/hack-5.10/645-netfilter-connmark-introduce-set-dscpmark.patch;h=2d3fe01a755b9eb0a0b2bc0494bb002d735c4390;hb=HEAD has some superb ascii art
<limbo_>
any idea about dlan support?
<nbd>
ldir: that one can probably also be implemented as a separate ebpf block somehow
<nbd>
do you think you could add support to ctinfo for setting connmark based on dscp?
<limbo_>
@nbd or @ldir do you have any idea or hint for me?
<ldir>
nbd: my understanding is that this is a layering violation.
<nbd>
how so?
<nbd>
limbo_: i have no idea about that stuff
<ldir>
it's years since I looked at this.
<nbd>
why do you think it's a layering violation then?
<limbo_>
ok thanks, is it better to ask in the forum?
<nbd>
limbo_: probably
<limbo_>
ok, thanks.
limbo_ has quit [Quit: Page closed]
<ldir>
because when I 1st looked at this I thought the best place to 'store the decision' would be in the qdisc itself. That basically got shot down as 'you can't mess with conntrack from a qdisc' IIRC
<blocktrron>
stintel: poemgr will come to feeds, my last weeks were just packed
<nbd>
"in the qdisc itself" - you mean cake?
<ldir>
yes
<stintel>
blocktrron: great
<nbd>
ldir: well, i agree that it doesn't belong there
<nbd>
i think a sched action is different though
<ldir>
that's when I discovered your act_connmark
<nbd>
so i think in terms of scope and code change size, it would probably be easy to simply add a 'reverse' mode to ctinfo
<blocktrron>
stintel: and regarding discouraging - as long as it's in packages, i don't buy the "It's not the ultimate solution" argument
<blocktrron>
As long as it's not in core, the ability to use it goes over the "may or may not come" optimal solution
<ldir>
and I had the enlightenment of (ab)using ct connmark to store a DSCP, that could be restored by act_connmark.
<stintel>
blocktrron: agreed
<blocktrron>
Otherwise, how should we iterate over it. THis ends up in 20 forks, each adding a single feature / fixing a single bug
<blocktrron>
Bsically repeating my E-Mail here ;)
<ldir>
and the bastard child that is act_ctinfo, a blatant rip-off of your act_connmark but with slightly extra sauce.
<sauce>
only slightly?
<ldir>
or indeed source ;-)
<nbd>
ldir: maybe i'll go a different route with my module and make a separate cache to carry dscp marks over from egress to ingress
<nbd>
that would have one significant advantage
<nbd>
i want to make it possible to run my module not just on a router, but also on an ap that simply bridges traffic
<nbd>
or a repeater
<nbd>
the dscp marks would then be used not just for cake, but also for wifi
<nbd>
and i could solve the missing ip list issue by replicating the data from the main router
<nbd>
in the bridged traffic case, i can't rely on conntrack anyway
Ansuel has joined #openwrt-devel
<ldir>
sounds really good.
Tapper has quit [Ping timeout: 480 seconds]
<nbd>
actually, i just thought about it some more, and i think i have a better idea on how this could work
<nbd>
i'd like to know what you think about it
rua has joined #openwrt-devel
<nbd>
so i'm ignoring the dynamic deprioritisation for now, which i think can be handled separately
<nbd>
but for the common dscp marking, i don't think we actually need conntrack or a replacement for it
<nbd>
so let's assume that the ebpf based hash lookups for ips and ports are fast and we don't need to waste many cycles doing complex rule processing
<nbd>
i'd have two sets of maps for ip->dscp
<nbd>
one bigger map for the wan side ips
<nbd>
and a smaller one for host based prioritization
<nbd>
on egress, it does the lookup based on dest ip
<nbd>
on ingress it uses src ip
<nbd>
we may need to do a ct lookup only for the host prioritization case
<nbd>
only to look up the address
<nbd>
but i'm sure we can find a simple way to do that somehow
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<stintel>
how/where was it decided again if f2fs vs jffs2 is used for overlay?
Ansuel has quit [Ping timeout: 480 seconds]
<nbd>
stintel: fstools has 'drivers' for 'ubi', 'mtd' or 'rootdisk'
<nbd>
ubi/mtd use their respective filesystems, rootdisk chooses between f2fs and ext4 based on available space
<rmilecki>
clayface: accepted upstream? it's usually a rule but there are exceptions like b43 wireless driver
<rmilecki>
clayface: i don't think we can accept a patch with firmware of unclear licensing in OpenWrt source
<rmilecki>
clayface: do you think "kernel: 5.10: dsa: don't set skb->offload_fwd_mark" can break any DSA driver?
indy_ has joined #openwrt-devel
<clayface>
rmilecki: yep hence I lifted the whole file from the source with GPL footer. I can mention to ffainelli again about this or just try submitting
<rmilecki>
clayface: i believe the rule for upstream is still that blobs are not allowed in .c files
<rmilecki>
clayface: so you should probably:
<clayface>
rmilecki: skb->offload_fwd_mark shouldn't break anything. Can apply this only to bcm53xx to be safe
<rmilecki>
1. save poe_fw as binary file
<rmilecki>
2. contact lawyer
<rmilecki>
3. send patch to linux-firmware.git
<clayface>
rmilecki: ah yes extracting the blob was implied. It is also present in other devices, eg ubiquiti switches
<rmilecki>
oh, i wasn'y sure
<clayface>
that skb->offload_fwd_mark should also help with the ea9500, in case you have it
<rmilecki>
so yeah, that's the best way probably
<rmilecki>
clayface: no ea9500 here
<rsalvaterra>
Guys, anyone with an MT7615 seeing this? "ieee80211 phy1: hwmon: 'mt7615-phy1' is not a valid name attribute, please fix".
<rsalvaterra>
"All in all this is a very cool technology and great results especially on the big systems but even on smaller ones there are nice gains."
<karlp>
if I understand correctly, it's verifying that the tls endpoint exists and works, and then redirecting there, so just needed "any" known resource?
<karlp>
I guess loading.gif or any of the networking .pngs are the "right" safe option?
<stintel>
rsalvaterra: thanks btw for that queued spinlocks suggestion, it appears there is no more difference between SQM off or on now, on my M300
<stintel>
of course, this is speedtest.net, using server at my ISP, but on GPON ... you might have some slowdown due to neighbors
<stintel>
since I have plenty of ports now, should be easy to make a setup to do speedtests like that with local devices
<stintel>
but later
<jow>
karlp: yes, the intent was indeed to probe a well known ressource
<jow>
karlp: still using up.gif was an oversight when moving things to luci-compat
<jow>
(that naive probing is not working as well anymore since random SSL cert warnings prevent a successfull loading)
<rsalvaterra>
stintel: Don't mention it, I'm just a bit of an optimisation freak. :)
Ansuel has joined #openwrt-devel
<Ansuel>
Hi
<rsalvaterra>
Ansuel: Be patient with Andrew, reviewing is hard and the reviewer doesn't have all information. ;)
<rsalvaterra>
Hi, mate. :)
<Ansuel>
you stalker 1?!??!? ahhahah
<rsalvaterra>
Ansuel: I follow several Linux mailing lists, one of them is netdev. :)
<Ansuel>
anyway i hope he is reasonable. I already knew pushing all that special binding would have been a nightmare
<Ansuel>
also honest question. Did I look rude in the response?
indy has joined #openwrt-devel
<rsalvaterra>
No, at least not to me. :)
<Ansuel>
thx still trying to understand how to correctly communicate with reviewers
mrkiko has quit [Quit: leaving]
mrkiko has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
dangole has quit [Quit: Leaving]
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
eck has joined #openwrt-devel
<karlp>
jow: is restarting rpcd the "correct" way of making changes to the menu.d json files?
decke has quit [Quit: Leaving.]
<karlp>
it works, but it's not as convenient as just editing the lua controller was ;)
<Ansuel>
reload doesn't work ?
<karlp>
nope.
<karlp>
not even with luci.ccache.enable=0
<Ansuel>
ccache is not related to rpcd AFAIK
<karlp>
well, no, but it's the "only" knob for caching in luci.
<Ansuel>
but anyway why you need to do changes to menu.d ? change acl at runtime?
<karlp>
development?
<Ansuel>
if it's only dev i think restart is the correct way to apply the new acl
<karlp>
kinda expected that, but still tedious :)
<Ansuel>
annoying if you need to reloding everytime but that can be bypassed
<Ansuel>
relogin*
<karlp>
yeah, the relogin bit.
<karlp>
it's not too bad, it's normally just a little fiddle when I've got something new, like I was fiddling with tabs and first child and having something make a function call, not just a view.
<karlp>
it's working now :)
<Ansuel>
if you check the wiki there is an option to bypass any auth so you can dev and implement the menu... at the end you can check if all works correctly with the auth
<Ansuel>
you should be able to just compile an image with qca,package48 and check if it does work
<mangix>
Ugh marc.info is hard to browse
<Ansuel>
i posted the link if that's what you are searching
<mangix>
found it
<Ansuel>
wonder if the package option is set by default....
<mangix>
Ansuel: my archer works with package48
<Ansuel>
mangix can you add 2 line to the code? i'm curious of something....
<mangix>
sure
<Ansuel>
ok wait a second
<mangix>
wtf is ar8328?
<Ansuel>
in qca8k_setup_of_pws_reg after the val add something like val1. and then qca8k_read(priv, QCA8K_REG_PWS, &val1); and then pr_info("PWS_REG %x", val1);
<Ansuel>
compile and give me output of pws_reg
<Ansuel>
ar8328 is just 8327 with 176 pin.... it seems industrial package....
<Ansuel>
I suspect every ar8327 have package48 enabled by default or we need to enabled it to follow what the documentation say
<mangix>
you mean add extra val variable?
<Ansuel>
yes
<Ansuel>
and then after the extra val the 2 function to read and print the reg
<clayface>
Ansuel: do you want me to check this on the qca8337 as well?
<jow>
karlp: looks like it could go into tools-widgets
<jow>
*tools.widgets
<Ansuel>
clayface: mhhh in the documentation for qca8337 the bits for package are sets reserved so in theory that settings should be needed only for 8327
<karlp>
jow: thanks, looks giid, i was trying to read commonsjs and amd require stuff, and not figuring our the luci requirements
<Ansuel>
mangix: why always marvell cheap oem?
<mangix>
cheap?
<slh>
because their wired side is fast, mostly upstream and documented (the ex-wireless side however...)
<robimarko>
Mostly due to upstream support and documentation
<robimarko>
WLAN stuff is terrible
<robimarko>
Especially since NXP bought it
<mangix>
what did nxp do?
<Ansuel>
right so it's really the fact that they do things the ""right"" way
philipp64|work has quit [Quit: philipp64|work]
<Ansuel>
mangix: nothing? that's the problem LOL
<robimarko>
NXP stopped all of the upstreaming for WLAN cards
<robimarko>
Almost fully stopped releasing FW updates etc
<robimarko>
And all of their new AX cards are completely unsupported upstream, you only have their driver
<robimarko>
Which of course only works with certain kernels, etc
<mangix>
Ansuel: did. I don't see many commits from marvell upstream anymore.
<mangix>
robimarko: what's the business sense in doing this?
<digitalcircuit>
Ansuel: Do you have a starting point for looking into the ipq806x v5.10 changed MMC problem ( https://github.com/openwrt/openwrt/pull/3954#issuecomment-933033672 ), or is that something I should look into before continuing my CPU crash/reset testing? I've restored my second NBG6817 to working status (first purchased Nov 2019, second in 2020) and it has the same MMC module that v5.10 won't boot with.
<Ansuel>
digitalcircuit: just to make sure we had a regression between 5.4 and 5.10 ? it worked with 5.4 and broke with 5.10 ?
<robimarko>
mangix: They actually do upstream their HW, the whole Armada 7k, 8k and even Octeon TX2 is upstreamed including networking
<JiiPee>
Also I am getting error on build if I try to use 5.10 kernel. Complains that kernel image is too big. Is that know issue with mt7620a devices?
<robimarko>
mangix: But more importantly, docs are much easier to get, you just need an NDA to get to Extranet and you have 90% of the stuff there
* digitalcircuit
again apologizes for not testing v5.10 earlier; he didn't even think something like this (switched MMC modules in production runs) could be an issue.
<robimarko>
mangix: But its not all perfect, magic bit stuff tends to get forgotten especially on Armada 3k
<mangix>
JiiPee: ar8327 switch?
<robimarko>
mangix: As far as NXP goes, no idea why they went that way after buying WLAN stuff from Marvell
<mangix>
robimarko: I guess my question is who are their customers?
<mangix>
I know it's not google
<JiiPee>
[ 65.342784] Atheros AR8216/AR8236/AR8316 mdio-bus:00: Port 4 is up
<robimarko>
mangix: No idea, I know know of Globalscale using that stuff
<JiiPee>
[ 65.370187] Atheros AR8216/AR8236/AR8316 mdio-bus:00: Port 5 is up
<JiiPee>
so yeah I think so
<robimarko>
mangix: I see that you asked about Mochabin, yeah I am involved in it.
<mangix>
JiiPee: want to do some testing?
<mangix>
ribomarko: cool
<JiiPee>
Sure I can do if I can
<robimarko>
mangix: I (Actually, Sartura the company I work for) is upstreaming Linux DTS, OpenWrt, U-boot and ARM ATF for it
<mangix>
JiiPee: let me prepare a patch for you
<robimarko>
mangix: I am sick due to damn COVID so it got delayed a bit, but I will be sending U-boot and ARM ATF(TF-A or whatever its called now) upstream next week
<JiiPee>
mangix: ok
<JiiPee>
Oh and does anyone have general idea why mt7610 5G wifi works for some and others not? Is it bin blob issue? Like bin blob is actually hardcoded to module in original firmware and not actually using the one what can be found from config partition?
<JiiPee>
I have google alot about that issue but cannot find any conclusion
<mangix>
JiiPee: seems I don't understand this hardware
<mangix>
you have eth0 being connected to 2 switches?
<JiiPee>
It uses pr4303 as base
<JiiPee>
I do not know much about this stuff, I am mostly copy/paste this, based to clone device
<JiiPee>
Just had to find right offset for mt7610 binblob and mac address
<JiiPee>
And I changed lets + switch ports so they work now
<JiiPee>
I have it running if you need some commands to run
<Ansuel>
digitalcircuit: i think the problem is with the new mmc.... do we have any source... i think the workaround is there
<mangix>
JiiPee: that is just...strange. I have never seen eth0 being connected to two switches at the same time
<mangix>
JiiPee: are all ports connected to ar8327?
<JiiPee>
mangix: I do not know
<mangix>
based on DTS, looks like it
<JiiPee>
I think there is switch for wan port and another for 4xlan
<mangix>
does your device have 6 ethernet ports?
<JiiPee>
5
<mangix>
k so 02_network specifies lan1-4, and wan as belonging to the ar8327 switch
<mangix>
and then the other switch's port5 is lan???
<mangix>
does ifconfig show lan1-4, wan, AND lan?
<JiiPee>
nope
<JiiPee>
I can pastebin
<mangix>
sure
<mangix>
oh wait this is swconfig...
<mangix>
JiiPee: do you see a LuCI > Network > Switch section?
<stintel>
geez, wondering why my SPF+ modules aren't working in the ECS4100 :P
<Ansuel>
slh i still didn't test but also another user reported some strange stuff to it... probably the switch is dropping packet from the secondary cpu
<slh>
yeah, there is something strange going on, as soon as I diverge from lan/ wan with the dsa syntax
<Ansuel>
something needs to be tweaked for acl and br handling i think...
<JiiPee>
mangix: does that require 5.10 kernel? I cannot build with 5.10, complains that image is too big
<mangix>
yes it does. oh well. disregard it.
<JiiPee>
:/
<mangix>
JiiPee: some context: there's work on converting devices using ar8327/37 to a newer driver.
<JiiPee>
ok
<JiiPee>
I saw someone on other device had also issues with kernel not fitting to partition, I think he/she have done patch to split kernel. So who knows, maybe someone port it to similar devices like mine at some point
robimarko has quit [Quit: Page closed]
Tusker has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
<clayface>
Ansuel: Isn't the mx65 a different use case for the secondary cpu port? I think everything else is 1 cpu port for WAN, the other for LAN
<clayface>
on the mx65, for packets going to a MAC address on the other switch, go out port 6. So the main CPU port will have no visibility. Is that desirable?
<Ansuel>
clayface: did you tested how it does bheave with setting only the regs ?
mangix has quit [Remote host closed the connection]
mangix has joined #openwrt-devel
<clayface>
didn't get round to it yet, maybe tomorrow or if not over the weekend. I think it will need more because packets would still be routed out port0
<clayface>
going to sleep here. Will check this tomorrow. Good night!