PR 1.5 https://github.com/vyos/vyos-1x/pull/2750
PR 1.4 https://github.com/vyos/vyos-1x/pull/2751
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Jan 4 2024
Jan 4 2024
Viacheslav added a parent task for T5876: Dhcp bug in latest 1.5 rolling releases: T3316: Use Kea DHCP(v6) instead of ISC DHCP(v6).
c-po moved T5894: Extend get_config_dict() with additional parameter with_pki that defaults to False from Need Triage to Finished on the VyOS 1.4 Sagitta board.
Still issue persists when u create a new install its fine but upgrading breaks dhcp server ,tried in latest rolling releases 😢 why no solution??? YET...........
syncer updated subscribers of T577: Unconfigured Ethernet interface discovery partial failure on boot.
@dmbaturin @c-po can you see this and tell me if it's still current
syncer triaged T5895: Inconsistent text output with multiple commit-archive locations as Normal priority.
Jan 3 2024
Jan 3 2024
danielpo added a comment to T5892: container network interface and policy fails to apply after reboot.
OK, local-route actually worked!
Thanks!
Viacheslav added a comment to T5892: container network interface and policy fails to apply after reboot.
The same issue could be with any dynamic interface like PPP that could be don't exists during the boot process/ISP issues
c-po closed T5879: tunnel: sourceing from dynamic pppoe0 interface will fail on reboots as Resolved.
c-po changed the status of T5880: verify_source_interface should not allow dynamic interfaces like ppp, l2tp, ipoe or sstpc client interfaces, a subtask of T5879: tunnel: sourceing from dynamic pppoe0 interface will fail on reboots, from Open to In progress.
c-po changed the status of T5880: verify_source_interface should not allow dynamic interfaces like ppp, l2tp, ipoe or sstpc client interfaces from Open to In progress.
c-po changed the status of T3264: Allow custom ACME provider for certbot, a subtask of T5886: Add support for ACME protocol (LetsEncrypt), from Open to In progress.
c-po moved T5887: Upgrade Linux Kernel to 6.6.y (2023 LTS edition) from Need Triage to In Progress on the VyOS 1.5 Circinus board.
Which version?
Viacheslav changed the status of T5848: Add triple-isolate flow isolation option to CAKE QoS policy from Open to In progress.
Just a heads up that the above script can potentially destroy the config on boot, because if the system is fast enough, the hook will run before the boot config has finished loading. This will result either in an error when commiting because the config is locked (good outcome), or the config not being loaded at all (bad outcome). I've changed it a bit to actually wait for the boot config to load and now it runs safer, but it's still a bit janky in my opinion, I'm still hoping we can get something that works in-system for this case
PR submitted: https://github.com/vyos/vyos-1x/pull/2746
If I connect to the router and issue the commands
Jan 2 2024
Jan 2 2024
n.fort changed the status of T5888: Firewall upgrade fails because of icmpv6 from Confirmed to Needs testing.
n.fort changed the status of T5888: Firewall upgrade fails because of icmpv6 from Open to Confirmed.
c-po added a comment to T5879: tunnel: sourceing from dynamic pppoe0 interface will fail on reboots.
PR for 1.4 sagitta https://github.com/vyos/vyos-1x/pull/2732
c-po added a comment to T5880: verify_source_interface should not allow dynamic interfaces like ppp, l2tp, ipoe or sstpc client interfaces.
PR for 1.4 sagitta https://github.com/vyos/vyos-1x/pull/2732
jestabro moved T5885: image-tools: relax restriction on image-name length from 32 to 64 from Need Triage to Finished on the VyOS 1.4 Sagitta board.
jestabro closed T5885: image-tools: relax restriction on image-name length from 32 to 64 as Resolved.
Jan 1 2024
Jan 1 2024
c-po added a parent task for T3651: Move certbot request to op-mode: T5886: Add support for ACME protocol (LetsEncrypt).
c-po added a subtask for T5886: Add support for ACME protocol (LetsEncrypt): T3651: Move certbot request to op-mode.
c-po added a parent task for T3264: Allow custom ACME provider for certbot: T5886: Add support for ACME protocol (LetsEncrypt).
jestabro added a comment to T5885: image-tools: relax restriction on image-name length from 32 to 64.
jestabro renamed T5885: image-tools: relax restriction on image-name length from 32 to 64 from image-tools: loosen restriction on image-name length from 32 to 64 to image-tools: relax restriction on image-name length from 32 to 64.
jestabro triaged T5885: image-tools: relax restriction on image-name length from 32 to 64 as Normal priority.
jestabro moved T5883: Preserve file ownership in /config subdirs on add system image from Need Triage to Finished on the VyOS 1.4 Sagitta board.
jestabro closed T5883: Preserve file ownership in /config subdirs on add system image, a subtask of T3316: Use Kea DHCP(v6) instead of ISC DHCP(v6), as Resolved.
What I noticed is whenever you update rolling versions it breaks dhcp ,but when you make a new install it is fine.
Just to report back
Sorry maybe I’m not understanding you. The address you’ve highlighted isn’t valid in any case (it only has 6 segments). At the very best it should look like 2602:fcad:2:fffe:5054:ff:XXXX:XXXX (with eight segments). 2602:fcad:2:fffe::/64 is a valid prefix on our network, but there would need to be another 4 segments at the end for SLAAC assigned addresses (which is how that particular address is being assigned). I’d need to look deeper into what the correct address should be, which is why we provided the iperf3 example given the shorter / defined host addresses (with the hope that someone else smarter than me might see the pattern of how the addresses are being mangled). Thanks.
c-po moved T5474: Establish common file name pattern for XML conf mode commands from Need Triage to Finished on the VyOS 1.5 Circinus board.
c-po moved T5474: Establish common file name pattern for XML conf mode commands from Need Triage to Finished on the VyOS 1.4 Sagitta board.
c-po added a project to T5474: Establish common file name pattern for XML conf mode commands: VyOS 1.5 Circinus.
Yes but "2602:fcad:2:fffe:5054:ff" is a valid host in your case?
Hmm, I also just realized the SRC_PORT and DST_PORT are 0 in both the IPv4 and IPv6 flows (also seen in the first example).
No -- I don't believe that's a valid IPv6 address. We just ran some iperf3 tests between two servers on our network 2602:fcad:1::12 <-> 2602:fcad:1:ffff::ffff. Here's what showed up in nfdump (our Netflow collector). I'm not seeing an obvious pattern on how the addresses are being mangled.
Dec 31 2023
Dec 31 2023
You mean that for SRC_IP you expect it to be "2602:fcad:2:fffe:5054:ff" and not "14d:63f:2602:fcad:2:fffe:5054:ff" ?
c-po added a comment to T5879: tunnel: sourceing from dynamic pppoe0 interface will fail on reboots.
Apachez added a comment to T5879: tunnel: sourceing from dynamic pppoe0 interface will fail on reboots.
Related to the list provided in https://vyos.dev/T5706 ?
Dec 30 2023
Dec 30 2023
c-po renamed T5879: tunnel: sourceing from dynamic pppoe0 interface will fail on reboots from tunnel: souring from dynamic pppoe0 interface will fail on reboots to tunnel: sourceing from dynamic pppoe0 interface will fail on reboots.
It is more of a question for Jool.
Or you can use a range of required ports that aren't used by the system
I've tinkered with this a bit , but a problem I have is that I need multiple ip addresses on the outgoing interface(s). I understand that Jool takes all ports, so It's needed for everything to work properly.
On my own WAN interface, this is not a problem, I can just assign another ip from my ISP.
PR https://github.com/vyos/vyos-1x/pull/2724
vyos@r4:~$ add system image latest
Removing 1.3 backport as it's not trivial. Implementation depends on python3-pyhump (not available and must be self build) and also on vyos.opmode framework which does not exist for 1.3 equuleus