- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 14 2022
@NikolayP Could you re-test it?
Some detail here T1280
@sdev: in your original commit for this task, recent rules are somehow semi-discarded (the time/counter condition will not be written out; however, the action will be written out) because of an apparent problem with nftables in this area.
Thanks; I just tested commenting out line 5 of that file, and it successfully works around the issue, allowing me to set a link-local IPv6 address as my endpoint. The wireguard connection itself also works, and I can pass traffic.
@odhnera Try to comment or delete the validation string and restart vyos-configd service
Jan 13 2022
Getting link-local addresses to work would probably be very low-priority, but I did run into an extremely niche case where I wanted to do that. It's not the type of situation that would happen in a production environment, but I was running VyOS on a computer tethered via ethernet to an Android-based phone, and I wanted to connect to a wireguard peer running on the phone. Modern version of Android randomize the IPv4 address of their tethered interface on each reboot, but their link-local IPv6 address remains the same, making it more convenient to use it.
Link-local addresses with %ethX are not accepted in any protocols/peers/etc. A few services are allowed to set them as listen like ssh/dns at the moment.
Is there a real use case why you need it on wireguard interfaces?
It generates by openvpn, maybe something new in the new OpenVPN version
So I see only one option - add mode server-bridge
@hensur I'm glad you reimplemented this feature. Come on
See comment in T4164: is working now.
See comment in T4164: my config runs through easily now.
@sdev this (and the other fixes) look promising: after upgrading to the latest rolling release from 13.1.2022, both the example provided in the ticket as well as my config (a copy of my production setup with rules covering PBR, empty groups, references to "defines" in PBR rules) ran through easily. My production config created no errors when loading the config after the update.
Thanks for the report, working on the fix now.
In T4164#116547, @mTx87 wrote:seems like policy based routing not working.
moved my comment to a new bug request to keep this one here clean.
Any updates? No one?
Jan 12 2022
but wasn't necessary on VyOS 1.4-rolling-202109280217
so I guess changes to FRR that are the cause right?
Add neighbors to their proper afi:
- Incorrect custom scripts data if used tunX interfaces
- Allow inputs.ethtool only on Ethernet interfaces, by default it tries to get statistics from each interface, template
Jan 12 19:37:30 r11-roll telegraf[7703]: 2022-01-12T17:37:30Z E! [inputs.ethtool] Error in plugin: dum0 stats: operation not supported Jan 12 19:37:30 r11-roll telegraf[7703]: 2022-01-12T17:37:30Z E! [inputs.ethtool] Error in plugin: gretap0 driver: operation not supported Jan 12 19:37:30 r11-roll telegraf[7703]: 2022-01-12T17:37:30Z E! [inputs.ethtool] Error in plugin: gre0 driver: operation not supported Jan 12 19:37:30 r11-roll telegraf[7703]: 2022-01-12T17:37:30Z E! [inputs.ethtool] Error in plugin: erspan0 driver: operation not supported
Incorrect custom scripts data if used 'tun' interface
https://github.com/vyos/vyos-1x/blob/current/src/etc/telegraf/custom_scripts/show_interfaces_input_filter.py
yes, you are right:
Jan 11 2022
Forgot that my PR for WLB was still a draft. That the jump does seem to be created properly with this PR in place.
That build at 08:11 UTC was a couple of hours before the commit was merged: https://github.com/vyos/vyos-1x/commit/f97144259335102c3d96b232cbb0af4970120d62