astlinux-users — AstLinux Users Mailing List

Re: [Astlinux-users] DAHDI cards and AstLinux 1.5.x testing

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

Hi Gonzalo,

Thanks very much for the timely testing.

Great results.  Perfect.

Lonnie



> On Dec 30, 2022, at 4:54 PM, Gonzalo Ibáñez <gon...@ho...> wrote:
> 
> Hi,
> 
> So far so good, everything ok and sound quality from/to analog lines is ok:
> 
> |||||
> | A |     Release: astlinux-1.5-5689-b4e39c - Asterisk 18.15.1
> | s |   Host Name:
> | t |   Last Boot: 2022-12-30 21:26
> | L |       Linux: 5.10.158-astlinux x86_64
> | i |         CPU: Intel Atom N2800 (4x) @ 1866 MHz
> | n |         RAM: 1982 MB
> | u |  Board Type: genx86_64
> | x |    Hardware: Generic x86_64
> |||||
> 
> [   16.650210] dahdi: loading out-of-tree module taints kernel.
> [   16.652463] dahdi: Version: 3.2.0
> [   16.653220] dahdi: Telephony Interface Registered on major 196
> [   16.679708] No freshmaker chip
> [   17.400332] Module 0: Installed -- AUTO FXO (SPAIN mode)
> [   17.888371] Module 1: Installed -- AUTO FXS/DPO
> [   18.389722] Module 2: Installed -- AUTO FXS/DPO
> [   18.390139] Module 3: Not installed
> [   18.392192] Found a Wildcard TDM: Wildcard TDM400P REV I (3 modules)
> [   18.441892] dahdi_echocan_oslec: Registered echo canceler 'OSLEC'
> [   38.318682] ioctl: Start OnHookTrans, card 1
> [   38.959017] ioctl: Start OnHookTrans, card 2
> 
> # lsdahdi
> ### Span  1: WCTDM/4 "Wildcard TDM400P REV I Board 5" (MASTER)
>   1 FXO        FXSKS       (In use) (EC: OSLEC - INACTIVE)  
>   2 FXS        FXOKS       (In use) (EC: OSLEC - INACTIVE)  
>   3 FXS        FXOKS       (In use) (EC: OSLEC - INACTIVE)  
>   4 unknown    Reserved  
> 
> # asterisk -rx "dahdi show status"
> Description                              Alarms  IRQ    bpviol CRC    Fra Codi Options  LBO
> Wildcard TDM400P REV I Board 5           OK      0      0      0      CAS Unk           0 db (CSU)/0-133 feet (DSX-1)
> 
> 
> Thanks again and a happy new year to everybody.
> 
> Regards.
> De: Ionel Chila <ion...@ma...>
> Enviado: viernes, 30 de diciembre de 2022 21:10
> Para: Lonnie Abelbeck <li...@lo...>
> Cc: AstLinux Users Mailing List <ast...@li...>; Gonzalo Ibáñez <gon...@ho...>
> Asunto: Re: DAHDI cards and AstLinux 1.5.x testing
>  
> Lonnie,
> 
> First of all Merry Christmas and Happy New Year.  As always you’re being awesome and thanks for thinking of us through this upgrade process as well thanks for working so hard through your holidays. 
> 
> I can confirm that everything works perfect after this upgrade Sir. Should I stay on this version or reverse back and wait for the official release?
> 
> THANKS again Sir
> 
> 
> 
> <Screenshot 2022-12-30 at 2.07.54 PM.png>
> <Screenshot 2022-12-30 at 2.06.55 PM.png>
> <Screenshot 2022-12-30 at 2.04.49 PM.png>
> 
> 
> 
> 
> 
> 
> > On Dec 30, 2022, at 1:18 PM, Lonnie Abelbeck <li...@lo...> wrote:
> > 
> > Hi ... specially Ionel and Gonzalo (or others) for DAHDI testing.
> > 
> > You previously tested the AstLinux 1.4.x series with DAHDI 3.1.0, at that time we patched dahdi-linux to include PCI card support for: wctdm24xxp, wctdm and wcfxo
> > 
> > Gonzalo indicated it worked:
> > --
> >> |||||
> >> | A |     Release: astlinux-1.4-4806-e5d33e - Asterisk 13.34.0
> >> | s |   Host Name:
> >> | t |   Last Boot: 2020-08-30 12:38
> >> | L |       Linux: 4.19.140-astlinux x86_64
> >> | i |         CPU: Intel Atom N2800 (4x) @ 1866 MHz
> >> | n |         RAM: 1983 MB
> >> | u |  Board Type: genx86_64
> >> | x |    Hardware: Generic x86_64
> >> |||||
> >> 
> >> 
> >> [   24.405610] dahdi: Version: 3.1.0
> >> [   24.409381] dahdi: Telephony Interface Registered on major 196
> >> [   24.435136] No freshmaker chip
> >> [   25.149448] Module 0: Installed -- AUTO FXO (SPAIN mode)
> >> [   25.635354] Module 1: Installed -- AUTO FXS/DPO
> >> [   25.719428] Excessive leakage detected on module 2: 1 volts (03) after 34 ms
> >> [   25.719490] ProSLIC module 2 failed leakage test.  Check for short circuit
> >> [   26.126341] Module 2: Installed -- AUTO FXS/DPO
> >> [   26.126752] Module 3: Not installed
> >> [   26.136305] Found a Wildcard TDM: Wildcard TDM400P REV I (3 modules)
> >> [   26.182717] dahdi_echocan_oslec: Registered echo canceler 'OSLEC'
> >> [   44.144753] ioctl: Start OnHookTrans, card 1
> >> [   45.064225] ioctl: Start OnHookTrans, card 2
> > --
> > 
> > 
> > It is more than 2 years later and the AstLinux Team is working on the AstLinux 1.5.x series with DAHDI 3.2.0 and Linux Kernel 5.10.y, we have included the same patches to maintain PCI card support for: wctdm24xxp, wctdm and wcfxo
> > 
> > While the Linux Kernel 5.10.y drivers build properly, we have no way to test if things still work using those cards.
> > 
> > 
> > It now needs testing ... there is a new Pre-Release Version: astlinux-1.5-5689-b4e39c
> > 
> > Info:
> > https://www.astlinux-project.org/dev.html
> > 
> > With the console, use the CLI to upgrade via the appropriate Pre-Release Repository URL for your Asterisk version.
> > 
> > If you want to, revert back to your previous image with "upgrade-run-image revert" and "kernel-reboot" CLI commands.
> > 
> > In theory, it should just work.
> > 
> > Please post your test results here.
> > 
> > Thanks!
> > 
> > Lonnie
> > 

Re: [Astlinux-users] DAHDI cards and AstLinux 1.5.x testing

[Gonzalo I. <gon...@ho...>]

Hi,

So far so good, everything ok and sound quality from/to analog lines is ok:

|||||
| A |     Release: astlinux-1.5-5689-b4e39c - Asterisk 18.15.1
| s |   Host Name:
| t |   Last Boot: 2022-12-30 21:26
| L |       Linux: 5.10.158-astlinux x86_64
| i |         CPU: Intel Atom N2800 (4x) @ 1866 MHz
| n |         RAM: 1982 MB
| u |  Board Type: genx86_64
| x |    Hardware: Generic x86_64
|||||

[   16.650210] dahdi: loading out-of-tree module taints kernel.
[   16.652463] dahdi: Version: 3.2.0
[   16.653220] dahdi: Telephony Interface Registered on major 196
[   16.679708] No freshmaker chip
[   17.400332] Module 0: Installed -- AUTO FXO (SPAIN mode)
[   17.888371] Module 1: Installed -- AUTO FXS/DPO
[   18.389722] Module 2: Installed -- AUTO FXS/DPO
[   18.390139] Module 3: Not installed
[   18.392192] Found a Wildcard TDM: Wildcard TDM400P REV I (3 modules)
[   18.441892] dahdi_echocan_oslec: Registered echo canceler 'OSLEC'
[   38.318682] ioctl: Start OnHookTrans, card 1
[   38.959017] ioctl: Start OnHookTrans, card 2

# lsdahdi
### Span  1: WCTDM/4 "Wildcard TDM400P REV I Board 5" (MASTER)
  1 FXO        FXSKS       (In use) (EC: OSLEC - INACTIVE)
  2 FXS        FXOKS       (In use) (EC: OSLEC - INACTIVE)
  3 FXS        FXOKS       (In use) (EC: OSLEC - INACTIVE)
  4 unknown    Reserved

# asterisk -rx "dahdi show status"
Description                              Alarms  IRQ    bpviol CRC    Fra Codi Options  LBO
Wildcard TDM400P REV I Board 5           OK      0      0      0      CAS Unk           0 db (CSU)/0-133 feet (DSX-1)


Thanks again and a happy new year to everybody.

Regards.
________________________________
De: Ionel Chila <ion...@ma...>
Enviado: viernes, 30 de diciembre de 2022 21:10
Para: Lonnie Abelbeck <li...@lo...>
Cc: AstLinux Users Mailing List <ast...@li...>; Gonzalo Ibáñez <gon...@ho...>
Asunto: Re: DAHDI cards and AstLinux 1.5.x testing

Lonnie,

First of all Merry Christmas and Happy New Year.  As always you’re being awesome and thanks for thinking of us through this upgrade process as well thanks for working so hard through your holidays.

I can confirm that everything works perfect after this upgrade Sir. Should I stay on this version or reverse back and wait for the official release?

THANKS again Sir



[cid:820...@EU...]
[cid:b00...@EU...]
[cid:e12...@EU...]






> On Dec 30, 2022, at 1:18 PM, Lonnie Abelbeck <li...@lo...> wrote:
>
> Hi ... specially Ionel and Gonzalo (or others) for DAHDI testing.
>
> You previously tested the AstLinux 1.4.x series with DAHDI 3.1.0, at that time we patched dahdi-linux to include PCI card support for: wctdm24xxp, wctdm and wcfxo
>
> Gonzalo indicated it worked:
> --
>> |||||
>> | A |     Release: astlinux-1.4-4806-e5d33e - Asterisk 13.34.0
>> | s |   Host Name:
>> | t |   Last Boot: 2020-08-30 12:38
>> | L |       Linux: 4.19.140-astlinux x86_64
>> | i |         CPU: Intel Atom N2800 (4x) @ 1866 MHz
>> | n |         RAM: 1983 MB
>> | u |  Board Type: genx86_64
>> | x |    Hardware: Generic x86_64
>> |||||
>>
>>
>> [   24.405610] dahdi: Version: 3.1.0
>> [   24.409381] dahdi: Telephony Interface Registered on major 196
>> [   24.435136] No freshmaker chip
>> [   25.149448] Module 0: Installed -- AUTO FXO (SPAIN mode)
>> [   25.635354] Module 1: Installed -- AUTO FXS/DPO
>> [   25.719428] Excessive leakage detected on module 2: 1 volts (03) after 34 ms
>> [   25.719490] ProSLIC module 2 failed leakage test.  Check for short circuit
>> [   26.126341] Module 2: Installed -- AUTO FXS/DPO
>> [   26.126752] Module 3: Not installed
>> [   26.136305] Found a Wildcard TDM: Wildcard TDM400P REV I (3 modules)
>> [   26.182717] dahdi_echocan_oslec: Registered echo canceler 'OSLEC'
>> [   44.144753] ioctl: Start OnHookTrans, card 1
>> [   45.064225] ioctl: Start OnHookTrans, card 2
> --
>
>
> It is more than 2 years later and the AstLinux Team is working on the AstLinux 1.5.x series with DAHDI 3.2.0 and Linux Kernel 5.10.y, we have included the same patches to maintain PCI card support for: wctdm24xxp, wctdm and wcfxo
>
> While the Linux Kernel 5.10.y drivers build properly, we have no way to test if things still work using those cards.
>
>
> It now needs testing ... there is a new Pre-Release Version: astlinux-1.5-5689-b4e39c
>
> Info:
> https://www.astlinux-project.org/dev.html
>
> With the console, use the CLI to upgrade via the appropriate Pre-Release Repository URL for your Asterisk version.
>
> If you want to, revert back to your previous image with "upgrade-run-image revert" and "kernel-reboot" CLI commands.
>
> In theory, it should just work.
>
> Please post your test results here.
>
> Thanks!
>
> Lonnie
>

Re: [Astlinux-users] DAHDI cards and AstLinux 1.5.x testing

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

Hi Ionel,

> I can confirm that everything works perfect after this upgrade Sir.

Excellent!


> Should I stay on this version or reverse back and wait for the official release?

I am personally running astlinux-1.5-5689-b4e39c ... there are no issues that I am currently aware of.

You can always revert later if you see issues.

BTW, the official astlinux-1.5.0 release will most likely be 8-10 weeks away.

Lonnie




> On Dec 30, 2022, at 2:10 PM, Ionel Chila <ion...@ma...> wrote:
> 
> Lonnie,
> 
> First of all Merry Christmas and Happy New Year.  As always you’re being awesome and thanks for thinking of us through this upgrade process as well thanks for working so hard through your holidays. 
> 
> I can confirm that everything works perfect after this upgrade Sir. Should I stay on this version or reverse back and wait for the official release?
> 
> THANKS again Sir
> 
> 
> 
> <Screenshot 2022-12-30 at 2.07.54 PM.png><Screenshot 2022-12-30 at 2.06.55 PM.png><Screenshot 2022-12-30 at 2.04.49 PM.png>
> 
> 
> 
> 
> 
>> On Dec 30, 2022, at 1:18 PM, Lonnie Abelbeck <li...@lo...> wrote:
>> 
>> Hi ... specially Ionel and Gonzalo (or others) for DAHDI testing.
>> 
>> You previously tested the AstLinux 1.4.x series with DAHDI 3.1.0, at that time we patched dahdi-linux to include PCI card support for: wctdm24xxp, wctdm and wcfxo
>> 
>> Gonzalo indicated it worked:
>> --
>>> |||||
>>> | A |     Release: astlinux-1.4-4806-e5d33e - Asterisk 13.34.0
>>> | s |   Host Name:
>>> | t |   Last Boot: 2020-08-30 12:38
>>> | L |       Linux: 4.19.140-astlinux x86_64
>>> | i |         CPU: Intel Atom N2800 (4x) @ 1866 MHz
>>> | n |         RAM: 1983 MB
>>> | u |  Board Type: genx86_64
>>> | x |    Hardware: Generic x86_64
>>> |||||
>>> 
>>> 
>>> [   24.405610] dahdi: Version: 3.1.0
>>> [   24.409381] dahdi: Telephony Interface Registered on major 196
>>> [   24.435136] No freshmaker chip
>>> [   25.149448] Module 0: Installed -- AUTO FXO (SPAIN mode)
>>> [   25.635354] Module 1: Installed -- AUTO FXS/DPO
>>> [   25.719428] Excessive leakage detected on module 2: 1 volts (03) after 34 ms
>>> [   25.719490] ProSLIC module 2 failed leakage test.  Check for short circuit
>>> [   26.126341] Module 2: Installed -- AUTO FXS/DPO
>>> [   26.126752] Module 3: Not installed
>>> [   26.136305] Found a Wildcard TDM: Wildcard TDM400P REV I (3 modules)
>>> [   26.182717] dahdi_echocan_oslec: Registered echo canceler 'OSLEC'
>>> [   44.144753] ioctl: Start OnHookTrans, card 1
>>> [   45.064225] ioctl: Start OnHookTrans, card 2
>> --
>> 
>> 
>> It is more than 2 years later and the AstLinux Team is working on the AstLinux 1.5.x series with DAHDI 3.2.0 and Linux Kernel 5.10.y, we have included the same patches to maintain PCI card support for: wctdm24xxp, wctdm and wcfxo
>> 
>> While the Linux Kernel 5.10.y drivers build properly, we have no way to test if things still work using those cards.
>> 
>> 
>> It now needs testing ... there is a new Pre-Release Version: astlinux-1.5-5689-b4e39c
>> 
>> Info:
>> https://www.astlinux-project.org/dev.html
>> 
>> With the console, use the CLI to upgrade via the appropriate Pre-Release Repository URL for your Asterisk version.
>> 
>> If you want to, revert back to your previous image with "upgrade-run-image revert" and "kernel-reboot" CLI commands.
>> 
>> In theory, it should just work.
>> 
>> Please post your test results here.
>> 
>> Thanks!
>> 
>> Lonnie
>> 
> 

Re: [Astlinux-users] DAHDI cards and AstLinux 1.5.x testing

[Gonzalo <gon...@ho...>]

Thanks Lonnie for not forgetting us the analogue ones! :-)

I'll test it and give you feedback on this thread in a week or so.

Regards.


El 30 de diciembre de 2022 19:18:43 UTC, Lonnie Abelbeck <li...@lo...> escribió:
>Hi ... specially Ionel and Gonzalo (or others) for DAHDI testing.
>
>You previously tested the AstLinux 1.4.x series with DAHDI 3.1.0, at that time we patched dahdi-linux to include PCI card support for: wctdm24xxp, wctdm and wcfxo
>
>Gonzalo indicated it worked:
>--
>> |||||
>> | A |     Release: astlinux-1.4-4806-e5d33e - Asterisk 13.34.0
>> | s |   Host Name:
>> | t |   Last Boot: 2020-08-30 12:38
>> | L |       Linux: 4.19.140-astlinux x86_64
>> | i |         CPU: Intel Atom N2800 (4x) @ 1866 MHz
>> | n |         RAM: 1983 MB
>> | u |  Board Type: genx86_64
>> | x |    Hardware: Generic x86_64
>> |||||
>> 
>> 
>> [   24.405610] dahdi: Version: 3.1.0
>> [   24.409381] dahdi: Telephony Interface Registered on major 196
>> [   24.435136] No freshmaker chip
>> [   25.149448] Module 0: Installed -- AUTO FXO (SPAIN mode)
>> [   25.635354] Module 1: Installed -- AUTO FXS/DPO
>> [   25.719428] Excessive leakage detected on module 2: 1 volts (03) after 34 ms
>> [   25.719490] ProSLIC module 2 failed leakage test.  Check for short circuit
>> [   26.126341] Module 2: Installed -- AUTO FXS/DPO
>> [   26.126752] Module 3: Not installed
>> [   26.136305] Found a Wildcard TDM: Wildcard TDM400P REV I (3 modules)
>> [   26.182717] dahdi_echocan_oslec: Registered echo canceler 'OSLEC'
>> [   44.144753] ioctl: Start OnHookTrans, card 1
>> [   45.064225] ioctl: Start OnHookTrans, card 2
>--
>
>
>It is more than 2 years later and the AstLinux Team is working on the AstLinux 1.5.x series with DAHDI 3.2.0 and Linux Kernel 5.10.y, we have included the same patches to maintain PCI card support for: wctdm24xxp, wctdm and wcfxo
>
>While the Linux Kernel 5.10.y drivers build properly, we have no way to test if things still work using those cards.
>
>
>It now needs testing ... there is a new Pre-Release Version: astlinux-1.5-5689-b4e39c
>
>Info:
>https://www.astlinux-project.org/dev.html
>
>With the console, use the CLI to upgrade via the appropriate Pre-Release Repository URL for your Asterisk version.
>
>If you want to, revert back to your previous image with "upgrade-run-image revert" and "kernel-reboot" CLI commands.
>
>In theory, it should just work.
>
>Please post your test results here.
>
>Thanks!
>
>Lonnie
>

[Astlinux-users] DAHDI cards and AstLinux 1.5.x testing

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

Hi ... specially Ionel and Gonzalo (or others) for DAHDI testing.

You previously tested the AstLinux 1.4.x series with DAHDI 3.1.0, at that time we patched dahdi-linux to include PCI card support for: wctdm24xxp, wctdm and wcfxo

Gonzalo indicated it worked:
--
> |||||
> | A |     Release: astlinux-1.4-4806-e5d33e - Asterisk 13.34.0
> | s |   Host Name:
> | t |   Last Boot: 2020-08-30 12:38
> | L |       Linux: 4.19.140-astlinux x86_64
> | i |         CPU: Intel Atom N2800 (4x) @ 1866 MHz
> | n |         RAM: 1983 MB
> | u |  Board Type: genx86_64
> | x |    Hardware: Generic x86_64
> |||||
> 
> 
> [   24.405610] dahdi: Version: 3.1.0
> [   24.409381] dahdi: Telephony Interface Registered on major 196
> [   24.435136] No freshmaker chip
> [   25.149448] Module 0: Installed -- AUTO FXO (SPAIN mode)
> [   25.635354] Module 1: Installed -- AUTO FXS/DPO
> [   25.719428] Excessive leakage detected on module 2: 1 volts (03) after 34 ms
> [   25.719490] ProSLIC module 2 failed leakage test.  Check for short circuit
> [   26.126341] Module 2: Installed -- AUTO FXS/DPO
> [   26.126752] Module 3: Not installed
> [   26.136305] Found a Wildcard TDM: Wildcard TDM400P REV I (3 modules)
> [   26.182717] dahdi_echocan_oslec: Registered echo canceler 'OSLEC'
> [   44.144753] ioctl: Start OnHookTrans, card 1
> [   45.064225] ioctl: Start OnHookTrans, card 2
--


It is more than 2 years later and the AstLinux Team is working on the AstLinux 1.5.x series with DAHDI 3.2.0 and Linux Kernel 5.10.y, we have included the same patches to maintain PCI card support for: wctdm24xxp, wctdm and wcfxo

While the Linux Kernel 5.10.y drivers build properly, we have no way to test if things still work using those cards.


It now needs testing ... there is a new Pre-Release Version: astlinux-1.5-5689-b4e39c

Info:
https://www.astlinux-project.org/dev.html

With the console, use the CLI to upgrade via the appropriate Pre-Release Repository URL for your Asterisk version.

If you want to, revert back to your previous image with "upgrade-run-image revert" and "kernel-reboot" CLI commands.

In theory, it should just work.

Please post your test results here.

Thanks!

Lonnie

[Astlinux-users] Announcing AstLinux Release: 1.4.8

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

Announcing AstLinux Release: 1.4.8

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

AstLinux 1.4.8 Highlights:
* Asterisk Versions: 13.38.3, 16.29.1, 18.15.1
* Support for UEFI boot in addition to Legacy BIOS boot

* Linux Kernel 4.19.266, security and bug fixes
* igc, backport from linux-5.4.211, Intel i225/i226 2.5-Gigabit Ethernet Network Driver
* r8125, version 9.010.01, Realtek RTL8125 2.5-Gigabit Ethernet Network Driver
* RUNNIX, version bump to runnix-0.6.13
* OpenSSL, version bump to 1.1.1s
* ddclient, ddclient-curl version 3.8.3-07, add IPv64 (https://ipv64.net/) service type for both IPv4 and IPv6
* libcurl (curl) version bump to 7.86.0, security fixes: CVE-2022-35252, CVE-2022-32221, CVE-2022-35260, CVE-2022-42915, CVE-2022-42916
* netsnmp, version bump to 5.9.3, security fixes: CVE-2022-24805, CVE-2022-24809, CVE-2022-24806, CVE-2022-24807, CVE-2022-24808, CVE-2022-24810
* pjsip version 2.12.1, backport two security fixes (c4d3498 and 450baca) from pjproject 2.13
* sqlite, version bump to 3.39.4
* strongSwan, version 5.5.3, security fix: CVE-2022-40617
* unbound, version bump to 1.17.0, security fix: CVE-2022-3204
* vnStat, version bump to 2.10
* zabbix, version bump to 4.0.44
* VMware Tools (open-vm-tools) version 10.3.10, security fix: CVE-2022-31676
* Network tab, Dynamic DNS Update, add "IPv64" service type. More Info: https://ipv64.net/ 
* Asterisk '13se' (stable edition) version 13.38.3 is the last Asterisk 13.x "Legacy" version, built --without-pjproject
* Package upgrades providing important security and bug fixes

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

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

AstLinux Team

Re: [Astlinux-users] No "eth0" device found on HP T510 Thin Client - astlinux 1.4.7

[Tim G. <te...@en...>]

Hi Michael and Lennie -

Thanks so much for your quick replies. I was just about to check Michael's
solution when your reply came in, Lennie.

*B I N G O !*

I had used the VM image instead of the non-VM generic image of AstLinux. A
re-installation resolved my issue without any tinkering!

Thanks to you both for your help. I knew it had to be something very simple!

Tim



On Fri, Dec 9, 2022 at 8:50 AM Lonnie Abelbeck <li...@lo...>
wrote:

>
>
> > On Dec 9, 2022, at 2:57 AM, Michael Keuter <li...@mk...>
> wrote:
> >
> >
> >
> >> Am 09.12.2022 um 04:33 schrieb Tim Griffin <te...@en...>:
> >>
> >> Hi all; I've just blown the dust off of an HP T150 thin client box (4GB
> RAM/16GB Flash, VIA Eden X2 U4200 processor @ 1Ghz) and installed the
> latest x64 version of ASTLinux (1.4.7).
> >> The operating system installs without error, but after booting, and
> despite apparently installing the
> >> "Intel PRO/1000 Network Driver 3.8.7-NAPI" driver, ASTLinux cannot find
> "eth0", and there is consequently no network available.
> >>
> >> Yet, if I boot the machine just to a RUNNIX shell, "lspci" shows the
> network adapter (Broadcom Inc. BCM57780 Gigabit Ethernet PCIe (rev 01))
> installed as "eth0" (albeit without an IP address):
> >>
> >> <IMG_4382.JPG>
> >> If I let ASTLinux boot to completion, it seems to load the "Intel
> PRO/1000 Network Driver 3.8.7-NAPI" and the "8139 Fast Ethernet drive
> 0.9.28", but then cannot find "eth0" (last line of screen shot).
> >> <IMG_4384.JPG>
> >>
> >> <IMG_4386.JPG>
> >>
> >> When boot into ASTLinux, my installation does not have anything
> pertaining to "net" in the /etc/udev/rules directory either:
> >>
> >> <IMG_4396.JPG>
> >>
> >> I can confirm that the network cable was attached to the box and
> connection/activity indicators were illuminated, so the hardware seems okay.
> >>
> >> After booting into ASTLinux, "ifconfig" shows the following:
> >>
> >> <IMG_4394.JPG>
> >>
> >> One other interesting anomaly is that "eth0" *is* reported right at the
> end of the boot:
> >>
> >> <IMG_4395.JPG>
> >>
> >> But then the OS doesn't seem to initialize "eth0" leaving the
> environment networkless.
> >>
> >> While I am relatively used to working on Ubuntu servers, I've never had
> to operate at the level of network interface drivers, so I'm a little lost
> as to where to look for the problem and how to attempt a resolution.
> >>
> >> Is there something about 1.4.7 that it would not necessarily include
> and enable a network driver for this adapter?
> >>
> >>
> >> Thanks!
> >> Tim
> >
> > Hi Tim,
> >
> > the available network drivers can be found in "/etc/rc.modules".
> > I think for Broadcom NICs you can try the "tg3" driver.
> >
> > Michael
>
> Hi Tim,
>
> Your mistake was to use the "Guest VM x86-64bit (Video Console):" ISO
> (genx86_64-vm) instead of the "Generic x86-64bit (Video Console):" ISO
> (genx86_64) more tuned to your hardware.  Probably a misclick.
>
> -- Quick solution
>
> modprobe tg3
>
> and see if the NIC comes alive, if so, edit /etc/rc.modules and add tg3
> and comment out virtio_net
>
> -- Better solution
>
> Reinstall via USB boot drive using the "Generic x86-64bit (Video
> Console):" ISO download (genx86_64)
>
>
> Cool to see such an old box come alive!
>
> Lonnie
>
>
>
>
> _______________________________________________
> 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] No "eth0" device found on HP T510 Thin Client - astlinux 1.4.7

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

> On Dec 9, 2022, at 2:57 AM, Michael Keuter <li...@mk...> wrote:
> 
> 
> 
>> Am 09.12.2022 um 04:33 schrieb Tim Griffin <te...@en...>:
>> 
>> Hi all; I've just blown the dust off of an HP T150 thin client box (4GB RAM/16GB Flash, VIA Eden X2 U4200 processor @ 1Ghz) and installed the latest x64 version of ASTLinux (1.4.7). 
>> The operating system installs without error, but after booting, and despite apparently installing the 
>> "Intel PRO/1000 Network Driver 3.8.7-NAPI" driver, ASTLinux cannot find "eth0", and there is consequently no network available. 
>> 
>> Yet, if I boot the machine just to a RUNNIX shell, "lspci" shows the network adapter (Broadcom Inc. BCM57780 Gigabit Ethernet PCIe (rev 01)) installed as "eth0" (albeit without an IP address):
>> 
>> <IMG_4382.JPG>
>> If I let ASTLinux boot to completion, it seems to load the "Intel PRO/1000 Network Driver 3.8.7-NAPI" and the "8139 Fast Ethernet drive 0.9.28", but then cannot find "eth0" (last line of screen shot). 
>> <IMG_4384.JPG>
>> 
>> <IMG_4386.JPG>
>> 
>> When boot into ASTLinux, my installation does not have anything pertaining to "net" in the /etc/udev/rules directory either:
>> 
>> <IMG_4396.JPG>
>> 
>> I can confirm that the network cable was attached to the box and connection/activity indicators were illuminated, so the hardware seems okay.
>> 
>> After booting into ASTLinux, "ifconfig" shows the following:
>> 
>> <IMG_4394.JPG>
>> 
>> One other interesting anomaly is that "eth0" *is* reported right at the end of the boot:
>> 
>> <IMG_4395.JPG>
>> 
>> But then the OS doesn't seem to initialize "eth0" leaving the environment networkless.
>> 
>> While I am relatively used to working on Ubuntu servers, I've never had to operate at the level of network interface drivers, so I'm a little lost as to where to look for the problem and how to attempt a resolution. 
>> 
>> Is there something about 1.4.7 that it would not necessarily include and enable a network driver for this adapter? 
>> 
>> 
>> Thanks!
>> Tim
> 
> Hi Tim,
> 
> the available network drivers can be found in "/etc/rc.modules".
> I think for Broadcom NICs you can try the "tg3" driver.
> 
> Michael

Hi Tim,

Your mistake was to use the "Guest VM x86-64bit (Video Console):" ISO (genx86_64-vm) instead of the "Generic x86-64bit (Video Console):" ISO (genx86_64) more tuned to your hardware.  Probably a misclick.

-- Quick solution

modprobe tg3

and see if the NIC comes alive, if so, edit /etc/rc.modules and add tg3 and comment out virtio_net

-- Better solution

Reinstall via USB boot drive using the "Generic x86-64bit (Video Console):" ISO download (genx86_64)


Cool to see such an old box come alive!

Lonnie

Re: [Astlinux-users] No "eth0" device found on HP T510 Thin Client - astlinux 1.4.7

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

> Am 09.12.2022 um 04:33 schrieb Tim Griffin <te...@en...>:
> 
> Hi all; I've just blown the dust off of an HP T150 thin client box (4GB RAM/16GB Flash, VIA Eden X2 U4200 processor @ 1Ghz) and installed the latest x64 version of ASTLinux (1.4.7). 
> The operating system installs without error, but after booting, and despite apparently installing the 
> "Intel PRO/1000 Network Driver 3.8.7-NAPI" driver, ASTLinux cannot find "eth0", and there is consequently no network available. 
> 
> Yet, if I boot the machine just to a RUNNIX shell, "lspci" shows the network adapter (Broadcom Inc. BCM57780 Gigabit Ethernet PCIe (rev 01)) installed as "eth0" (albeit without an IP address):
> 
> <IMG_4382.JPG>
> If I let ASTLinux boot to completion, it seems to load the "Intel PRO/1000 Network Driver 3.8.7-NAPI" and the "8139 Fast Ethernet drive 0.9.28", but then cannot find "eth0" (last line of screen shot). 
> <IMG_4384.JPG>
> 
> <IMG_4386.JPG>
> 
> When boot into ASTLinux, my installation does not have anything pertaining to "net" in the /etc/udev/rules directory either:
> 
> <IMG_4396.JPG>
> 
> I can confirm that the network cable was attached to the box and connection/activity indicators were illuminated, so the hardware seems okay.
> 
> After booting into ASTLinux, "ifconfig" shows the following:
> 
> <IMG_4394.JPG>
> 
> One other interesting anomaly is that "eth0" *is* reported right at the end of the boot:
> 
> <IMG_4395.JPG>
> 
> But then the OS doesn't seem to initialize "eth0" leaving the environment networkless.
> 
> While I am relatively used to working on Ubuntu servers, I've never had to operate at the level of network interface drivers, so I'm a little lost as to where to look for the problem and how to attempt a resolution. 
> 
> Is there something about 1.4.7 that it would not necessarily include and enable a network driver for this adapter? 
> 
> 
> Thanks!
> Tim

Hi Tim,

the available network drivers can be found in "/etc/rc.modules".
I think for Broadcom NICs you can try the "tg3" driver.

Michael

http://www.mksolutions.info

[Astlinux-users] No "eth0" device found on HP T510 Thin Client - astlinux 1.4.7

[Tim G. <te...@en...>]

Hi all; I've just blown the dust off of an HP T150 thin client box (4GB
RAM/16GB Flash, VIA Eden X2 U4200 processor @ 1Ghz) and installed the
latest x64 version of ASTLinux (1.4.7).
The operating system installs without error, but after booting, and despite
apparently installing the
"Intel PRO/1000 Network Driver 3.8.7-NAPI" driver, ASTLinux cannot find
"eth0", and there is consequently no network available.

Yet, if I boot the machine just to a RUNNIX shell, "lspci" shows the
network adapter (Broadcom Inc. BCM57780 Gigabit Ethernet PCIe (rev 01))
installed as "eth0" (albeit without an IP address):

[image: IMG_4382.JPG]
If I let ASTLinux boot to completion, it seems to load the "Intel PRO/1000
Network Driver 3.8.7-NAPI" and the "8139 Fast Ethernet drive 0.9.28", but
then cannot find "eth0" (last line of screen shot).
[image: IMG_4384.JPG]

[image: IMG_4386.JPG]

When boot into ASTLinux, my installation does not have anything pertaining
to "net" in the /etc/udev/rules directory either:

[image: IMG_4396.JPG]

I can confirm that the network cable was attached to the box and
connection/activity indicators were illuminated, so the hardware seems okay.

After booting into ASTLinux, "ifconfig" shows the following:

[image: IMG_4394.JPG]

One other interesting anomaly is that "eth0" *is* reported right at the end
of the boot:

[image: IMG_4395.JPG]

But then the OS doesn't seem to initialize "eth0" leaving the environment
networkless.

While I am relatively used to working on Ubuntu servers, I've never had to
operate at the level of network interface drivers, so I'm a little lost as
to where to look for the problem and how to attempt a resolution.

Is there something about 1.4.7 that it would not necessarily include and
enable a network driver for this adapter?


Thanks!
Tim

Re: [Astlinux-users] Turning of DHCP logging

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

Thanks Lonnie.

Not sure why I'm not getting it for other IPoE broadband services though?

Regards
Michael Knill

On 3/11/2022, 12:01 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    Michael,

    BTW the "daemon.err udhcpc" are not actually error logs, just informational logs in this case.

    The .err only log marking was a bug/feature in Busybox log messages. [1]

    Lonnie

    [1] https://github.com/mirror/busybox/commit/253c4e787a799a3e1f92957ed791b5222f8d2f64



    > On Nov 1, 2022, at 9:57 PM, Michael Knill <mic...@ip...> wrote:
    > 
    > Hi Lonnie
    > 
    > Yes that would be nice. My lease time is 300s.
    > Still not sure why I'm getting those errors though.
    > 
    > Regards 
    > Michael Knill 
    > 
    > 
    > 
    > On 2/11/2022, 11:56 am, "Lonnie Abelbeck" <li...@lo... <mailto:li...@lo...>> wrote:
    > 
    > 
    > Addendum:
    > For my cable modem, only one "sending discover" is needed for this udhcpc session:
    > --
    > Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: started, v1.30.1
    > Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: sending discover
    > Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: sending select for 98.xx.xx.xx
    > Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: lease of 98.xx.xx.xx obtained, lease time 86400
    > --
    > My IP address is somewhat "sticky" associated with my external interface MAC address. If the MAC address changed or 24 hours of no activity then it may take a little longer and more "sending discover" messages to grab an IP.
    > 
    > 
    > Lonnie
    > 
    > 
    > 
    > 
    >> On Nov 1, 2022, at 7:28 PM, Lonnie Abelbeck <li...@lo... <mailto:li...@lo...>> wrote:
    >> 
    >>> It does not have this error from the same provider on other broadband types.
    >> 
    >> Which "broadband types" are you talking about, is IPoE a cable modem or something else?
    >> 
    >> Lonnie
    >> 
    >> 
    >> 
    >> 
    >>> On Nov 1, 2022, at 4:44 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
    >>> 
    >>> Thanks Lonnie. Yes there does seem to be a problem as I do get the standard lease obtained logs:
    >>> Nov 2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: sending renew to 103.55.93.1
    >>> Nov 2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: lease of 103.55.93.92 obtained, lease time 300
    >>> 
    >>> It does not have this error from the same provider on other broadband types. Do you have any idea what it could be?
    >>> 
    >>> Regards 
    >>> Michael Knill 
    >>> 
    >>> 
    >>> 
    >>> On 2/11/2022, 8:12 am, "Lonnie Abelbeck" <li...@lo... <mailto:li...@lo...> <mailto:li...@lo... <mailto:li...@lo...>>> wrote:
    >>> 
    >>> 
    >>> Normally you would see 3 or 4 of those logs before DHCP client was successful.
    >>> 
    >>> 
    >>> After many "sending discover" udhcpc will drop to the background and continue. Possibly DHCP is acquired after 30 seconds or so?
    >>> 
    >>> 
    >>> For local networks, this is not normal. You can't disable the logs as there should not be an endless stream of them.
    >>> 
    >>> 
    >>> Lonnie
    >>> 
    >>> 
    >>> 
    >>> 
    >>> 
    >>> 
    >>>> On Nov 1, 2022, at 3:10 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...><mailto:mic...@ip...<mailto:mic...@ip...>>> wrote:
    >>>> 
    >>>> Hi Group
    >>>> 
    >>>> This is a new service that we have not used before. They use IPoE and so I have configured the WAN to be DHCP.
    >>>> It all appears to be working but I am getting lots of logs:
    >>>> Nov 2 06:55:46 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
    >>>> Nov 2 06:55:48 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
    >>>> Nov 2 06:55:50 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
    >>>> Nov 2 06:55:52 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
    >>>> Nov 2 06:55:54 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
    >>>> Nov 2 06:55:56 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
    >>>> Nov 2 06:56:18 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
    >>>> Nov 2 06:56:20 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
    >>>> Nov 2 06:56:22 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
    >>>> 
    >>>> Is this normal? Can I turn them off?
    >>>> 
    >>>> Regards
    >>>> 
    >>>> Michael Knill
    >>>> Managing Director
    >>>> 
    >>>> D: +61 2 6189 1360
    >>>> P: +61 2 6140 4656
    >>>> E: mic...@ip... <mailto:mic...@ip...> <mailto:mic...@ip... <mailto:mic...@ip...>>
    >>>> W: ipcsolutions.com.au
    >>>> 
    >>>> <image001.png>
    >>>> Smarter Business Communications
    >>>> 
    >>>> _______________________________________________
    >>>> Astlinux-users mailing list
    >>>> Ast...@li... <mailto:Ast...@li...> <mailto:Ast...@li... <mailto:Ast...@li...>>
    >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users><https://lists.sourceforge.net/lists/listinfo/astlinux-users&lt;https://lists.sourceforge.net/lists/listinfo/astlinux-users&gt;>
    >>>> 
    >>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...><mailto:pa...@kr... <mailto:pa...@kr...>>.
    >>> 
    >>> 
    >>> 
    >>> 
    >>> 
    >>> 
    >>> _______________________________________________
    >>> Astlinux-users mailing list
    >>> Ast...@li... <mailto:Ast...@li...> <mailto:Ast...@li... <mailto:Ast...@li...>>
    >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users><https://lists.sourceforge.net/lists/listinfo/astlinux-users&lt;https://lists.sourceforge.net/lists/listinfo/astlinux-users&gt;>
    >>> 
    >>> 
    >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...><mailto:pa...@kr... <mailto:pa...@kr...>>.
    >>> 
    >>> 
    >>> 
    >>> 
    >>> _______________________________________________
    >>> Astlinux-users mailing list
    >>> Ast...@li... <mailto:Ast...@li...>
    >>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users>
    >>> 
    >>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>.
    >> 
    >> 
    >> 
    >> _______________________________________________
    >> Astlinux-users mailing list
    >> Ast...@li... <mailto:Ast...@li...>
    >> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users>
    >> 
    >> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>.
    > 
    > 
    > 
    > 
    > 
    > 
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li... <mailto:Ast...@li...>
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users>
    > 
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto: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] Turning of DHCP logging

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

Michael,

BTW the "daemon.err udhcpc" are not actually error logs, just informational logs in this case.

The .err only log marking was a bug/feature in Busybox log messages. [1]

Lonnie

[1] https://github.com/mirror/busybox/commit/253c4e787a799a3e1f92957ed791b5222f8d2f64



> On Nov 1, 2022, at 9:57 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Lonnie
> 
> Yes that would be nice. My lease time is 300s.
> Still not sure why I'm getting those errors though.
> 
> Regards 
> Michael Knill 
> 
> 
> 
> On 2/11/2022, 11:56 am, "Lonnie Abelbeck" <li...@lo... <mailto:li...@lo...>> wrote:
> 
> 
> Addendum:
> For my cable modem, only one "sending discover" is needed for this udhcpc session:
> --
> Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: started, v1.30.1
> Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: sending discover
> Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: sending select for 98.xx.xx.xx
> Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: lease of 98.xx.xx.xx obtained, lease time 86400
> --
> My IP address is somewhat "sticky" associated with my external interface MAC address. If the MAC address changed or 24 hours of no activity then it may take a little longer and more "sending discover" messages to grab an IP.
> 
> 
> Lonnie
> 
> 
> 
> 
>> On Nov 1, 2022, at 7:28 PM, Lonnie Abelbeck <li...@lo... <mailto:li...@lo...>> wrote:
>> 
>>> It does not have this error from the same provider on other broadband types.
>> 
>> Which "broadband types" are you talking about, is IPoE a cable modem or something else?
>> 
>> Lonnie
>> 
>> 
>> 
>> 
>>> On Nov 1, 2022, at 4:44 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
>>> 
>>> Thanks Lonnie. Yes there does seem to be a problem as I do get the standard lease obtained logs:
>>> Nov 2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: sending renew to 103.55.93.1
>>> Nov 2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: lease of 103.55.93.92 obtained, lease time 300
>>> 
>>> It does not have this error from the same provider on other broadband types. Do you have any idea what it could be?
>>> 
>>> Regards 
>>> Michael Knill 
>>> 
>>> 
>>> 
>>> On 2/11/2022, 8:12 am, "Lonnie Abelbeck" <li...@lo... <mailto:li...@lo...> <mailto:li...@lo... <mailto:li...@lo...>>> wrote:
>>> 
>>> 
>>> Normally you would see 3 or 4 of those logs before DHCP client was successful.
>>> 
>>> 
>>> After many "sending discover" udhcpc will drop to the background and continue. Possibly DHCP is acquired after 30 seconds or so?
>>> 
>>> 
>>> For local networks, this is not normal. You can't disable the logs as there should not be an endless stream of them.
>>> 
>>> 
>>> Lonnie
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Nov 1, 2022, at 3:10 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...><mailto:mic...@ip...<mailto:mic...@ip...>>> wrote:
>>>> 
>>>> Hi Group
>>>> 
>>>> This is a new service that we have not used before. They use IPoE and so I have configured the WAN to be DHCP.
>>>> It all appears to be working but I am getting lots of logs:
>>>> Nov 2 06:55:46 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>>> Nov 2 06:55:48 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>>> Nov 2 06:55:50 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>>> Nov 2 06:55:52 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>>> Nov 2 06:55:54 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>>> Nov 2 06:55:56 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>>> Nov 2 06:56:18 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>>> Nov 2 06:56:20 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>>> Nov 2 06:56:22 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>>> 
>>>> Is this normal? Can I turn them off?
>>>> 
>>>> Regards
>>>> 
>>>> Michael Knill
>>>> Managing Director
>>>> 
>>>> D: +61 2 6189 1360
>>>> P: +61 2 6140 4656
>>>> E: mic...@ip... <mailto:mic...@ip...> <mailto:mic...@ip... <mailto:mic...@ip...>>
>>>> W: ipcsolutions.com.au
>>>> 
>>>> <image001.png>
>>>> Smarter Business Communications
>>>> 
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li... <mailto:Ast...@li...> <mailto:Ast...@li... <mailto:Ast...@li...>>
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users><https://lists.sourceforge.net/lists/listinfo/astlinux-users&lt;https://lists.sourceforge.net/lists/listinfo/astlinux-users&gt;>
>>>> 
>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...><mailto:pa...@kr... <mailto:pa...@kr...>>.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li... <mailto:Ast...@li...> <mailto:Ast...@li... <mailto:Ast...@li...>>
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users><https://lists.sourceforge.net/lists/listinfo/astlinux-users&lt;https://lists.sourceforge.net/lists/listinfo/astlinux-users&gt;>
>>> 
>>> 
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...><mailto:pa...@kr... <mailto:pa...@kr...>>.
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li... <mailto:Ast...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users>
>>> 
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>.
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li... <mailto:Ast...@li...>
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users>
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li... <mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users>
> 
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto: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] Turning of DHCP logging

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

Hi Lonnie

Yes that would be nice. My lease time is 300s.
Still not sure why I'm getting those errors though.

Regards 
Michael Knill 



On 2/11/2022, 11:56 am, "Lonnie Abelbeck" <li...@lo... <mailto:li...@lo...>> wrote:


Addendum:
For my cable modem, only one "sending discover" is needed for this udhcpc session:
--
Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: started, v1.30.1
Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: sending discover
Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: sending select for 98.xx.xx.xx
Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: lease of 98.xx.xx.xx obtained, lease time 86400
--
My IP address is somewhat "sticky" associated with my external interface MAC address. If the MAC address changed or 24 hours of no activity then it may take a little longer and more "sending discover" messages to grab an IP.


Lonnie




> On Nov 1, 2022, at 7:28 PM, Lonnie Abelbeck <li...@lo... <mailto:li...@lo...>> wrote:
> 
>> It does not have this error from the same provider on other broadband types.
> 
> Which "broadband types" are you talking about, is IPoE a cable modem or something else?
> 
> Lonnie
> 
> 
> 
> 
>> On Nov 1, 2022, at 4:44 PM, Michael Knill <mic...@ip... <mailto:mic...@ip...>> wrote:
>> 
>> Thanks Lonnie. Yes there does seem to be a problem as I do get the standard lease obtained logs:
>> Nov 2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: sending renew to 103.55.93.1
>> Nov 2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: lease of 103.55.93.92 obtained, lease time 300
>> 
>> It does not have this error from the same provider on other broadband types. Do you have any idea what it could be?
>> 
>> Regards 
>> Michael Knill 
>> 
>> 
>> 
>> On 2/11/2022, 8:12 am, "Lonnie Abelbeck" <li...@lo... <mailto:li...@lo...> <mailto:li...@lo... <mailto:li...@lo...>>> wrote:
>> 
>> 
>> Normally you would see 3 or 4 of those logs before DHCP client was successful.
>> 
>> 
>> After many "sending discover" udhcpc will drop to the background and continue. Possibly DHCP is acquired after 30 seconds or so?
>> 
>> 
>> For local networks, this is not normal. You can't disable the logs as there should not be an endless stream of them.
>> 
>> 
>> Lonnie
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Nov 1, 2022, at 3:10 PM, Michael Knill <mic...@ip... <mailto:mic...@ip...><mailto:mic...@ip... <mailto:mic...@ip...>>> wrote:
>>> 
>>> Hi Group
>>> 
>>> This is a new service that we have not used before. They use IPoE and so I have configured the WAN to be DHCP.
>>> It all appears to be working but I am getting lots of logs:
>>> Nov 2 06:55:46 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:55:48 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:55:50 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:55:52 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:55:54 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:55:56 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:56:18 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:56:20 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:56:22 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> 
>>> Is this normal? Can I turn them off?
>>> 
>>> Regards
>>> 
>>> Michael Knill
>>> Managing Director
>>> 
>>> D: +61 2 6189 1360
>>> P: +61 2 6140 4656
>>> E: mic...@ip... <mailto:mic...@ip...> <mailto:mic...@ip... <mailto:mic...@ip...>>
>>> W: ipcsolutions.com.au
>>> 
>>> <image001.png>
>>> Smarter Business Communications
>>> 
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li... <mailto:Ast...@li...> <mailto:Ast...@li... <mailto:Ast...@li...>>
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users> <https://lists.sourceforge.net/lists/listinfo/astlinux-users&lt;https://lists.sourceforge.net/lists/listinfo/astlinux-users&gt;>
>>> 
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... <mailto:pa...@kr...><mailto:pa...@kr... <mailto:pa...@kr...>>.
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li... <mailto:Ast...@li...> <mailto:Ast...@li... <mailto:Ast...@li...>>
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users> <https://lists.sourceforge.net/lists/listinfo/astlinux-users&lt;https://lists.sourceforge.net/lists/listinfo/astlinux-users&gt;>
>> 
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... <mailto:pa...@kr...><mailto:pa...@kr... <mailto:pa...@kr...>>.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li... <mailto:Ast...@li...>
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users <https://lists.sourceforge.net/lists/listinfo/astlinux-users>
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... <mailto:pa...@kr...>.
> 
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li... <mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-users <https://lists.sourceforge.net/lists/listinfo/astlinux-users>
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... <mailto:pa...@kr...>.






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


Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... <mailto:pa...@kr...>.

Re: [Astlinux-users] Turning of DHCP logging

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

Addendum:
For my cable modem, only one "sending discover" is needed for this udhcpc session:
--
Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: started, v1.30.1
Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: sending discover
Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: sending select for 98.xx.xx.xx
Oct 27 15:26:45 gw-lan daemon.err udhcpc[595]: lease of 98.xx.xx.xx obtained, lease time 86400
--
My IP address is somewhat "sticky" associated with my external interface MAC address.  If the MAC address changed or 24 hours of no activity then it may take a little longer and more "sending discover" messages to grab an IP.

Lonnie


> On Nov 1, 2022, at 7:28 PM, Lonnie Abelbeck <li...@lo...> wrote:
> 
>> It does not have this error from the same provider on other broadband types.
> 
> Which "broadband types" are you talking about, is IPoE a cable modem or something else?
> 
> Lonnie
> 
> 
> 
> 
>> On Nov 1, 2022, at 4:44 PM, Michael Knill <mic...@ip...> wrote:
>> 
>> Thanks Lonnie. Yes there does seem to be a problem as I do get the standard lease obtained logs:
>> Nov  2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: sending renew to 103.55.93.1
>> Nov  2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: lease of 103.55.93.92 obtained, lease time 300
>> 
>> It does not have this error from the same provider on other broadband types. Do you have any idea what it could be?
>> 
>> Regards 
>> Michael Knill 
>> 
>> 
>> 
>> On 2/11/2022, 8:12 am, "Lonnie Abelbeck" <li...@lo... <mailto:li...@lo...>> wrote:
>> 
>> 
>> Normally you would see 3 or 4 of those logs before DHCP client was successful.
>> 
>> 
>> After many "sending discover" udhcpc will drop to the background and continue. Possibly DHCP is acquired after 30 seconds or so?
>> 
>> 
>> For local networks, this is not normal. You can't disable the logs as there should not be an endless stream of them.
>> 
>> 
>> Lonnie
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Nov 1, 2022, at 3:10 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
>>> 
>>> Hi Group
>>> 
>>> This is a new service that we have not used before. They use IPoE and so I have configured the WAN to be DHCP.
>>> It all appears to be working but I am getting lots of logs:
>>> Nov 2 06:55:46 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:55:48 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:55:50 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:55:52 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:55:54 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:55:56 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:56:18 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:56:20 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> Nov 2 06:56:22 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>>> 
>>> Is this normal? Can I turn them off?
>>> 
>>> Regards
>>> 
>>> Michael Knill
>>> Managing Director
>>> 
>>> D: +61 2 6189 1360
>>> P: +61 2 6140 4656
>>> E: mic...@ip... <mailto:mic...@ip...>
>>> W: ipcsolutions.com.au
>>> 
>>> <image001.png>
>>> Smarter Business Communications
>>> 
>>> _______________________________________________
>>> Astlinux-users mailing list
>>> Ast...@li... <mailto:Ast...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users>
>>> 
>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>.
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li... <mailto:Ast...@li...>
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users>
>> 
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto: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] Turning of DHCP logging

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

> It does not have this error from the same provider on other broadband types.

Which "broadband types" are you talking about, is IPoE a cable modem or something else?

Lonnie




> On Nov 1, 2022, at 4:44 PM, Michael Knill <mic...@ip...> wrote:
> 
> Thanks Lonnie. Yes there does seem to be a problem as I do get the standard lease obtained logs:
> Nov  2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: sending renew to 103.55.93.1
> Nov  2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: lease of 103.55.93.92 obtained, lease time 300
> 
> It does not have this error from the same provider on other broadband types. Do you have any idea what it could be?
> 
> Regards 
> Michael Knill 
> 
> 
> 
> On 2/11/2022, 8:12 am, "Lonnie Abelbeck" <li...@lo... <mailto:li...@lo...>> wrote:
> 
> 
> Normally you would see 3 or 4 of those logs before DHCP client was successful.
> 
> 
> After many "sending discover" udhcpc will drop to the background and continue. Possibly DHCP is acquired after 30 seconds or so?
> 
> 
> For local networks, this is not normal. You can't disable the logs as there should not be an endless stream of them.
> 
> 
> Lonnie
> 
> 
> 
> 
> 
> 
>> On Nov 1, 2022, at 3:10 PM, Michael Knill <mic...@ip...<mailto:mic...@ip...>> wrote:
>> 
>> Hi Group
>> 
>> This is a new service that we have not used before. They use IPoE and so I have configured the WAN to be DHCP.
>> It all appears to be working but I am getting lots of logs:
>> Nov 2 06:55:46 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>> Nov 2 06:55:48 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>> Nov 2 06:55:50 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>> Nov 2 06:55:52 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>> Nov 2 06:55:54 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>> Nov 2 06:55:56 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>> Nov 2 06:56:18 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>> Nov 2 06:56:20 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>> Nov 2 06:56:22 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>> 
>> Is this normal? Can I turn them off?
>> 
>> Regards
>> 
>> Michael Knill
>> Managing Director
>> 
>> D: +61 2 6189 1360
>> P: +61 2 6140 4656
>> E: mic...@ip... <mailto:mic...@ip...>
>> W: ipcsolutions.com.au
>> 
>> <image001.png>
>> Smarter Business Communications
>> 
>> _______________________________________________
>> Astlinux-users mailing list
>> Ast...@li... <mailto:Ast...@li...>
>> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users>
>> 
>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto:pa...@kr...>.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li... <mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-users<https://lists.sourceforge.net/lists/listinfo/astlinux-users>
> 
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr...<mailto: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] Turning of DHCP logging

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

Thanks Lonnie. Yes there does seem to be a problem as I do get the standard lease obtained logs:
Nov  2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: sending renew to 103.55.93.1
Nov  2 06:54:54 30590-Canb_Comm-CM1 daemon.err udhcpc[358]: lease of 103.55.93.92 obtained, lease time 300

It does not have this error from the same provider on other broadband types. Do you have any idea what it could be?

Regards 
Michael Knill 



On 2/11/2022, 8:12 am, "Lonnie Abelbeck" <li...@lo... <mailto:li...@lo...>> wrote:


Normally you would see 3 or 4 of those logs before DHCP client was successful.


After many "sending discover" udhcpc will drop to the background and continue. Possibly DHCP is acquired after 30 seconds or so?


For local networks, this is not normal. You can't disable the logs as there should not be an endless stream of them.


Lonnie






> On Nov 1, 2022, at 3:10 PM, Michael Knill <mic...@ip... <mailto:mic...@ip...>> wrote:
> 
> Hi Group
> 
> This is a new service that we have not used before. They use IPoE and so I have configured the WAN to be DHCP.
> It all appears to be working but I am getting lots of logs:
> Nov 2 06:55:46 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov 2 06:55:48 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov 2 06:55:50 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov 2 06:55:52 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov 2 06:55:54 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov 2 06:55:56 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov 2 06:56:18 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov 2 06:56:20 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov 2 06:56:22 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> 
> Is this normal? Can I turn them off?
> 
> Regards
> 
> Michael Knill
> Managing Director
> 
> D: +61 2 6189 1360
> P: +61 2 6140 4656
> E: mic...@ip... <mailto:mic...@ip...>
> W: ipcsolutions.com.au
> 
> <image001.png>
> Smarter Business Communications
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li... <mailto:Ast...@li...>
> https://lists.sourceforge.net/lists/listinfo/astlinux-users <https://lists.sourceforge.net/lists/listinfo/astlinux-users>
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... <mailto:pa...@kr...>.






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


Donations to support AstLinux are graciously accepted via PayPal to pa...@kr... <mailto:pa...@kr...>.

Re: [Astlinux-users] Turning of DHCP logging

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

Normally you would see 3 or 4 of those logs before DHCP client was successful.

After many "sending discover" udhcpc will drop to the background and continue.  Possibly DHCP is acquired after 30 seconds or so?

For local networks, this is not normal.  You can't disable the logs as there should not be an endless stream of them.

Lonnie



> On Nov 1, 2022, at 3:10 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Group
>  
> This is a new service that we have not used before. They use IPoE and so I have configured the WAN to be DHCP.
> It all appears to be working but I am getting lots of logs:
> Nov  2 06:55:46 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov  2 06:55:48 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov  2 06:55:50 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov  2 06:55:52 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov  2 06:55:54 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov  2 06:55:56 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov  2 06:56:18 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov  2 06:56:20 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
> Nov  2 06:56:22 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
>  
> Is this normal? Can I turn them off?
>  
> 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] Turning of DHCP logging

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

Hi Group

This is a new service that we have not used before. They use IPoE and so I have configured the WAN to be DHCP.
It all appears to be working but I am getting lots of logs:
Nov  2 06:55:46 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
Nov  2 06:55:48 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
Nov  2 06:55:50 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
Nov  2 06:55:52 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
Nov  2 06:55:54 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
Nov  2 06:55:56 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
Nov  2 06:56:18 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
Nov  2 06:56:20 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover
Nov  2 06:56:22 30590-Canb_Comm-CM1 daemon.err udhcpc[24542]: sending discover

Is this normal? Can I turn them off?

Regards

Michael Knill
Managing Director

D: +61 2 6189 1360
P: +61 2 6140 4656
E: mic...@ip...<mailto:mic...@ip...>
W: ipcsolutions.com.au<https://ipcsolutions.com.au/>

 [Icon  Description automatically generated]
Smarter Business Communications

Re: [Astlinux-users] Wireguard significantly delays Astlinux bootup when using hostname for peer

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

I have run into the same issue.  The best answer of course is not to rely
on DNS but rather to provide the endpoint IP address.  That of course is
not always possible so I had to come up with what is best described as a
very ugly hack.  Very ugly.  I use it to setup a 2nd VPN so it doesn't
interfere with how astlinux manages startup/shutdown of VPNs.

In the firewall custom config I created a function that spawns off a
background task which waits for DNS to come alive and then does whatever
needs to be done (or fails after a timeout).  It has been a long time since
I wrote this, so I probably forgot some of the details.  But this is a
copy/paste from my custom firewall script with some very custom stuff
removed.  If the DNS service is detected as working, then I call another
function start_vpn which is also in the same script... I've included a
"simplified" version of that below too.

I sure wish there was an easier way.

wait_for_DNS()
{
  local any_host="google.com"
  local RETRY PID
  local TIMEOUT=6

  echo "[CUSTOM RULE] spawn background to wait for DNS service"
  (
    RETRY=6

    while [ $RETRY -gt 0 ]; do
      RETRY=$((RETRY - 1))

      local IPV4="$(host -t A $any_host | sed -n -r -e 's#^.* has address
([0-9.]+)$#\1#p')"
      if [ -n "$IPV4" ]; then
        #
=============================================================================
        # DNS Service must be up so safe to continue

        start_vpn "$VPN2IF" "$VPN2IP" "$VPN2IPV6" "$VPN2DNS"

        #
=============================================================================
        exit
      else
        logger -s -t CUSTOM_RULE -p user.info "DNS service not up, sleep
for 5 seconds"
        sleep 5
      fi
    done
    logger -s -t CUSTOM_RULE -p user.error "Time out waiting for DNS
service, dependent rules not set"
  ) &
  PID=$!
  while [ $TIMEOUT -gt 0 ] && kill -0 $PID >/dev/null 2>&1; do
    TIMEOUT=$((TIMEOUT - 1))
    sleep 1
  done
}
wait_for_DNS

start_vpn()
{
  local if_name="$1"
  local if_ip="$2"
  local if_ipv6="$3"
  local if_dns="$4"
  local INTNETS=""

  if [ -n "$if_name" ]; then
    if ip link show dev $if_name >/dev/null 2>&1; then
      echo "[CUSTOM RULE] VPN interface ($if_name) already exists, delete
it"
      ip link delete dev $if_name
    fi
    if ip link add dev $if_name type wireguard            &&
       ip address add dev $if_name ${if_ip}/32             &&
       [ -n "$if_ipv6" ] && ip address add dev $if_name ${if_ipv6}/64  ||
true &&
       wg setconf $if_name /mnt/kd/wireguard/${if_name}.conf &&
       ip link set mtu 1340 up dev $if_name;
    then
      echo "[CUSTOM RULE] VPN interface ($if_name) created"
      # logger -s -t CUSTOM_RULE -p user.info "VPN interface ($if_name)
created"
    else
      echo "[CUSTOM RULE] VPN2IF ($if_name) create failed"
      logger -s -t CUSTOM_RULE -p user.error "VPN interface ($if_name)
create failed"
    fi
    # route DNS IP address over the VPN in default routing table
    ip route add $if_dns dev $if_name
    # create a new routing table (400) with default route to VPN interface
    # and send all packets marked with 0x8 bit to that table
    ip route add default dev $if_name table 400
    ip rule add from $INTIP/24 fwmark 0x8/0x8 table 400 priority 2000
>/dev/null 2>&1
    ip4tables -t mangle -A PREROUTING -d $INTIP/24 -j ACCEPT

    # make sure traffic from my internal interface is permitted to forward
to/from the VPN interface
    ip4tables -A FORWARD_CHAIN -i $INTIF -o $if_name -j ACCEPT
    ip4tables -A FORWARD_CHAIN -i $if_name -o $INTIF -j ACCEPT
    # and NAT traffic over the VPN
    ip4tables -t nat -A NAT_POSTROUTING_CHAIN -s $INTIP/20 ! -d $INTIP/24
-o $if_name -j MASQUERADE

    if [ -n "$if_ipv6" ]; then
      # create a new routing table (400) with default route to VPN interface
      # and send all packets marked with 0x8 bit to that table
      ip -6 route add default dev $if_name table 400
      INTNETS=$(ip -6 -o addr show dev $INTIF scope global | awk '$3 ==
"inet6" { split($4, field, "/"); print field[1]; next; }')
      for net in $INTNETS; do
        ip -6 rule add from $net/$DHCPV6_CLIENT_PREFIX_LEN fwmark 0x8/0x8
table 400 priority 2000 >/dev/null 2>&1
        ip6tables -t mangle -A PREROUTING -d $net/$DHCPV6_CLIENT_PREFIX_LEN
-j ACCEPT
      done

      # make sure traffic from my internal interface is permitted to
forward to/from the VPN interface
      ip6tables -A FORWARD_CHAIN -i $INTIF -o $if_name -j ACCEPT
      ip6tables -A FORWARD_CHAIN -i $if_name -o $INTIF -j ACCEPT
      # and NAT traffic over the VPN
      for net in $INTNETS; do
        ip6tables -t nat -A POSTROUTING -s $net/$DHCPV6_CLIENT_PREFIX_LEN
-o $if_name -j MASQUERADE
      done
    else
      # the VPN does not support IPv6 so drop all attempts to connect by
IPv6
      ip6tables -I FORWARD_CHAIN -i $INTIF dst -j DROP
    fi
  fi
}

On Mon, Oct 31, 2022 at 11:04 PM Michael Knill <
mic...@ip...> wrote:

> Hi Group
>
>
>
> When using Wireguard with hostnames, I have noticed that if there is no
> DNS available, Wireguard prevents Astlinux from booting up for a very long
> period of time as it sits and waits for the resolution of the hostname it
> has in the peer configuration.
>
>
>
> Is there a way to prevent this from happening as its very problematic?
>
>
>
> Regards
>
>
>
> *Michael Knill*
>
> Managing Director
>
>
>
> D: +61 2 6189 1360
>
> P: +61 2 6140 4656
>
> E: mic...@ip...
>
> W: ipcsolutions.com.au
>
>
>
>  [image: Icon Description automatically generated]
>
> *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] Wireguard significantly delays Astlinux bootup when using hostname for peer

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

Hi Michael,

I don't have any special incantation ... when DNS fails it can be very problematic.

Using an IP address in WG, or use "DNS Forwarder Hosts:" to locally define the DNS A record.

If connectivity is not the DNS issue, then a more robust DNS server set.

I doubt you learned anything new here. :-)

Lonnie




> On Oct 31, 2022, at 9:47 PM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Group
>  
> When using Wireguard with hostnames, I have noticed that if there is no DNS available, Wireguard prevents Astlinux from booting up for a very long period of time as it sits and waits for the resolution of the hostname it has in the peer configuration.
>  
> Is there a way to prevent this from happening as its very problematic?
>  
> 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] Wireguard significantly delays Astlinux bootup when using hostname for peer

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

Hi Group

When using Wireguard with hostnames, I have noticed that if there is no DNS available, Wireguard prevents Astlinux from booting up for a very long period of time as it sits and waits for the resolution of the hostname it has in the peer configuration.

Is there a way to prevent this from happening as its very problematic?

Regards

Michael Knill
Managing Director

D: +61 2 6189 1360
P: +61 2 6140 4656
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.4.7

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

Announcing AstLinux Release: 1.4.7

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

AstLinux 1.4.7 Highlights:
* Asterisk Versions: 13.38.3, 16.27.0, 18.13.0
* Support for UEFI boot in addition to Legacy BIOS boot

* Linux Kernel 4.19.254, security and bug fixes
* igc, backport from linux-5.4.208, Intel i225 2.5-Gigabit Ethernet Network Driver
* r8125, version 9.009.02, Realtek RTL8125 2.5-Gigabit Ethernet Network Driver
* igb, version bump to 5.11.4, Intel 1.0-Gigabit Ethernet Network Driver
* RUNNIX, version bump to runnix-0.6.12
* OpenSSL, version bump to 1.1.1q, security fixes: CVE-2022-2068, CVE-2022-2097
* WireGuard VPN, module 1.0.20220627 (version bump), tools 1.0.20210914 (no change)
* htop, version bump to 3.2.1
* libcurl (curl) version bump to 7.84.0, security fixes: CVE-2022-32205, CVE-2022-32206, CVE-2022-32207, CVE-2022-32208
* pjsip version bump to 2.12.1, security fixes: many
* sqlite, version bump to 3.39.2, security fix: CVE-2022-35737
* unbound, version bump to 1.16.2, security fixes: CVE-2022-30698, CVE-2022-30699
* zabbix, version bump to 4.0.43
* Asterisk '13se' (stable edition) version 13.38.3 is the last Asterisk 13.x "Legacy" version, built --without-pjproject
* Package upgrades providing important security and bug fixes

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

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

AstLinux Team

Re: [Astlinux-users] MSMTP: E-Mail From root?

[Dan R. <da...@ry...>]

SMTP_FROM is different from the "From:" email header?  That's really odd.It's a good thing I had your help with this.  It's unlikely I would have figured this out without this group.  Take care,Dan
-------- Original message --------From: Lonnie Abelbeck <li...@lo...> Date: 8/7/22  2:02 PM  (GMT-05:00) To: AstLinux Users Mailing List <ast...@li...> Subject: Re: [Astlinux-users] MSMTP: E-Mail From root? Dan, great to hear that did the trick.Yes, the SMTP_FROM is required by some providers.Michael has needed SMTP_FROM for years, my email provider has not ever required SMTP_FROM (the default ro...@do...d is fine).Adding to the confusion is the SMTP_FROM is different from the "From:" email header.Lonnie> On Aug 7, 2022, at 12:36 PM, Dan Ryson <da...@ry...> wrote:> > Michael and Lonnie,> > Thank you.  That worked perfectly.  > > A review of prior e-mails from the PBX all show  a "from" address of root.  This "new" symptom appears to have been triggered by a change at my e-mail provider.  > > Best wishes,> > Dan> > On 8/7/22 11:24, Michael Keuter wrote:>> You need to define SMTP_FROM="us...@ho...">> for your sender address in your user.conf>> >> Sent from a mobile device.>> >> Michael Keuter>> >>> Am 07.08.2022 um 17:02 schrieb Dan Ryson <da...@ry...>:>>> >>> >>> All,>>> >>> I've been trying to figure out why I'm experiencing a new MSMTP symptom on two completely separate PBXs; both running AstLinux 1.4.6.  Within the last few weeks, I've started seeing bounce messages like the one pasted below.  For some reason, mail appears to be going out with a "from" address of root.    >>> >>> sip mail.err msmtp: host=smtp.ryson.org tls=on auth=on user=da...@ry... from=ro...@ry... recipients=da...@ry... smtpstatus=550 smtpmsg='550 sorry, you can?t send as this user' errormsg='envelope from address ro...@ry... not accepted by the server' exitcode=EX_DATAERR >>> >>> I see the same thing with the Test SMTP Mail Relay dialog under the Network tab while entering my e-mail address to both the "to" and "from" text boxes.  >>> >>> <image.png>>>> >>> The symptom also occurs from the command line (with some portions redacted):>>> >>> sip kd #  echo "hello there username." | msmtp --debug -a default da...@ry...>>> loaded system configuration file /etc/msmtprc>>> ignoring user configuration file /root/.msmtprc: No such file or directory>>> using account default from /etc/msmtprc>>> host = smtp.ryson.org>>> port = 465>>> source ip = (not set)>>> proxy host = (not set)>>> proxy port = 0>>> socket = (not set)>>> timeout = 30 seconds>>> protocol = smtp>>> domain = localhost>>> auth = LOGIN>>> <-- 235 ok, go ahead (#2.0.0)>>> --> MAIL FROM:<ro...@ry...>>>> --> RCPT TO:<da...@ry...>>>> --> DATA>>> <-- 550 sorry, you can't send as this user>>> msmtp: envelope from address ro...@ry... not accepted by the server>>> msmtp: server message: 550 sorry, you can't send as this user>>> msmtp: could not send mail (account default from /etc/msmtprc)>>> >>> As always, I'd appreciate any insight.>>> >>> Thanks,>>> >>> Dan>>> _______________________________________________>>> 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/astlinux-usersDonations to support AstLinux are graciously accepted via PayPal to pa...@kr....

Re: [Astlinux-users] MSMTP: E-Mail From root?

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

Dan, great to hear that did the trick.

Yes, the SMTP_FROM is required by some providers.

Michael has needed SMTP_FROM for years, my email provider has not ever required SMTP_FROM (the default ro...@do...d is fine).

Adding to the confusion is the SMTP_FROM is different from the "From:" email header.


Lonnie



> On Aug 7, 2022, at 12:36 PM, Dan Ryson <da...@ry...> wrote:
> 
> Michael and Lonnie,
> 
> Thank you.  That worked perfectly.  
> 
> A review of prior e-mails from the PBX all show  a "from" address of root.  This "new" symptom appears to have been triggered by a change at my e-mail provider.  
> 
> Best wishes,
> 
> Dan
> 
> On 8/7/22 11:24, Michael Keuter wrote:
>> You need to define SMTP_FROM="us...@ho..."
>> for your sender address in your user.conf
>> 
>> Sent from a mobile device.
>> 
>> Michael Keuter
>> 
>>> Am 07.08.2022 um 17:02 schrieb Dan Ryson <da...@ry...>:
>>> 
>>> 
>>> All,
>>> 
>>> I've been trying to figure out why I'm experiencing a new MSMTP symptom on two completely separate PBXs; both running AstLinux 1.4.6.  Within the last few weeks, I've started seeing bounce messages like the one pasted below.  For some reason, mail appears to be going out with a "from" address of root.    
>>> 
>>> sip mail.err msmtp: host=smtp.ryson.org tls=on auth=on user=da...@ry... from=ro...@ry... recipients=da...@ry... smtpstatus=550 smtpmsg='550 sorry, you can?t send as this user' errormsg='envelope from address ro...@ry... not accepted by the server' exitcode=EX_DATAERR 
>>> 
>>> I see the same thing with the Test SMTP Mail Relay dialog under the Network tab while entering my e-mail address to both the "to" and "from" text boxes.  
>>> 
>>> <image.png>
>>> 
>>> The symptom also occurs from the command line (with some portions redacted):
>>> 
>>> sip kd #  echo "hello there username." | msmtp --debug -a default da...@ry...
>>> loaded system configuration file /etc/msmtprc
>>> ignoring user configuration file /root/.msmtprc: No such file or directory
>>> using account default from /etc/msmtprc
>>> host = smtp.ryson.org
>>> port = 465
>>> source ip = (not set)
>>> proxy host = (not set)
>>> proxy port = 0
>>> socket = (not set)
>>> timeout = 30 seconds
>>> protocol = smtp
>>> domain = localhost
>>> auth = LOGIN
>>> <-- 235 ok, go ahead (#2.0.0)
>>> --> MAIL FROM:<ro...@ry...>
>>> --> RCPT TO:<da...@ry...>
>>> --> DATA
>>> <-- 550 sorry, you can't send as this user
>>> msmtp: envelope from address ro...@ry... not accepted by the server
>>> msmtp: server message: 550 sorry, you can't send as this user
>>> msmtp: could not send mail (account default from /etc/msmtprc)
>>> 
>>> As always, I'd appreciate any insight.
>>> 
>>> Thanks,
>>> 
>>> Dan
>>> _______________________________________________
>>> 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] MSMTP: E-Mail From root?

[Dan R. <da...@ry...>]

Michael and Lonnie,

Thank you.  That worked perfectly.

A review of prior e-mails from the PBX all show  a "from" address of 
root.  This "new" symptom appears to have been triggered by a change at 
my e-mail provider.

Best wishes,

Dan

On 8/7/22 11:24, Michael Keuter wrote:
> You need to define SMTP_FROM="us...@ho..."
> for your sender address in your user.conf
>
> Sent from a mobile device.
>
> Michael Keuter
>
>> Am 07.08.2022 um 17:02 schrieb Dan Ryson <da...@ry...>:
>>
>> 
>> All,
>>
>> I've been trying to figure out why I'm experiencing a new MSMTP 
>> symptom on two completely separate PBXs; both running AstLinux 
>> 1.4.6.  Within the last few weeks, I've started seeing bounce 
>> messages like the one pasted below.  For some reason, mail appears to 
>> be going out with a "from" address of /root/.
>>
>> sip mail.err msmtp: host=smtp.ryson.org tls=on auth=on 
>> user=da...@ry... from=ro...@ry... recipients=da...@ry... 
>> smtpstatus=550 smtpmsg='550 sorry, you can?t send as this user' 
>> errormsg='envelope from address ro...@ry... not accepted by the 
>> server' exitcode=EX_DATAERR
>>
>> I see the same thing with the /Test SMTP Mail Relay/ dialog under the 
>> Network tab while entering my e-mail address to both the "to" and 
>> "from" text boxes.
>>
>> image.png
>>
>> The symptom also occurs from the command line (with some portions 
>> redacted):
>>
>> sip kd #  echo "hello there username." | msmtp --debug -a default 
>> da...@ry...
>> loaded system configuration file /etc/msmtprc
>> ignoring user configuration file /root/.msmtprc: No such file or 
>> directory
>> using account default from /etc/msmtprc
>> host = smtp.ryson.org
>> port = 465
>> source ip = (not set)
>> proxy host = (not set)
>> proxy port = 0
>> socket = (not set)
>> timeout = 30 seconds
>> protocol = smtp
>> domain = localhost
>> auth = LOGIN
>> <-- 235 ok, go ahead (#2.0.0)
>> --> MAIL FROM:<ro...@ry...>
>> --> RCPT TO:<da...@ry...>
>> --> DATA
>> <-- 550 sorry, you can't send as this user
>> msmtp: envelope from address ro...@ry... not accepted by the server
>> msmtp: server message: 550 sorry, you can't send as this user
>> msmtp: could not send mail (account default from /etc/msmtprc)
>>
>> As always, I'd appreciate any insight.
>>
>> Thanks,
>>
>> Dan
>> _______________________________________________
>> 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 top...@kr....