User Details
- User Since
- Jul 3 2023, 12:48 PM (72 w, 6 d)
Sep 3 2024
@n.fort I like the interface log sub command, gives us a nice way to take on additional logging things later, but for now log link-status seems good to me.
Aug 9 2024
Aug 7 2024
Mar 7 2024
Feb 26 2024
@tjjh89017 Have a look at https://vyos.dev/T5965
Jan 31 2024
New data point. I installed vanilla Debian 12, connected modem via
Jan 30 2024
Seemingly long term solution is to migrate to a DHCP/DHCPv6 server that supports it. I've been going back and forth with the systemd folks -- https://github.com/systemd/systemd/issues/27219
One of them seems to show it works fine, but I can't replicate it. I am going to try and do it under just normal Debian 12 bookwork and not VyOS so as not to introduce anything strange
Jan 24 2024
@c-po This would be the commits from https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/67 and 2 of mine to fix the issues with that PR, plus add support for ARPHRD_NONE
Digging into it a little, @c-po mentioned in Slack about trying https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/67 (the stalled PR). I had to fix a few things which I left as a comment on that PR just in case some else stumbles on it.
Jan 22 2024
Just as a temporary solution before a long term one is figured out, I did implement this as a post-boot script. For any one who stumbles on this
Jan 21 2024
dhclient just straight up doesn't work with raw-ip, so there isn't really an event that I can imagine it could trigger off. Even if there was I don't know what we'd even do, I don't think it would be good to have the dhclient hooks be the thing that gets the IP from mmcli -m 0 -b 2 and configures all the associated bits if we went that way.
The wwan0 interface doesn't have a MAC address so dhclient doesn't know what to do
Jan 20 2024
After thinking a bit I suppose there is 3 possible solutions.
Jan 19 2024
Dec 21 2023
All good from my side! Just did quick test and it seems to work as expected. Thanks @n.fort
Oct 25 2023
This is causing smoketests on the nightly builds to fail
DEBUG - Traceback (most recent call last): DEBUG - File "/usr/libexec/vyos/conf_mode/nat66.py", line 127, in <module> DEBUG - generate(c) DEBUG - File "/usr/libexec/vyos/conf_mode/nat66.py", line 101, in generate DEBUG - render(nftables_nat66_config, 'firewall/nftables-nat66.j2', nat, permission=0o755) DEBUG - File "/usr/lib/python3/dist-packages/vyos/template.py", line 142, in render DEBUG - rendered = render_to_string(template, content, formater, location) DEBUG - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DEBUG - File "/usr/lib/python3/dist-packages/vyos/template.py", line 111, in render_to_string DEBUG - rendered = template.render(content) DEBUG - ^^^^^^^^^^^^^^^^^^^^^^^^ DEBUG - File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1301, in render DEBUG - self.environment.handle_exception() DEBUG - File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 936, in handle_exception DEBUG - raise rewrite_traceback_stack(source=source) DEBUG - File "/usr/share/vyos/templates/firewall/nftables-nat66.j2", line 28, in top-level template code DEBUG - {{ config | nat_rule(rule, 'source', ipv6=True) }} DEBUG - ^^^^^^^^^^^^^^^^^^^^^^^^^ DEBUG - File "/usr/lib/python3/dist-packages/vyos/template.py", line 660, in nat_rule DEBUG - return parse_nat_rule(rule_conf, rule_id, nat_type, ipv6) DEBUG - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DEBUG - File "/usr/lib/python3/dist-packages/vyos/nat.py", line 58, in parse_nat_rule DEBUG - oiface = rule_conf['outbound_interface']['interface_group'] DEBUG - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^ DEBUG - TypeError: string indices must be integers, not 'str'
Oct 23 2023
Jul 26 2023
@c-po just added the sudo on a live box to test the changes and I can confirm that fixes it. No auth prompt when doing a load config.
Now I did notice that every time I do a load config it runs that migration script which stops/starts the container which is not ideal.