@c-po In addition, I also feedback several questions (if this is not a problem, please tell me the correct understanding and use):

PR for this task https://github.com/vyos/libpam-radius-auth/pull/3
I propose to use always source-address as NAS-IP-Address if it defined

I added some comments on the PR. First I thought this is a duplicate of T2507 but technically it's not as pdns-recursor supports 2 types of lua file: lua-dns-script and lua-config-file. This task is for lua-dns-script while T2507 is for lua-config-file.

Upstream says this is normal behavior when DNSSEC is enabled, so the workaround that I'm working on (addNTA) is actually the proper fix.

Tested successfully on 1.3-rolling-202005250117

vyos@RTR1:~$ show sstp-server sessions 
 ifname | username |     ip     | ip6 | ip6-dp | calling-sid | rate-limit | state  |  uptime  | rx-bytes | tx-bytes 
--------+----------+------------+-----+--------+-------------+------------+--------+----------+----------+----------
 sstp0  | test     | 100.64.2.0 |     |        |   x.x.x.x.  |            | active | 00:01:16 | 27.9 KiB | 80.3 KiB

Tested on 1.3-rolling-202005250117, works as expected.

@jjakob, yes, thank you.
PR for 1.3: https://github.com/vyos/vyos-1x/pull/434
I will summit PR for 1.2 once 1.3 is released and tested.

PR https://github.com/vyos/vyatta-cfg-quagga/pull/47
for 1.2 and 1.3.

I tried out DHCPv6-PD but so far no luck (but for a separate reason).

I'm would like to try out the new VyOS 1.3 DHCPv6-PD feature.

Prefix delegation is a very important function, which needs to be used to provide routable prefix segment allocation to users.

You can download 20200523 and later scrolling images to use this feature

Dhcpv6-pd can be used normally at present, and it works well in my ISP.

I have just done a bit of background research to understand this change, after I noticed that the level option was deleted from my VyOS config.

See also: https://phabricator.vyos.net/T2209 (Documentation has reference to the old 'user x level admin' option)

These pages also needs updating:

• https://support.vyos.io/en/kb/articles/adding-users-2
• https://support.vyos.io/en/kb/articles/vyos-user-privilege-levels-2

Here is a PR for the work: pull 425 for vyos-1x package

From comments, it looks like this feature is now available?

If this field is only the len, of prefix, there is no need to use prefix writing.

I replaced the distributed guest utilities (vyos-xe-guest-utilities) with the ones that come with xcp-ng. But this changed nothing regarding the packet loss. Tho, now they get properly recognized by xcp-ng :-)

I‘m asking myself if length should be specified as decimal number or as ::/60 prefix?

The "auto grep" could be added to show log indeed that it only displays you pppoe stuff.

In T2505#64896, @jjakob wrote:

If this can be solved by a kernel update, there was talk about maybe having different build "flavors" in the past - one with all the hardware nic drivers, one without. The minimal image could then have the latest (5.x) kernel.
There's T2085 which prevents us from testing any newer kernel ourselves as it's built by Jenkinsfiles in the CI, we'd need to manually do the steps the CI does to build a kernel. I proposed a shared script solution for these repositories in that task that could be called from both the CI and vyos-build, this would allow anyone to build all packages, including the kernel, through vyos-build, just for cases like this.

We probably should send this PoC script (vyos-build/scripts/build-packages.) to the graveyard as it causes more trouble then good I feel.

Note that it is now possible to set the pre-login banner to an empty string: T2099

Guess the CLI needs a change here as this requirement was overseen. It could look something like this (note that PPPoE can be replaced by any other interface), need to work out the details.

The called code can return 3 - in that case in that case _run should return an empty string

Thank you. Finally, RA was able to set and distribute all the new IPv6 64bits prefixes with the following instructions:

Just found this ticket after upgrading and wondering where the show interfaces pppoe pppoe0 log command had gone. I did find it useful to check why a PPPoE interface hadn't come up.

@jack9603301 Do you have a working RA on that interface? You can set service router-advert interface <if> prefix ::/64 for RA to advertise all prefixes on the interface. That way if the DHCPv6-PD prefix changes it will send advertisements for the new prefix automatically.

@Sonicbx @jjakob I also created https://phabricator.vyos.net/T2504 - I think we duplicated the issue here. You can close whichever issue you want.

@c-po At present, through DHCPv6 PD, IP can be obtained on the bridge, but cannot be distributed to the client through SLAAC. Is it my configuration error?

If this can be solved by a kernel update, there was talk about maybe having different build "flavors" in the past - one with all the hardware nic drivers, one without. The minimal image could then have the latest (5.x) kernel.
There's T2085 which prevents us from testing any newer kernel ourselves as it's built by Jenkinsfiles in the CI, we'd need to manually do the steps the CI does to build a kernel. I proposed a shared script solution for these repositories in that task that could be called from both the CI and vyos-build, this would allow anyone to build all packages, including the kernel, through vyos-build, just for cases like this.

In T2505#64889, @c-po wrote:

There is no newer kernel then 4.19.124 on the 4.19x train. Newer Kernels do not work as the out-of-tree Intel drivers for the NICs and QAT won‘t compile for Kernel >5.3 and that is bot an LTS one.

Cool, thanks for pointing this out; I will take T2501, and will probably rename for clarity.

There is no newer kernel then 4.19.124 on the 4.19x train. Newer Kernels do not work as the out-of-tree Intel drivers for the NICs and QAT won‘t compile for Kernel >5.3 and that is bot an LTS one.

Welcome - need to make a prefix-hint CLI node for the future

https://phabricator.vyos.net/T935 Here’s the same thing happening in the past. I think it was resolved by doing kernel updates? Can someone do a kernel update in the rolling build?

@jestabro thanks for that tip, vyos-config-debug helped me track down the failing code. At least I can continue working until T2501 is fixed.

@jjakob, yes I see the issue there; but firstly, did you try debugging with boot parameter 'vyos-config-debug' ? cf.

Yup, sorry. Just figured that out too after reading https://blog.kylemanna.com/ipv6/using-native-ipv6-via-comcast-in-san-francisco/.

@jjakob yes, thanks for pointing this out ...

No, its just an ID. Please read my comments above and inser the prefix ::/60 infinity; line and reboot

Appreciate it. Sorry, I had assumed VyOS was using dhclient, not DHCP6c.

You only receive a /64 prefix, try adjusting the template then change sla-len to 4

In T421#64836, @c-po wrote:

sla-len should be 12 in your case then.

If that does not work, it could be that you need to hint comcast you want to have a /60 PD, by addin prefix ::/60 infinity; here into line 26

https://github.com/vyos/vyos-1x/blob/current/data/templates/dhcp-client/ipv6.tmpl#L26

or on the router itself you find the file here: /usr/share/vyos/templates/dhcp-client/ipv6.tmpl

@jestabro I think T2501 is related to this - can you take a look?

Thanks, @fetzerms !

sla-len should be 12 in your case then.

In T421#63911, @c-po wrote:

From the Git commit:

commit faa85accc99d6ff777f12f5dd9e43a6dd8f7e7a2 (origin/ipv6-pd)
Author: Christian Poessinger <christian@poessinger.com>
Date:   Sun May 17 20:15:45 2020 +0200

    pppoe: dhcpv6-pd: T421: initial support

    The following configuration will assign a /64 prefix out of a /56 delegation
    to eth0. The IPv6 address assigned to eth0 will be <prefix>::ffff/64.
    If you do not know the prefix size delegated to you, start with sla-len 0.

      pppoe pppoe0 {
          authentication {
              password vyos
              user vyos
          }
          description sadfas
          dhcpv6-options {
              delegate eth0 {
                  interface-id 65535
                  sla-id 0
                  sla-len 8
              }
          }
          ipv6 {
              address {
                  autoconf
              }
              enable
          }
          source-interface eth1
      }

      vyos@vyos:~$ show interfaces
      Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
      Interface        IP Address                        S/L  Description
      ---------        ----------                        ---  -----------
      eth0             2001:db8:8003:400::ffff/64        u/u

This is a proof of concept. What is not working?

• IPv6 address is not removed from delegated interface
• router-advertisements? Not tested yet!

In T2457#63617, @jjakob wrote:

Why not just use the OS's ping command? It does address resolution. Resolving a IP address as hostname would leak the IP via DNS as well.

That patch is invalid as ping.py does not exist under vyos-1x package, its in vyatta-op.

@c-po I suspect that the problem has been found, but after I executed the restart PPPoE command, the default travel was lost. My configuration name wrote the following static route:

interface-route 0.0.0.0/0 {

next-hop-interface pppoe0 {
}

}
interface-route6 ::/0 {

next-hop-interface pppoe0 {
}

}
table 150 {

interface-route 0.0.0.0/0 {
    next-hop-interface pppoe0 {
    }
}
interface-route6 ::/0 {
    next-hop-interface pppoe0 {
    }
}

}

But it disappeared after disconnect interface pppoe0.

Just thought I'd say that this implementation has worked for my DHCPv6-PD enabled ISP in Australia :)

@jestabro Sorry for the delay, I did not find a proper maintenance window... Today I verified the fix and it seems to work. My automation scripts run through just fine, without the error.

https://github.com/vyos/vyos-1x/pull/422/files

low-brow caching:

A friend also thought about set service nettty for network tty (which it is infact)