dae: 0.4.0 -> 0.6.0rc2

[pokon548]

Description of changes

As 0.4.0 is not compilable after kernel > 6.9, I have updated dae to 0.6.0rc2 and updated this pr. All descriptions down below is coming from the original 0.5.1 pr.

Due to the external dns issue: daeuniverse/dae#412, I had temporarily reverted dae to 0.4.0 in #281740. Now this issue seems to be resolved on 0.5.1, tested using smartdns as local resolver with following configs (sensitive info were redacted for privacy):

config.dae:

global {
  wan_interface: auto

  log_level: info
  allow_insecure: false
  auto_config_kernel_parameter: true
  auto_config_firewall_rule: true

  dial_mode: ip
}

dns {
  upstream {
    global-dns: 'udp://127.0.0.1:53100'
    china-dns: 'udp://127.0.0.1:53101'
  }
  routing {
    request {
      qname(geosite:cn) -> china-dns
      fallback: global-dns
    }
  }
}

node {
  local: [REDACTED]
}

group {
  local {
    policy: min_moving_avg
  }
}

routing {
  pname(smartdns) && dip(geoip:cn) -> direct
  pname(smartdns) -> local
  dip(geoip:private) -> direct
  
  fallback: local
}

smartdns:

    services.smartdns = {
      enable = true;
      settings = {
        bind = [ ":53100 -group global-dns" ":53101 -group china-dns" ];
        server = "8.8.8.8 -bootstrap-dns";
        user = "nobody";
        force-AAAA-SOA = "yes";
        server-https = [
          "https://8.8.8.8/dns-query -group global-dns -exclude-default-group"
          "https://223.5.5.5/dns-query -group china-dns -exclude-default-group"
        ];
      };
    };

Feel free to leave comments here if external dns works for you :)

By the way, I basically just changed hash and vendorHash to adapt 0.5.1, based on the original 0.5.0 commit from @zzzsyyy: #278695. It would not be possible for me to draft this pr so fast without that commit, so big thanks for your kind contribution!

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[oluceps]

Does this version function properly on your device? I've tested on mine and it fails to filter connections effectively. Everything works correctly on v0.4.0.

[pokon548]

Does this version function properly on your device?

Yes, I had deployed 0.5.1 on one of my proxmox vm for more than a week, without any issues.

it fails to filter connections effectively.

Did you means the routing config will not works for you? If so, will try to reproduce on my vm (Seems also works fine for me).

[oluceps]

Does this version function properly on your device?

Yes, I had deployed 0.5.1 on one of my proxmox vm for more than a week, without any issues.

it fails to filter connections effectively.

Did you means the routing config will not works for you? If so, will try to reproduce on my vm (Seems also works fine for me).

The manifestation is a connectivity check failure, as well as unsuccessful curl requests, it is unable to capture any connections from the host. Not only me find this issue. I'm trying to bisect commits. May need to add module options if there are changes that affect compatibility. FWIW the log of testing dae main HEAD: https://pb.nyaw.xyz/pleasing-crayfish.txt and my config file https://pb.nyaw.xyz/climbing-seahorse.txt.

[pokon548]

Does this version function properly on your device?

Yes, I had deployed 0.5.1 on one of my proxmox vm for more than a week, without any issues.

it fails to filter connections effectively.

Did you means the routing config will not works for you? If so, will try to reproduce on my vm (Seems also works fine for me).

The manifestation is a connectivity check failure, as well as unsuccessful curl requests, it is unable to capture any connections from the host. Not only me find this issue. I'm trying to bisect commits. May need to add module options if there are changes that affect compatibility. FWIW the log of testing dae main HEAD: pb.nyaw.xyz/pleasing-crayfish.txt and my config file pb.nyaw.xyz/climbing-seahorse.txt.

Reproduced with following config (Not minimal): https://fars.ee/o6Vp. smartdns config remains intact.
Will try to biscuit the issue soon.

[pokon548]

Does this version function properly on your device?

Yes, I had deployed 0.5.1 on one of my proxmox vm for more than a week, without any issues.

it fails to filter connections effectively.

Did you means the routing config will not works for you? If so, will try to reproduce on my vm (Seems also works fine for me).

The manifestation is a connectivity check failure, as well as unsuccessful curl requests, it is unable to capture any connections from the host. Not only me find this issue. I'm trying to bisect commits. May need to add module options if there are changes that affect compatibility. FWIW the log of testing dae main HEAD: pb.nyaw.xyz/pleasing-crayfish.txt and my config file pb.nyaw.xyz/climbing-seahorse.txt.

Comment out this line seems resolved the issue for me:

udp_check_dns: 'dns.google.com:53,8.8.8.8,2001:4860:4860::8888'

Could you try to also comment out this line in your profile and see if the issue gone for you?

My bad, seems the actual issue comes with this parameter:

auto_config_firewall_rule

If I set this option to false, then I could reproduce consistent result just like yours. However if setting it to true, then the issue disappeared immediately. Not sure why this would cause the issue.
Config file: https://fars.ee/xn0d.

[oluceps]

Does this version function properly on your device?

Yes, I had deployed 0.5.1 on one of my proxmox vm for more than a week, without any issues.

it fails to filter connections effectively.

Did you means the routing config will not works for you? If so, will try to reproduce on my vm (Seems also works fine for me).

The manifestation is a connectivity check failure, as well as unsuccessful curl requests, it is unable to capture any connections from the host. Not only me find this issue. I'm trying to bisect commits. May need to add module options if there are changes that affect compatibility. FWIW the log of testing dae main HEAD: pb.nyaw.xyz/pleasing-crayfish.txt and my config file pb.nyaw.xyz/climbing-seahorse.txt.

Comment out this line seems resolved the issue for me:

udp_check_dns: 'dns.google.com:53,8.8.8.8,2001:4860:4860::8888'

Could you try to also comment out this line in your profile and see if the issue gone for you?

My bad, seems the actual issue comes with this parameter:

auto_config_firewall_rule

If I set this option to false, then I could reproduce consistent result just like yours. However if setting it to true, then the issue disappeared immediately. Not sure why this would cause the issue. Config file: https://fars.ee/xn0d.

This config caused the same issue on my machine when I set the option auto_config_firewall_rule to true, actually, it also happened when I disabled my firewall, so it may not be the reason I guess.

I'm not sure if this issue widely exists on v0.5.1 with nixos, so I approve of making it be tested by more people in some way.

[oluceps]

Result of nixpkgs-review pr 287239 run on x86_64-linux 1

1 package built:

• dae

[SuperSandro2000]

Do we really need the rc version or can we use a release before that?

[pokon548]

Do we really need the rc version or can we use a release before that?

Unfortunately no, as the last release 0.5.1 is also not compilable on kernel 6.9 (which is already landed in unstable branch). Related pr daeuniverse/dae#483 is not appliable for 0.5.1 too.