A very nice test, I always tested with USB to serial adapters and not with a real serial port.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed Search
Mar 9 2021
Mar 9 2021
Viacheslav added a comment to T3396: syslog can't be configured with an ipv6 literal destination in 1.2.x.
PR for "current" https://github.com/vyos/vyos-1x/pull/764
Viacheslav added a comment to T3396: syslog can't be configured with an ipv6 literal destination in 1.2.x.
Expected format @[2001:db8::2]:514
Viacheslav moved T3392: vrrp over dhcp default route bug (unexpected vrf) from Open to Backport Candidates on the VyOS 1.4 Sagitta board.
Looks good on 1.4-rolling-202103090218:
Viacheslav changed the status of T3392: vrrp over dhcp default route bug (unexpected vrf) from Open to Needs testing.
Viacheslav moved T3271: qemu-kvm grub issue from Open to Backport Candidates on the VyOS 1.4 Sagitta board.
I kill the vm 80+ times.
All works fine.
@c-po can we "cherry-pick" it to 1.3.0?
Mar 8 2021
Mar 8 2021
stepler changed the status of T3395: WAN load-balancing fails with nexthop dhcp from Open to In progress.
Looks good on 1.4-rolling-202103080218:
Looks good on 1.4-rolling-202103080218:
Mar 7 2021
Mar 7 2021
vrf detected even it not created
https://github.com/vyos/vyos-1x/blob/dd35eb76153191bc487e3ea23c3e73c753ec1d4b/src/etc/dhcp/dhclient-enter-hooks.d/03-vyos-ipwrapper#L55-L59
root@r-roll01:/home/vyos# basename /sys/class/net/eth1/upper_* | sed -e 's/upper_//' eth1v1
Viacheslav updated the task description for T3392: vrrp over dhcp default route bug (unexpected vrf).
Viacheslav renamed T3392: vrrp over dhcp default route bug (unexpected vrf) from vrrp over dhcp default route bug to vrrp over dhcp default route bug (unexpected vrf).
Viacheslav changed the status of T3300: Add DHCP default route distance from In progress to Needs testing.
Wrong behavior
Unknown Object (User) added a comment to T3353: PPPoE server wrong vlan-range generating config.
@Viacheslav , thanks for improving, now it works properly. I found one interesting moment, it looks like we cant configure via CLI listen to PPPoE clients on interfaces eth1 and eth1.50 or eth1.something at the same time.
vyos@vyos# run show configuration commands | match "pppoe-server interface" set service pppoe-server interface eth1 vlan-id '50' set service pppoe-server interface eth1.1000 vlan-range '1-4095' [edit] vyos@vyos# set service pppoe-server interface eth1
Viacheslav moved T3379: Add global-parameters name-server for dhcpv6-server from Open to Backport Candidates on the VyOS 1.4 Sagitta board.
Also does not display other interfaces under the end node
vyos@RTR1# run show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 xxx.xxx.36.246/24 u/u
lo 127.0.0.1/8 u/u
::1/128
tun0 2001:470:xxxx:xxx::2/64 u/u HE.NET IPv6 Tunnel
[edit]
vyos@RTR1# run show interfaces tunnel
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
[edit]
vyos@RTR1# run show interfaces ethernet
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
[edit]
vyos@RTR1#Mar 6 2021
Mar 6 2021
For 1.2 this could be evaluated in the tunnels node.def file by something like:
c-po moved T3381: Change GRE tunnel failed from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T3381: Change GRE tunnel failed from Backport Candidates to Finished on the VyOS 1.4 Sagitta board.
c-po moved T3381: Change GRE tunnel failed from Needs Triage to Backlog on the VyOS 1.2 Crux (VyOS 1.2.7) board.
Mar 5 2021
Mar 5 2021
c-po renamed T3318: Update Linux Kernel to v5.4.208 / 5.10.142 from Update Linux Kernel to v5.4.101 / 5.10.19 to Update Linux Kernel to v5.4.102 / 5.10.20.
Submitted this PR to fix the issue:
Mar 4 2021
Mar 4 2021
Viacheslav changed the status of T3388: show interfaces doesn't display pppoeX from Open to Confirmed.
Expected output, in VyOS 1.3.0-rc1 works fine
showvyos@vyos:~$ show int
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 - u/u WAN01-pppoe
eth1 10.0.0.1/24 u/u LAN
eth2 192.0.2.12/24 u/u WAN02-dhcp
eth3 - u/u
lo 127.0.0.1/8 u/u
::1/128
pppoe0 10.1.1.101/32 u/uViacheslav renamed T3388: show interfaces doesn't display pppoeX from show interfaces don't show pppoeX to show interfaces doesn't display pppoeX.
Viacheslav changed the status of T3386: PPPoE-server don't start with local authentication from Open to Needs testing.
Viacheslav changed the status of T3211: ability to redistribute ISIS into other routing protocols from Open to Needs testing.
Backport to 1.3 done
c-po moved T3386: PPPoE-server don't start with local authentication from Backport Candidates to Finished on the VyOS 1.4 Sagitta board.
c-po moved T3386: PPPoE-server don't start with local authentication from Need Triage to Finished on the VyOS 1.3 Equuleus board.
Viacheslav moved T3386: PPPoE-server don't start with local authentication from Open to Backport Candidates on the VyOS 1.4 Sagitta board.
c-po moved T3381: Change GRE tunnel failed from Open to Backport Candidates on the VyOS 1.4 Sagitta board.
Issue also exists in VyOS 1.2.7-rc1
Unexpected redistribution for isis VyOS 1.4-rolling-202103040218
Unknown Object (User) added a comment to T3386: PPPoE-server don't start with local authentication.
There is a bug exactly with client-ip-pool range, config generated with the mistake
[ip-pool] gw-ip-address=10.1.1.1 10.1.1.100-10.1.1.111
but expected
10.1.1.100-111
Viacheslav added a project to T3386: PPPoE-server don't start with local authentication: VyOS 1.4 Sagitta.
I also attempted to fix this bug by writing to grub.cfg.new, calling fsync() on it, renaming it to grub.cfg, and calling fsync() on the directory. Unfortunately, I still encountered an unbootable system.
You can review the patch here
Also, It can't check that cmd on hypervisor
Mar 3 2021
Mar 3 2021
I attempted to fix this bug by journaling all filesystem data (ext3/4 mount option data=journal). Unfortunately, I still encountered an unbootable system.
jack9603301 moved T3385: Support for disabling ARP responses from In Progress to Open on the VyOS 1.4 Sagitta board.
jack9603301 moved T3385: Support for disabling ARP responses from Open to In Progress on the VyOS 1.4 Sagitta board.
jack9603301 moved T3384: Support UDP bandwidth testing from Open to In Progress on the VyOS 1.4 Sagitta board.
Due to the limited ability to open a pull request on the linux kernel's github repository, I had to submit the patch to netfilter maintainers team by email.
@linuxludo Can you share a link?
It seems to be a BUG in netfilter conntrack module with GRE protocol over IPv6.
I patched the conntrack module and it now works as expected.
I just submit this patch to the netfilter maintainers.
Wait & See...
I've had this bite me a few times now as well, but I wasn't able to pin it down before to being a bug.
Mar 2 2021
Mar 2 2021
It seems it some upstream issue
vyos@r-roll01# sudo ip tunnel add tun22 mode gre local 203.0.113.1 remote any [edit] vyos@r-roll01# sudo ip tunnel change tun22 mode gre local 203.0.113.1 remote 203.0.113.254 add tunnel "tun22" failed: Invalid argument [edit] vyos@r-roll01#
For 1.4 the same fail
Config
set interfaces tunnel tun1 address '10.20.30.1/30' set interfaces tunnel tun1 encapsulation 'gre' set interfaces tunnel tun1 source-address '192.168.122.11' set interfaces tunnel tun1 multicast 'disable' commit set interfaces tunnel tun1 remote 192.168.122.12 commit
Updated PR
I replace raw dhcpv6 global-parameters with leafNode.
Viacheslav renamed T3379: Add global-parameters name-server for dhcpv6-server from Add global-parameters for dhcpv6-server to Add global-parameters name-server for dhcpv6-server.
Looks like it is not possible using udev: https://stackoverflow.com/questions/40676914/how-to-set-up-a-udev-rule-for-eth-link-down-link-up
@FileGo will be fixed in the next rolling release.
Viacheslav changed the status of T3377: show interfaces throws error from Confirmed to Needs testing.
To reproduce, add one tunnel
I think it related T2651