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.

@jjakob @c-po Execute the following command. Although the default route can be generated automatically, it may be a bug in the current PPPoE function. In a specific environment, restarting PPPoE dialing will not maintain dialing status!

Issue with socket.gethostbyname()

PR https://github.com/vyos/vyos-1x/pull/409

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.

@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:

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

There are still some problems about IPv6, even when I restart it, I can't get IPv6 immediately. I don't know when it has some impact on my ISP environment, but it may be a bug that is hard to find. In a previous version of 1.2, IPv6 was acquired normally. Is it necessary for the official to cross compare with the latest version of 1.2.3? (may be 1.2.3, I hope I remember correctly)

How does vyos timeout PPPoE?

Successfully tested on the VyOS 1.3-rolling-202005130117.
Full opennhrp logs might be enabled by the following command

Fixed in T832

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.

https://github.com/joejulian/xterm/blob/master/resize.c Not complicated to port in the vyos library, replacing the current code and therefore only run when required

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.

Actually I think this is a result of T2434 since the source interface is bond1, so I'm closing this again. My apologies.

@jjakob This doesn't appear to have been fixed in VyOS 1.3-rolling-202005130117

Should we trap the signal in vash, set an env value and use it with vyos?

I have tested the fix in https://github.com/vyos/vyatta-cfg-vpn/pull/31 successfully on VyOS 1.2.5 with the hotfix mentiones. Happy to see this in 1.2.6

I have tested the fix in https://github.com/vyos/vyatta-cfg-vpn/pull/31 successfully on VyOS 1.2.5 with the hotfix mentiones. Happy to see this in 1.2.6

No Problem - nice to see races for bugfixes

@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.

This was a breaking change

same of

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.

Thank you for the good explanation in the issue!