minimal has quit [Remote host closed the connection]
minimal has joined #openwrt-devel
minimal has quit [Quit: Leaving]
mangix has joined #openwrt-devel
KGB-0 has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
felix has quit []
felix has joined #openwrt-devel
philipp64 has joined #openwrt-devel
ekathva has joined #openwrt-devel
snh_ has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
aiyion has joined #openwrt-devel
aiyion_ has quit [Ping timeout: 480 seconds]
valku has quit [Quit: valku]
snh has joined #openwrt-devel
ecloud_ has quit [Ping timeout: 480 seconds]
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
<nick[m]1234>
anyone any idea why bcm53xx does not build initramfs (noob question). they are defined in the makefile (at least I think they are), however not available after building
aiyion_ has joined #openwrt-devel
<mrkiko>
rmilecki may be able to help you out with this
<Grommish>
nick[m]1234: it cut the wifi throughout in half because of the proprietary Broadcom drivers :(
mangix has quit [Read error: Connection reset by peer]
mangix has joined #openwrt-devel
<Grommish>
And the only way I could find them was to use a super old Tomato load with like a 3.x kernel
<Grommish>
I bailed on it at that point and just set the thing up as a dumb AP
<nick[m]1234>
the unifi switch 8, is just some PoE device
<Grommish>
Shouldn't be an issue without Wifi.. At least, I didn't notice a wired drop
<Grommish>
but that's one of my primary wifi devices so I couldn't lose it
<nick[m]1234>
interestingly the device has linux upstream support ^^
<nick[m]1234>
which wifi device are you now using?
<Grommish>
I've got the R8000 running OEM firmware and a Zyxel running OEM.. both in dump AP mode.. I have the Itus with OpenWrt playing overseer and an ER10x with EdgeOS I'll eventually get back to
<Grommish>
er dumb*
<nick[m]1234>
hmmmm, but wpa3 and owe?
<Grommish>
wpa2
<Grommish>
I don't do handoff, I just have 2 Wifi neworks across 2.4/5ghz on opposite sides of the house
<Grommish>
The Itus and Er10x are no wifi, so it keeps it easy
<Grommish>
The Zyxel is what my ISP wants me to use, but they can sod-off
<Grommish>
It's a EMG3415-B10A which seems to be a one-off for ISPs
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<Tapper>
ksmbd stil not working in master.
<Tapper>
Wed Apr 20 07:38:56 2022 kern.err kernel: [ 170.090512] ksmbd: No IPC daemon response for 20s
<Tapper>
the ksmbd crashes are under Kernel 5.10 because know one seems to know how to how I should get ksmbd to work under kernel 5.15
<Tapper>
ksmbd is all so fucked under OpenWrt 21.xx and 22.xx
<Tapper>
BTW ksmbd is so broken network shares does not even show up under luci even tho I have th eluci-app-ksmbd package installed
<ynezz>
Tapper: I assume, that with 5.15 as a quick workaround, until it's properly packaged, you can just compile it in into your kernel using `make kernel_menuconfig`
<Tapper>
ynezz So I have to remove the ksmbd packages and just use the kmod-ksmbd?
<Tapper>
Will luci-app-ksmbd work then?
<Tapper>
ynezzThe thing is I used samba but it's so dam big.
<Tapper>
I think samba takes up about 5 mb
<ynezz>
I assume, that luci is just a layer above that kernel/userspace stuff, so once you get kernel and userspace working together, then luci should work
* Tapper
nods.
<Tapper>
I will giv it a go later thanks
<Tapper>
Some one should look at fixing ksmbd for 21.xx and 22.xx tho
<ynezz>
so IIUC 5.15.17+ should work with latest ksmbd-tools v3.4.4, for 5.10 you probably need to downgrade ksmbd-tools to version 3.4.2
<shibboleth>
kmod-ovpn-dco - 5.10.111+2021-10-05-1017d4ad-2 - This module enhances the performance of the OpenVPN userspace software by offloading the data channel processing to kernelspace.
<mrkiko>
shibboleth: thanks!!
<shibboleth>
it'd be great to have dco as an option in master though
<ynezz>
rsalvaterra: sure, you've my ack, thanks
<ynezz>
Mangix: can't you just backport the fix commit?
<f00b4r0>
ok so if I create a standard bridge and enslave the mt7915e wifi iface to it with chilli listening on the bridge, it works. If I create a bridge-vlan with chilli listening on the vlan interface, the wireless packets are mangled
<f00b4r0>
and this only happens (so far) with mt7915e
<nbd>
f00b4r0: are received packets mangled, or transmitted packets?
<f00b4r0>
in other words it fails when the wireless device is a member of a bridge-vlan, and works when it's a member of a normal bridge
<f00b4r0>
transmitted ones
<f00b4r0>
received are ok
<nbd>
how are they mangled?
<f00b4r0>
the ethertype is replaced with payload lenght
<nbd>
hm
<nbd>
please try creating a monitor mode interface on the same mt7915 card and bring it up
<f00b4r0>
i've tried manually bisecting mt76 but I can go as far as october 23 2021 before it no longer builds with current master
<nbd>
no need to capture any packets on it
<nbd>
just make sure it's there and active
<nbd>
and see if that affects packet mangling
<f00b4r0>
ok i want to reboot to make sure the result is positive, but it seems to be
<nbd>
ok, so encapsulation offload is messing it up
<nbd>
and i may have an idea why
minimal has joined #openwrt-devel
<nbd>
maybe skb->protocol is not properly initialized for transmitted packets
<f00b4r0>
ok I can confirm that having the monitor interface makes the bug disappear
grift_ has quit [Remote host closed the connection]
StifflersMagic has joined #openwrt-devel
<philipp64>
Is Toke ever on IRC? What's his handle?
philipp64 has quit [Quit: philipp64]
Tapper has quit [Ping timeout: 480 seconds]
philipp64 has joined #openwrt-devel
<tohojo>
philipp64: I am indeed 🙂
<philipp64>
ah, hi. was trying to tweak my config and noticed `qdisc_really_really_advanced` and couldn't figure out what it does because it doesn't seem to be in /etc/init.d/sqm ...
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<tohojo>
iirc, it's just the thing in luci that hides part some of the UI?
<philipp64>
ah.
<philipp64>
so it doesn't affect performance.
<tohojo>
nah
<philipp64>
okay. and how does `overhead` default if it's not set?
<philipp64>
I've got G.PON so I'm assuming it's 14 (6+6+2... i.e. Ethernet V2)
<tohojo>
it defaults to 0
<philipp64>
Hmm... 40 bytes of overhead in native encapsulation mode...
<philipp64>
what are valid values for `linklayer`?
<philipp64>
I see `none` and `atm`...
Tapper has joined #openwrt-devel
<f00b4r0>
nbd: I've successfully backported your patch to 21.02. I understand mt76 will not be updated in 21.02: is it ok if I submit this patch cherry-picked (in packages/kernel/mt76/patches) for inclusion in next point release?
<f00b4r0>
"successfully backported" == it works there too
<nbd>
sure
<f00b4r0>
ok, I'll send to m-l then
jlsalvador has quit [Read error: Connection reset by peer]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<mirko>
is peter stadler around here by any chance?
jlsalvador has joined #openwrt-devel
danitool has joined #openwrt-devel
ecloud_ has quit [Ping timeout: 480 seconds]
dgcampea has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
<jow>
nbd: I'm investigating spurious rpcd issues on very large ubus messages again. From what I've observed, the root cause is that the ubus client code receives an -1/EPIPE in sendmsg(), this causes the ubus client socket to get deregistered from the uloop while the higher level logic still assumes that it is alive
<jow>
nbd: it's a conntrack list dump, part of some real time data exposed by luci via ubus
<jow>
nbd: I'll switch that to cgi-io later, but still I'd like to make rpcd a bit more resillient against this, in order to prevent single plugins/procedures taking down the whole daemon
<nbd>
maybe just split the results into multiple messages
<jow>
is the protocol allowing multiple replies for a single request?
<jow>
or do you mean implementing paging in higher level application logic?
<nbd>
multiple replies per request is alloweed
Tapper has quit [Ping timeout: 480 seconds]
<jow>
hm
<nbd>
you'll get multiple calls to the data_Cb
<jow>
yep, I see
<jow>
usefulnes depends on how the receiver is merging the data though
<jow>
in uhttpd-mod-ubus each reply's attributes will overwrite the previous ones in the result blob buffer, but that can be worked around byx using unique toplevel keys for the partial messages
<nbd>
one possiblity would be to change the code so that on a request you can specify that you want an array of result data tables (one entry per data cb)
<nbd>
so it would be backwards compatible
<jow>
right, some kind of multipart signalling would be needed
<jow>
nbd: thanks, I'll think some more about it and plan for a mitigation
<Habbie>
hurricos, final score with the WL-330 (after a dump via uboot and fighting squashfs until I found sasquatch) - https://wikidevi.wi-cat.ru/Sitecom_WL-330 :)
<Habbie>
hurricos, given that it's 4 MB, i think i won't bother with actual openwrt efforts
Vavooon has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
dgcampea has quit [Remote host closed the connection]
<slh>
at least the ath9k hw rng isn't really 'good' (talking about its raw output, not how it's weighed), but it does improve the situation for these devices - so someone pushed for it to become available. carl9170 is a USB device (and a rather short lived chipset generation), popular, but not really common to be used in routers (I did, for a while, don't want to repeat that again), so probably no one felt
<slh>
it was necessary. similar thinking has probably gone on for b43, no one really knows how 'good' the rng is, the SOCs are aging and don't see that much interest anymore, so probably a reason for no one pushing for it