astlinux-users — AstLinux Users Mailing List

Re: [Astlinux-users] Lanner NCA-1510

[Lonnie A. <li...@lo...>]

> On Nov 17, 2025, at 6:12 PM, aut...@gm... wrote:
> 
> Thanks Lonnie, here is the output from when I try to install from a USB drive:APIC: Switch to symmetric I/O mode setup
> ------------[ cut here ]------------
> kernel BUG at arch/x86/kernel/apic/apic.c:1599!
> invalid opcode: 0000 [#1] PREEMPT SMP
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.241-cip64-astlinux #1
> Hardware name: Default string Default string/Default string, BIOS 5.13 02/06/2025

You do not have anything plugged into the M.2 slot, correct?

You can search the interwebs for "invalid opcode: 0000" and see similar results.  Often a hardware issue, possibly a BIOS issue.  I see the RAM is soldered on the NCA-1510 board.

I personally have never encountered this "invalid opcode: 0000" error before.

I suppose testing another Linux distro could be the next step to debug this.  Though I'm not sure what change could fix this for AstLinux.

Lonnie

Re: [Astlinux-users] Lanner NCA-1510

[<aut...@gm...>]

Thanks Lonnie, here is the output from when I try to install from a USB
drive:



Version 2.19.1266. Copyright (C) 2025 American Megatrends, Inc.
NCA-1510 BIOS V1.16(02/06/2025)
Press <Tab> or <DEL> to enter setup.Syslinux 6.03 (EFI; )
                                                         Copyright (C)
2011-2014

#######################################
#     AstLinux ISO UEFI Installer     #
#######################################

install)  Install Menu (default)


Loading /runnix/runnix... ok
Loading /runnix/runnix.img...ok
Linux version 5.10.241-cip64-astlinux (build@build)
(x86_64-unknown-linux-gnu-gcc (crosstool-NG 1.25.0) 9.4.0, GNU ld
(crosstool-NG 1.25.0) 2.35.1) #1 SMP PREEMPT Thu Oct 30 13:07:53 CDT 2025
Command line: BOOT_IMAGE=/runnix/runnix initrd=/runnix/runnix.img
root=/dev/ram0 ro init=/runnix runimg=auto libata.dma=3 rootdelay=8
console=ttyS0,115200n8
BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000003e2dffff] usable
BIOS-e820: [mem 0x000000003e2e0000-0x000000003e2fffff] reserved
BIOS-e820: [mem 0x000000003e300000-0x00000000784bafff] usable
BIOS-e820: [mem 0x00000000784bb000-0x00000000784cafff] reserved
BIOS-e820: [mem 0x00000000784cb000-0x000000007d494fff] usable
BIOS-e820: [mem 0x000000007d495000-0x000000007df73fff] reserved
BIOS-e820: [mem 0x000000007df74000-0x000000007df83fff] ACPI data
BIOS-e820: [mem 0x000000007df84000-0x000000007e3b7fff] ACPI NVS
BIOS-e820: [mem 0x000000007e3b8000-0x000000007f33afff] reserved
BIOS-e820: [mem 0x000000007f33b000-0x000000007f7fffff] usable
BIOS-e820: [mem 0x000000007f800000-0x000000007fffffff] reserved
BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
BIOS-e820: [mem 0x00000000fd000000-0x00000000fe7fffff] reserved
BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
BIOS-e820: [mem 0x0000000100000000-0x000000027fffffff] usable
NX (Execute Disable) protection: active
extended physical RAM map:
reserve setup_data: [mem 0x0000000000000000-0x000000000009ffff] usable
reserve setup_data: [mem 0x00000000000a0000-0x00000000000fffff] reserved
reserve setup_data: [mem 0x0000000000100000-0x000000003e2dffff] usable
reserve setup_data: [mem 0x000000003e2e0000-0x000000003e2fffff] reserved
reserve setup_data: [mem 0x000000003e300000-0x0000000077483017] usable
reserve setup_data: [mem 0x0000000077483018-0x0000000077496857] usable
reserve setup_data: [mem 0x0000000077496858-0x0000000077497017] usable
reserve setup_data: [mem 0x0000000077497018-0x00000000774aa857] usable
reserve setup_data: [mem 0x00000000774aa858-0x00000000774ab017] usable
reserve setup_data: [mem 0x00000000774ab018-0x00000000774be857] usable
reserve setup_data: [mem 0x00000000774be858-0x00000000774bf017] usable
reserve setup_data: [mem 0x00000000774bf018-0x00000000774d2857] usable
reserve setup_data: [mem 0x00000000774d2858-0x00000000784bafff] usable
reserve setup_data: [mem 0x00000000784bb000-0x00000000784cafff] reserved
reserve setup_data: [mem 0x00000000784cb000-0x000000007d494fff] usable
reserve setup_data: [mem 0x000000007d495000-0x000000007df73fff] reserved
reserve setup_data: [mem 0x000000007df74000-0x000000007df83fff] ACPI data
reserve setup_data: [mem 0x000000007df84000-0x000000007e3b7fff] ACPI NVS
reserve setup_data: [mem 0x000000007e3b8000-0x000000007f33afff] reserved
reserve setup_data: [mem 0x000000007f33b000-0x000000007f7fffff] usable
reserve setup_data: [mem 0x000000007f800000-0x000000007fffffff] reserved
reserve setup_data: [mem 0x00000000e0000000-0x00000000efffffff] reserved
reserve setup_data: [mem 0x00000000fd000000-0x00000000fe7fffff] reserved
reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
reserve setup_data: [mem 0x0000000100000000-0x000000027fffffff] usable
efi: EFI v2.60 by American Megatrends
efi: ACPI 2.0=0x7df7c000 ACPI=0x7df7c000 TPMFinalLog=0x7e386000
SMBIOS=0x7f20e000 SMBIOS 3.0=0x7f20d000 ESRT=0x7c2d5d98 MEMATTR=0x7c1f0018
TPMEventLog=0x7df7a018
SMBIOS 3.0.0 present.
DMI: Default string Default string/Default string, BIOS 5.13 02/06/2025
tsc: Detected 1600.000 MHz processor
last_pfn = 0x280000 max_arch_pfn = 0x400000000
x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
last_pfn = 0x7f800 max_arch_pfn = 0x400000000
found SMP MP-table at [mem 0x000fcdf0-0x000fcdff]
esrt: Reserving ESRT space from 0x000000007c2d5d98 to 0x000000007c2d5dd0.
Using GB pages for direct mapping
Secure boot disabled
RAMDISK: [mem 0x774d3000-0x7799cfff]
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000000007DF7C000 000024 (v02 ALASKA)
ACPI: XSDT 0x000000007DF7C098 0000B4 (v01 ALASKA A M I    01072009 AMI
 00010013)
ACPI: FACP 0x000000007DF80FD8 000114 (v06 ALASKA A M I    01072009 AMI
 00010013)
ACPI: DSDT 0x000000007DF7C1E0 004DF4 (v02 ALASKA A M I    01072009 INTL
20061109)
ACPI: FACS 0x000000007E3B6080 000040
ACPI: FPDT 0x000000007DF810F0 000044 (v01 ALASKA A M I    01072009 AMI
 00010013)
ACPI: FIDT 0x000000007DF81138 00009C (v01 ALASKA A M I    01072009 AMI
 00010013)
ACPI: MCFG 0x000000007DF811D8 00003C (v01 ALASKA A M I    01072009 MSFT
00000097)
ACPI: WDAT 0x000000007DF81218 0001AC (v01 ALASKA A M I    01072009 MSFT
00010013)
ACPI: APIC 0x000000007DF813C8 000068 (v04 INTEL  TIANO    00000001 MSFT
00000000)
ACPI: BDAT 0x000000007DF81430 000030 (v01                 00000000
 00000000)
ACPI: HPET 0x000000007DF81460 000038 (v01 ALASKA A M I    00000001 MSFT
01000013)
ACPI: UEFI 0x000000007DF81498 000042 (v01 ALASKA A M I    00000002
 01000013)
ACPI: SSDT 0x000000007DF814E0 001901 (v02 PmRef  CpuPm    00003000 INTL
20061109)
ACPI: DMAR 0x000000007DF82DE8 000070 (v01 INTEL  BDW      00000001 INTL
00000001)
ACPI: SPCR 0x000000007DF82E58 000050 (v02 A M I  APTIO V  01072009 AMI.
0005000D)
ACPI: TPM2 0x000000007DF82EA8 000034 (v03 ALASKA A M I    00000001 AMI
 00000000)
ACPI: HEST 0x000000007DF82EE0 0000A8 (v01 INTEL  VND      00000001 INTL
00000001)
ACPI: BERT 0x000000007DF82F88 000030 (v01 INTEL  VND      00000001 INTL
00000001)
ACPI: ERST 0x000000007DF82FB8 000230 (v01 INTEL  VND      00000001 INTL
00000001)
ACPI: EINJ 0x000000007DF831E8 000150 (v01 INTEL  VND      00000001 INTL
00000001)
ACPI: WSMT 0x000000007DF83338 000028 (v01 ALASKA A M I    01072009 AMI
 00010013)
ACPI: Reserving FACP table memory at [mem 0x7df80fd8-0x7df810eb]
ACPI: Reserving DSDT table memory at [mem 0x7df7c1e0-0x7df80fd3]
ACPI: Reserving FACS table memory at [mem 0x7e3b6080-0x7e3b60bf]
ACPI: Reserving FPDT table memory at [mem 0x7df810f0-0x7df81133]
ACPI: Reserving FIDT table memory at [mem 0x7df81138-0x7df811d3]
ACPI: Reserving MCFG table memory at [mem 0x7df811d8-0x7df81213]
ACPI: Reserving WDAT table memory at [mem 0x7df81218-0x7df813c3]
ACPI: Reserving APIC table memory at [mem 0x7df813c8-0x7df8142f]
ACPI: Reserving BDAT table memory at [mem 0x7df81430-0x7df8145f]
ACPI: Reserving HPET table memory at [mem 0x7df81460-0x7df81497]
ACPI: Reserving UEFI table memory at [mem 0x7df81498-0x7df814d9]
ACPI: Reserving SSDT table memory at [mem 0x7df814e0-0x7df82de0]
ACPI: Reserving DMAR table memory at [mem 0x7df82de8-0x7df82e57]
ACPI: Reserving SPCR table memory at [mem 0x7df82e58-0x7df82ea7]
ACPI: Reserving TPM2 table memory at [mem 0x7df82ea8-0x7df82edb]
ACPI: Reserving HEST table memory at [mem 0x7df82ee0-0x7df82f87]
ACPI: Reserving BERT table memory at [mem 0x7df82f88-0x7df82fb7]
ACPI: Reserving ERST table memory at [mem 0x7df82fb8-0x7df831e7]
ACPI: Reserving EINJ table memory at [mem 0x7df831e8-0x7df83337]
ACPI: Reserving WSMT table memory at [mem 0x7df83338-0x7df8335f]
Zone ranges:
  DMA      [mem 0x0000000000001000-0x0000000000ffffff]
  DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
  Normal   [mem 0x0000000100000000-0x000000027fffffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000000001000-0x000000000009ffff]
  node   0: [mem 0x0000000000100000-0x000000003e2dffff]
  node   0: [mem 0x000000003e300000-0x00000000784bafff]
  node   0: [mem 0x00000000784cb000-0x000000007d494fff]
  node   0: [mem 0x000000007f33b000-0x000000007f7fffff]
  node   0: [mem 0x0000000100000000-0x000000027fffffff]
Initmem setup node 0 [mem 0x0000000000001000-0x000000027fffffff]
On node 0, zone DMA: 1 pages in unavailable ranges
On node 0, zone DMA: 96 pages in unavailable ranges
On node 0, zone DMA32: 32 pages in unavailable ranges
On node 0, zone DMA32: 16 pages in unavailable ranges
On node 0, zone DMA32: 7846 pages in unavailable ranges
On node 0, zone Normal: 2048 pages in unavailable ranges
ACPI: PM-Timer IO Port: 0x1808
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a201 base: 0xfed00000
ACPI: SPCR: console: uart,io,0x3f8,115200
TSC deadline timer available
smpboot: Allowing 2 CPUs, 0 hotplug CPUs
[mem 0x80000000-0xdfffffff] available for PCI devices
clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 1910969940391419 ns
setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:2 nr_node_ids:1
percpu: Embedded 44 pages/cpu s148120 r0 d32104 u1048576
Built 1 zonelists, mobility grouping on.  Total pages: 2058487
Kernel command line: BOOT_IMAGE=/runnix/runnix initrd=/runnix/runnix.img
root=/dev/ram0 ro init=/runnix runimg=auto libata.dma=3 rootdelay=8
console=ttyS0,115200n8
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 8115596K/8348452K available (8193K kernel code, 592K rwdata, 1308K
rodata, 932K init, 456K bss, 232600K reserved, 0K cma-reserved)
rcu: Preemptible hierarchical RCU implementation.
rcu:    RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
        Trampoline variant of Tasks RCU enabled.
rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS: 4352, nr_irqs: 440, preallocated irqs: 16
random: crng init done
Console: colour dummy device 80x25
printk: console [ttyS0] enabled
ACPI: Core revision 20200925
clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:
79635855245 ns
APIC: Switch to symmetric I/O mode setup
------------[ cut here ]------------
kernel BUG at arch/x86/kernel/apic/apic.c:1599!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.241-cip64-astlinux #1
Hardware name: Default string Default string/Default string, BIOS 5.13
02/06/2025
RIP: 0010:0xffffffff8102a95b
Code: bf f0 00 00 00 e8 c7 fc ff ff bf f0 00 00 00 80 e4 fe 89 c6 e8 c2 fc
ff ff 48 8b 05 cf 2e b1 00 ff 90 a0 00 00 00 85 c0 75 02 <0f> 0b 48 8b 05
bc 2e b1 00 41 bd 00 02 00 00 ff 90 b0 00 00 00 bf
RSP: 0000:ffffffff81c03e78 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000fffffdff
RDX: 0000000000000000 RSI: 00000000fffffeff RDI: 0000000000000020
RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000fffffdff
R10: ffffffff81c03d38 R11: ffffffff81c03d30 R12: 000000000000008f
R13: ffffffff81d4f0a0 R14: 000000000000008f R15: 0000000078210e98
FS:  0000000000000000(0000) GS:ffff88827fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff88827ffff000 CR3: 0000000003c0a000 CR4: 00000000000000b0
Call Trace:
 ? 0xffffffff814f140c
 ? 0xffffffff81cda219
 ? 0xffffffff81cce87a
 ? 0xffffffff81cc7d8b
 ? 0xffffffff81000111
---[ end trace 0e7f5b15690cd53c ]---
RIP: 0010:0xffffffff8102a95b
Code: bf f0 00 00 00 e8 c7 fc ff ff bf f0 00 00 00 80 e4 fe 89 c6 e8 c2 fc
ff ff 48 8b 05 cf 2e b1 00 ff 90 a0 00 00 00 85 c0 75 02 <0f> 0b 48 8b 05
bc 2e b1 00 41 bd 00 02 00 00 ff 90 b0 00 00 00 bf
RSP: 0000:ffffffff81c03e78 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000fffffdff
RDX: 0000000000000000 RSI: 00000000fffffeff RDI: 0000000000000020
RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000fffffdff
R10: ffffffff81c03d38 R11: ffffffff81c03d30 R12: 000000000000008f
R13: ffffffff81d4f0a0 R14: 000000000000008f R15: 0000000078210e98
FS:  0000000000000000(0000) GS:ffff88827fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff88827ffff000 CR3: 0000000003c0a000 CR4: 00000000000000b0
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

Re: [Astlinux-users] Lanner NCA-1510

[Lonnie A. <li...@lo...>]

> On Nov 16, 2025, at 12:47 AM, aut...@gm... wrote:
> 
> The kernel panic happens after I've booted from the USB drive and started the installation process.  The install just stops after a few seconds.  The target drive is untouched, as far as I can tell.
> 
> Would it be helpful to see the console output?

That would help to give context.

I'm wondering if the kernel is actually booting or not, possibly the creation of the bootable USB drive is the issue.

It could be a BIOS configuration issue as well.  Without any context it is hard to diagnose.


PS: Another thought, you mentioned placing a SSD into the M.2 Mini-PCIe slot, that could be causing an issue since that is only made for a WiFi card.

For the Lanner NCA-1510 with AstLinux, you need either the optional 2.5" SATA cable with SSD or install to and run off a USB boot drive [1] [2].

Lonnie

[1] Example: SAMSUNG FIT Plus 3.1 USB Flash Drive, 128GB

[2] https://doc.astlinux-project.org/userdoc:boot-usb-storage

Re: [Astlinux-users] Lanner NCA-1510

[Lonnie A. <li...@lo...>]

> On Nov 16, 2025, at 12:47 AM, aut...@gm... wrote:
> 
> The kernel panic happens after I've booted from the USB drive and started the installation process.  The install just stops after a few seconds.  The target drive is untouched, as far as I can tell.
> 
> Would it be helpful to see the console output?

That would help to give context.

I'm wondering if the kernel is actually booting or not, possibly the creation of the bootable USB drive is the issue.

It could be a BIOS configuration issue as well.  Without any context it is hard to diagnose.

Lonnie

Re: [Astlinux-users] Lanner NCA-1510

[<aut...@gm...>]

The kernel panic happens after I've booted from the USB drive and started
the installation process.  The install just stops after a few seconds.  The
target drive is untouched, as far as I can tell.

Would it be helpful to see the console output?

JT

Re: [Astlinux-users] Lanner NCA-1510

[Lonnie A. <li...@lo...>]

> On Nov 14, 2025, at 9:08 PM, aut...@gm... wrote:
> 
> 
> Not yet.  I'm going to try to installing Debian or Ubuntu via serial console and see if I get the same kernel panic.  pfSense installs and runs fine, but it's FreeBSD.  I got the box directly from Lanner with the storage and memory.
> 
> JT

Odd, does the kernel start booting ?  Possibly you could show the kernel panic in context.

Lonnie

Re: [Astlinux-users] Lanner NCA-1510

[<aut...@gm...>]

Not yet.  I'm going to try to installing Debian or Ubuntu via serial
console and see if I get the same kernel panic.  pfSense installs and runs
fine, but it's FreeBSD.  I got the box directly from Lanner with the
storage and memory.

JT

Re: [Astlinux-users] Lanner NCA-1510

[Lonnie A. <li...@lo...>]

> On Nov 14, 2025, at 8:25 AM, aut...@gm... wrote:
> 
> Hi Lonnie,
> 
> I was using an FW-7525B with a CF card, and it worked fine as well.
> 
> As for the NCA-1510C:
> 
> 1.  Yes, I'm using the serial console version, astlinux-1.5.12-genx86_64-serial.iso.  The box came with the necessary USB console cable.  The box has a PL2303GC chip and works with PuTTY.
> 
> 2.  The box does not have a 2.5" SATA SSD, but an M.2 SATA SSD.  Would this make a difference?
> 
> 3.  I mounted the ISO in Windows 10 and copied the files to a USB drive, and then booted the box from the USB for a UEFI install.  I set the BIOS for UEFI.
> 
> Thanks for your help!
> 
> JT

Did you get the NCA-1510 working?

From the Lanner docs, the M.2 slot looks like it is for WiFi cards, not SATA, am I wrong?

Lonnie

Re: [Astlinux-users] Lanner NCA-1510

[<aut...@gm...>]

Hi Lonnie,

I was using an FW-7525B with a CF card, and it worked fine as well.

As for the NCA-1510C:

1.  Yes, I'm using the serial console version,
astlinux-1.5.12-genx86_64-serial.iso.  The box came with the necessary USB
console cable.  The box has a PL2303GC chip and works with PuTTY.

2.  The box does not have a 2.5" SATA SSD, but an M.2 SATA SSD.  Would this
make a difference?

3.  I mounted the ISO in Windows 10 and copied the files to a USB drive,
and then booted the box from the USB for a UEFI install.  I set the BIOS
for UEFI.

Thanks for your help!

JT

Re: [Astlinux-users] Lanner NCA-1510

[Lonnie A. <li...@lo...>]

> On Nov 13, 2025, at 7:34 PM, aut...@gm... wrote:
> 
> Has anyone tried to install AstLinux on a Lanner NCA-1510?  I'm getting this:
> 
> kernel BUG at arch/x86/kernel/apic/apic.c:1599!
> invalid opcode: 0000 [#1] PREEMPT SMP
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.241-cip64-astlinux #1
> 
> This is from AstLinux 1.5.12, although I've tried a few older versions and get the same result.  The machine is a Lanner NCA-1510C (Intel C3308), which is similar to a Netgate SG-5100.

Hi JT,

Short answer, AstLinux 1.5.12 should work on your Lanner NCA-1510C.

I have a similar, but older Lanner FW-7525A (Intel C2358) and it works well with AstLinux 1.5.12 with UEFI BIOS, 2.5" SATA SSD.

Questions:

1) Are you using the "genx86_64-serial" version?  Do you have the USB serial console cable for that box?

2) Are you using 2.5" SATA storage?

3) Did you install AstLinux booting with the Generic x86-64bit (Serial Console) Installer ISO from here [1] ?

3a) Or did you extract the ISO's os/ genx86_64-serial-1.5.12-asterisk-....img file and dd it to your storage [2]?

Lonnie

[1] https://www.astlinux-project.org/

[2] https://doc.astlinux-project.org/userdoc:new-install

[Astlinux-users] Lanner NCA-1510

[<aut...@gm...>]

Has anyone tried to install AstLinux on a Lanner NCA-1510?  I'm getting
this:

kernel BUG at arch/x86/kernel/apic/apic.c:1599!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.241-cip64-astlinux #1

This is from AstLinux 1.5.12, although I've tried a few older versions and
get the same result.  The machine is a Lanner NCA-1510C (Intel C3308),
which is similar to a Netgate SG-5100.

Any help would be appreciated.

JT

[Astlinux-users] Announcing AstLinux Release: 1.5.12

[Lonnie A. <li...@lo...>]

Announcing AstLinux Release: 1.5.12

More Info: AstLinux Project
https://www.astlinux-project.org/

AstLinux 1.5.12 Highlights:
* Asterisk Versions: 16.30.0, 18.26.4, 20.15.2
* Linux Kernel 5.10.241-cip64, security and bug fixes
* RUNNIX, version bump to runnix-0.6.24
* OpenSSL, version 1.1.1w, security fix: CVE-2025-9230
* libcurl (curl) version bump to 8.16.0, security fix: CVE-2025-9086
* libpng, version bump to 1.6.50
* libxml2, version 2.11.9, security fixes: CVE-2025-6021, CVE-2025-6170
* chrony, version bump to 4.8
* expat, version bump to 2.7.3, security fix: CVE-2025-59375
* fping, version bump to 5.4
* iperf3, version bump to 3.19.1
* jansson, version bump to 2.14.1
* msmtp, version bump to 1.8.32
* nut, major version bump to 2.8.4, Note: change to only supporting usbhid-ups, netxml-ups drivers
* sqlite, version bump to 3.50.4
* tiff, version bump to 4.7.1, security fix: CVE-2024-13978
* unbound, version bump to 1.24.0
* unionfs (fuse), version bump to 3.7
* ca-certificates, update trusted root certificates 2025-09-09
* Asterisk '16se' (stable edition) version 16.30.0 is the last Asterisk 16.x "Legacy" version, built --without-pjproject and --without-dahdi
* Package upgrades providing important security and bug fixes

Full ChangeLog:
https://raw.githubusercontent.com/astlinux-project/astlinux/1.5.12/docs/ChangeLog.txt

All users are encouraged to upgrade, read the ChangeLog for the details.

AstLinux Team

Re: [Astlinux-users] Extending Astlinux disk

[Michael K. <mic...@ip...>]

Thanks Lonnie

Looks like a rebuild with Tarsnap restore is the only way. It’s relatively painless but enough of a hassle to reconsider having a smaller partition.


Regards

Michael Knill



From: Lonnie Abelbeck <li...@lo...>
Date: Monday, 1 September 2025 at 12:51 am
To: AstLinux Users Mailing List <ast...@li...>
Subject: Re: [Astlinux-users] Extending Astlinux disk

Hi Micheal,

Here is an example Proxmox VM with a 8 GB disk

pbx-pve ~ # df -h
Filesystem                Size      Used Available Use% Mounted on
...
/dev/sda1               255.6M    121.3M    134.3M  47% /oldroot/cdrom
/dev/sda2               237.9M     17.5M    207.6M   8% /mnt/asturw
/dev/sda3                 7.4G      2.9M      7.0G   0% /mnt/kd

pbx-pve ~ # findfs LABEL=RUNNIX
/dev/sda1
pbx-pve ~ # findfs LABEL=ASTURW
/dev/sda2
pbx-pve ~ # findfs LABEL=ASTKD
/dev/sda3

The standard 256 MB partitions for the RUNNIX and ASTURW are generally good, and don't need to be changed.

The ASTKD partition, as small as a few GB can provide production usage for many cases.


> is there any way that I can change the partitions in Astlinux to use the extra space without having to rebuild it?

One solution might be to archive/prune via 'scp' or 's3fs' to external storage, keeping a smaller ASTKD partition practical.

Otherwise, we don't include any tools to extend the size of the partition.

Lonnie



> On Aug 31, 2025, at 4:20 AM, Michael Knill <mic...@ip...> wrote:
>
> Hi Group
>
> I have a number of Astlinux VM which Im creating a standard template for. In my new DC, storage is actually now the most expensive resource so wanting to limit it where I can.
> Im thinking of starting pretty low which should be fine for most Its quite easy in OpenStack to extend a volume if I really needed to but is there any way that I can change the partitions in Astlinux to use the extra space without having to rebuild it?
>
> Regards
>  Michael Knill
> Managing Director
>  D: +61 2 6189 1360
> P: +61 2 6140 4656
> E: mic...@ip...
> W: ipcsolutions.com.au
>   <image001.png>Smarter Business Communications
>   _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....




_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] Extending Astlinux disk

[Lonnie A. <li...@lo...>]

Hi Micheal,

Here is an example Proxmox VM with a 8 GB disk

pbx-pve ~ # df -h
Filesystem                Size      Used Available Use% Mounted on
...
/dev/sda1               255.6M    121.3M    134.3M  47% /oldroot/cdrom
/dev/sda2               237.9M     17.5M    207.6M   8% /mnt/asturw
/dev/sda3                 7.4G      2.9M      7.0G   0% /mnt/kd

pbx-pve ~ # findfs LABEL=RUNNIX          
/dev/sda1
pbx-pve ~ # findfs LABEL=ASTURW
/dev/sda2
pbx-pve ~ # findfs LABEL=ASTKD 
/dev/sda3

The standard 256 MB partitions for the RUNNIX and ASTURW are generally good, and don't need to be changed.

The ASTKD partition, as small as a few GB can provide production usage for many cases.


> is there any way that I can change the partitions in Astlinux to use the extra space without having to rebuild it?

One solution might be to archive/prune via 'scp' or 's3fs' to external storage, keeping a smaller ASTKD partition practical.

Otherwise, we don't include any tools to extend the size of the partition.

Lonnie



> On Aug 31, 2025, at 4:20 AM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Group
> 
> I have a number of Astlinux VM which Im creating a standard template for. In my new DC, storage is actually now the most expensive resource so wanting to limit it where I can.
> Im thinking of starting pretty low which should be fine for most Its quite easy in OpenStack to extend a volume if I really needed to but is there any way that I can change the partitions in Astlinux to use the extra space without having to rebuild it?
> 
> Regards
>  Michael Knill
> Managing Director
>  D: +61 2 6189 1360
> P: +61 2 6140 4656
> E: mic...@ip...
> W: ipcsolutions.com.au
>   <image001.png>Smarter Business Communications
>   _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

[Astlinux-users] Extending Astlinux disk

[Michael K. <mic...@ip...>]

Hi Group

I have a number of Astlinux VM which Im creating a standard template for. In my new DC, storage is actually now the most expensive resource so wanting to limit it where I can.
Im thinking of starting pretty low which should be fine for most Its quite easy in OpenStack to extend a volume if I really needed to but is there any way that I can change the partitions in Astlinux to use the extra space without having to rebuild it?


Regards



Michael Knill

Managing Director



D: +61 2 6189 1360<tel:+61261891360>

P: +61 2 6140 4656<tel:+61261404656>

E: mic...@ip...<mailto:mic...@ip...>

W: ipcsolutions.com.au<https://ipcsolutions.com.au/>



 [Icon  Description automatically generated]

Smarter Business Communications

Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

[Michael K. <mic...@ip...>]

Thanks Lonnie

Will probably do 2)


Regards

Michael Knill



From: Lonnie Abelbeck <li...@lo...>
Date: Saturday, 30 August 2025 at 12:31 am
To: AstLinux Users Mailing List <ast...@li...>
Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

Hi Michael,

Possible solutions ...

1) (most desirable IMO)
Use only one NIC for the VM, and use VLAN(s) (ex. eth0.10, eth0.20) for the additional interfaces/subnets.

2)
Manually create the '/etc/udev/rules.d/70-persistent-net.rules' file with the static "fa:16:3e:*" MACs.

3) (least desirable IMO)
It does seem the "fa:16:3e:*" MAC is common to Red Hat OpenStack, so '/usr/lib/udev/rules.d/75-persistent-net-generator.rules' could be patched in the build system for the udev package... (untested)

--- udev-3.2.14/rule_generator/75-persistent-net-generator.rules.orig 2025-08-29 09:24:02.162262410 -0500
+++ udev-3.2.14/rule_generator/75-persistent-net-generator.rules 2025-08-29 09:26:03.782398817 -0500
@@ -61,6 +61,8 @@
 ENV{MATCHADDR}=="52:54:ab:*", GOTO="globally_administered_whitelist"
 # Kingston Technologies
 ENV{MATCHADDR}=="e2:0c:0f:*", GOTO="globally_administered_whitelist"
+# Red Hat OpenStack VM
+ENV{MATCHADDR}=="fa:16:3e:*", GOTO="globally_administered_whitelist"
   # match interface dev_id
 ATTR{dev_id}=="?*", ENV{MATCHDEVID}="$attr{dev_id}"


Lonnie



> On Aug 28, 2025, at 10:05 PM, Michael Knill <mic...@ip...> wrote:
>
> Ok I have found out from my provider that their MAC addresses are static and using the MAC address is how they recommend sorting out this issue.
> They mentioned the issue stems from the fact they cannot control which order Openstack adds the NICs to the VM, which in turn can cause the PCI address to change, and the kernel will rename devices based on that.
>
> As such, would you think it would be reasonable to manually create this file or could I modify the existing generator file or add a new one to automatically add it in?
>
> Regards
> Michael Knill
>   From: Michael Knill <mic...@ip...>
> Date: Thursday, 28 August 2025 at 3:39 pm
> To: AstLinux Users Mailing List <ast...@li...>
> Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created
>
> Thanks Lonnie
>
> I will confirm if the MAC’s change or not from the provider.
>
> Regards
> Michael Knill
>   From: Lonnie Abelbeck <li...@lo...>
> Date: Thursday, 28 August 2025 at 12:08 am
> To: AstLinux Users Mailing List <ast...@li...>
> Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created
>
> Michael,
>
> If the VM host MACs are changing from reboot to reboot, the 70-persistent-net.rules must not be generated, as that would cause problems.  Single NIC would not matter in this case, but multiple NICs are at the mercy of the VM host consistently maintaining the NIC order.
>
> I presume you are not seeing a problem with an OpenStack VM host, but you are just thinking ahead.
>
> FYI, here are some sample guest VM instances:
>
> ## Proxmox KVM (70-persistent-net.rules generated)
> pbx-pve ~ # mac2vendor bc:24:11
> Proxmox Server Solutions GmbH
>
> ## Linode KVM (no 70-persistent-net.rules)
> linode ~ # mac2vendor f2:3c:91
> Randomized MAC Address
>
> ## Vultr KVM (no 70-persistent-net.rules)
> vultr ~ # mac2vendor 56:00:01
> Randomized MAC Address
>
> ## UTM QEMU (no 70-persistent-net.rules)
> pbx-macos ~ # mac2vendor ee:df:27
> Randomized MAC Address
>
> Both Proxmox KVM and UTM QEMU can define the MAC address in the configuration, as such it is static.
>
> Both Linode KVM and Vultr KVM interface MACs do not change from reboot to reboot.
>
> Lonnie
>
>
>
> > On Aug 27, 2025, at 2:09 AM, Michael Knill <mic...@ip...> wrote:
> >
> > Thanks Lonnie
> >
> > So considering my MAC addresses are fa:16:3e:* could I comment out the following line from this file and reboot:
> >
> > # do not use "locally administered" MAC address
> > # ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""
> >
> > I would only edit for multi interface VM’s which are currently only our softswitch servers.
> >
> > What do you think? Or I could just build a manual one?
> >
> > Regards
> > Michael Knill
> >   From: Lonnie Abelbeck <li...@lo...>
> > Date: Wednesday, 27 August 2025 at 10:27 am
> > To: AstLinux Users Mailing List <ast...@li...>
> > Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created
> >
> > Hi Michael,
> >
> > That [1] file is generated by this udev rule:
> > --
> > /usr/lib/udev/rules.d/75-persistent-net-generator.rules
> > --
> > Not trivial to follow, but you can see how some interfaces are skipped.
> >
> > For many VM guests, no [1] file is auto-generated.
> >
> > None of my KVM Hypervisor Guest VMs have a [1] file.  Though in all cases the first interface is "eth0".
> >
> > I have never needed it, but you could add a manual [1] file (with specific MAC addresses) if needed.
> >
> > Lonnie
> >
> > [1] /etc/udev/rules.d/70-persistent-net.rules
> >
> >
> >
> > > On Aug 26, 2025, at 6:54 PM, Michael Knill <mic...@ip...> wrote:
> > >
> > > Hi All
> > >
> > > Im just wondering when '/etc/udev/rules.d/70-persistent-net.rules’ is created. I have Astlinux in an OpenStack VM and the NIC assignments appear to be pretty random and Im concerned that they could change on a reboot.
> > >
> > > I looked for this file but I could not find it:
> > > 12810-IPCPROD-SSFE1 kd # ls -la /etc/udev/rules.d/
> > > total 24
> > > drwxrwxr-x    1 root     root           120 Jul  5  2023 .
> > > drwxrwxr-x    1 root     root            80 Jul  5  2023 ..
> > > -rw-r--r--    1 root     root         11589 Jul  5  2023 62-nut-usbups.rules
> > > -rw-r--r--    1 root     root           753 Jul  5  2023 dahdi.rules
> > > -rw-r--r--    1 root     root           185 Jul  5  2023 usbtty.rules
> > > -rw-r--r--    1 root     root           531 Jul  5  2023 xpp.rules
> > >
> > > I thought this file was auto created as I usually have to delete it if I change NIC’s so wondering how it all works?
> > >
> > > Regards
> > >  Michael Knill
> > > Managing Director
> > >  D: +61 2 6189 1360
> > > P: +61 2 6140 4656
> > > E: mic...@ip...
> > > W: ipcsolutions.com.au
> > >   <image001.png>Smarter Business Communications
> > >   _______________________________________________
> > > Astlinux-users mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> >
> >
> >
> >
> > _______________________________________________
> > Astlinux-users mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> > _______________________________________________
> > Astlinux-users mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....




_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

[Lonnie A. <li...@lo...>]

Hi Michael,

Possible solutions ...

1) (most desirable IMO)
Use only one NIC for the VM, and use VLAN(s) (ex. eth0.10, eth0.20) for the additional interfaces/subnets.

2)
Manually create the '/etc/udev/rules.d/70-persistent-net.rules' file with the static "fa:16:3e:*" MACs.

3) (least desirable IMO)
It does seem the "fa:16:3e:*" MAC is common to Red Hat OpenStack, so '/usr/lib/udev/rules.d/75-persistent-net-generator.rules' could be patched in the build system for the udev package... (untested)

--- udev-3.2.14/rule_generator/75-persistent-net-generator.rules.orig 2025-08-29 09:24:02.162262410 -0500
+++ udev-3.2.14/rule_generator/75-persistent-net-generator.rules 2025-08-29 09:26:03.782398817 -0500
@@ -61,6 +61,8 @@
 ENV{MATCHADDR}=="52:54:ab:*", GOTO="globally_administered_whitelist"
 # Kingston Technologies
 ENV{MATCHADDR}=="e2:0c:0f:*", GOTO="globally_administered_whitelist"
+# Red Hat OpenStack VM
+ENV{MATCHADDR}=="fa:16:3e:*", GOTO="globally_administered_whitelist"
   # match interface dev_id
 ATTR{dev_id}=="?*", ENV{MATCHDEVID}="$attr{dev_id}"


Lonnie



> On Aug 28, 2025, at 10:05 PM, Michael Knill <mic...@ip...> wrote:
> 
> Ok I have found out from my provider that their MAC addresses are static and using the MAC address is how they recommend sorting out this issue.
> They mentioned the issue stems from the fact they cannot control which order Openstack adds the NICs to the VM, which in turn can cause the PCI address to change, and the kernel will rename devices based on that.
> 
> As such, would you think it would be reasonable to manually create this file or could I modify the existing generator file or add a new one to automatically add it in?
> 
> Regards
> Michael Knill
>   From: Michael Knill <mic...@ip...>
> Date: Thursday, 28 August 2025 at 3:39 pm
> To: AstLinux Users Mailing List <ast...@li...>
> Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created
> 
> Thanks Lonnie
> 
> I will confirm if the MAC’s change or not from the provider.
> 
> Regards
> Michael Knill
>   From: Lonnie Abelbeck <li...@lo...>
> Date: Thursday, 28 August 2025 at 12:08 am
> To: AstLinux Users Mailing List <ast...@li...>
> Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created
> 
> Michael,
> 
> If the VM host MACs are changing from reboot to reboot, the 70-persistent-net.rules must not be generated, as that would cause problems.  Single NIC would not matter in this case, but multiple NICs are at the mercy of the VM host consistently maintaining the NIC order.
> 
> I presume you are not seeing a problem with an OpenStack VM host, but you are just thinking ahead.
> 
> FYI, here are some sample guest VM instances:
> 
> ## Proxmox KVM (70-persistent-net.rules generated)
> pbx-pve ~ # mac2vendor bc:24:11
> Proxmox Server Solutions GmbH
> 
> ## Linode KVM (no 70-persistent-net.rules)
> linode ~ # mac2vendor f2:3c:91
> Randomized MAC Address
> 
> ## Vultr KVM (no 70-persistent-net.rules)
> vultr ~ # mac2vendor 56:00:01
> Randomized MAC Address
> 
> ## UTM QEMU (no 70-persistent-net.rules)
> pbx-macos ~ # mac2vendor ee:df:27
> Randomized MAC Address
> 
> Both Proxmox KVM and UTM QEMU can define the MAC address in the configuration, as such it is static.
> 
> Both Linode KVM and Vultr KVM interface MACs do not change from reboot to reboot.
> 
> Lonnie
> 
> 
> 
> > On Aug 27, 2025, at 2:09 AM, Michael Knill <mic...@ip...> wrote:
> >
> > Thanks Lonnie
> >
> > So considering my MAC addresses are fa:16:3e:* could I comment out the following line from this file and reboot:
> >
> > # do not use "locally administered" MAC address
> > # ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""
> >
> > I would only edit for multi interface VM’s which are currently only our softswitch servers.
> >
> > What do you think? Or I could just build a manual one?
> >
> > Regards
> > Michael Knill
> >   From: Lonnie Abelbeck <li...@lo...>
> > Date: Wednesday, 27 August 2025 at 10:27 am
> > To: AstLinux Users Mailing List <ast...@li...>
> > Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created
> >
> > Hi Michael,
> >
> > That [1] file is generated by this udev rule:
> > --
> > /usr/lib/udev/rules.d/75-persistent-net-generator.rules
> > --
> > Not trivial to follow, but you can see how some interfaces are skipped.
> >
> > For many VM guests, no [1] file is auto-generated.
> >
> > None of my KVM Hypervisor Guest VMs have a [1] file.  Though in all cases the first interface is "eth0".
> >
> > I have never needed it, but you could add a manual [1] file (with specific MAC addresses) if needed.
> >
> > Lonnie
> >
> > [1] /etc/udev/rules.d/70-persistent-net.rules
> >
> >
> >
> > > On Aug 26, 2025, at 6:54 PM, Michael Knill <mic...@ip...> wrote:
> > >
> > > Hi All
> > >
> > > Im just wondering when '/etc/udev/rules.d/70-persistent-net.rules’ is created. I have Astlinux in an OpenStack VM and the NIC assignments appear to be pretty random and Im concerned that they could change on a reboot.
> > >
> > > I looked for this file but I could not find it:
> > > 12810-IPCPROD-SSFE1 kd # ls -la /etc/udev/rules.d/
> > > total 24
> > > drwxrwxr-x    1 root     root           120 Jul  5  2023 .
> > > drwxrwxr-x    1 root     root            80 Jul  5  2023 ..
> > > -rw-r--r--    1 root     root         11589 Jul  5  2023 62-nut-usbups.rules
> > > -rw-r--r--    1 root     root           753 Jul  5  2023 dahdi.rules
> > > -rw-r--r--    1 root     root           185 Jul  5  2023 usbtty.rules
> > > -rw-r--r--    1 root     root           531 Jul  5  2023 xpp.rules
> > >
> > > I thought this file was auto created as I usually have to delete it if I change NIC’s so wondering how it all works?
> > >
> > > Regards
> > >  Michael Knill
> > > Managing Director
> > >  D: +61 2 6189 1360
> > > P: +61 2 6140 4656
> > > E: mic...@ip...
> > > W: ipcsolutions.com.au
> > >   <image001.png>Smarter Business Communications
> > >   _______________________________________________
> > > Astlinux-users mailing list
> > > Ast...@li...
> > > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> > >
> > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> >
> >
> >
> >
> > _______________________________________________
> > Astlinux-users mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> > _______________________________________________
> > Astlinux-users mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

[Michael K. <mic...@ip...>]

Ok I have found out from my provider that their MAC addresses are static and using the MAC address is how they recommend sorting out this issue.
They mentioned the issue stems from the fact they cannot control which order Openstack adds the NICs to the VM, which in turn can cause the PCI address to change, and the kernel will rename devices based on that.

As such, would you think it would be reasonable to manually create this file or could I modify the existing generator file or add a new one to automatically add it in?


Regards

Michael Knill



From: Michael Knill <mic...@ip...>
Date: Thursday, 28 August 2025 at 3:39 pm
To: AstLinux Users Mailing List <ast...@li...>
Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

Thanks Lonnie

I will confirm if the MAC’s change or not from the provider.


Regards

Michael Knill



From: Lonnie Abelbeck <li...@lo...>
Date: Thursday, 28 August 2025 at 12:08 am
To: AstLinux Users Mailing List <ast...@li...>
Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

Michael,

If the VM host MACs are changing from reboot to reboot, the 70-persistent-net.rules must not be generated, as that would cause problems.  Single NIC would not matter in this case, but multiple NICs are at the mercy of the VM host consistently maintaining the NIC order.

I presume you are not seeing a problem with an OpenStack VM host, but you are just thinking ahead.

FYI, here are some sample guest VM instances:

## Proxmox KVM (70-persistent-net.rules generated)
pbx-pve ~ # mac2vendor bc:24:11
Proxmox Server Solutions GmbH

## Linode KVM (no 70-persistent-net.rules)
linode ~ # mac2vendor f2:3c:91
Randomized MAC Address

## Vultr KVM (no 70-persistent-net.rules)
vultr ~ # mac2vendor 56:00:01
Randomized MAC Address

## UTM QEMU (no 70-persistent-net.rules)
pbx-macos ~ # mac2vendor ee:df:27
Randomized MAC Address

Both Proxmox KVM and UTM QEMU can define the MAC address in the configuration, as such it is static.

Both Linode KVM and Vultr KVM interface MACs do not change from reboot to reboot.

Lonnie



> On Aug 27, 2025, at 2:09 AM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> So considering my MAC addresses are fa:16:3e:* could I comment out the following line from this file and reboot:
>
> # do not use "locally administered" MAC address
> # ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""
>
> I would only edit for multi interface VM’s which are currently only our softswitch servers.
>
> What do you think? Or I could just build a manual one?
>
> Regards
> Michael Knill
>   From: Lonnie Abelbeck <li...@lo...>
> Date: Wednesday, 27 August 2025 at 10:27 am
> To: AstLinux Users Mailing List <ast...@li...>
> Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created
>
> Hi Michael,
>
> That [1] file is generated by this udev rule:
> --
> /usr/lib/udev/rules.d/75-persistent-net-generator.rules
> --
> Not trivial to follow, but you can see how some interfaces are skipped.
>
> For many VM guests, no [1] file is auto-generated.
>
> None of my KVM Hypervisor Guest VMs have a [1] file.  Though in all cases the first interface is "eth0".
>
> I have never needed it, but you could add a manual [1] file (with specific MAC addresses) if needed.
>
> Lonnie
>
> [1] /etc/udev/rules.d/70-persistent-net.rules
>
>
>
> > On Aug 26, 2025, at 6:54 PM, Michael Knill <mic...@ip...> wrote:
> >
> > Hi All
> >
> > Im just wondering when '/etc/udev/rules.d/70-persistent-net.rules’ is created. I have Astlinux in an OpenStack VM and the NIC assignments appear to be pretty random and Im concerned that they could change on a reboot.
> >
> > I looked for this file but I could not find it:
> > 12810-IPCPROD-SSFE1 kd # ls -la /etc/udev/rules.d/
> > total 24
> > drwxrwxr-x    1 root     root           120 Jul  5  2023 .
> > drwxrwxr-x    1 root     root            80 Jul  5  2023 ..
> > -rw-r--r--    1 root     root         11589 Jul  5  2023 62-nut-usbups.rules
> > -rw-r--r--    1 root     root           753 Jul  5  2023 dahdi.rules
> > -rw-r--r--    1 root     root           185 Jul  5  2023 usbtty.rules
> > -rw-r--r--    1 root     root           531 Jul  5  2023 xpp.rules
> >
> > I thought this file was auto created as I usually have to delete it if I change NIC’s so wondering how it all works?
> >
> > Regards
> >  Michael Knill
> > Managing Director
> >  D: +61 2 6189 1360
> > P: +61 2 6140 4656
> > E: mic...@ip...
> > W: ipcsolutions.com.au
> >   <image001.png>Smarter Business Communications
> >   _______________________________________________
> > Astlinux-users mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....




_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

[Michael K. <mic...@ip...>]

Thanks Lonnie

I will confirm if the MAC’s change or not from the provider.


Regards

Michael Knill



From: Lonnie Abelbeck <li...@lo...>
Date: Thursday, 28 August 2025 at 12:08 am
To: AstLinux Users Mailing List <ast...@li...>
Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

Michael,

If the VM host MACs are changing from reboot to reboot, the 70-persistent-net.rules must not be generated, as that would cause problems.  Single NIC would not matter in this case, but multiple NICs are at the mercy of the VM host consistently maintaining the NIC order.

I presume you are not seeing a problem with an OpenStack VM host, but you are just thinking ahead.

FYI, here are some sample guest VM instances:

## Proxmox KVM (70-persistent-net.rules generated)
pbx-pve ~ # mac2vendor bc:24:11
Proxmox Server Solutions GmbH

## Linode KVM (no 70-persistent-net.rules)
linode ~ # mac2vendor f2:3c:91
Randomized MAC Address

## Vultr KVM (no 70-persistent-net.rules)
vultr ~ # mac2vendor 56:00:01
Randomized MAC Address

## UTM QEMU (no 70-persistent-net.rules)
pbx-macos ~ # mac2vendor ee:df:27
Randomized MAC Address

Both Proxmox KVM and UTM QEMU can define the MAC address in the configuration, as such it is static.

Both Linode KVM and Vultr KVM interface MACs do not change from reboot to reboot.

Lonnie



> On Aug 27, 2025, at 2:09 AM, Michael Knill <mic...@ip...> wrote:
>
> Thanks Lonnie
>
> So considering my MAC addresses are fa:16:3e:* could I comment out the following line from this file and reboot:
>
> # do not use "locally administered" MAC address
> # ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""
>
> I would only edit for multi interface VM’s which are currently only our softswitch servers.
>
> What do you think? Or I could just build a manual one?
>
> Regards
> Michael Knill
>   From: Lonnie Abelbeck <li...@lo...>
> Date: Wednesday, 27 August 2025 at 10:27 am
> To: AstLinux Users Mailing List <ast...@li...>
> Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created
>
> Hi Michael,
>
> That [1] file is generated by this udev rule:
> --
> /usr/lib/udev/rules.d/75-persistent-net-generator.rules
> --
> Not trivial to follow, but you can see how some interfaces are skipped.
>
> For many VM guests, no [1] file is auto-generated.
>
> None of my KVM Hypervisor Guest VMs have a [1] file.  Though in all cases the first interface is "eth0".
>
> I have never needed it, but you could add a manual [1] file (with specific MAC addresses) if needed.
>
> Lonnie
>
> [1] /etc/udev/rules.d/70-persistent-net.rules
>
>
>
> > On Aug 26, 2025, at 6:54 PM, Michael Knill <mic...@ip...> wrote:
> >
> > Hi All
> >
> > Im just wondering when '/etc/udev/rules.d/70-persistent-net.rules’ is created. I have Astlinux in an OpenStack VM and the NIC assignments appear to be pretty random and Im concerned that they could change on a reboot.
> >
> > I looked for this file but I could not find it:
> > 12810-IPCPROD-SSFE1 kd # ls -la /etc/udev/rules.d/
> > total 24
> > drwxrwxr-x    1 root     root           120 Jul  5  2023 .
> > drwxrwxr-x    1 root     root            80 Jul  5  2023 ..
> > -rw-r--r--    1 root     root         11589 Jul  5  2023 62-nut-usbups.rules
> > -rw-r--r--    1 root     root           753 Jul  5  2023 dahdi.rules
> > -rw-r--r--    1 root     root           185 Jul  5  2023 usbtty.rules
> > -rw-r--r--    1 root     root           531 Jul  5  2023 xpp.rules
> >
> > I thought this file was auto created as I usually have to delete it if I change NIC’s so wondering how it all works?
> >
> > Regards
> >  Michael Knill
> > Managing Director
> >  D: +61 2 6189 1360
> > P: +61 2 6140 4656
> > E: mic...@ip...
> > W: ipcsolutions.com.au
> >   <image001.png>Smarter Business Communications
> >   _______________________________________________
> > Astlinux-users mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>
>
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....




_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

[Lonnie A. <li...@lo...>]

Michael,

If the VM host MACs are changing from reboot to reboot, the 70-persistent-net.rules must not be generated, as that would cause problems.  Single NIC would not matter in this case, but multiple NICs are at the mercy of the VM host consistently maintaining the NIC order.

I presume you are not seeing a problem with an OpenStack VM host, but you are just thinking ahead.

FYI, here are some sample guest VM instances:

## Proxmox KVM (70-persistent-net.rules generated)
pbx-pve ~ # mac2vendor bc:24:11
Proxmox Server Solutions GmbH

## Linode KVM (no 70-persistent-net.rules)
linode ~ # mac2vendor f2:3c:91
Randomized MAC Address

## Vultr KVM (no 70-persistent-net.rules)
vultr ~ # mac2vendor 56:00:01
Randomized MAC Address

## UTM QEMU (no 70-persistent-net.rules)
pbx-macos ~ # mac2vendor ee:df:27
Randomized MAC Address

Both Proxmox KVM and UTM QEMU can define the MAC address in the configuration, as such it is static.

Both Linode KVM and Vultr KVM interface MACs do not change from reboot to reboot.

Lonnie



> On Aug 27, 2025, at 2:09 AM, Michael Knill <mic...@ip...> wrote:
> 
> Thanks Lonnie
> 
> So considering my MAC addresses are fa:16:3e:* could I comment out the following line from this file and reboot:
> 
> # do not use "locally administered" MAC address
> # ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""
> 
> I would only edit for multi interface VM’s which are currently only our softswitch servers.
> 
> What do you think? Or I could just build a manual one?
> 
> Regards
> Michael Knill
>   From: Lonnie Abelbeck <li...@lo...>
> Date: Wednesday, 27 August 2025 at 10:27 am
> To: AstLinux Users Mailing List <ast...@li...>
> Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created
> 
> Hi Michael,
> 
> That [1] file is generated by this udev rule:
> --
> /usr/lib/udev/rules.d/75-persistent-net-generator.rules
> --
> Not trivial to follow, but you can see how some interfaces are skipped.
> 
> For many VM guests, no [1] file is auto-generated.
> 
> None of my KVM Hypervisor Guest VMs have a [1] file.  Though in all cases the first interface is "eth0".
> 
> I have never needed it, but you could add a manual [1] file (with specific MAC addresses) if needed.
> 
> Lonnie
> 
> [1] /etc/udev/rules.d/70-persistent-net.rules
> 
> 
> 
> > On Aug 26, 2025, at 6:54 PM, Michael Knill <mic...@ip...> wrote:
> >
> > Hi All
> >
> > Im just wondering when '/etc/udev/rules.d/70-persistent-net.rules’ is created. I have Astlinux in an OpenStack VM and the NIC assignments appear to be pretty random and Im concerned that they could change on a reboot.
> >
> > I looked for this file but I could not find it:
> > 12810-IPCPROD-SSFE1 kd # ls -la /etc/udev/rules.d/
> > total 24
> > drwxrwxr-x    1 root     root           120 Jul  5  2023 .
> > drwxrwxr-x    1 root     root            80 Jul  5  2023 ..
> > -rw-r--r--    1 root     root         11589 Jul  5  2023 62-nut-usbups.rules
> > -rw-r--r--    1 root     root           753 Jul  5  2023 dahdi.rules
> > -rw-r--r--    1 root     root           185 Jul  5  2023 usbtty.rules
> > -rw-r--r--    1 root     root           531 Jul  5  2023 xpp.rules
> >
> > I thought this file was auto created as I usually have to delete it if I change NIC’s so wondering how it all works?
> >
> > Regards
> >  Michael Knill
> > Managing Director
> >  D: +61 2 6189 1360
> > P: +61 2 6140 4656
> > E: mic...@ip...
> > W: ipcsolutions.com.au
> >   <image001.png>Smarter Business Communications
> >   _______________________________________________
> > Astlinux-users mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

[Michael K. <mic...@ip...>]

Thanks Lonnie

So considering my MAC addresses are fa:16:3e:* could I comment out the following line from this file and reboot:

# do not use "locally administered" MAC address
# ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""

I would only edit for multi interface VM’s which are currently only our softswitch servers.

What do you think? Or I could just build a manual one?


Regards

Michael Knill



From: Lonnie Abelbeck <li...@lo...>
Date: Wednesday, 27 August 2025 at 10:27 am
To: AstLinux Users Mailing List <ast...@li...>
Subject: Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

Hi Michael,

That [1] file is generated by this udev rule:
--
/usr/lib/udev/rules.d/75-persistent-net-generator.rules
--
Not trivial to follow, but you can see how some interfaces are skipped.

For many VM guests, no [1] file is auto-generated.

None of my KVM Hypervisor Guest VMs have a [1] file.  Though in all cases the first interface is "eth0".

I have never needed it, but you could add a manual [1] file (with specific MAC addresses) if needed.

Lonnie

[1] /etc/udev/rules.d/70-persistent-net.rules



> On Aug 26, 2025, at 6:54 PM, Michael Knill <mic...@ip...> wrote:
>
> Hi All
>
> Im just wondering when '/etc/udev/rules.d/70-persistent-net.rules’ is created. I have Astlinux in an OpenStack VM and the NIC assignments appear to be pretty random and Im concerned that they could change on a reboot.
>
> I looked for this file but I could not find it:
> 12810-IPCPROD-SSFE1 kd # ls -la /etc/udev/rules.d/
> total 24
> drwxrwxr-x    1 root     root           120 Jul  5  2023 .
> drwxrwxr-x    1 root     root            80 Jul  5  2023 ..
> -rw-r--r--    1 root     root         11589 Jul  5  2023 62-nut-usbups.rules
> -rw-r--r--    1 root     root           753 Jul  5  2023 dahdi.rules
> -rw-r--r--    1 root     root           185 Jul  5  2023 usbtty.rules
> -rw-r--r--    1 root     root           531 Jul  5  2023 xpp.rules
>
> I thought this file was auto created as I usually have to delete it if I change NIC’s so wondering how it all works?
>
> Regards
>  Michael Knill
> Managing Director
>  D: +61 2 6189 1360
> P: +61 2 6140 4656
> E: mic...@ip...
> W: ipcsolutions.com.au
>   <image001.png>Smarter Business Communications
>   _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....




_______________________________________________
Astlinux-users mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

[Lonnie A. <li...@lo...>]

Hi Michael,

That [1] file is generated by this udev rule:
--
/usr/lib/udev/rules.d/75-persistent-net-generator.rules
--
Not trivial to follow, but you can see how some interfaces are skipped.

For many VM guests, no [1] file is auto-generated.

None of my KVM Hypervisor Guest VMs have a [1] file.  Though in all cases the first interface is "eth0".

I have never needed it, but you could add a manual [1] file (with specific MAC addresses) if needed.

Lonnie

[1] /etc/udev/rules.d/70-persistent-net.rules



> On Aug 26, 2025, at 6:54 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi All
> 
> Im just wondering when '/etc/udev/rules.d/70-persistent-net.rules’ is created. I have Astlinux in an OpenStack VM and the NIC assignments appear to be pretty random and Im concerned that they could change on a reboot.
> 
> I looked for this file but I could not find it:
> 12810-IPCPROD-SSFE1 kd # ls -la /etc/udev/rules.d/
> total 24
> drwxrwxr-x    1 root     root           120 Jul  5  2023 .
> drwxrwxr-x    1 root     root            80 Jul  5  2023 ..
> -rw-r--r--    1 root     root         11589 Jul  5  2023 62-nut-usbups.rules
> -rw-r--r--    1 root     root           753 Jul  5  2023 dahdi.rules
> -rw-r--r--    1 root     root           185 Jul  5  2023 usbtty.rules
> -rw-r--r--    1 root     root           531 Jul  5  2023 xpp.rules
> 
> I thought this file was auto created as I usually have to delete it if I change NIC’s so wondering how it all works?
> 
> Regards
>  Michael Knill
> Managing Director
>  D: +61 2 6189 1360
> P: +61 2 6140 4656
> E: mic...@ip...
> W: ipcsolutions.com.au
>   <image001.png>Smarter Business Communications
>   _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

[Astlinux-users] When is '/etc/udev/rules.d/70-persistent-net.rules' created

[Michael K. <mic...@ip...>]

Hi All

Im just wondering when '/etc/udev/rules.d/70-persistent-net.rules’ is created. I have Astlinux in an OpenStack VM and the NIC assignments appear to be pretty random and Im concerned that they could change on a reboot.

I looked for this file but I could not find it:
12810-IPCPROD-SSFE1 kd # ls -la /etc/udev/rules.d/
total 24
drwxrwxr-x    1 root     root           120 Jul  5  2023 .
drwxrwxr-x    1 root     root            80 Jul  5  2023 ..
-rw-r--r--    1 root     root         11589 Jul  5  2023 62-nut-usbups.rules
-rw-r--r--    1 root     root           753 Jul  5  2023 dahdi.rules
-rw-r--r--    1 root     root           185 Jul  5  2023 usbtty.rules
-rw-r--r--    1 root     root           531 Jul  5  2023 xpp.rules

I thought this file was auto created as I usually have to delete it if I change NIC’s so wondering how it all works?


Regards



Michael Knill

Managing Director



D: +61 2 6189 1360<tel:+61261891360>

P: +61 2 6140 4656<tel:+61261404656>

E: mic...@ip...<mailto:mic...@ip...>

W: ipcsolutions.com.au<https://ipcsolutions.com.au/>



 [Icon  Description automatically generated]

Smarter Business Communications

Re: [Astlinux-users] OpenVPN TLS Resource Exhaustion Event

[Michael K. <li...@mk...>]

2 facts about Yealink firmware regarding OpenVPN

a) SHA256 is supported from FW 80 and later
b) FW 83 is using OpenVPN 2.4.2, FW 86 is using 2.4.9

Hope that helps.

Sent from a mobile device.

Michael Keuter

> Am 08.08.2025 um 15:28 schrieb Lonnie Abelbeck <li...@lo...>:
> 
> Hi Michael,
> 
> Agreed, for public OpenVPN exposure, either TLS-Auth or strict firewall rules are best practice.
> 
> We have stuck with OpenVPN 2.4 to be backward compatible to older IP Phone OpenVPN implementations.  One of the few places OpenVPN is used over WireGuard.
> 
> I am not sure if Yealink always supported the TLS-Auth feature, you might double-check your oldest Yealink firmware to make sure TLS-Auth is supported across the board.
> 
> Possibly using a low-end (inexpensive) GL.iNet box with WireGuard would be an alternative to the OpenVPN solution via Yealink.
> 
> Lonnie
> 
> 
> 
>> On Aug 8, 2025, at 12:11 AM, Michael Knill <mic...@ip...> wrote:
>> 
>> PS TLS Auth did solve the problem but having to redo all the OpenVPN certs is a daunting task.
>> 
>> Regards
>> Michael Knill
>>  From: Michael Knill <mic...@ip...>
>> Date: Friday, 8 August 2025 at 2:41 pm
>> To: AstLinux Users Mailing List <ast...@li...>
>> Subject: Re: [Astlinux-users] OpenVPN TLS Resource Exhaustion Event
>> 
>> PS TLS Auth is easy to do but I would need to reissue all the certificates to the OpenVPN peers (mainly Yealink phones).
>> We are testing it now but it would only be for new systems. If it works and we don’t have another option, we may need to suck it up and change them all.  
>> 
>> Regards
>> Michael Knill
>>  From: Michael Knill <mic...@ip...>
>> Date: Friday, 8 August 2025 at 1:41 pm
>> To: AstLinux List <ast...@li...>
>> Subject: [Astlinux-users] OpenVPN TLS Resource Exhaustion Event
>> 
>> Hi All
>> 
>> We run pretty low memory on our hosted Astlinux systems with about 100M available and today we experienced an OpenVPN attack on a number of our systems.
>> The attack consisted of around 1000 attempted logins between the period of 9:26:43 to 9:29:31. This number of failed TLS attempts caused many of our systems to run out of memory which became quite messy.
>> 
>> After doing some research, it appears the issue is:
>>    • OpenVPN 2.4.12 has inherent memory management limitations with failed TLS connections.
>>    • While CVE-2017-7521 was patched, the 2.4.x architecture still leaks memory during TLS exhaustion attacks.
>>    • Each failed handshake leaves behind unfreed memory (~4-8KB), accumulating over thousands of attempts.
>> 
>> To fix this problem we need to upgrade to OpenVPN 2.5.x or 2.6.x and add the tls-auth directive however as this is not easy to do, what are my other options.
>> Can I enable adaptive ban for OpenVPN? Implement rate limiting in iptables?
>> 
>> Thanks all.
>> 
>> Regards
>> Michael Knill
>> Managing Director
>> D: +61 2 6189 1360
>> P: +61 2 6140 4656
>> E: mic...@ip...
>> W: ipcsolutions.com.au
>>  <image001.png>Smarter Business Communications
>>  _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> 
> 
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] OpenVPN TLS Resource Exhaustion Event

[Michael K. <li...@mk...>]

Update: I am quite sure, regarding my old scripts, that TLS-Auth was already supported in Yealink FW 72 or 73.
Also all Yealink phones of the last 10 years (except the old W52P (FW 81)) can be at least upgraded to FW 83 (T4x, T5x, DECT).

Michael

https://mksolutions.info


> Am 08.08.2025 um 15:53 schrieb Michael Keuter <li...@mk...>:
> 
> 2 facts about Yealink firmware regarding OpenVPN
> 
> a) SHA256 is supported from FW 80 and later
> b) FW 83 is using OpenVPN 2.4.2, FW 86 is using 2.4.9
> 
> Hope that helps.
> 
> Sent from a mobile device.
> 
> Michael Keuter
> 
>> Am 08.08.2025 um 15:28 schrieb Lonnie Abelbeck <li...@lo...>:
>> 
>> Hi Michael,
>> 
>> Agreed, for public OpenVPN exposure, either TLS-Auth or strict firewall rules are best practice.
>> 
>> We have stuck with OpenVPN 2.4 to be backward compatible to older IP Phone OpenVPN implementations.  One of the few places OpenVPN is used over WireGuard.
>> 
>> I am not sure if Yealink always supported the TLS-Auth feature, you might double-check your oldest Yealink firmware to make sure TLS-Auth is supported across the board.
>> 
>> Possibly using a low-end (inexpensive) GL.iNet box with WireGuard would be an alternative to the OpenVPN solution via Yealink.
>> 
>> Lonnie
>> 
>> 
>> 
>>> On Aug 8, 2025, at 12:11 AM, Michael Knill <mic...@ip...> wrote:
>>> 
>>> PS TLS Auth did solve the problem but having to redo all the OpenVPN certs is a daunting task.
>>> 
>>> Regards
>>> Michael Knill
>>> From: Michael Knill <mic...@ip...>
>>> Date: Friday, 8 August 2025 at 2:41 pm
>>> To: AstLinux Users Mailing List <ast...@li...>
>>> Subject: Re: [Astlinux-users] OpenVPN TLS Resource Exhaustion Event
>>> 
>>> PS TLS Auth is easy to do but I would need to reissue all the certificates to the OpenVPN peers (mainly Yealink phones).
>>> We are testing it now but it would only be for new systems. If it works and we don’t have another option, we may need to suck it up and change them all.  
>>> 
>>> Regards
>>> Michael Knill
>>> From: Michael Knill <mic...@ip...>
>>> Date: Friday, 8 August 2025 at 1:41 pm
>>> To: AstLinux List <ast...@li...>
>>> Subject: [Astlinux-users] OpenVPN TLS Resource Exhaustion Event
>>> 
>>> Hi All
>>> 
>>> We run pretty low memory on our hosted Astlinux systems with about 100M available and today we experienced an OpenVPN attack on a number of our systems.
>>> The attack consisted of around 1000 attempted logins between the period of 9:26:43 to 9:29:31. This number of failed TLS attempts caused many of our systems to run out of memory which became quite messy.
>>> 
>>> After doing some research, it appears the issue is:
>>>  • OpenVPN 2.4.12 has inherent memory management limitations with failed TLS connections.
>>>  • While CVE-2017-7521 was patched, the 2.4.x architecture still leaks memory during TLS exhaustion attacks.
>>>  • Each failed handshake leaves behind unfreed memory (~4-8KB), accumulating over thousands of attempts.
>>> 
>>> To fix this problem we need to upgrade to OpenVPN 2.5.x or 2.6.x and add the tls-auth directive however as this is not easy to do, what are my other options.
>>> Can I enable adaptive ban for OpenVPN? Implement rate limiting in iptables?
>>> 
>>> Thanks all.
>>> 
>>> Regards
>>> Michael Knill
>>> Managing Director
>>> D: +61 2 6189 1360
>>> P: +61 2 6140 4656
>>> E: mic...@ip...
>>> W: ipcsolutions.com.au
>>> <image001.png>Smarter Business Communications
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>> 
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>