astlinux-users — AstLinux Users Mailing List

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....
> 

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

[Lonnie A. <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....

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

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

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<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. <mic...@ip...>]

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<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

[Astlinux-users] OpenVPN TLS Resource Exhaustion Event

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

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<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

[Astlinux-users] Announcing AstLinux Release: 1.5.11

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

Announcing AstLinux Release: 1.5.11

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

New Documentation Topics:
Protectli VP2430 Intel N150 Fanless Appliance [1]
Qotom Q10922H6 Intel N100 Fanless Appliance [2]
MeLE QuieterDL Intel N100 Fanless Mini PC [3]

AstLinux 1.5.11 Highlights:
* Asterisk Versions: 16.30.0, 18.26.2, 20.14.1
* Linux Kernel 5.10.238-cip61, security and bug fixes
* RUNNIX, version bump to runnix-0.6.23
* OpenSSL, version 1.1.1w, security fix: CVE-2024-13176
* OpenSSH, version 8.4p1, security fix: CVE-2025-32728
* libcurl (curl) version bump to 8.14.1
* libmad, version 0.15.1b, security fixes: CVE-2017-8372, CVE-2017-8373, CVE-2017-8374
* libxml2, version 2.11.9, many (7) security fixes
* chrony, version bump to 4.7
* keepalived, version bump to 2.3.4
* Monit, version bump to 5.35.2
* msmtp, version bump to 1.8.30
* mtr, version bump to 0.96
* php, version 7.2.34, add security fix: GHSA-wg4p-4hqh-c3g9
* screen, version 5.0.1, many (5) security fixes
* smartctl (smartmontools), version bump to 7.5, drivedb.h snapshot 2025-04-27
* sox, version 14.4.2, many (23) security fixes
* sqlite, version bump to 3.50.2
* stunnel, version bump to 5.75
* sudo, version 1.8.32, backport security fix: CVE-2025-32462
* unbound, version bump to 1.23.0
* WireGuard, wireguard-tools, version bump to 1.0.20250521
* ca-certificates, update trusted root certificates 2025-05-20
* mac2vendor, oui.txt database snapshot 2025-07-14
* 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.11/docs/ChangeLog.txt

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

AstLinux Team

[1] https://doc.astlinux-project.org/userdoc:board_protectli_vp2430
[2] https://doc.astlinux-project.org/userdoc:board_qotom_q10922h6
[3] https://doc.astlinux-project.org/userdoc:board_mele_quieterdl

Re: [Astlinux-users] PJSIP migration

[The C. K. <eld...@ya...>]

 PJSIP is confusing at first but after a short time its flow is pretty easy... the part i miss most about CHAN_SIP is the 'sip show peers' in a nice compact easy to read format.. pjsip show endpoints is not so easy..  several lines per station / trunk.. 
you can use the wizard format to have all of your PJSIP parameters in one entry vs multiple objects per peer / trunk. im not sure if astlinux has the wizrd co,piled in or not (ive been using regular asterisk for quite some time..  
    On Sunday, June 22, 2025 at 02:03:12 PM EDT, David Kerr <da...@ke...> wrote:  
 
 I migrated from SIP to PJSIP several months ago.  In general it went okay, but I ran into a problem with one DID provider... outbound would work fine, inbound calls just never arrived and nothing would show up in the asterisk debug messages.  I had to tcpdump the SIP packets to figure out what was going on.
The problem was authentication on the inbound SIP requests... PJSIP/asterisk was sending back an authentication challenge on the inbound calls.  This is typical for outbound, but not inbound and the DID provider could not handle. I commented out the "auth = did_provider" statement and that got it working on inbound calls.
David


On Sun, Jun 22, 2025 at 1:25 PM Dr. Peter Voigt <pv...@uo...> wrote:

Hi Lonie,

thanks for your quick reply. Nice to hear that chan_sip support will be
continued with version 20.x giving me at least some more time for this complex
migration. I've configured Asterisk numerous yours ago and almost left it
untoched as it is simply working. Therefore I am not an Asterisk expert at all
and I am having only little incentive to migrate to res_pjsip with lots of time
needed just to have things working as they to for years.

If you ever stumble over any of these migration scripts, please let me know to
let me give them a try.

Regards,
Peter


On Sat, 2025-06-21 at 17:38 -0500, Lonnie Abelbeck wrote:
> Hi Peter,
> 
> The AstLinux, Asterisk version 20.x [1] still contains chan_sip.  That will be
> the last of chan_sip support.
> 
> Personally I still use chan_sip, so I have no experience migrating to
> chan_pjsip.
> 
> It is my understanding there are scripts to roughly perform the migration for
> you.
> 
> Lonnie
> 
> [1] https://doc.astlinux-project.org/userdoc:tt_asterisk_upgrade_version
> 
> 
> 
> > On Jun 21, 2025, at 11:52 AM, Dr. Peter Voigt <pv...@uo...> wrote:
> > 
> > I am currently running astlinux-1.5.10 x86_64 - Asterisk 18.26.1 using
> > chan_sip.
> > 
> > If reading all information correctly, Asterisk 18 will be the last
> > Asterisk supporting chan_sip.
> > 
> > So I think it is time to start migrating to res_pjsip.so. My current 
> > chan_sip.so configuration is quite simple, just containing two trunk
> > definitions connecting to two different providers and two extensions
> > according
> > to my to phones.
> > 
> > I have checked already that module pjsip is loaded (res_pjsip.so and various
> > modules starting with res_pjsip).
> > 
> > To get a rough understanding of the whole migration process: Will it be
> > enough
> > to migrate configuration file sip.conf to pjsip.conf and subsequently delete
> > sip.conf. Furthermore, is it sufficient to replace any occurance of "SIP" in
> > extensions.conf with "PJSIP"?
> > 
> > I appreciate any feedback including helpful links for further reading
> > possibly
> > showing running pjsip.conf examples.
> > 
> > Regards,
> > Peter
> > 
> > 
> > 
> > _______________________________________________
> > 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] PJSIP migration

[David K. <da...@ke...>]

I migrated from SIP to PJSIP several months ago.  In general it went okay,
but I ran into a problem with one DID provider... outbound would work fine,
inbound calls just never arrived and nothing would show up in the asterisk
debug messages.  I had to tcpdump the SIP packets to figure out what was
going on.

The problem was authentication on the inbound SIP requests...
PJSIP/asterisk was sending back an authentication challenge on the inbound
calls.  This is typical for outbound, but not inbound and the DID provider
could not handle. I commented out the "auth = did_provider" statement and
that got it working on inbound calls.

David



On Sun, Jun 22, 2025 at 1:25 PM Dr. Peter Voigt <pv...@uo...> wrote:

> Hi Lonie,
>
> thanks for your quick reply. Nice to hear that chan_sip support will be
> continued with version 20.x giving me at least some more time for this
> complex
> migration. I've configured Asterisk numerous yours ago and almost left it
> untoched as it is simply working. Therefore I am not an Asterisk expert at
> all
> and I am having only little incentive to migrate to res_pjsip with lots of
> time
> needed just to have things working as they to for years.
>
> If you ever stumble over any of these migration scripts, please let me
> know to
> let me give them a try.
>
> Regards,
> Peter
>
>
> On Sat, 2025-06-21 at 17:38 -0500, Lonnie Abelbeck wrote:
> > Hi Peter,
> >
> > The AstLinux, Asterisk version 20.x [1] still contains chan_sip.  That
> will be
> > the last of chan_sip support.
> >
> > Personally I still use chan_sip, so I have no experience migrating to
> > chan_pjsip.
> >
> > It is my understanding there are scripts to roughly perform the
> migration for
> > you.
> >
> > Lonnie
> >
> > [1] https://doc.astlinux-project.org/userdoc:tt_asterisk_upgrade_version
> >
> >
> >
> > > On Jun 21, 2025, at 11:52 AM, Dr. Peter Voigt <pv...@uo...> wrote:
> > >
> > > I am currently running astlinux-1.5.10 x86_64 - Asterisk 18.26.1 using
> > > chan_sip.
> > >
> > > If reading all information correctly, Asterisk 18 will be the last
> > > Asterisk supporting chan_sip.
> > >
> > > So I think it is time to start migrating to res_pjsip.so. My current
> > > chan_sip.so configuration is quite simple, just containing two trunk
> > > definitions connecting to two different providers and two extensions
> > > according
> > > to my to phones.
> > >
> > > I have checked already that module pjsip is loaded (res_pjsip.so and
> various
> > > modules starting with res_pjsip).
> > >
> > > To get a rough understanding of the whole migration process: Will it be
> > > enough
> > > to migrate configuration file sip.conf to pjsip.conf and subsequently
> delete
> > > sip.conf. Furthermore, is it sufficient to replace any occurance of
> "SIP" in
> > > extensions.conf with "PJSIP"?
> > >
> > > I appreciate any feedback including helpful links for further reading
> > > possibly
> > > showing running pjsip.conf examples.
> > >
> > > Regards,
> > > Peter
> > >
> > >
> > >
> > > _______________________________________________
> > > 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] PJSIP migration

[Dr. P. V. <pv...@uo...>]

Hi Michael,

I did not yet know that there is a special section of ChatGPT dealing with
Asterisk configuration - thanks.

However, my experience with ChatGPT are very mixed especially with detailed
questions on complex topics which tend to be wrong in the first place. And even
if you more or less know that the answer is wrong or at least incomplete and
repeat the questions with more details giving, ChatGPT just agrees with you
about the previous wrong answer but does not give much more valuable information
for me to learn.

Therefore I will probably continue searching for documents and example
cocnfigurations that might be as base for my own configuration.

Last but not least you have to fully understand your final configuration
especially with regard to security.

Regards,
Peter


On Sat, 2025-06-21 at 22:34 +0000, Michael Knill wrote:
> Hi Peter
>  
> I need to do the same thing at some stage.
> I have seen migration articles online for this but I will be using ChatGPT
> with the Asterisk Ace GPT😊
>  
> Regards
> Michael Knill
>  
>  
> From:Dr. Peter Voigt <pv...@uo...>
> Date: Sunday, 22 June 2025 at 3:10 am
> To: AstLinux List <ast...@li...>
> Subject: [Astlinux-users] PJSIP migration
> I am currently running astlinux-1.5.10 x86_64 - Asterisk 18.26.1 using
> chan_sip.
> 
> If reading all information correctly, Asterisk 18 will be the last
> Asterisk supporting chan_sip.
> 
> So I think it is time to start migrating to res_pjsip.so. My current 
> chan_sip.so configuration is quite simple, just containing two trunk
> definitions connecting to two different providers and two extensions according
> to my to phones.
> 
> I have checked already that module pjsip is loaded (res_pjsip.so and various
> modules starting with res_pjsip).
> 
> To get a rough understanding of the whole migration process: Will it be enough
> to migrate configuration file sip.conf to pjsip.conf and subsequently delete
> sip.conf. Furthermore, is it sufficient to replace any occurance of "SIP" in 
> extensions.conf with "PJSIP"?
> 
> I appreciate any feedback including helpful links for further reading possibly
> showing running pjsip.conf examples.
> 
> Regards,
> Peter
> 
> 
> 
> _______________________________________________
> 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] PJSIP migration

[Dr. P. V. <pv...@uo...>]

Hi Lonie,

thanks for your quick reply. Nice to hear that chan_sip support will be
continued with version 20.x giving me at least some more time for this complex
migration. I've configured Asterisk numerous yours ago and almost left it
untoched as it is simply working. Therefore I am not an Asterisk expert at all
and I am having only little incentive to migrate to res_pjsip with lots of time
needed just to have things working as they to for years.

If you ever stumble over any of these migration scripts, please let me know to
let me give them a try.

Regards,
Peter


On Sat, 2025-06-21 at 17:38 -0500, Lonnie Abelbeck wrote:
> Hi Peter,
> 
> The AstLinux, Asterisk version 20.x [1] still contains chan_sip.  That will be
> the last of chan_sip support.
> 
> Personally I still use chan_sip, so I have no experience migrating to
> chan_pjsip.
> 
> It is my understanding there are scripts to roughly perform the migration for
> you.
> 
> Lonnie
> 
> [1] https://doc.astlinux-project.org/userdoc:tt_asterisk_upgrade_version
> 
> 
> 
> > On Jun 21, 2025, at 11:52 AM, Dr. Peter Voigt <pv...@uo...> wrote:
> > 
> > I am currently running astlinux-1.5.10 x86_64 - Asterisk 18.26.1 using
> > chan_sip.
> > 
> > If reading all information correctly, Asterisk 18 will be the last
> > Asterisk supporting chan_sip.
> > 
> > So I think it is time to start migrating to res_pjsip.so. My current 
> > chan_sip.so configuration is quite simple, just containing two trunk
> > definitions connecting to two different providers and two extensions
> > according
> > to my to phones.
> > 
> > I have checked already that module pjsip is loaded (res_pjsip.so and various
> > modules starting with res_pjsip).
> > 
> > To get a rough understanding of the whole migration process: Will it be
> > enough
> > to migrate configuration file sip.conf to pjsip.conf and subsequently delete
> > sip.conf. Furthermore, is it sufficient to replace any occurance of "SIP" in
> > extensions.conf with "PJSIP"?
> > 
> > I appreciate any feedback including helpful links for further reading
> > possibly
> > showing running pjsip.conf examples.
> > 
> > Regards,
> > Peter
> > 
> > 
> > 
> > _______________________________________________
> > 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] PJSIP migration

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

Hi Peter

I need to do the same thing at some stage.
I have seen migration articles online for this but I will be using ChatGPT with the Asterisk Ace GPT 😊

Regards
Michael Knill


From: Dr. Peter Voigt <pv...@uo...>
Date: Sunday, 22 June 2025 at 3:10 am
To: AstLinux List <ast...@li...>
Subject: [Astlinux-users] PJSIP migration
I am currently running astlinux-1.5.10 x86_64 - Asterisk 18.26.1 using
chan_sip.

If reading all information correctly, Asterisk 18 will be the last
Asterisk supporting chan_sip.

So I think it is time to start migrating to res_pjsip.so. My current
chan_sip.so configuration is quite simple, just containing two trunk
definitions connecting to two different providers and two extensions according
to my to phones.

I have checked already that module pjsip is loaded (res_pjsip.so and various
modules starting with res_pjsip).

To get a rough understanding of the whole migration process: Will it be enough
to migrate configuration file sip.conf to pjsip.conf and subsequently delete
sip.conf. Furthermore, is it sufficient to replace any occurance of "SIP" in
extensions.conf with "PJSIP"?

I appreciate any feedback including helpful links for further reading possibly
showing running pjsip.conf examples.

Regards,
Peter



_______________________________________________
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] PJSIP migration

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

Hi Peter,

The AstLinux, Asterisk version 20.x [1] still contains chan_sip.  That will be the last of chan_sip support.

Personally I still use chan_sip, so I have no experience migrating to chan_pjsip.

It is my understanding there are scripts to roughly perform the migration for you.

Lonnie

[1] https://doc.astlinux-project.org/userdoc:tt_asterisk_upgrade_version



> On Jun 21, 2025, at 11:52 AM, Dr. Peter Voigt <pv...@uo...> wrote:
> 
> I am currently running astlinux-1.5.10 x86_64 - Asterisk 18.26.1 using
> chan_sip.
> 
> If reading all information correctly, Asterisk 18 will be the last
> Asterisk supporting chan_sip.
> 
> So I think it is time to start migrating to res_pjsip.so. My current 
> chan_sip.so configuration is quite simple, just containing two trunk
> definitions connecting to two different providers and two extensions according
> to my to phones.
> 
> I have checked already that module pjsip is loaded (res_pjsip.so and various
> modules starting with res_pjsip).
> 
> To get a rough understanding of the whole migration process: Will it be enough
> to migrate configuration file sip.conf to pjsip.conf and subsequently delete
> sip.conf. Furthermore, is it sufficient to replace any occurance of "SIP" in 
> extensions.conf with "PJSIP"?
> 
> I appreciate any feedback including helpful links for further reading possibly
> showing running pjsip.conf examples.
> 
> Regards,
> Peter
> 
> 
> 
> _______________________________________________
> 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] PJSIP migration

[Dr. P. V. <pv...@uo...>]

I am currently running astlinux-1.5.10 x86_64 - Asterisk 18.26.1 using
chan_sip.

If reading all information correctly, Asterisk 18 will be the last
Asterisk supporting chan_sip.

So I think it is time to start migrating to res_pjsip.so. My current 
chan_sip.so configuration is quite simple, just containing two trunk
definitions connecting to two different providers and two extensions according
to my to phones.

I have checked already that module pjsip is loaded (res_pjsip.so and various
modules starting with res_pjsip).

To get a rough understanding of the whole migration process: Will it be enough
to migrate configuration file sip.conf to pjsip.conf and subsequently delete
sip.conf. Furthermore, is it sufficient to replace any occurance of "SIP" in 
extensions.conf with "PJSIP"?

I appreciate any feedback including helpful links for further reading possibly
showing running pjsip.conf examples.

Regards,
Peter