Why is it sometimes called twice?

Begging for a merge will not speed things up. You multiple times refused to adopt the patch to our guidelines and it is still unclear if this is the right path to go.

Well I do no longer maintain it so it‘s defacto dead. It only served as poc, I rather use some bash aliases now to build my packages and rely on the deb mirror.

No

The recent implementation here uses the python ifconfig module and walks it to detect interfaces marked as beidgable. I found such constructs are way too slow, simply listing ls -1 /sys/class/net (and do some filtering) is magnitudes faster.

I think I drop the script as it was considered as a PoC but its heavily unmaintained

That is what VyConf is for

It‘s implemented in 1.2 but not with the new nftables based NAT backend as the required commands could not be translated from ip6tables.

Validator now prevents this

In addition a show opmode command should be added to list all the USB serial stuff in a human friendly way

Completion helper:

In T421#65476, @gadams wrote:

Recovery from failures does seem generally desirable, but it would also be preferable to discover errors in configuration while in conf code. For this reason, it seems like the best way to handle this would be to defer starting dhcp6c until the very end of configuring all the interfaces, if that's possible. Is there a mechanism already to do this, or should I look into restructuring things slightly.

@gadams it makes no sense to use this as a catch-all thread. New requests/bugs should go into dedicated tasks.

Yes there have been issues with interface naming in the past. Hopefully they are finally resolved in 1.3 now.

https://github.com/vyos/vyos-1x/blob/current/python/vyos/ifconfig/dhcp.py#L113

During testing I've found that there is a well known problem (we had for ethernet interfaces) also in the serial ports. They can be enumerated and mapped to /dev/ttyUSBxxx differently from boot to boot. This is especially painful on my development APU4 board which also has a Sierra Wireless MC7710 LTE module installed which operates via ttyUSB2 (when no serial console cable is attached) - on subsequent boots this can become ttyUSB3 or depending on the number of FT232 dongles I attach.

@gadams your mentioned problem is already fixed in the latest rolling image

@jack9603301 your assumptions are invalid. I have a fully reboot-save PPPoE setup. Please stop making wrong assumptions! and search the code properly!

@gadams, please describe use case where wide does not start and include config with expected result and VyOS version. Sure config can be adjusted, luckily its an open Git repo so just send a PR.

dhclient is not used, wide-dhcp client is started on demand. Also prefixes are properly assigned to interfaces, using this at home for pppoe. Specific prefix size request is implemented as of T2506.

Windows 10 works with SLAAC like a charm.

I tried mocking with your configuration and thus needed to delete the policy statement as I have no policy installed. Maybe you can boot your system with the vyos-config-debug option and share the output? Or send the full config.boot.

Why is there no eth0 on VyOS 1.2.5?

https://github.com/vyos/vyatta-conntrack/commit/02c29a9f1f6ddb3c04aee948781e765a7ca2c829

@jack9603301 please note that this is currently a beta implementation which of course contains bugs. Also the CLI will change in the near future to support requesting specific prefix sizes (T2506)

The ethernet TypeError is fixed in the upcoming rolling release

a) should not be the case

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.

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.

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

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

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

sla-len should be 12 in your case then.

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.

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