Daniel Golle

Instead of creating a patch file in `package/kernel/mt76/patches` this patch should be sent upstream to the linux-wireless mailing list, merged into the wireless-next tree and then it can be picked...

I don't think @nbd168 is willing to accept downstream patches on mt76. And as it is a "problem that happens in the field" that's a good argument for upstream Linux...

@LorenzoBianconi @nbd168 Any idea what is going on here? The same version of wireless backports should be used in both cases. I'm currently traveling and don't have time to look...

@danpawlik When using OpenWrt all you stated above is currently true. There is another approach for layer 2 offloading pending upstream approval implemented by @ericwoud which doesn't require the `bridger`...

I got several devices with 64 MiB of RAM and they all boot fine, even with Linux 6.6. In order to run asterisk (!) on some of them I use...

@arinc9 Let me know if any additional patches are needed on top of that for MPTCP.

The idea behind enabling it by default is to allow users of the binary distribution to make use of MPTCP tunneling for link aggregation. There is apparently huge demand for...

Thank you @hauke for bringing the existing pull requests to my attention. I've picked the module from #14323 and made `CONFIG_KERNEL_MPTCP_IPV6` dependent on `CONFIG_IPV6`.

> what about bpf schedulers from mptcp next? I'm open to include those in a future PR backporting the necessary changes from net-next once they are available there.

The way Alpine does it works fine for libraries which provide a versioned `.so.$ABIVERSION` file. However, it doesn't work for ABI-versioned plugins like `libustream-ssl.so`.