User Details
- User Since
- Feb 6 2023, 8:40 PM (188 w, 6 d)
May 26 2026
May 12 2026
resolved by https://github.com/vyos/vyos-1x/pull/5163 also smoke test was good and automated tests were good on my end
May 11 2026
signed and checking on smoke test
Apr 10 2026
Aug 20 2025
Aug 17 2025
Aug 15 2025
appears to be working again with VyOS 2025.08.13-0020-rolling
this might be interacting with firewall global-options receive-redirects
Aug 13 2025
many dns timeouts persist. is this interacting with wan load balancing?
Aug 1 2025
this issue persists, it's now manifesting itself in different ways. about 10% of DNS lookups from LAN clients still fail, now it's 10% of addresses looked up instead of 10% of queries total.
the ticket is closed, and
ssh vyos@vyos -- /opt/vyatta/bin/vyatta-op-cmd-wrapper show interfaces
Jul 31 2025
VyOS 2025.07.28-0022-rolling has completely broken the remote access connectivity.
set service dns forwarding cache-size 10000 set service dns forwarding system
appears to resolve the issue, any insights?
# python3 <<'EOF'
> import socket
> import time
> import struct
> import random
> import sys
>
> # --- Configuration ---
> DNS_SERVER = "8.8.8.8"
> DNS_PORT = 53
> QUERY_DOMAIN = "google.com"
> TIMEOUT = 1.0 # 1 second timeout
>
> # --- Counters ---
> success_count = 0
> timeout_count = 0
> total_count = 0
>
> def build_dns_query(domain_name):
> # Standard DNS query header
> transaction_id = random.randint(0, 65535)
> flags = 0x0100 # Standard query
> questions = 1
> header = struct.pack('!HHHHHH', transaction_id, flags, questions, 0, 0, 0)
>
> # Question section
> qname = b''
> for part in domain_name.split('.'):
> qname += struct.pack('B', len(part)) + part.encode('utf-8')
> qname += b'\x00' # End of QNAME
>
> qtype = 1 # A record
> qclass = 1 # IN class
> question = struct.pack('!HH', qtype, qclass)
>
> return header + qname + question
>
> def print_stats():
> global success_count, timeout_count, total_count
> if total_count == 0:
> return
>
> timeout_rate = (timeout_count / total_count) * 100
> status_line = (
> f"\rSuccess: {success_count} | "
> f"Timeouts: {timeout_count} | "
> f"Total: {total_count} | "
> f"Timeout Rate: {timeout_rate:.2f}% "
> )
> sys.stdout.write(status_line)
> sys.stdout.flush()
>
> print(f"--- Starting DNS timeout test against {DNS_SERVER} (Ctrl+C to stop) ---")
>
> try:
> while True:
> total_count += 1
> query = build_dns_query(QUERY_DOMAIN)
>
> sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
> sock.settimeout(TIMEOUT)
>
> try:
> sock.sendto(query, (DNS_SERVER, DNS_PORT))
> data, addr = sock.recvfrom(512)
> success_count += 1
> except socket.timeout:
> timeout_count += 1
> except Exception as e:
> # Handle other potential errors, though timeout is the one we expect
> timeout_count += 1
> finally:
> sock.close()
>
> print_stats()
> time.sleep(1)
>
> except KeyboardInterrupt:
> print("\n--- Test stopped. Final Statistics ---")
> print_stats()
> print("\n")
>
> EOF
--- Starting DNS timeout test against 8.8.8.8 (Ctrl+C to stop) ---
Success: 68 | Timeouts: 0 | Total: 68 | Timeout Rate: 0.00% ^C
--- Test stopped. Final Statistics ---
Success: 68 | Timeouts: 0 | Total: 68 | Timeout Rate: 0.00%Dec 4 2024
modifying any settings in the vpn block seems to break remote access until the vpn l2tp remote-access authentication local-users block is modified
still an issue in latest
Oct 31 2024
Sep 26 2024
What is the approach for preventing offloads from being added back in after boot? I deleting them before upgrading, upgraded to a nightly with this patch, but I observed the offloads returned:
Feb 18 2024
Feb 16 2024
interesting, it may have been broken sometime between 1.3.1 and 1.3.6 then. I used automations like these all the time. let me verify the behavior generally on ubuntu
Jan 29 2024
Feb 25 2023
Yes, apparently so from GitHub.