Definitely miss behavior is generated by the new interface MGT that was created when assigning MGT vrf to eth0.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 4 2022
Aug 28 2022
Aug 14 2022
Dec 9 2021
Nov 5 2021
Nov 2 2021
Nov 1 2021
Oct 31 2021
Oct 26 2021
Oct 25 2021
Oct 23 2021
The client (IP: 192.168.122.78) doesn't connect to VyOS via OpenConnect VPN.
Tested on version: VyOS 1.3.0-epa2
Same as T3919
Oct 22 2021
Oct 21 2021
Oct 19 2021
Oct 18 2021
Other test.
In same lab, pool for LAN subnet was modified:
More tests where done on version 1.3.0-epa1.
First, dhcp_server.py was modified as indicated.
Oct 17 2021
Oct 16 2021
Oct 14 2021
Is a double task, it looks like the package is not update upstream.
Oct 13 2021
Oct 11 2021
Obviously in a perfect world we get "unique" and "stable". I do think giving stability priority makes sense.
@lucasec the reason for switching to the platform UUID instead of building up out own one was that it was not "unique".
Oct 10 2021
I surveyed all the hardware I have to see what kind of UUIDs they report:
Implemented in
The DUID is presented in binary inside /var/lib/dhcpv6/dhcp6c_duid to read it back into ASCII use: hexdump -e '"%07.7_ax " 1/2 "%04x" " " 14/1 "%02x:" "\n"' /var/lib/dhcpv6/dhcp6c_duid
Oct 9 2021
Unfortunately reverting back the public key did not lead to any good results either.
Oct 8 2021
Oct 5 2021
Yeah, that seems reasonable to me. I would prefer not add clutter to the system node if it can be avoided.