clandmeter has quit [Quit: Alpine Linux, the security-oriented, lightweight Linux distribution]
danieli has quit [Quit: Alpine Linux, the security-oriented, lightweight Linux distribution]
danieli has joined #openwrt-devel
clandmeter has joined #openwrt-devel
srslypascal has quit [Quit: Leaving]
Tapper has joined #openwrt-devel
srslypascal has joined #openwrt-devel
<mrkiko>
Slimey: yeah :D coming back home after long trip is nice
<mrkiko>
Slimey: for an arbitrary definition of long of course :D
robimarko has joined #openwrt-devel
danitool has joined #openwrt-devel
<rua>
Hi, all. Could DSA accelerate the traffic through a bridge between VLAN devices with different VLAN ID?
<rua>
For example, if lan1@eth0 and lan2@eth0 are two slave ports under the same switch, could a bridge between lan1.1@lan1 and lan2.1@lan2 be handled by the switch without bothering the CPU?
<jow>
would surprise me if it would be supported
<rua>
jow: You mean such traffic should still be handled by the CPU?
<jow>
not saying it should, but - without actually knowing the subsystem in detail - I would be surprised if the capability exists in the DSA framework *and* there's capabilities in the switch IC hardware to offload such traffic
<rua>
Traffic like bridge between lan1.1@lan1 and lan2.2@lan2 should also be handled by the CPU?
<rua>
jow: So if I need to bridge a VLAN from wan side to one of the lan port, the best way to handle it should be adding the wan port to br-lan, let vlan filtering to handle the vlan, and adding a vlan and corresponding filtering rule for untagged packets?
<jow>
rua: yes, that will likely be the most performant approach
csrf has quit [Ping timeout: 480 seconds]
<rua>
jow: Is that to say, that most offloadings of DSA framework can only be done on the bridge of slave devices?
<jow>
my impression is that offloading generally only applies to vlan port groups
<jow>
so one vlan table entry, with N ports assigned where each port is either egress tag or egress untag
<jow>
accellerating bridging of different vlans would require hardware support for rewriting vlan tags
<jow>
and support/abstraction for that in the dsa software layer
<jow>
I don't know if and how many devices support the former and if the latter is even implemented
<rua>
Is offloading of traffics between slave devices not bridged together basically out of the scope of DSA?
<jow>
yes
robimarko has quit [Quit: Leaving]
<dhewg>
jow: I could use some sort of event to listen to network interface up/down events, where the interface can be part of a bridge, so there're no hotplug calls for that device atm. Is somethink like this okay and acceptable? http://sprunge.us/LO0QYf
<dhewg>
`ubus subscribe network.device` gives "{ "updown": {"name":"lan2","up":false} }" upon unplugging the cable
<dhewg>
(oh, that's a netifd patch ofc)
<rua>
jow: Thanks. I have learned the restriction of DSA that we just talked about.
srslypascal is now known as Guest1168
srslypascal has joined #openwrt-devel
cbeznea has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Guest1168 has quit [Ping timeout: 480 seconds]
gladiac has quit [Quit: k thx bye]
robimarko has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
<mrkiko>
dhewg: Hi! Maybe you can help me out :) I am using FB7530 with pppoe- isolated one switch port. It works fine, but I am in a non-DSA build. Any hint or example for when I'll have to do it with DSA?
<karlp>
how come I have /sys/kernel/debug/dynamic_debug if the CONFIG_KERNEL_DYNAMIC_DEBUG option is off? I thought the presence of that control file indicated that it was available?
<karlp>
ah. right, ok, this is so that it can be on, but we don't compile all the strings in .. ok. that makes sense I guess.
<jow>
hgl: it is needed to rewrite the native configuration file
<jow>
hgl: otherwise you would just deliver a reload signal to dnsmasq without actually handing it an updated configuration
<hgl>
jow, ah, it regenerates config from UCI, I see, thanks
<karlp>
huh, stillweird, I get _some_ dyndbg working via kernel cmdline, others nothing at all.
<karlp>
works fine: "file drivers/base/firmware_loader/* +fmp"
<karlp>
nothign at all: "file drivers/bluetooth/* +fmp"
<karlp>
yet my bluetooth works happily after boot, and adding that to the control file after boot works too.
robimarko has joined #openwrt-devel
tlj has quit [Remote host closed the connection]
torv has quit [Remote host closed the connection]
danitool has quit [Ping timeout: 480 seconds]
<G10h4ck>
I am looking into hostapd internals to investigare a possible future of something better both then 802.11s and WDS, I have been jumping around functions callback etc. I feel to have understood a few things but seems the typical software with aeons of incrusted changes, does someone know if there is some documentation that at least explain the architecture?
Ansuel has joined #openwrt-devel
gladiac has joined #openwrt-devel
<soxrok2212>
G10h4ck: 802.11s is standardized. is what you propose also standardized?
<soxrok2212>
also Ansuel: tp-link GPL also told me to f-off :)
<robimarko>
I am gonna guess for a CN only device?
<soxrok2212>
yep
<Ansuel>
same
<Ansuel>
they act like they are completely indepentend but that is just bs ...
<robimarko>
Well, the CN legal entity is
<robimarko>
And good luck enforcing GPL on them
<soxrok2212>
uhhhh huh. i told the fw people i dont need it any more since i just dumped the flash chip so they can eat their own words lol
<Ansuel>
one extra reason to not trust CN products...
<soxrok2212>
thats why i refuse to plug it in and am also against that redmi ax6000 change to put stock partitions back
<Ansuel>
anyway i'm having so much fun with github ci and dockerfile and the fact that they love to modify source on packing stuff
<Ansuel>
one doesn't like specific char... dockerfile seems to drop links...
* soxrok2212
hates docker
<Ansuel>
it's handy but probably not designed for what i want to accomplish
<f00b4r0>
is it expected that CONFIG_TARGET_ROOTFS_PARTSIZE is only modifiable if ext4 images are selected, yet it does affected squashfs' f2fs rootfs size?
<f00b4r0>
there seems to be some config dependency snafu
<f00b4r0>
oh this is target-specific i see
* f00b4r0
prepares patch
<Ansuel>
oh no
<f00b4r0>
oh no?
valku has joined #openwrt-devel
<Ansuel>
OH NO!
<soxrok2212>
OH YEAHHHH
<f00b4r0>
oh... kay? :)
<Ansuel>
ahahaha
<f00b4r0>
oh i see; the patch is already there, only not backported
<f00b4r0>
stintel: would you mind backporting dc51342d34c267d6dc8c69d72979cab394f49d4b to 22.03? :)
tlj has joined #openwrt-devel
goliath has joined #openwrt-devel
tlj has quit [Ping timeout: 480 seconds]
<stintel>
f00b4r0: ask me on Tuesday if still needed
<stintel>
on second thought, done
tlj has joined #openwrt-devel
<mrkiko>
soxrok2212: so you're up to your tp-link mt9886 porting effort!! Nice!
<mrkiko>
soxrok2212: how is it going?
<soxrok2212>
mrkiko: bad so far. tp-link doesnt want to give sources or firmware. i was able to dump the flash but im having trouble identifying u-boot and env. i can drop into u-boot from uart but they block most useful commands
swalker has quit [Remote host closed the connection]
<soxrok2212>
i did a tcpdump on it and this thing immediately started calling out to china
<mrkiko>
soxrok2212: via password or omitting them from config?
<mrkiko>
soxrok2212: well, if you have external access to flash, you might consider replacing u-boot alltogeter
swalker has joined #openwrt-devel
Habbie has quit [Ping timeout: 480 seconds]
<soxrok2212>
i did but im trying to stay within bounds for the average person to be able to flash
<soxrok2212>
i do*
<mrkiko>
soxrok2212: ok, but if it turns out youcanflash onlyvia serial, then probably we already lost the average mark :D
<mrkiko>
soxrok2212: anyway, good luck!!
<soxrok2212>
thank you :)
<Ansuel>
stintel btw skipping download for prebuilt tools seems non trivial our download logic is so complex LOL
<Ansuel>
also with COPY in dockerfile it seems the build all core packages job is failing in finding libtool bin for some reason
<jow>
instead of hacking on prebuilt tools it's likely easier to introdcue a menuconfig option to use host utils
<Ansuel>
isn't that problematic as we apply custom patch to some tools?
<LUART>
I have the whole toolchain installed and can compile the actual file, but I need help to find the values that need to be switched for The FRITZ 3000 Repeater in the tsi file
<LUART>
Noone seems to be assigned to it currently,but I guess it would be a quick fix to do it manually?
Tapper has joined #openwrt-devel
<f00b4r0>
stintel: thanks :)
<hgl>
Ansuel, any thoughts on the nginx package change proposal?
<G10h4ck>
> <soxrok2212> G10h4ck: 802.11s is standardized. is what you propose also standardized?
<G10h4ck>
no it is not standardized
<G10h4ck>
it is an experiment to test viability of a possibility that emerged talking with nbd about mesh networks, and how to do on newer radios/drivers
<soxrok2212>
ah
<soxrok2212>
Ansuel: i think u-boot is at 0x20000 in that binary, i think its uboot-usb?
<soxrok2212>
header is 0x010064AA
<G10h4ck>
all the standarized things I have found and read off, even those having mesh in the name are very limited...
<Habbie>
yolo, -many- gateways/CPEs are openwrt based, though
<slh>
not that this changes really anything for using- or getting them supported, sadly
<LUARC>
Anyone able to help with an issue of writing openwrt to an AVM 3000 device? I want to manually install it but I need to fix certain values https://github.com/openwrt/openwrt/issues/5077
<yolo>
Habbie: did some quick reading, RDK-B is for service providers(cable & telcom) that has agents for central management and configuration, openwrt for home users, for the most part
<yolo>
by agent I mean TR069 etc
<Habbie>
right
<Habbie>
and then there's RDK-V for tv boxes, but i think we'll ignore that now :)
<Habbie>
also RDK is not very open
<Habbie>
which makes openwrt much more attractive for hobbyists
<yolo>
the one really matters is only RDK-B, the rest are not that popular yet, I also noticed they use their own lighten.js for UI which i'm clueless at this point, something like luci?
<Habbie>
that i don't know
<yolo>
someone should 'enhance' openwrt to the service providers, it has everything they ever need, just add some agents in lua will be enough for remote configuration&management
<yolo>
there is no point for RDK-B
<Habbie>
many vendors ship openwrt 14.xx with some management ;)