Steps involved in adding a new kernel version

For Developers
1

I'd like to build the 6.10 series of kernels for x86/64. I do not care about other targets. As I type this, the 6.10 series of kernels is current stable mainline so I would like to target that. I did find this thread.

What I have done so far is:

  • copy target/linux/x86/patches-6.6 to target/linux/x86/patches-6.10 and refresh them
  • copied the respective 6.6 files to 6.10: include/kernel-6.10 target/linux/x86/64/config-6.10 target/linux/x86/config-6.10
  • Edited target/linux/x86/Makefile

Is there a make target that will refresh the needed kernel configs ie make olddefconfig or something unique to the OpenWrt build system? Thanks for any tips.

2

Long road, not trivial, but I will note you missed a wee bit:
target/linux/generic/
and IIRC I saw a x86 6.10k WIP somewhere...

3 Likes
3

Thanks, I copied over the patches from target/linux/generic/ to their respective 6.10 dirs and am refreshing them now.

  1. If you can point me to someone else's WIP for 6.10 that would great
  2. Any info on updating the configs?
4

It is not announced to be LTS series, so it will end before you manage to copy files.

1 Like
5

Valid point, I still want to know about updating the kernel configs though.

6

You are trying to do a lot of work with apparently very small gain!?

So what have you found in 6.10 that is so important?

To change a kernel takes a couple of month just to get the kernel working with all patches and differences since last upgrade. It is like the software dev version of brain surgery.

And once you have a working buildable kernel the work to get it working with actual devices comes.

And this is not counting the dev time added if any dependable package has been changed that make the whole project go to a stand still until solved.

Maybe you haven’t noticed, but we don’t have a stable release for 2024 yet, and I can’t even say it will come one. The reason for that is because it was decided half way done to upgrade from 6.1 to 6.6 to get longer available LTS time.

1 Like
7

The huge, layered, patch stacks (which wouldn't be necessary for x86_64, but are for pretty much all other targets) is what makes this endeavour difficult - identifying what has been merged meanwhile, what has been merged in a different way and needs changes elsewhere, what needs porting, what needs rebasing and fixing. The first target taking on this task is obviously the most difficult one (and for strange reasons, that is rarely x86_64). 'Sadly' (no, I do understand this, but it makes things difficult) a lot of patches have crept into 'generic', because they are wanted/ needed for multiple targets - so it's rather difficult to distinguish between patches that are necessary for OpenWrt to work properly (e.g. some sysctl changes the firewall relies upon), which are just there to support special hardware (as in not necessary for x86) for multiple targets that isn't supported mainline yet and which are just hacks to decrease kernel size, reduce unaligned accesses and similar optional cruft (which is necessary for extremely resource constrained devices, but just makes rebasing difficult).

As a result, porting OpenWrt to newer kernels is harder as it could/ should be, but sadly most of the common plastic routers really require those patches. Only few targets are (mostly) mainline ready, without needing extensive patches of some kind. Obviously there is a strong desire for upstream-first development in OpenWrt, to reduce these pains - but there sadly are many required patches that will need a long time cooking to become palatable to mainline developers (and for many of the old targets, where even more patching was required or the recent QCA based targets with large gaps in mainline support, this is rather wishful thinking - making this a question between wanting to get this hardware supported while it still matters or taking years of 'unusable' mainline development).

It would be great if OpenWrt were easier to push forward to newer kernels, but if it were - most of the primary targets would pretty much fall by the wayside (or would require a massive influx of new/ additional developer manpower to stay closer on top of mainline developments).

7 Likes
8

Thanks for the replies, all. I was thinking I would good to learn how to do the update, but see now that even for x86/64 that it isn’t trivial and for a non-LTS kernel, too much effort.

I am assuming that the answer to my question about the kernel config update is: it’s a manual process to add the new symbols to, generic, x86, and x86/64.

9

Unless I missed some magic bullet (very well possible), it was a fully manual process for me - symbol by symbol (wait for the the build to fail, add the new settings, rinse and repeat; yes, there is make kerneloldconfig, but that didn't catch everything).

4 Likes
10

I would like to have amd-pstate Preferred Core support which was mainlined in the 6.9 series of kernels.

2 Likes
11

you can always try * running openwrt in a container, it's actually pretty easy with systemd-nspawn. In a way it makes more sense to do that with a x86 target anyway, they typically exceed the requirements to run openwrt by a fair amount, especially in memory. This let you also use a single host to run multiple containers of openwrt, so for instance you can have an internet router, then a vpn router, different containers same host and from my experience it works well, but I haven't tried advanced things like SQM/QOS or advanced firewall rules the only limitation I see so far for me is the ntp server facilities don't work, but it seems like there are --capability arguments that can be used to grant access. Another thing I want to look into is limiting what cpus a container can run on, which appears to be possible, so then the routing performance won't be impacted as much if I do a heavy task like encoding or something in a nother container or the host.

I've been thinking about outlinining all the steps to do it, even to make things easier for myself next time I set things up.

* I realise it's unsupported and may not work as expected

12

It is explicitly unsupported, because it doesn't and can't work. In a container, OpenWrt can't load/ unload kernel modules, set sysctl configurations or get hardware (device) access, this doesn't work. Yes, you can get the webinterface, but the primary functionality is fundamentally broken and insecure (as settings the firewall depends on simply fail).

1 Like
13

I get what you are saying but this is false. DHCP leases, NAT, and wireless AP (after passing through the device to the container) work fine

Not sure about security, but the firewall rules all appear to be existing and operating just fine for me

nft list ruleset
table inet fw4 {
        chain input {
                type filter hook input priority filter; policy drop;
                iif "lo" accept comment "!fw4: Accept traffic from loopback"
                ct state vmap { invalid : drop, established : accept, related : accept } comment "!fw4: Handle inbound flows"
                iifname "br-lan" jump input_lan comment "!fw4: Handle lan IPv4/IPv6 input traffic"
                iifname "ibr0" jump input_wan comment "!fw4: Handle wan IPv4/IPv6 input traffic"
                iifname "nordvpn" jump input_wanClamp comment "!fw4: Handle wanClamp IPv4/IPv6 input traffic"
                jump handle_reject
        }

        chain forward {
                type filter hook forward priority filter; policy drop;
                ct state vmap { invalid : drop, established : accept, related : accept } comment "!fw4: Handle forwarded flows"
                iifname "br-lan" jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
                iifname "ibr0" jump forward_wan comment "!fw4: Handle wan IPv4/IPv6 forward traffic"
                iifname "nordvpn" jump forward_wanClamp comment "!fw4: Handle wanClamp IPv4/IPv6 forward traffic"
                jump handle_reject
        }

        chain output {
                type filter hook output priority filter; policy accept;
                oif "lo" accept comment "!fw4: Accept traffic towards loopback"
                ct state vmap { invalid : drop, established : accept, related : accept } comment "!fw4: Handle outbound flows"
                oifname "br-lan" jump output_lan comment "!fw4: Handle lan IPv4/IPv6 output traffic"
                oifname "ibr0" jump output_wan comment "!fw4: Handle wan IPv4/IPv6 output traffic"
                oifname "nordvpn" jump output_wanClamp comment "!fw4: Handle wanClamp IPv4/IPv6 output traffic"
        }

        chain prerouting {
                type filter hook prerouting priority filter; policy accept;
                iifname "br-lan" jump helper_lan comment "!fw4: Handle lan IPv4/IPv6 helper assignment"
        }

        chain handle_reject {
                meta l4proto tcp reject with tcp reset comment "!fw4: Reject TCP traffic"
                reject comment "!fw4: Reject any other traffic"
        }

        chain input_lan {
                ct status dnat accept comment "!fw4: Accept port redirections"
                jump accept_from_lan
        }

        chain output_lan {
                jump accept_to_lan
        }

        chain forward_lan {
                tcp dport 853 counter packets 0 bytes 0 jump handle_reject comment "!fw4: ubus:https-dns-proxy[instance1] rule 1"
                udp dport 853 counter packets 0 bytes 0 jump handle_reject comment "!fw4: ubus:https-dns-proxy[instance1] rule 1"
                jump accept_to_wan comment "!fw4: Accept lan to wan forwarding"
                jump accept_to_wanClamp comment "!fw4: Accept lan to wanClamp forwarding"
                ct status dnat accept comment "!fw4: Accept port forwards"
                jump accept_to_lan
        }

        chain helper_lan {
        }

        chain accept_from_lan {
                iifname "br-lan" counter packets 294 bytes 20213 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
        }

        chain accept_to_lan {
                oifname "br-lan" counter packets 14 bytes 2000 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
        }

        chain input_wan {
                meta nfproto ipv4 udp dport 68 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCP-Renew"
                icmp type echo-request counter packets 0 bytes 0 accept comment "!fw4: Allow-Ping"
                meta nfproto ipv4 meta l4proto igmp counter packets 0 bytes 0 accept comment "!fw4: Allow-IGMP"
                meta nfproto ipv6 udp dport 546 counter packets 3 bytes 643 accept comment "!fw4: Allow-DHCPv6"
                ip6 saddr fe80::/10 icmpv6 type . icmpv6 code { mld-listener-query . no-route, mld-listener-report . no-route, mld-listener-done . no-route, mld2-listener-report . no-route } counter packets 0 bytes 0 accept comment "!fw4: Allow-MLD"
                icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply, nd-router-solicit, nd-router-advert } limit rate 1000/second burst 5 packets counter packets 7 bytes 1680 accept comment "!fw4: Allow-ICMPv6-Input"
                icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, nd-neighbor-solicit . no-route, nd-neighbor-advert . no-route, parameter-problem . admin-prohibited } limit rate 1000/second burst 5 packets counter packets 4 bytes 272 accept comment "!fw4: Allow-ICMPv6-Input"
                jump reject_from_wan
        }

        chain output_wan {
                jump accept_to_wan
        }

        chain forward_wan {
                icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply } limit rate 1000/second burst 5 packets counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward"
                icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, parameter-problem . admin-prohibited } limit rate 1000/second burst 5 packets counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward"
                meta l4proto esp counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-IPSec-ESP"
                udp dport 500 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-ISAKMP"
                jump reject_to_wan
        }

        chain accept_to_wan {
                oifname "ibr0" counter packets 19 bytes 5643 accept comment "!fw4: accept wan IPv4/IPv6 traffic"
        }

        chain reject_from_wan {
                iifname "ibr0" counter packets 0 bytes 0 jump handle_reject comment "!fw4: reject wan IPv4/IPv6 traffic"
        }

        chain reject_to_wan {
                oifname "ibr0" counter packets 0 bytes 0 jump handle_reject comment "!fw4: reject wan IPv4/IPv6 traffic"
        }

        chain input_wanClamp {
                jump reject_from_wanClamp
        }

        chain output_wanClamp {
                jump accept_to_wanClamp
        }

        chain forward_wanClamp {
                jump reject_to_wanClamp
        }

        chain accept_to_wanClamp {
                oifname "nordvpn" counter packets 729 bytes 186795 accept comment "!fw4: accept wanClamp IPv4/IPv6 traffic"
        }

        chain reject_from_wanClamp {
                iifname "nordvpn" counter packets 1 bytes 58 jump handle_reject comment "!fw4: reject wanClamp IPv4/IPv6 traffic"
        }

        chain reject_to_wanClamp {
                oifname "nordvpn" counter packets 0 bytes 0 jump handle_reject comment "!fw4: reject wanClamp IPv4/IPv6 traffic"
        }

        chain dstnat {
                type nat hook prerouting priority dstnat; policy accept;
                iifname "br-lan" jump dstnat_lan comment "!fw4: Handle lan IPv4/IPv6 dstnat traffic"
        }

        chain srcnat {
                type nat hook postrouting priority srcnat; policy accept;
                oifname "ibr0" jump srcnat_wan comment "!fw4: Handle wan IPv4/IPv6 srcnat traffic"
                oifname "nordvpn" jump srcnat_wanClamp comment "!fw4: Handle wanClamp IPv4/IPv6 srcnat traffic"
        }

        chain srcnat_wan {
                meta nfproto ipv4 masquerade comment "!fw4: Masquerade IPv4 wan traffic"
        }

        chain srcnat_wanClamp {
                meta nfproto ipv4 masquerade comment "!fw4: Masquerade IPv4 wanClamp traffic"
        }

        chain raw_prerouting {
                type filter hook prerouting priority raw; policy accept;
        }

        chain raw_output {
                type filter hook output priority raw; policy accept;
        }

        chain mangle_prerouting {
                type filter hook prerouting priority mangle; policy accept;
        }

        chain mangle_postrouting {
                type filter hook postrouting priority mangle; policy accept;
                oifname "nordvpn" tcp flags syn / fin,syn,rst tcp option maxseg size set rt mtu comment "!fw4: Zone wanClamp IPv4/IPv6 egress MTU fixing"
        }

        chain mangle_input {
                type filter hook input priority mangle; policy accept;
        }

        chain mangle_output {
                type route hook output priority mangle; policy accept;
        }

        chain mangle_forward {
                type filter hook forward priority mangle; policy accept;
                iifname "nordvpn" tcp flags syn / fin,syn,rst tcp option maxseg size set rt mtu comment "!fw4: Zone wanClamp IPv4/IPv6 ingress MTU fixing"
        }

        chain dstnat_lan {
                tcp dport 53 counter packets 0 bytes 0 redirect to :53 comment "!fw4: ubus:https-dns-proxy[instance1] redirect 0"
                udp dport 53 counter packets 182 bytes 12430 redirect to :53 comment "!fw4: ubus:https-dns-proxy[instance1] redirect 0"
        }
}
14

That is incorrect, but I'm not going to repeat this again. A lot of functionality required by OpenWrt is not just userspace based, but depends on kernel features and settings (among others, sysctl). Those things not working is dangerous, both in terms of things not working at all and more subtile security holes.

1 Like
15

Yeah it's fair enough, i'm going to keep using it myself since it seems ok to me for my use case

16

If the time isn’t working the encryption isn’t working and then TLS can get disconnected mostly depending on how much wrong time you have and if it is wrong before or after real time.

Encryption to begin with is hard to get it working on real hardware. To get meaningful entropy in virtual environments is just making it even harder.

17

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.