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.

Maybe you need pppoe option +ipv6 ipv6cp-use-ipaddr?
https://askubuntu.com/questions/56890/ipv6-over-pppoe
I don't use IPv6 over PPPoE so I don't know much more unfortunately.
Edit: if I understand that option correctly, it tells pppd to assign the address itself, so you don't need (must not use) ipv6 address autoconf in that case. It all depends on how your ISP implements IPv6 - autoconf is for SLAAC only.

One of the functions in Section (python/vyos/ifconfig/section.py) should provide a replacement

I think this would be even better: https://github.com/lime45/serial/blob/master/resize.c (it's a stripped down resize.c), I haven't tested it yet though. I'm not sure where it would be best to put it, as it's a separate compiled program. Other such programs have their own repositories (vyos-utils), maybe 'vyos-xterm-resize' would be best.
I'm busy with work projects until at least next week so VyOS is on the backburner, when I get more time I'd like to rewrite the old console setup code.

Note however, that of the 2 mentioned shell script methods to poll the terminal emulator for its size, the first one (res()) didn't work for me (using GNU screen as the terminal, it returned an error after timeout), the 2nd one (res2()) worked (which is the one using xterm's special escape code). Both suffer from the same 0.5s delay, so the best would be to use xterm-resize, which is almost immediate.

There is no way to send a SIGWINCH over serial - see https://unix.stackexchange.com/a/19265
We can, however, poll the terminal for its size - at login and on every command exit (bash trap DEBUG)

As a workaround you can set it to a non-0 value to make the interface work. Obviously it changes the configuration so it doesn't fix the issue.

@c-po beat me to it by 1 minute - I was wondering why my PR wouldn't merge. I apologise for the error.

Right - that should be 'addresses-add' - the keys are different from other interfaces, and I don't have any tunnels configured to test. I'll make a patch.

Ducumentation at https://docs.vyos.io/en/latest/interfaces/ethernet.html#cfgcmd-set-interfaces-ethernet-interface-ipv6-address-autoconf
is inaccurate, forwarding is not disabled if autoconf is set. It probably refers to behavior before a rewrite was done and should be updated.

https://github.com/vyos/vyos-1x/pull/407

Replicated the issue, I can't get a autoconf address just by setting ipv6 address autoconf. The problem is accept_ra=1, which means to not accept RAs if forwarding=1 (which it is, as we're a router).
Running sudo sh -c echo 2 > /proc/sys/net/ipv6/conf/br2/accept_ra' will make it accept RAs. We must fix the issue by also doing this in the interface scripts.

why does DHCPv6 provide an address with a prefix of 128?

@dmbaturin numeric breaks with --non-negative 0 (should be true)

$ /usr/libexec/vyos/validators/numeric --non-negative 0
Fatal error: exception Invalid_argument("compare: abstract value")

The virtual machine takes DHCPv6 (over opnsense firewall virtual machine) directly from the main route of vyos1, but after waiting for a while, it can only get the suffix with the prefix of 128 that cannot be routed.

Do you have service router-advert set on the interface that you want to have the fc00:470:f1cd:101::/64 on, and does it have managed-flag set? For a client to use DHCPv6, it must first get a RA with managed flag, only then it'll try DHCPv6. The interface must not have no-default-link-local, because RA and DHCPv6 depend on a link-local to work.
What does your show interfaces and show service router-advert show protocols config look like, and also run show ipv6 route and run show dhcpv6 server leases?
I'm running 202005090117 as well and I have no problem with DHCPv6, so the problem must be with your configuration.

I did something similar, including generating the changelog with name/email and releasing, here: https://github.com/jjakob/vyos-build/commit/8353f1653be76c5b200b9357ebb9d76a84d3139c
The version name generated is also one I arrived at after some consulting, what confused me the most was what the precedence of the special characters is, that wasn't very well documented in debian's docs - elbandi's suggestions are all correct and very good.

Since PR#376 I'm getting nothing logged into the file set by vyos.log.debug at all:

Hmm, another thing - how about hot-pluggable ethernet cards? They could be USB, or in the enterprise world servers that support PCIe hot-plug could have ethernet cards swapped on-the-fly. I'm thinking the MTU detector script would need to be executed via udev rules on 'add' events.

Comparison of the numeric validator:

$ time sudo sh -c 'for ((n=0;n<1000;n++)); do /usr/libexec/vyos/validators/numeric 1; done'

New tests with the OCaml validate-value (same machine as above)

$ time sudo sh -c 'for ((n=0;n<1000;n++)); do ipaddrcheck --is-any-net "192.0.2.1/24"; done'

This is an issue with the new OCaml validator 29dee3abb55d0f0c6b91b311f30521b45d7e46b6 @dmbaturin

Reproduced with 1.3-rolling-202005090117

I see the XML format did use to have a way to set 'type', but this was regarded as unimportant and removed. It's very important for the bash completion scripts and needs to be added back.

I again ran into a situation where it would be nice if create=False were the default, and if we could use the Interface class without creating the physical interface. The bridge member port configuration defaults were previously stored as a dict in interfaces-bridge.py, but as I added a method Interface.add_to_bridge() that all interfaces can call on themselves, I couldn't place the default port config into BridgeIf: when creating a bridge for the first time, the physical interface doesn't exist, but we need to get the member port default config in interfaces-bridge.py get_config() without creating the physical bridge interface (this should only happen in apply()). Thus I had to put it in util.get_bridge_member_config(). If I could call BridgeIf.get_member_config() when the physical interface doesn't exist without creating the physical interface, thet code could be moved from vyos.util into BridgeIf.

Thanks to @thomas-mangin there is now a common function to parse common interface options in configdict.intf_to_dict() and other common functions to get (configtree.add_to_dict()), verify and apply (ifconfig-vlan.py) vif and vif-s/vif-c configuration which simplifies things a lot. It can be used by other interfaces that support those options (all L2 interfaces, and tunnels in L2 mode). Those functions are already used by bonding, bridge, ethernet, pseudo-ethernet and wireless, it wouldn't be much work to add them to other L2-capable interfaces.

How would the auto-detection work? Go through all the possible MTUs one by one? (a binary search would be way better) I'm not sure how long that would take for systems with lots of interfaces. We also need to then save this limitation somewhere permanent, and read it from the interface code, possibly a custom validator script (the shell completion can't be made dynamic). I guess this would be okay, depending on how much time it would take. The speed would depend on the interface driver. There could be drivers that are very slow, we couldn't test them and people would complain.

Please test using the latest rolling ISO at https://downloads.vyos.io/?dir=rolling/current/amd64 which has multiple fixes for interfaces included. Also, I still don't understand what the exact issue is. I have a similar configuration here and I have no issues with the image from 20200509.

Since the issue is resolved can this be closed?

I've fixed the service files for isc-dhcp (in T2438), other service files still ned to be moved to Type=forking or a suitable type (notify/dbus...) to fix their behavior, unless they already are.

https://github.com/vyos/vyos-1x/pull/404

202005051136 has multiple issues, there are multiple PRs waiting to be applied on vyos-1x to fix them. You didn't append the exact error messages.

@thomas-mangin I saw that and I think it's a good idea, to even make it into a common library we could use from all interface scripts. Does it work correctly on boot however? I see it uses exactly the same config.py methods that I'm talking about above that would return incorrect values on boot. I didn't try it but I'm highly suspecting it doesn't.

The fix for the error for openvpn is already waiting in PR since yesterday, fix for pseudo-ethernet and vxlan will be ready right now.

Wouldn't it be better to add it to the vyos-1x Makefile so we could test it ourselves, before committing, making a PR, it being merged, and only then figuring out it's a problem?

I couldn't reproduce this on my own build I made yesterday, I'll try it with the above ISO

In T2409#62999, @jestabro wrote:

I suggest you ignore T2030 for a moment --- I recall discussing that issue with the author, but I think the code comments are leading you astray ... we can return to that later.

You appear to equate active with the saved config file, in your first comment above;

No, I am not equating the active config with the saved config file.

that will be the case, after the boot commit completes, which begs the question: what do mean 'at boot' --- at some point during the boot process (in vyos-router), a config session is initialized, the config file (or a default if first boot after install) is loaded, and committed. Between load and commit during boot, there is no active of effective config defined, nor can you query it without error, as it is meaningless; on the other hand, between load and commit, the proposed config (showConfig --show-working-only) is what you would expect; after commit, one has active/effective == proposed, assuming no error.

This is exactly what I had in mind, but maybe my terminology was inaccurate: between load and the end of the commit, during the commit, we have the proposed config, which can be queried with get_value() etc., and the effective config, which can be queried with get_effective_value() etc.
Currently the interface scripts take the proposed config and apply it, but there are some places where they already compare it with effective config, to see what the differences are and what to apply.
For example:
https://github.com/vyos/vyos-1x/blob/current/python/vyos/configdict.py#L299-L315
This takes the difference between get_values and get_effective values to see what addresses to remove.

Changing this to

chown nobody:vyattacfg /config/dhcpd.leases*; \
chmod 664 /config/dhcpd.leases*; \

(note the *)
has fixed the error with dhcpd. The same needs to be done to dhcpv6.

https://github.com/vyos/vyos-1x/pull/400

Still TODO: apply STP settings when re-adding interface to bridge from interface scripts, currently the interface loses configured STP settings, but is at least readded to the bridge.

https://github.com/vyos/vyos-1x/pull/398

https://github.com/vyos/vyos-1x/pull/399

https://github.com/vyos/vyos-1x/pull/397

Personally I don't understand the insistence on keeping everything Python - in some cases, it is simply much better to use a more suitable language. A simple C program is IMO simpler and more KISS than a python daemon with a listening socket with clients connecting to it via UDP. You're invoking several layers of the OS (networking, process management, sockets) that are completely unnecessary in a simple "is this value OK?" program. I don't like convoluted solutions to solve a simple problem.

@thomas-mangin if you can demonstrate your idea implementing the actual validator code would be close performance-wise to the old shell/C validators, I would be on board with it. But personally I like shell and C better :)

It's due to Python startup time. Validation of every config node requires a full startup of Python. It would be better to if the validators were shell scripts or C programs, as they were before, the load time is very small :) I think this is also a part of the significant difference in boot and commit times between 1.2 and 1.3.

03:42:04  DEBUG - Traceback (most recent call last):
03:42:04  DEBUG -   File "/usr/libexec/vyos/conf_mode/interfaces-wireless.py", line 810, in <module>
03:42:04  DEBUG -     verify(c)
03:42:04  DEBUG -   File "/usr/libexec/vyos/conf_mode/interfaces-wireless.py", line 621, in verify
03:42:04  DEBUG -     verify_vlan_config(wifi)
03:42:04  DEBUG -   File "/usr/lib/python3/dist-packages/vyos/ifconfig_vlan.py", line 155, in verify_vlan_config
03:42:04  DEBUG -     for vif in config['vif'].values():
03:42:04  DEBUG - AttributeError: 'list' object has no attribute 'values'
03:42:04  DEBUG - 
03:42:04  DEBUG - 
03:42:04  DEBUG - 
03:42:04  DEBUG - [[interfaces wireless wlan10]] failed
03:42:04  DEBUG - Commit failed

Forgot to migrate other interfaces to use the new functions. Will prepare a new PR.

Correct me if I'm wrong, I haven't tried it in practice, but the commits that fixed T2030 would seem to support my understanding.

@jestabro so get_config_dict(effective=True) will return an empty config dict on boot? AFAIK by reading config.py, it will be the same as get_config_dict(effective=False), so the diff between them will return 0 differences, thus nothing to apply, even though there's everything to apply (as it's a first commit on boot).

for example: an error in apply() raises ApplyError. in main, we catch the ApplyError and re-run the whole get_config, verify, apply chain but with effective config instead of session config (for example by get_config_dict, then comparing the old and new config dicts, we can kill two birds with one stone: get a revert function, and have a granular apply logic that only applies changed settings - though I'm not sure that can work with the way the effective config is obtained right now, AFAIK on boot both are identical so it wouldn't work: see T2409)

@thomas-mangin seems mostly fine via quick glance. Only the max_mtu is imo wrong - the device may support jumbo frames. If we limit upper MTU to 1500 we'll prevent the user from using jumbo frames if he chooses to. I can't think of a good way to solve this whole issue within the confines of the current get_config/verify/apply separation. We simply can't verify if the MTU is allowed for the hardware without trying to apply it. Some network cards don't support jumbo frames, some do, with various upper limits: baby giant, super jumbo,... (https://en.wikipedia.org/wiki/Jumbo_frame)

Tested it right now, set interfaces bridge br0 member interface eth3.4 worked fine with latest current vyos-1x, so the next ISO should definitely have this fixed.

See T2427, the fix for that was merged today and will be in the next ISO build. I'll test that new ISO too to see if I catch any migration errors (I tested it just on a test VM without upgrading and I didn't see any VLAN errors, several configured VLANs seemed to work)
Edit: I see the error is for eth vif in a bridge, I didn't test that, just vif on ethernet and eth in a bridge. I'll test it today.

https://github.com/vyos/vyos-1x/pull/393

Why do we need to remove all addresses from the interface when it is disabled? That causes a commit error on dhcp:

vyos@vyos# set service dhcp-server disable 
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# delet service dhcp-server disable 
[edit]
vyos@vyos# commit
[ service dhcp-server ]
DHCP server configuration error!
None of configured DHCP subnets does not have appropriate
primary IP address on any broadcast interface.

@thomas-mangin there was a bug in PR #383 that prevented bond interfaces from coming up - it thought the members had addresses assigned, but they didn't. Something in my PR#384 fixed it - I'm not exactly sure what - probably assigning the intf['intf'] in get_intf_from_dict or fixing the _basename function. There is still a bug with IPv6 link-locals that worked fine before - I'll see if it's easy to track down, if not I'll open a new task for it.

It seems to be reading the output of something that thinks it's talking to a VT100 terminal.

@Viacheslav I confirmed the bug you have with assigning 'fe80::/64' when it shouldn't. It appered after https://github.com/vyos/vyos-1x/pull/383 - I'll investigate once my other PR gets merged and open a task for it. (note that it should add the fe80::(eui-64)/64 based on mac address by default and no-default-link-local did disable it before PR#383)

@c-po is it possible to detect the exact networking setup used on the host? If not, I don't think that'll do any good, because the hypervisor is just that - a hypervisor. There can be many different types of networking. Like in this case, Openstack's SDN supports a lower MTU than a bridged or NATed connection with the same hypervisor would. The only reliable way is to detect the max MTU in some way (the kernel/device driver must know this, the question how can we read it) - the first step is to not touch the default MTU if the user doesn't set it.

So the minimum MTU for IPv6 is 1280. Setting ipv6 address no-default-link-local will probably fix this.

@Viacheslav do you have IPv6 disabled per chance? What's the output of ip addr dev eth1 after the failed commits? What's the full eth1 config?
The odd thing to me here is that it shouldn't ever be adding just fe80::/64, it should get the mac (using self.get_mac()) and create a single EUI64 address. The longer fe80:: address looks as it should be.