ubnt@ubnt:~$ sudo modprobe sctp
modprobe: FATAL: Module sctp not found in directory /lib/modules/4.14.54-UBNT
this isn't openwrt, we know nothing about the stock firmware on your Uni device.
It appears you are using firmware that is not from the official OpenWrt project.
When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.
Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).
If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.
Oh I’m sorry I did not mention this! I have installed OpenWrt on my EdgeRouter-X device (version string : OpenWrt 23.05.6 r24232-539228933c / LuCI openwrt-23.05 branch git-25.222.75657-7ce34fe ). This, along with other IPv6-related lacunae, was the final straw for me to bite the bullet and make the jump.
I have not yet upgraded to the supported version, thinking this is fine for me now - since there are some complications relating to the partition sizing on my device for 24.05. Does the supported version have more kernel compilation options or something?
I just cannot find SCTP in firewall section. Not even a search with / revealed anything useful, like "sctp" protocol match support (NEW) that I found for the ER-X kernel source (only found the module that allows the router itself to use the protocol, which is not that useful). Can you perhaps check and let me know what I’m missing here?
The manual nft command worked! Does this mean SCTP is already part of the base nftables/xtables/netfilter? And how can this be propagated to the LuCI GUI such that it can accept port numbers for SCTP?
I couldn’t find anything with CONFIG_NF_CT_ in the menuconfig though (note that I’m not too acquainted with this kernel compilation thing yet). Could you help me a little with whether I should find this in the menuconfig application? Or should I find it in .config? Or should I manually type it in and not expect any other sign of its presence? Because I expect that in future I might need stateful tracking.
Well, helps if you re-read the thread. make kernel_menuconfig
You can try to complete fw4 to interpret all protocols with ports and all protocols with query-id. I dont see much need for those in a common home. That would need a backward incompatibility ie config v2.0. Significantly bigger than writing your own rules.
Apologies for missing it, but I had already tried both in the beginning : kernel_menuconfig did not yield any difference in the available options for my purpose, couldn’t find any such option… I don’t know what I’m doing wrong though!
Writing my own rules will certainly work for me, but if the OpenWrt firewall supports SCTP properly, is there any reason not to have the UI allow its proper usage?
If the OpenWrt firewall supports sctp it will be pretty lonely out there as nobody else will use it.
I kind of very precisely said that you have to fix up in luci and fw4 that if selected protocol is with ports like udplite then ports are presented in ui and parsed into rules. Otherwise those protocols are handled like ipsec esp without ports.
Understood mostly. Just trying to redo from scratch because something is off with my make kernel_menuconfig now (why is it compiling stuff when I just wanted the menu selection??). Brb.
So I ran into this kind of error (FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/Caching.cpp.o) while makeing kernel_menuconfig which involved building llvm-bpf… apparently the toolchain has to be built before even configuring the kernel build options! Even after I fixed that one I ran into further strange errors involving AMD HSA (!!) I “solved” it by choosing to use the system llvm instead of compiling the one sourced by OpenWrt. Now I’m able to see the actual kernel options! (Earlier the menu was identical to menuconfig options , with some vague errors!)
I’ll report back after compiling — I’ll still need help to install the module in a proper way.
I was finally able to compile the kernel and the relevant modules… Thanks a lot for the help @brada4. I’m using https://blog.blaok.me/patching-an-openwrt-kernel-module/ as a reference in addition to the build system documentation (which is quite good actually).
Now my biggest fear is that installing the kernel (I’m presuming I can’t just insmod my compiled module to the distribution kernel) might cause it to bootloop and lock me out of the device permanently.
Does OpenWrt have any facilities to help with recovering from a bootloop? And of course, requesting some best practices around replacing the distribution kernel with a custom compiled one.
Good guidance.
You have to use sysupgrade file from your build, nor kernel. Also OpenWrt kmods will not work, make a copy of kmod-*-*pk arttifacts from build tree should you need to add one.
Normal packages work. Also note kmod-sctp and sctp-conntrack do not need eachother by any means.
The change from kernel parameter is that sctp will have proper NAT state teacker, like tcp dropping out-of-line packets.
Feel free to report fw4 bugs if * protocol is interpreted as tcp(,udp(,icmp).