Menu
▾
▴
astlinux-users — AstLinux Users Mailing List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(91) |
Feb
(111) |
Mar
(226) |
Apr
(65) |
May
(197) |
Jun
(202) |
Jul
(92) |
Aug
(87) |
Sep
(120) |
Oct
(133) |
Nov
(89) |
Dec
(155) |
| 2008 |
Jan
(251) |
Feb
(136) |
Mar
(174) |
Apr
(149) |
May
(56) |
Jun
(32) |
Jul
(36) |
Aug
(171) |
Sep
(245) |
Oct
(244) |
Nov
(218) |
Dec
(272) |
| 2009 |
Jan
(113) |
Feb
(119) |
Mar
(192) |
Apr
(117) |
May
(93) |
Jun
(46) |
Jul
(80) |
Aug
(54) |
Sep
(109) |
Oct
(70) |
Nov
(145) |
Dec
(110) |
| 2010 |
Jan
(137) |
Feb
(87) |
Mar
(45) |
Apr
(157) |
May
(58) |
Jun
(99) |
Jul
(188) |
Aug
(136) |
Sep
(101) |
Oct
(100) |
Nov
(61) |
Dec
(60) |
| 2011 |
Jan
(84) |
Feb
(43) |
Mar
(70) |
Apr
(17) |
May
(69) |
Jun
(28) |
Jul
(43) |
Aug
(21) |
Sep
(151) |
Oct
(120) |
Nov
(84) |
Dec
(101) |
| 2012 |
Jan
(119) |
Feb
(82) |
Mar
(70) |
Apr
(115) |
May
(66) |
Jun
(131) |
Jul
(70) |
Aug
(65) |
Sep
(66) |
Oct
(86) |
Nov
(197) |
Dec
(81) |
| 2013 |
Jan
(65) |
Feb
(48) |
Mar
(32) |
Apr
(68) |
May
(98) |
Jun
(59) |
Jul
(41) |
Aug
(52) |
Sep
(42) |
Oct
(37) |
Nov
(10) |
Dec
(27) |
| 2014 |
Jan
(61) |
Feb
(34) |
Mar
(30) |
Apr
(52) |
May
(45) |
Jun
(40) |
Jul
(28) |
Aug
(9) |
Sep
(39) |
Oct
(69) |
Nov
(55) |
Dec
(19) |
| 2015 |
Jan
(13) |
Feb
(21) |
Mar
(5) |
Apr
(14) |
May
(30) |
Jun
(51) |
Jul
(31) |
Aug
(12) |
Sep
(29) |
Oct
(15) |
Nov
(24) |
Dec
(16) |
| 2016 |
Jan
(62) |
Feb
(76) |
Mar
(30) |
Apr
(43) |
May
(46) |
Jun
(62) |
Jul
(21) |
Aug
(49) |
Sep
(67) |
Oct
(27) |
Nov
(26) |
Dec
(38) |
| 2017 |
Jan
(7) |
Feb
(12) |
Mar
(69) |
Apr
(59) |
May
(54) |
Jun
(40) |
Jul
(76) |
Aug
(82) |
Sep
(92) |
Oct
(51) |
Nov
(32) |
Dec
(30) |
| 2018 |
Jan
(22) |
Feb
(25) |
Mar
(34) |
Apr
(35) |
May
(37) |
Jun
(21) |
Jul
(69) |
Aug
(55) |
Sep
(17) |
Oct
(67) |
Nov
(9) |
Dec
(5) |
| 2019 |
Jan
(19) |
Feb
(12) |
Mar
(15) |
Apr
(19) |
May
|
Jun
(27) |
Jul
(27) |
Aug
(25) |
Sep
(25) |
Oct
(27) |
Nov
(10) |
Dec
(14) |
| 2020 |
Jan
(22) |
Feb
(20) |
Mar
(36) |
Apr
(40) |
May
(52) |
Jun
(35) |
Jul
(21) |
Aug
(32) |
Sep
(71) |
Oct
(27) |
Nov
(11) |
Dec
(16) |
| 2021 |
Jan
(16) |
Feb
(21) |
Mar
(21) |
Apr
(27) |
May
(17) |
Jun
|
Jul
(2) |
Aug
(22) |
Sep
(23) |
Oct
(7) |
Nov
(11) |
Dec
(28) |
| 2022 |
Jan
(23) |
Feb
(18) |
Mar
(9) |
Apr
(15) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(15) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(10) |
| 2023 |
Jan
(14) |
Feb
(10) |
Mar
(11) |
Apr
(13) |
May
(2) |
Jun
(30) |
Jul
(1) |
Aug
(15) |
Sep
(13) |
Oct
(3) |
Nov
(25) |
Dec
(5) |
| 2024 |
Jan
(3) |
Feb
(10) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(15) |
Jul
(7) |
Aug
(10) |
Sep
(3) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(3) |
Feb
(1) |
Mar
(7) |
Apr
(5) |
May
(13) |
Jun
(16) |
Jul
(1) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael K. <mic...@ip...> - 2017-06-14 22:47:59
|
Hi Lonnie Im not sure that Option 66 is actually the issue here now I have done further testing however I would certainly rather not be sending out this Option at all. Unfortunately you can only add or change items with dnsmasq.static, you cannot remove them. Looks like the best option is to roll my own. Thanks everyone for your help. Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux List <ast...@li...> Date: Thursday, 15 June 2017 at 12:07 am To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot Michael, First, I have never heard of an issue like this. The DHCP option 66 is sent regardless if the TFTP server is enabled or not, as it can be used for HTTP and HTTPS services as well. Can't you disable PXE booting in the BIOS of your Intel NUC’s ? It would seem to me that is where the problem is. Lonnie On Jun 14, 2017, at 12:27 AM, Michael Knill <mic...@ip...> wrote: > So is my only option here to maintain my own copy of dnsmasq.conf or is there a better way e.g. edit the init process to remove the TFTP options? > Maybe a TFTP checkbox on the Network Tab against the interface or something similar? > > Regards > Michael Knill > > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 8:55 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > >> Am 08.06.2017 um 10:33 schrieb Michael Knill <mic...@ip...>: >> >> Yes I thought about tags but really I would rather is not be sent at all. >> Any other options for doing this? >> >> Regards >> Michael Knill > > I have not tested how setting to null behaves: > > dhcp-option=lan,option:tftp-server,"" > > Needs to be tested. > >> -----Original Message----- >> From: Michael Keuter <li...@mk...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Thursday, 8 June 2017 at 6:20 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot >> >>> Am 08.06.2017 um 09:48 schrieb Michael Knill <mic...@ip...>: >>> >>> Hi Michael >>> So I already have enable-tftp=eth1.100,tun0 and the data interface is eth1. I think this command is for turning ON TFTP when DHCP is turned OFF. >>> /etc/dnsmasq.conf has the tftp-server option included so I assume that it will still be there. >>> >>> Is there any way I can look at the actual config? >>> I think I might plug a machine in and really see what I am getting. >>> >>> Regards >>> Michael Knill >> >> OK, there might be another way around this with tags. >> E.g.: >> >> ---- >> dhcp-mac=set:yealink,00:15:65:*:*:* >> dhcp-mac=set:phones,00:15:65:*:*:* >> dhcp-option=tag:yealink,option:tftp-server,"http://192.168.102.1/phoneprov/yealink/" >> >> dhcp-mac=set:snom,00:04:13:*:*:* >> dhcp-mac=set:phones,00:04:13:*:*:* >> dhcp-option=tag:snom,option:tftp-server,"http://192.168.102.1/phoneprov/snom/" >> >> #dhcp-boot=tag:!phones,thinstation/pxelinux.0,pbx3,192.168.100.3 >> ---- >> >> This way only "non-phones" would get the last "dhcp-boot" option >> You could of course make other (more useful) tags. >> >> Just keep in mind "/etc/dnsmasq.conf" is automatically created and then "/mnt/kd/dnsmasq.static" is included into it. >> >>> -----Original Message----- >>> From: Michael Keuter <li...@mk...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Thursday, 8 June 2017 at 5:39 pm >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot >>> >>>> Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>: >>>> >>>> Hi group >>>> >>>> What is the best way to provide DHCP on an interface but turn off TFTP? >>>> I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN! >>>> >>>> Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,"" >>>> >>>> Has anyone had this issue before? >>>> >>>> Regards >>>> Michael Knill >>> >>> Hi Michael, >>> >>> from our AstLinux changelog :-) >>> >>> -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP. >>> More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static". >>> >>> Michael >> >> Michael > > > Michael > > http://www.mksolutions.info > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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.... > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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.... ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ 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.... |
|
From: The C. K. <eld...@ya...> - 2017-06-14 14:17:54
|
I pulled out my few-years-old NUC, and it went on to HDD boot when it couldnt get a valid filename from the TFTP.. im not using DNSMASQ. but i put the MAC address of it in my dhcpd.conf with a option 66 that went nowhere..bogus filename so it failed to get a boot file and just went on to boot from its drive....
-Christopher
From: Lonnie Abelbeck <li...@lo...>
To: AstLinux Users Mailing List <ast...@li...>
Sent: Wednesday, June 14, 2017 10:12 AM
Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot
Michael,
First, I have never heard of an issue like this.
The DHCP option 66 is sent regardless if the TFTP server is enabled or not, as it can be used for HTTP and HTTPS services as well.
Can't you disable PXE booting in the BIOS of your Intel NUC’s ? It would seem to me that is where the problem is.
Lonnie
On Jun 14, 2017, at 12:27 AM, Michael Knill <mic...@ip...> wrote:
> So is my only option here to maintain my own copy of dnsmasq.conf or is there a better way e.g. edit the init process to remove the TFTP options?
> Maybe a TFTP checkbox on the Network Tab against the interface or something similar?
>
> Regards
> Michael Knill
>
> -----Original Message-----
> From: Michael Keuter <li...@mk...>
> Reply-To: AstLinux List <ast...@li...>
> Date: Thursday, 8 June 2017 at 8:55 pm
> To: AstLinux List <ast...@li...>
> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot
>
>> Am 08.06.2017 um 10:33 schrieb Michael Knill <mic...@ip...>:
>>
>> Yes I thought about tags but really I would rather is not be sent at all.
>> Any other options for doing this?
>>
>> Regards
>> Michael Knill
>
> I have not tested how setting to null behaves:
>
> dhcp-option=lan,option:tftp-server,""
>
> Needs to be tested.
>
>> -----Original Message-----
>> From: Michael Keuter <li...@mk...>
>> Reply-To: AstLinux List <ast...@li...>
>> Date: Thursday, 8 June 2017 at 6:20 pm
>> To: AstLinux List <ast...@li...>
>> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot
>>
>>> Am 08.06.2017 um 09:48 schrieb Michael Knill <mic...@ip...>:
>>>
>>> Hi Michael
>>> So I already have enable-tftp=eth1.100,tun0 and the data interface is eth1. I think this command is for turning ON TFTP when DHCP is turned OFF.
>>> /etc/dnsmasq.conf has the tftp-server option included so I assume that it will still be there.
>>>
>>> Is there any way I can look at the actual config?
>>> I think I might plug a machine in and really see what I am getting.
>>>
>>> Regards
>>> Michael Knill
>>
>> OK, there might be another way around this with tags.
>> E.g.:
>>
>> ----
>> dhcp-mac=set:yealink,00:15:65:*:*:*
>> dhcp-mac=set:phones,00:15:65:*:*:*
>> dhcp-option=tag:yealink,option:tftp-server,"http://192.168.102.1/phoneprov/yealink/"
>>
>> dhcp-mac=set:snom,00:04:13:*:*:*
>> dhcp-mac=set:phones,00:04:13:*:*:*
>> dhcp-option=tag:snom,option:tftp-server,"http://192.168.102.1/phoneprov/snom/"
>>
>> #dhcp-boot=tag:!phones,thinstation/pxelinux.0,pbx3,192.168.100.3
>> ----
>>
>> This way only "non-phones" would get the last "dhcp-boot" option
>> You could of course make other (more useful) tags.
>>
>> Just keep in mind "/etc/dnsmasq.conf" is automatically created and then "/mnt/kd/dnsmasq.static" is included into it.
>>
>>> -----Original Message-----
>>> From: Michael Keuter <li...@mk...>
>>> Reply-To: AstLinux List <ast...@li...>
>>> Date: Thursday, 8 June 2017 at 5:39 pm
>>> To: AstLinux List <ast...@li...>
>>> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot
>>>
>>>> Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>:
>>>>
>>>> Hi group
>>>>
>>>> What is the best way to provide DHCP on an interface but turn off TFTP?
>>>> I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN!
>>>>
>>>> Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,""
>>>>
>>>> Has anyone had this issue before?
>>>>
>>>> Regards
>>>> Michael Knill
>>>
>>> Hi Michael,
>>>
>>> from our AstLinux changelog :-)
>>>
>>> -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP.
>>> More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static".
>>>
>>> Michael
>>
>> Michael
>
>
> Michael
>
> http://www.mksolutions.info
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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....
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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....
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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....
|
|
From: Lonnie A. <li...@lo...> - 2017-06-14 14:07:32
|
Michael, First, I have never heard of an issue like this. The DHCP option 66 is sent regardless if the TFTP server is enabled or not, as it can be used for HTTP and HTTPS services as well. Can't you disable PXE booting in the BIOS of your Intel NUC’s ? It would seem to me that is where the problem is. Lonnie On Jun 14, 2017, at 12:27 AM, Michael Knill <mic...@ip...> wrote: > So is my only option here to maintain my own copy of dnsmasq.conf or is there a better way e.g. edit the init process to remove the TFTP options? > Maybe a TFTP checkbox on the Network Tab against the interface or something similar? > > Regards > Michael Knill > > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 8:55 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > >> Am 08.06.2017 um 10:33 schrieb Michael Knill <mic...@ip...>: >> >> Yes I thought about tags but really I would rather is not be sent at all. >> Any other options for doing this? >> >> Regards >> Michael Knill > > I have not tested how setting to null behaves: > > dhcp-option=lan,option:tftp-server,"" > > Needs to be tested. > >> -----Original Message----- >> From: Michael Keuter <li...@mk...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Thursday, 8 June 2017 at 6:20 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot >> >>> Am 08.06.2017 um 09:48 schrieb Michael Knill <mic...@ip...>: >>> >>> Hi Michael >>> So I already have enable-tftp=eth1.100,tun0 and the data interface is eth1. I think this command is for turning ON TFTP when DHCP is turned OFF. >>> /etc/dnsmasq.conf has the tftp-server option included so I assume that it will still be there. >>> >>> Is there any way I can look at the actual config? >>> I think I might plug a machine in and really see what I am getting. >>> >>> Regards >>> Michael Knill >> >> OK, there might be another way around this with tags. >> E.g.: >> >> ---- >> dhcp-mac=set:yealink,00:15:65:*:*:* >> dhcp-mac=set:phones,00:15:65:*:*:* >> dhcp-option=tag:yealink,option:tftp-server,"http://192.168.102.1/phoneprov/yealink/" >> >> dhcp-mac=set:snom,00:04:13:*:*:* >> dhcp-mac=set:phones,00:04:13:*:*:* >> dhcp-option=tag:snom,option:tftp-server,"http://192.168.102.1/phoneprov/snom/" >> >> #dhcp-boot=tag:!phones,thinstation/pxelinux.0,pbx3,192.168.100.3 >> ---- >> >> This way only "non-phones" would get the last "dhcp-boot" option >> You could of course make other (more useful) tags. >> >> Just keep in mind "/etc/dnsmasq.conf" is automatically created and then "/mnt/kd/dnsmasq.static" is included into it. >> >>> -----Original Message----- >>> From: Michael Keuter <li...@mk...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Thursday, 8 June 2017 at 5:39 pm >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot >>> >>>> Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>: >>>> >>>> Hi group >>>> >>>> What is the best way to provide DHCP on an interface but turn off TFTP? >>>> I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN! >>>> >>>> Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,"" >>>> >>>> Has anyone had this issue before? >>>> >>>> Regards >>>> Michael Knill >>> >>> Hi Michael, >>> >>> from our AstLinux changelog :-) >>> >>> -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP. >>> More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static". >>> >>> Michael >> >> Michael > > > Michael > > http://www.mksolutions.info > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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.... > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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.... |
|
From: Michael K. <mic...@ip...> - 2017-06-14 11:24:56
|
Yeah thanks for the idea but it just removes the lines: enable-tftp tftp-root=/tftpboot Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Wednesday, 14 June 2017 at 5:40 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot Have you tried to disable the TFTP-server on the network tab? And then make your own settings in dnsmasq.static ... Sent from a mobile device. Michael Keuter > Am 14.06.2017 um 07:27 schrieb Michael Knill <mic...@ip...>: > > So is my only option here to maintain my own copy of dnsmasq.conf or is there a better way e.g. edit the init process to remove the TFTP options? > Maybe a TFTP checkbox on the Network Tab against the interface or something similar? > > Regards > Michael Knill > > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 8:55 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > >> Am 08.06.2017 um 10:33 schrieb Michael Knill <mic...@ip...>: >> >> Yes I thought about tags but really I would rather is not be sent at all. >> Any other options for doing this? >> >> Regards >> Michael Knill > > I have not tested how setting to null behaves: > > dhcp-option=lan,option:tftp-server,"" > > Needs to be tested. > >> -----Original Message----- >> From: Michael Keuter <li...@mk...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Thursday, 8 June 2017 at 6:20 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot >> >>> Am 08.06.2017 um 09:48 schrieb Michael Knill <mic...@ip...>: >>> >>> Hi Michael >>> So I already have enable-tftp=eth1.100,tun0 and the data interface is eth1. I think this command is for turning ON TFTP when DHCP is turned OFF. >>> /etc/dnsmasq.conf has the tftp-server option included so I assume that it will still be there. >>> >>> Is there any way I can look at the actual config? >>> I think I might plug a machine in and really see what I am getting. >>> >>> Regards >>> Michael Knill >> >> OK, there might be another way around this with tags. >> E.g.: >> >> ---- >> dhcp-mac=set:yealink,00:15:65:*:*:* >> dhcp-mac=set:phones,00:15:65:*:*:* >> dhcp-option=tag:yealink,option:tftp-server,"http://192.168.102.1/phoneprov/yealink/" >> >> dhcp-mac=set:snom,00:04:13:*:*:* >> dhcp-mac=set:phones,00:04:13:*:*:* >> dhcp-option=tag:snom,option:tftp-server,"http://192.168.102.1/phoneprov/snom/" >> >> #dhcp-boot=tag:!phones,thinstation/pxelinux.0,pbx3,192.168.100.3 >> ---- >> >> This way only "non-phones" would get the last "dhcp-boot" option >> You could of course make other (more useful) tags. >> >> Just keep in mind "/etc/dnsmasq.conf" is automatically created and then "/mnt/kd/dnsmasq.static" is included into it. >> >>> -----Original Message----- >>> From: Michael Keuter <li...@mk...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Thursday, 8 June 2017 at 5:39 pm >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot >>> >>>> Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>: >>>> >>>> Hi group >>>> >>>> What is the best way to provide DHCP on an interface but turn off TFTP? >>>> I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN! >>>> >>>> Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,"" >>>> >>>> Has anyone had this issue before? >>>> >>>> Regards >>>> Michael Knill >>> >>> Hi Michael, >>> >>> from our AstLinux changelog :-) >>> >>> -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP. >>> More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static". >>> >>> Michael >> >> Michael > > > Michael > > http://www.mksolutions.info > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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.... > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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.... ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ 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.... |
|
From: Michael K. <li...@mk...> - 2017-06-14 07:40:09
|
Have you tried to disable the TFTP-server on the network tab? And then make your own settings in dnsmasq.static ... Sent from a mobile device. Michael Keuter > Am 14.06.2017 um 07:27 schrieb Michael Knill <mic...@ip...>: > > So is my only option here to maintain my own copy of dnsmasq.conf or is there a better way e.g. edit the init process to remove the TFTP options? > Maybe a TFTP checkbox on the Network Tab against the interface or something similar? > > Regards > Michael Knill > > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 8:55 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > >> Am 08.06.2017 um 10:33 schrieb Michael Knill <mic...@ip...>: >> >> Yes I thought about tags but really I would rather is not be sent at all. >> Any other options for doing this? >> >> Regards >> Michael Knill > > I have not tested how setting to null behaves: > > dhcp-option=lan,option:tftp-server,"" > > Needs to be tested. > >> -----Original Message----- >> From: Michael Keuter <li...@mk...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Thursday, 8 June 2017 at 6:20 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot >> >>> Am 08.06.2017 um 09:48 schrieb Michael Knill <mic...@ip...>: >>> >>> Hi Michael >>> So I already have enable-tftp=eth1.100,tun0 and the data interface is eth1. I think this command is for turning ON TFTP when DHCP is turned OFF. >>> /etc/dnsmasq.conf has the tftp-server option included so I assume that it will still be there. >>> >>> Is there any way I can look at the actual config? >>> I think I might plug a machine in and really see what I am getting. >>> >>> Regards >>> Michael Knill >> >> OK, there might be another way around this with tags. >> E.g.: >> >> ---- >> dhcp-mac=set:yealink,00:15:65:*:*:* >> dhcp-mac=set:phones,00:15:65:*:*:* >> dhcp-option=tag:yealink,option:tftp-server,"http://192.168.102.1/phoneprov/yealink/" >> >> dhcp-mac=set:snom,00:04:13:*:*:* >> dhcp-mac=set:phones,00:04:13:*:*:* >> dhcp-option=tag:snom,option:tftp-server,"http://192.168.102.1/phoneprov/snom/" >> >> #dhcp-boot=tag:!phones,thinstation/pxelinux.0,pbx3,192.168.100.3 >> ---- >> >> This way only "non-phones" would get the last "dhcp-boot" option >> You could of course make other (more useful) tags. >> >> Just keep in mind "/etc/dnsmasq.conf" is automatically created and then "/mnt/kd/dnsmasq.static" is included into it. >> >>> -----Original Message----- >>> From: Michael Keuter <li...@mk...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Thursday, 8 June 2017 at 5:39 pm >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot >>> >>>> Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>: >>>> >>>> Hi group >>>> >>>> What is the best way to provide DHCP on an interface but turn off TFTP? >>>> I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN! >>>> >>>> Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,"" >>>> >>>> Has anyone had this issue before? >>>> >>>> Regards >>>> Michael Knill >>> >>> Hi Michael, >>> >>> from our AstLinux changelog :-) >>> >>> -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP. >>> More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static". >>> >>> Michael >> >> Michael > > > Michael > > http://www.mksolutions.info > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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.... > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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.... |
|
From: Michael K. <mic...@ip...> - 2017-06-14 05:27:49
|
So is my only option here to maintain my own copy of dnsmasq.conf or is there a better way e.g. edit the init process to remove the TFTP options? Maybe a TFTP checkbox on the Network Tab against the interface or something similar? Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Thursday, 8 June 2017 at 8:55 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > Am 08.06.2017 um 10:33 schrieb Michael Knill <mic...@ip...>: > > Yes I thought about tags but really I would rather is not be sent at all. > Any other options for doing this? > > Regards > Michael Knill I have not tested how setting to null behaves: dhcp-option=lan,option:tftp-server,"" Needs to be tested. > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 6:20 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > >> Am 08.06.2017 um 09:48 schrieb Michael Knill <mic...@ip...>: >> >> Hi Michael >> So I already have enable-tftp=eth1.100,tun0 and the data interface is eth1. I think this command is for turning ON TFTP when DHCP is turned OFF. >> /etc/dnsmasq.conf has the tftp-server option included so I assume that it will still be there. >> >> Is there any way I can look at the actual config? >> I think I might plug a machine in and really see what I am getting. >> >> Regards >> Michael Knill > > OK, there might be another way around this with tags. > E.g.: > > ---- > dhcp-mac=set:yealink,00:15:65:*:*:* > dhcp-mac=set:phones,00:15:65:*:*:* > dhcp-option=tag:yealink,option:tftp-server,"http://192.168.102.1/phoneprov/yealink/" > > dhcp-mac=set:snom,00:04:13:*:*:* > dhcp-mac=set:phones,00:04:13:*:*:* > dhcp-option=tag:snom,option:tftp-server,"http://192.168.102.1/phoneprov/snom/" > > #dhcp-boot=tag:!phones,thinstation/pxelinux.0,pbx3,192.168.100.3 > ---- > > This way only "non-phones" would get the last "dhcp-boot" option > You could of course make other (more useful) tags. > > Just keep in mind "/etc/dnsmasq.conf" is automatically created and then "/mnt/kd/dnsmasq.static" is included into it. > >> -----Original Message----- >> From: Michael Keuter <li...@mk...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Thursday, 8 June 2017 at 5:39 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot >> >>> Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>: >>> >>> Hi group >>> >>> What is the best way to provide DHCP on an interface but turn off TFTP? >>> I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN! >>> >>> Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,"" >>> >>> Has anyone had this issue before? >>> >>> Regards >>> Michael Knill >> >> Hi Michael, >> >> from our AstLinux changelog :-) >> >> -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP. >> More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static". >> >> Michael > > Michael Michael http://www.mksolutions.info ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ 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.... |
|
From: Nedi <ne...@gm...> - 2017-06-10 11:27:41
|
David i have resolved this with m(Willkommen) in dialplan , yesterday this not working because i had in musiconhold.conf setting random=yes
exten =>10,1,Answer()
exten =>10,n,Set(CHANNEL(language)=de)
exten =>10,n,Set(destination=${CUT(EXTEN,"*",3)})
exten =>10,n,Set(source=${CUT(EXTEN,"*",2)})
exten =>10,n,Dial(SIP/17&SIP/10,35,m(Willkommen)tTwWxXr)
I changed in musiconhold.conf to radnom =no and works
[default]
mode=files
directory=/var/lib/asterisk/moh/default
random=no ; Play the files in a random order
Thanks
regards nedi
|
|
From: Nedi <ne...@gm...> - 2017-06-10 10:39:36
|
Hi David,
thanks
I need Dial and Playback at the same time.
I dian two internal number 10 is my deskphone and 17 is my voip gsm gateway ..
The problem is the gsm gateway, trough GSM Gateway i get the call but with delay and I would like to get incomin calls trough gsm gateway at the same time in the time the caller hearing the message Playback(Willkommen).
At the moment I have this in my extension,conf
exten =>10,1,Answer()
exten =>10,n,Set(CHANNEL(language)=de)
exten =>10,n,Set(destination=${CUT(EXTEN,"*",3)})
exten =>10,n,Set(source=${CUT(EXTEN,"*",2)})
exten =>10,n,Playback(Willkommen)
exten =>10,n,Dial(SIP/17&SIP/10,35,mtTwWxXr)
Regards
nedi
|
|
From: David K. <da...@ke...> - 2017-06-10 03:13:03
|
I think you would have to Park() the call on a queue, then go Dial() and when the called party answers you would take the parked call off the queue and connect to the channel that answered the call. At least I think that is what you are trying to accomplish? Or you could try the m() option on the Dial() command which will play music on hold while waiting for the other party to answer. David On Fri, Jun 9, 2017 at 5:34 PM, Nedi <ne...@gm...> wrote: > Hi List > Is there a way durring Incomming call to dial internal number and play > audio file to the caller at the same time. > best regards > nedi > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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.... > |
|
From: Nedi <ne...@gm...> - 2017-06-09 21:34:49
|
Hi List Is there a way durring Incomming call to dial internal number and play audio file to the caller at the same time. best regards nedi |
|
From: David K. <da...@ke...> - 2017-06-09 19:29:37
|
Just a heads up... This prerelease includes this bug... https://issues.asterisk.org/jira/browse/ASTERISK-27026 Work-around is to touch /etc/asterisk/ari.conf (ie, make sure that this file exists, even if empty) David On Fri, Jun 9, 2017 at 9:36 AM, Lonnie Abelbeck <li...@lo...> wrote: > Announcing Pre-Release Version: astlinux-1.0-8389 > > Significant update with Linux 3.16 kernel, will eventually become the new > AstLinux 1.3 series. > > The AstLinux Team is regularly upgrading packages containing security and > bug fixes as well as adding new features of our own. > > -- DHCPv6 with Prefix Delegation > http://doc.astlinux-project.org/userdoc:tt-dhcpv6-prefix-delegation > Note: If you previously enabled DHCPv6 in the Network tab -> Connection > Type, see IPv6 Autoconfig: "Assign GUA Prefix" reference. > > -- IPv6 ULA / NPTv6 Configuration > http://doc.astlinux-project.org/userdoc:tt_ipv6_ula_nptv6_config > > -- Traffic Shaper how uses fq_codel (Fair Queueing CoDel) for both 'htb' > and 'hfsc' types. Give 'hfsc' a try. > > -- The default serial baud rate is now 115200 instead of the previous > 19200. Upgrading RUNNIX will default to 115200. > > These pre-release images are for those who would like to take advantage of > the AstLinux development before the next official release, as well as > providing testing for the project. > > The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be > found under the "Development" tab of the AstLinux Project web site ... > > AstLinux Project -> Development > http://www.astlinux-project.org/dev.html > > While these images are considered 'stable', the lack of testing will not > make these images suitable for critical production systems. > > If you should come across an issue, please report back here. > > AstLinux Team > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2017-06-09 13:37:04
|
Announcing Pre-Release Version: astlinux-1.0-8389 Significant update with Linux 3.16 kernel, will eventually become the new AstLinux 1.3 series. The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- DHCPv6 with Prefix Delegation http://doc.astlinux-project.org/userdoc:tt-dhcpv6-prefix-delegation Note: If you previously enabled DHCPv6 in the Network tab -> Connection Type, see IPv6 Autoconfig: "Assign GUA Prefix" reference. -- IPv6 ULA / NPTv6 Configuration http://doc.astlinux-project.org/userdoc:tt_ipv6_ula_nptv6_config -- Traffic Shaper how uses fq_codel (Fair Queueing CoDel) for both 'htb' and 'hfsc' types. Give 'hfsc' a try. -- The default serial baud rate is now 115200 instead of the previous 19200. Upgrading RUNNIX will default to 115200. These pre-release images are for those who would like to take advantage of the AstLinux development before the next official release, as well as providing testing for the project. The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development http://www.astlinux-project.org/dev.html While these images are considered 'stable', the lack of testing will not make these images suitable for critical production systems. If you should come across an issue, please report back here. AstLinux Team |
|
From: Michael K. <mic...@ip...> - 2017-06-08 22:57:52
|
No that's not actually the issue as PPPoE always comes up fine. I'm starting to think it's when there is a power failure and PPPoE takes ages to come up, especially the new VDSL services we have here. Let's see how it goes. Regards Michael Knill Sent from my iPhone so please excuse my brevity. > On 8 Jun 2017, at 10:17 pm, Michael Keuter <li...@mk...> wrote: > > >> Am 08.06.2017 um 13:33 schrieb Michael Knill <mic...@ip...>: >> >> Hmm I think I will set this for PPPoE as it might solve some of my issues. Funny I have never found it. >> I thought 60 was a bit long but maybe better to be safe than sorry. >> >> ## Sometimes it takes a while for the WAN interface to come up... >> ## This can happen with frame relay and PPPoE, for example. >> ## Set this variable in seconds, and I will sleep on startup before >> ## I attempt to bring up the WAN interface. >> WANDELAY=60 >> >> Regards >> Michael Knill > > IMHO this is only for if you boot up or restart the computer, so the PPPoE service will wait <WANDELAY> secs before it starts. > > I think this might be better suited: > > ## The PPPoE restart delay (in seconds) between pppoe-stop and pppoe-start for a pppoe-restart. > ## Defaults to 2 seconds when not defined, some ISP's may require a much longer delay. > #PPPOE_RESTART_DELAY=2 > > >> -----Original Message----- >> From: Michael Knill <mic...@ip...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Thursday, 8 June 2017 at 9:01 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >> >> Could Monit do it? I am playing with it now! >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Michael Keuter <li...@mk...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Thursday, 8 June 2017 at 8:58 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >> >> >>> Am 08.06.2017 um 10:28 schrieb Michael Knill <mic...@ip...>: >>> >>> Ah so have you had similar problems to me then where Asterisk has still lost connectivity when PPPoE comes back? >>> Do you know why it does this? >>> >>> Regards >>> Michael Knill >> >> No not really, I just let the cron script run so that the ISP disconnect does not occur during office time. >> >> It would be nice if this could be monitored somehow and then action could be taken automatically (like with DynDNS). >> >>> -----Original Message----- >>> From: Michael Keuter <li...@mk...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Thursday, 8 June 2017 at 6:24 pm >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >>> >>> >>>> Am 08.06.2017 um 09:51 schrieb Michael Knill <mic...@ip...>: >>>> >>>> Slightly different but this happened again today. It was a registered trunk but I had to reload before it worked. >>>> >>>> Im beginning to think it's something to do with PPPoE/firewall. I have never had this problem at non PPPoE sites. >>>> >>>> Regards >>>> Michael Knill >>> >>> What I do at PPPoE sites is a cronjob that restarts PPPoE at 03:00, waits an amount of time (20-180 seconds, needs to be tested) and then restarts DNS and reloads Asterisk (whatever you need). >>> Usually the ISPs disconnect the DSL lines every 24 hours (at least here in Germany). >>> >>>> From: Michael Knill <mic...@ip...> >>>> Reply-To: AstLinux List <ast...@li...> >>>> Date: Wednesday, 7 June 2017 at 11:30 am >>>> To: AstLinux List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >>>> >>>> And its happened again at another site. Astlinux rebooted this time which I hope was a power failure. >>>> It just seems like Asterisk doesn't know that its up. Any ideas on how I should test this when it happens again? DNS issue maybe? >>>> I might also try sip qualify peer from the cli to see if this brings it up. >>>> >>>> Regards >>>> Michael Knill >>>> >>>> From: Michael Knill <mic...@ip...> >>>> Reply-To: AstLinux List <ast...@li...> >>>> Date: Monday, 5 June 2017 at 11:26 am >>>> To: AstLinux List <ast...@li...> >>>> Subject: [Astlinux-users] Problems with losing SIP Trunk >>>> >>>> Hi group >>>> >>>> I have actually reported this problem before but it was using a different network connection. >>>> Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via a firewall so it is using NAT but I don't think it should matter. >>>> It appears that when there is a particular event that there is a temporary loss of connectivity, but not a link down event, qualify or SIP OPTIONS pings do not make it to the trunk provider (or back again as I have not been able to test). Performing an Asterisk reload fixes the problem immediately. >>>> >>>> Before reload: >>>> I managed to check the reload before and after firewall states: >>>> Source Port (#'s) Destination Port Protocol Packets Bytes TTL >>>> 192.168.2.5 5060 192.168.2.38 5060 UDP 28535 16835829 2:59 >>>> 192.168.2.5 5060 192.168.2.39 5060 UDP 17450 10280235 2:58 >>>> 192.168.2.5 5060 192.168.2.35 5060 UDP 16930 9948145 2:59 >>>> 192.168.2.5 5060 192.168.2.42 5060 UDP 12961 7604592 2:54 >>>> 192.168.2.5 5060 192.168.2.37 5060 UDP 3561 2019123 2:57 >>>> 192.168.2.5 5060 192.168.2.36 5060 UDP 3454 1952748 2:53 >>>> 124.171.212.155 50133 172.30.10.2 7123 TCP 222 56430 7199:59 >>>> 192.168.2.22 17500 192.168.2.255 17500 UDP 200 45600 0:55 >>>> 192.168.2.22 17500 255.255.255.255 17500 UDP 100 22800 0:55 >>>> 192.168.2.30 138 192.168.2.255 138 UDP 1 229 0:58 >>>> 172.30.10.2 8272 (10) 8.8.8.8 53 UDP 2 211 0:59 >>>> 172.30.10.2 56406 (2) 113.20.24.94 10051 TCP 2 120 1:11 >>>> 48 Total Firewall States >>>> >>>> After reload: >>>> Source Port (#'s) Destination Port Protocol Packets Bytes TTL >>>> 192.168.2.5 5060 192.168.2.38 5060 UDP 28773 16975982 2:57 >>>> 192.168.2.5 5060 192.168.2.35 5060 UDP 17821 10475864 2:59 >>>> 192.168.2.5 5060 192.168.2.39 5060 UDP 17596 10365993 2:58 >>>> 192.168.2.5 5060 192.168.2.42 5060 UDP 13069 7667552 2:50 >>>> 192.168.2.5 5060 192.168.2.37 5060 UDP 3591 2035954 2:50 >>>> 192.168.2.5 5060 192.168.2.36 5060 UDP 3484 1969553 2:58 >>>> 124.171.212.155 50133 172.30.10.2 7123 TCP 548 132258 7199:59 >>>> 192.168.2.22 17500 192.168.2.255 17500 UDP 214 48792 0:43 >>>> 192.168.2.22 17500 255.255.255.255 17500 UDP 107 24396 0:43 >>>> 172.30.10.2 5060 125.213.162.112 5060 UDP 2 1042 0:50 >>>> 172.30.10.2 31249 (3) 8.8.8.8 53 UDP 2 211 0:59 >>>> 172.30.10.2 56424 (2) 113.20.24.94 10051 TCP 2 120 1:39 >>>> 28 Total Firewall States >>>> >>>> My provider 125.213.162.112 is now there so I assume that the problem is not in the firewall that Astlinux traverses but the Astlinux firewall itself. >>>> I am sending OPTIONS pings every 30 seconds. Why would this not just set up the firewall state again? Maybe its an Asterisk problem? >>>> >>>> Any ideas? What should I check when it happens again? >>>> >>>> Regards >>>> Michael Knill >>> >>> Michael >> >> Michael > > Michael > > http://www.mksolutions.info > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > 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.... |
|
From: Michael K. <li...@mk...> - 2017-06-08 12:16:35
|
> Am 08.06.2017 um 13:33 schrieb Michael Knill <mic...@ip...>: > > Hmm I think I will set this for PPPoE as it might solve some of my issues. Funny I have never found it. > I thought 60 was a bit long but maybe better to be safe than sorry. > > ## Sometimes it takes a while for the WAN interface to come up... > ## This can happen with frame relay and PPPoE, for example. > ## Set this variable in seconds, and I will sleep on startup before > ## I attempt to bring up the WAN interface. > WANDELAY=60 > > Regards > Michael Knill IMHO this is only for if you boot up or restart the computer, so the PPPoE service will wait <WANDELAY> secs before it starts. I think this might be better suited: ## The PPPoE restart delay (in seconds) between pppoe-stop and pppoe-start for a pppoe-restart. ## Defaults to 2 seconds when not defined, some ISP's may require a much longer delay. #PPPOE_RESTART_DELAY=2 > -----Original Message----- > From: Michael Knill <mic...@ip...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 9:01 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > > Could Monit do it? I am playing with it now! > > Regards > Michael Knill > > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 8:58 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > > >> Am 08.06.2017 um 10:28 schrieb Michael Knill <mic...@ip...>: >> >> Ah so have you had similar problems to me then where Asterisk has still lost connectivity when PPPoE comes back? >> Do you know why it does this? >> >> Regards >> Michael Knill > > No not really, I just let the cron script run so that the ISP disconnect does not occur during office time. > > It would be nice if this could be monitored somehow and then action could be taken automatically (like with DynDNS). > >> -----Original Message----- >> From: Michael Keuter <li...@mk...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Thursday, 8 June 2017 at 6:24 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >> >> >>> Am 08.06.2017 um 09:51 schrieb Michael Knill <mic...@ip...>: >>> >>> Slightly different but this happened again today. It was a registered trunk but I had to reload before it worked. >>> >>> Im beginning to think it's something to do with PPPoE/firewall. I have never had this problem at non PPPoE sites. >>> >>> Regards >>> Michael Knill >> >> What I do at PPPoE sites is a cronjob that restarts PPPoE at 03:00, waits an amount of time (20-180 seconds, needs to be tested) and then restarts DNS and reloads Asterisk (whatever you need). >> Usually the ISPs disconnect the DSL lines every 24 hours (at least here in Germany). >> >>> From: Michael Knill <mic...@ip...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Wednesday, 7 June 2017 at 11:30 am >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >>> >>> And its happened again at another site. Astlinux rebooted this time which I hope was a power failure. >>> It just seems like Asterisk doesn't know that its up. Any ideas on how I should test this when it happens again? DNS issue maybe? >>> I might also try sip qualify peer from the cli to see if this brings it up. >>> >>> Regards >>> Michael Knill >>> >>> From: Michael Knill <mic...@ip...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Monday, 5 June 2017 at 11:26 am >>> To: AstLinux List <ast...@li...> >>> Subject: [Astlinux-users] Problems with losing SIP Trunk >>> >>> Hi group >>> >>> I have actually reported this problem before but it was using a different network connection. >>> Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via a firewall so it is using NAT but I don't think it should matter. >>> It appears that when there is a particular event that there is a temporary loss of connectivity, but not a link down event, qualify or SIP OPTIONS pings do not make it to the trunk provider (or back again as I have not been able to test). Performing an Asterisk reload fixes the problem immediately. >>> >>> Before reload: >>> I managed to check the reload before and after firewall states: >>> Source Port (#'s) Destination Port Protocol Packets Bytes TTL >>> 192.168.2.5 5060 192.168.2.38 5060 UDP 28535 16835829 2:59 >>> 192.168.2.5 5060 192.168.2.39 5060 UDP 17450 10280235 2:58 >>> 192.168.2.5 5060 192.168.2.35 5060 UDP 16930 9948145 2:59 >>> 192.168.2.5 5060 192.168.2.42 5060 UDP 12961 7604592 2:54 >>> 192.168.2.5 5060 192.168.2.37 5060 UDP 3561 2019123 2:57 >>> 192.168.2.5 5060 192.168.2.36 5060 UDP 3454 1952748 2:53 >>> 124.171.212.155 50133 172.30.10.2 7123 TCP 222 56430 7199:59 >>> 192.168.2.22 17500 192.168.2.255 17500 UDP 200 45600 0:55 >>> 192.168.2.22 17500 255.255.255.255 17500 UDP 100 22800 0:55 >>> 192.168.2.30 138 192.168.2.255 138 UDP 1 229 0:58 >>> 172.30.10.2 8272 (10) 8.8.8.8 53 UDP 2 211 0:59 >>> 172.30.10.2 56406 (2) 113.20.24.94 10051 TCP 2 120 1:11 >>> 48 Total Firewall States >>> >>> After reload: >>> Source Port (#'s) Destination Port Protocol Packets Bytes TTL >>> 192.168.2.5 5060 192.168.2.38 5060 UDP 28773 16975982 2:57 >>> 192.168.2.5 5060 192.168.2.35 5060 UDP 17821 10475864 2:59 >>> 192.168.2.5 5060 192.168.2.39 5060 UDP 17596 10365993 2:58 >>> 192.168.2.5 5060 192.168.2.42 5060 UDP 13069 7667552 2:50 >>> 192.168.2.5 5060 192.168.2.37 5060 UDP 3591 2035954 2:50 >>> 192.168.2.5 5060 192.168.2.36 5060 UDP 3484 1969553 2:58 >>> 124.171.212.155 50133 172.30.10.2 7123 TCP 548 132258 7199:59 >>> 192.168.2.22 17500 192.168.2.255 17500 UDP 214 48792 0:43 >>> 192.168.2.22 17500 255.255.255.255 17500 UDP 107 24396 0:43 >>> 172.30.10.2 5060 125.213.162.112 5060 UDP 2 1042 0:50 >>> 172.30.10.2 31249 (3) 8.8.8.8 53 UDP 2 211 0:59 >>> 172.30.10.2 56424 (2) 113.20.24.94 10051 TCP 2 120 1:39 >>> 28 Total Firewall States >>> >>> My provider 125.213.162.112 is now there so I assume that the problem is not in the firewall that Astlinux traverses but the Astlinux firewall itself. >>> I am sending OPTIONS pings every 30 seconds. Why would this not just set up the firewall state again? Maybe its an Asterisk problem? >>> >>> Any ideas? What should I check when it happens again? >>> >>> Regards >>> Michael Knill >> >> Michael > > Michael Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2017-06-08 11:34:05
|
Hmm I think I will set this for PPPoE as it might solve some of my issues. Funny I have never found it. I thought 60 was a bit long but maybe better to be safe than sorry. ## Sometimes it takes a while for the WAN interface to come up... ## This can happen with frame relay and PPPoE, for example. ## Set this variable in seconds, and I will sleep on startup before ## I attempt to bring up the WAN interface. WANDELAY=60 Regards Michael Knill -----Original Message----- From: Michael Knill <mic...@ip...> Reply-To: AstLinux List <ast...@li...> Date: Thursday, 8 June 2017 at 9:01 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk Could Monit do it? I am playing with it now! Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Thursday, 8 June 2017 at 8:58 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > Am 08.06.2017 um 10:28 schrieb Michael Knill <mic...@ip...>: > > Ah so have you had similar problems to me then where Asterisk has still lost connectivity when PPPoE comes back? > Do you know why it does this? > > Regards > Michael Knill No not really, I just let the cron script run so that the ISP disconnect does not occur during office time. It would be nice if this could be monitored somehow and then action could be taken automatically (like with DynDNS). > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 6:24 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > > >> Am 08.06.2017 um 09:51 schrieb Michael Knill <mic...@ip...>: >> >> Slightly different but this happened again today. It was a registered trunk but I had to reload before it worked. >> >> Im beginning to think it's something to do with PPPoE/firewall. I have never had this problem at non PPPoE sites. >> >> Regards >> Michael Knill > > What I do at PPPoE sites is a cronjob that restarts PPPoE at 03:00, waits an amount of time (20-180 seconds, needs to be tested) and then restarts DNS and reloads Asterisk (whatever you need). > Usually the ISPs disconnect the DSL lines every 24 hours (at least here in Germany). > >> From: Michael Knill <mic...@ip...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Wednesday, 7 June 2017 at 11:30 am >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >> >> And its happened again at another site. Astlinux rebooted this time which I hope was a power failure. >> It just seems like Asterisk doesn't know that its up. Any ideas on how I should test this when it happens again? DNS issue maybe? >> I might also try sip qualify peer from the cli to see if this brings it up. >> >> Regards >> Michael Knill >> >> From: Michael Knill <mic...@ip...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Monday, 5 June 2017 at 11:26 am >> To: AstLinux List <ast...@li...> >> Subject: [Astlinux-users] Problems with losing SIP Trunk >> >> Hi group >> >> I have actually reported this problem before but it was using a different network connection. >> Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via a firewall so it is using NAT but I don't think it should matter. >> It appears that when there is a particular event that there is a temporary loss of connectivity, but not a link down event, qualify or SIP OPTIONS pings do not make it to the trunk provider (or back again as I have not been able to test). Performing an Asterisk reload fixes the problem immediately. >> >> Before reload: >> I managed to check the reload before and after firewall states: >> Source Port (#'s) Destination Port Protocol Packets Bytes TTL >> 192.168.2.5 5060 192.168.2.38 5060 UDP 28535 16835829 2:59 >> 192.168.2.5 5060 192.168.2.39 5060 UDP 17450 10280235 2:58 >> 192.168.2.5 5060 192.168.2.35 5060 UDP 16930 9948145 2:59 >> 192.168.2.5 5060 192.168.2.42 5060 UDP 12961 7604592 2:54 >> 192.168.2.5 5060 192.168.2.37 5060 UDP 3561 2019123 2:57 >> 192.168.2.5 5060 192.168.2.36 5060 UDP 3454 1952748 2:53 >> 124.171.212.155 50133 172.30.10.2 7123 TCP 222 56430 7199:59 >> 192.168.2.22 17500 192.168.2.255 17500 UDP 200 45600 0:55 >> 192.168.2.22 17500 255.255.255.255 17500 UDP 100 22800 0:55 >> 192.168.2.30 138 192.168.2.255 138 UDP 1 229 0:58 >> 172.30.10.2 8272 (10) 8.8.8.8 53 UDP 2 211 0:59 >> 172.30.10.2 56406 (2) 113.20.24.94 10051 TCP 2 120 1:11 >> 48 Total Firewall States >> >> After reload: >> Source Port (#'s) Destination Port Protocol Packets Bytes TTL >> 192.168.2.5 5060 192.168.2.38 5060 UDP 28773 16975982 2:57 >> 192.168.2.5 5060 192.168.2.35 5060 UDP 17821 10475864 2:59 >> 192.168.2.5 5060 192.168.2.39 5060 UDP 17596 10365993 2:58 >> 192.168.2.5 5060 192.168.2.42 5060 UDP 13069 7667552 2:50 >> 192.168.2.5 5060 192.168.2.37 5060 UDP 3591 2035954 2:50 >> 192.168.2.5 5060 192.168.2.36 5060 UDP 3484 1969553 2:58 >> 124.171.212.155 50133 172.30.10.2 7123 TCP 548 132258 7199:59 >> 192.168.2.22 17500 192.168.2.255 17500 UDP 214 48792 0:43 >> 192.168.2.22 17500 255.255.255.255 17500 UDP 107 24396 0:43 >> 172.30.10.2 5060 125.213.162.112 5060 UDP 2 1042 0:50 >> 172.30.10.2 31249 (3) 8.8.8.8 53 UDP 2 211 0:59 >> 172.30.10.2 56424 (2) 113.20.24.94 10051 TCP 2 120 1:39 >> 28 Total Firewall States >> >> My provider 125.213.162.112 is now there so I assume that the problem is not in the firewall that Astlinux traverses but the Astlinux firewall itself. >> I am sending OPTIONS pings every 30 seconds. Why would this not just set up the firewall state again? Maybe its an Asterisk problem? >> >> Any ideas? What should I check when it happens again? >> >> Regards >> Michael Knill > > Michael Michael http://www.mksolutions.info ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ 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.... ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ 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.... |
|
From: Michael K. <mic...@ip...> - 2017-06-08 11:01:26
|
Could Monit do it? I am playing with it now! Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Thursday, 8 June 2017 at 8:58 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > Am 08.06.2017 um 10:28 schrieb Michael Knill <mic...@ip...>: > > Ah so have you had similar problems to me then where Asterisk has still lost connectivity when PPPoE comes back? > Do you know why it does this? > > Regards > Michael Knill No not really, I just let the cron script run so that the ISP disconnect does not occur during office time. It would be nice if this could be monitored somehow and then action could be taken automatically (like with DynDNS). > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 6:24 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > > >> Am 08.06.2017 um 09:51 schrieb Michael Knill <mic...@ip...>: >> >> Slightly different but this happened again today. It was a registered trunk but I had to reload before it worked. >> >> Im beginning to think it's something to do with PPPoE/firewall. I have never had this problem at non PPPoE sites. >> >> Regards >> Michael Knill > > What I do at PPPoE sites is a cronjob that restarts PPPoE at 03:00, waits an amount of time (20-180 seconds, needs to be tested) and then restarts DNS and reloads Asterisk (whatever you need). > Usually the ISPs disconnect the DSL lines every 24 hours (at least here in Germany). > >> From: Michael Knill <mic...@ip...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Wednesday, 7 June 2017 at 11:30 am >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >> >> And its happened again at another site. Astlinux rebooted this time which I hope was a power failure. >> It just seems like Asterisk doesn't know that its up. Any ideas on how I should test this when it happens again? DNS issue maybe? >> I might also try sip qualify peer from the cli to see if this brings it up. >> >> Regards >> Michael Knill >> >> From: Michael Knill <mic...@ip...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Monday, 5 June 2017 at 11:26 am >> To: AstLinux List <ast...@li...> >> Subject: [Astlinux-users] Problems with losing SIP Trunk >> >> Hi group >> >> I have actually reported this problem before but it was using a different network connection. >> Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via a firewall so it is using NAT but I don't think it should matter. >> It appears that when there is a particular event that there is a temporary loss of connectivity, but not a link down event, qualify or SIP OPTIONS pings do not make it to the trunk provider (or back again as I have not been able to test). Performing an Asterisk reload fixes the problem immediately. >> >> Before reload: >> I managed to check the reload before and after firewall states: >> Source Port (#'s) Destination Port Protocol Packets Bytes TTL >> 192.168.2.5 5060 192.168.2.38 5060 UDP 28535 16835829 2:59 >> 192.168.2.5 5060 192.168.2.39 5060 UDP 17450 10280235 2:58 >> 192.168.2.5 5060 192.168.2.35 5060 UDP 16930 9948145 2:59 >> 192.168.2.5 5060 192.168.2.42 5060 UDP 12961 7604592 2:54 >> 192.168.2.5 5060 192.168.2.37 5060 UDP 3561 2019123 2:57 >> 192.168.2.5 5060 192.168.2.36 5060 UDP 3454 1952748 2:53 >> 124.171.212.155 50133 172.30.10.2 7123 TCP 222 56430 7199:59 >> 192.168.2.22 17500 192.168.2.255 17500 UDP 200 45600 0:55 >> 192.168.2.22 17500 255.255.255.255 17500 UDP 100 22800 0:55 >> 192.168.2.30 138 192.168.2.255 138 UDP 1 229 0:58 >> 172.30.10.2 8272 (10) 8.8.8.8 53 UDP 2 211 0:59 >> 172.30.10.2 56406 (2) 113.20.24.94 10051 TCP 2 120 1:11 >> 48 Total Firewall States >> >> After reload: >> Source Port (#'s) Destination Port Protocol Packets Bytes TTL >> 192.168.2.5 5060 192.168.2.38 5060 UDP 28773 16975982 2:57 >> 192.168.2.5 5060 192.168.2.35 5060 UDP 17821 10475864 2:59 >> 192.168.2.5 5060 192.168.2.39 5060 UDP 17596 10365993 2:58 >> 192.168.2.5 5060 192.168.2.42 5060 UDP 13069 7667552 2:50 >> 192.168.2.5 5060 192.168.2.37 5060 UDP 3591 2035954 2:50 >> 192.168.2.5 5060 192.168.2.36 5060 UDP 3484 1969553 2:58 >> 124.171.212.155 50133 172.30.10.2 7123 TCP 548 132258 7199:59 >> 192.168.2.22 17500 192.168.2.255 17500 UDP 214 48792 0:43 >> 192.168.2.22 17500 255.255.255.255 17500 UDP 107 24396 0:43 >> 172.30.10.2 5060 125.213.162.112 5060 UDP 2 1042 0:50 >> 172.30.10.2 31249 (3) 8.8.8.8 53 UDP 2 211 0:59 >> 172.30.10.2 56424 (2) 113.20.24.94 10051 TCP 2 120 1:39 >> 28 Total Firewall States >> >> My provider 125.213.162.112 is now there so I assume that the problem is not in the firewall that Astlinux traverses but the Astlinux firewall itself. >> I am sending OPTIONS pings every 30 seconds. Why would this not just set up the firewall state again? Maybe its an Asterisk problem? >> >> Any ideas? What should I check when it happens again? >> >> Regards >> Michael Knill > > Michael Michael http://www.mksolutions.info ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ 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.... |
|
From: Michael K. <li...@mk...> - 2017-06-08 10:58:26
|
> Am 08.06.2017 um 10:28 schrieb Michael Knill <mic...@ip...>: > > Ah so have you had similar problems to me then where Asterisk has still lost connectivity when PPPoE comes back? > Do you know why it does this? > > Regards > Michael Knill No not really, I just let the cron script run so that the ISP disconnect does not occur during office time. It would be nice if this could be monitored somehow and then action could be taken automatically (like with DynDNS). > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 6:24 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > > >> Am 08.06.2017 um 09:51 schrieb Michael Knill <mic...@ip...>: >> >> Slightly different but this happened again today. It was a registered trunk but I had to reload before it worked. >> >> Im beginning to think it's something to do with PPPoE/firewall. I have never had this problem at non PPPoE sites. >> >> Regards >> Michael Knill > > What I do at PPPoE sites is a cronjob that restarts PPPoE at 03:00, waits an amount of time (20-180 seconds, needs to be tested) and then restarts DNS and reloads Asterisk (whatever you need). > Usually the ISPs disconnect the DSL lines every 24 hours (at least here in Germany). > >> From: Michael Knill <mic...@ip...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Wednesday, 7 June 2017 at 11:30 am >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk >> >> And its happened again at another site. Astlinux rebooted this time which I hope was a power failure. >> It just seems like Asterisk doesn't know that its up. Any ideas on how I should test this when it happens again? DNS issue maybe? >> I might also try sip qualify peer from the cli to see if this brings it up. >> >> Regards >> Michael Knill >> >> From: Michael Knill <mic...@ip...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Monday, 5 June 2017 at 11:26 am >> To: AstLinux List <ast...@li...> >> Subject: [Astlinux-users] Problems with losing SIP Trunk >> >> Hi group >> >> I have actually reported this problem before but it was using a different network connection. >> Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via a firewall so it is using NAT but I don't think it should matter. >> It appears that when there is a particular event that there is a temporary loss of connectivity, but not a link down event, qualify or SIP OPTIONS pings do not make it to the trunk provider (or back again as I have not been able to test). Performing an Asterisk reload fixes the problem immediately. >> >> Before reload: >> I managed to check the reload before and after firewall states: >> Source Port (#'s) Destination Port Protocol Packets Bytes TTL >> 192.168.2.5 5060 192.168.2.38 5060 UDP 28535 16835829 2:59 >> 192.168.2.5 5060 192.168.2.39 5060 UDP 17450 10280235 2:58 >> 192.168.2.5 5060 192.168.2.35 5060 UDP 16930 9948145 2:59 >> 192.168.2.5 5060 192.168.2.42 5060 UDP 12961 7604592 2:54 >> 192.168.2.5 5060 192.168.2.37 5060 UDP 3561 2019123 2:57 >> 192.168.2.5 5060 192.168.2.36 5060 UDP 3454 1952748 2:53 >> 124.171.212.155 50133 172.30.10.2 7123 TCP 222 56430 7199:59 >> 192.168.2.22 17500 192.168.2.255 17500 UDP 200 45600 0:55 >> 192.168.2.22 17500 255.255.255.255 17500 UDP 100 22800 0:55 >> 192.168.2.30 138 192.168.2.255 138 UDP 1 229 0:58 >> 172.30.10.2 8272 (10) 8.8.8.8 53 UDP 2 211 0:59 >> 172.30.10.2 56406 (2) 113.20.24.94 10051 TCP 2 120 1:11 >> 48 Total Firewall States >> >> After reload: >> Source Port (#'s) Destination Port Protocol Packets Bytes TTL >> 192.168.2.5 5060 192.168.2.38 5060 UDP 28773 16975982 2:57 >> 192.168.2.5 5060 192.168.2.35 5060 UDP 17821 10475864 2:59 >> 192.168.2.5 5060 192.168.2.39 5060 UDP 17596 10365993 2:58 >> 192.168.2.5 5060 192.168.2.42 5060 UDP 13069 7667552 2:50 >> 192.168.2.5 5060 192.168.2.37 5060 UDP 3591 2035954 2:50 >> 192.168.2.5 5060 192.168.2.36 5060 UDP 3484 1969553 2:58 >> 124.171.212.155 50133 172.30.10.2 7123 TCP 548 132258 7199:59 >> 192.168.2.22 17500 192.168.2.255 17500 UDP 214 48792 0:43 >> 192.168.2.22 17500 255.255.255.255 17500 UDP 107 24396 0:43 >> 172.30.10.2 5060 125.213.162.112 5060 UDP 2 1042 0:50 >> 172.30.10.2 31249 (3) 8.8.8.8 53 UDP 2 211 0:59 >> 172.30.10.2 56424 (2) 113.20.24.94 10051 TCP 2 120 1:39 >> 28 Total Firewall States >> >> My provider 125.213.162.112 is now there so I assume that the problem is not in the firewall that Astlinux traverses but the Astlinux firewall itself. >> I am sending OPTIONS pings every 30 seconds. Why would this not just set up the firewall state again? Maybe its an Asterisk problem? >> >> Any ideas? What should I check when it happens again? >> >> Regards >> Michael Knill > > Michael Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2017-06-08 10:55:44
|
> Am 08.06.2017 um 10:33 schrieb Michael Knill <mic...@ip...>: > > Yes I thought about tags but really I would rather is not be sent at all. > Any other options for doing this? > > Regards > Michael Knill I have not tested how setting to null behaves: dhcp-option=lan,option:tftp-server,"" Needs to be tested. > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 6:20 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > >> Am 08.06.2017 um 09:48 schrieb Michael Knill <mic...@ip...>: >> >> Hi Michael >> So I already have enable-tftp=eth1.100,tun0 and the data interface is eth1. I think this command is for turning ON TFTP when DHCP is turned OFF. >> /etc/dnsmasq.conf has the tftp-server option included so I assume that it will still be there. >> >> Is there any way I can look at the actual config? >> I think I might plug a machine in and really see what I am getting. >> >> Regards >> Michael Knill > > OK, there might be another way around this with tags. > E.g.: > > ---- > dhcp-mac=set:yealink,00:15:65:*:*:* > dhcp-mac=set:phones,00:15:65:*:*:* > dhcp-option=tag:yealink,option:tftp-server,"http://192.168.102.1/phoneprov/yealink/" > > dhcp-mac=set:snom,00:04:13:*:*:* > dhcp-mac=set:phones,00:04:13:*:*:* > dhcp-option=tag:snom,option:tftp-server,"http://192.168.102.1/phoneprov/snom/" > > #dhcp-boot=tag:!phones,thinstation/pxelinux.0,pbx3,192.168.100.3 > ---- > > This way only "non-phones" would get the last "dhcp-boot" option > You could of course make other (more useful) tags. > > Just keep in mind "/etc/dnsmasq.conf" is automatically created and then "/mnt/kd/dnsmasq.static" is included into it. > >> -----Original Message----- >> From: Michael Keuter <li...@mk...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Thursday, 8 June 2017 at 5:39 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot >> >>> Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>: >>> >>> Hi group >>> >>> What is the best way to provide DHCP on an interface but turn off TFTP? >>> I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN! >>> >>> Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,"" >>> >>> Has anyone had this issue before? >>> >>> Regards >>> Michael Knill >> >> Hi Michael, >> >> from our AstLinux changelog :-) >> >> -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP. >> More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static". >> >> Michael > > Michael Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2017-06-08 08:33:14
|
Yes I thought about tags but really I would rather is not be sent at all. Any other options for doing this? Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Thursday, 8 June 2017 at 6:20 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > Am 08.06.2017 um 09:48 schrieb Michael Knill <mic...@ip...>: > > Hi Michael > So I already have enable-tftp=eth1.100,tun0 and the data interface is eth1. I think this command is for turning ON TFTP when DHCP is turned OFF. > /etc/dnsmasq.conf has the tftp-server option included so I assume that it will still be there. > > Is there any way I can look at the actual config? > I think I might plug a machine in and really see what I am getting. > > Regards > Michael Knill OK, there might be another way around this with tags. E.g.: ---- dhcp-mac=set:yealink,00:15:65:*:*:* dhcp-mac=set:phones,00:15:65:*:*:* dhcp-option=tag:yealink,option:tftp-server,"http://192.168.102.1/phoneprov/yealink/" dhcp-mac=set:snom,00:04:13:*:*:* dhcp-mac=set:phones,00:04:13:*:*:* dhcp-option=tag:snom,option:tftp-server,"http://192.168.102.1/phoneprov/snom/" #dhcp-boot=tag:!phones,thinstation/pxelinux.0,pbx3,192.168.100.3 ---- This way only "non-phones" would get the last "dhcp-boot" option You could of course make other (more useful) tags. Just keep in mind "/etc/dnsmasq.conf" is automatically created and then "/mnt/kd/dnsmasq.static" is included into it. > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 5:39 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > >> Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>: >> >> Hi group >> >> What is the best way to provide DHCP on an interface but turn off TFTP? >> I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN! >> >> Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,"" >> >> Has anyone had this issue before? >> >> Regards >> Michael Knill > > Hi Michael, > > from our AstLinux changelog :-) > > -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP. > More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static". > > Michael > > http://www.mksolutions.info Michael http://www.mksolutions.info ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ 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.... |
|
From: Michael K. <mic...@ip...> - 2017-06-08 08:28:43
|
Ah so have you had similar problems to me then where Asterisk has still lost connectivity when PPPoE comes back? Do you know why it does this? Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Thursday, 8 June 2017 at 6:24 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > Am 08.06.2017 um 09:51 schrieb Michael Knill <mic...@ip...>: > > Slightly different but this happened again today. It was a registered trunk but I had to reload before it worked. > > Im beginning to think it's something to do with PPPoE/firewall. I have never had this problem at non PPPoE sites. > > Regards > Michael Knill What I do at PPPoE sites is a cronjob that restarts PPPoE at 03:00, waits an amount of time (20-180 seconds, needs to be tested) and then restarts DNS and reloads Asterisk (whatever you need). Usually the ISPs disconnect the DSL lines every 24 hours (at least here in Germany). > From: Michael Knill <mic...@ip...> > Reply-To: AstLinux List <ast...@li...> > Date: Wednesday, 7 June 2017 at 11:30 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > > And its happened again at another site. Astlinux rebooted this time which I hope was a power failure. > It just seems like Asterisk doesn't know that its up. Any ideas on how I should test this when it happens again? DNS issue maybe? > I might also try sip qualify peer from the cli to see if this brings it up. > > Regards > Michael Knill > > From: Michael Knill <mic...@ip...> > Reply-To: AstLinux List <ast...@li...> > Date: Monday, 5 June 2017 at 11:26 am > To: AstLinux List <ast...@li...> > Subject: [Astlinux-users] Problems with losing SIP Trunk > > Hi group > > I have actually reported this problem before but it was using a different network connection. > Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via a firewall so it is using NAT but I don't think it should matter. > It appears that when there is a particular event that there is a temporary loss of connectivity, but not a link down event, qualify or SIP OPTIONS pings do not make it to the trunk provider (or back again as I have not been able to test). Performing an Asterisk reload fixes the problem immediately. > > Before reload: > I managed to check the reload before and after firewall states: > Source Port (#'s) Destination Port Protocol Packets Bytes TTL > 192.168.2.5 5060 192.168.2.38 5060 UDP 28535 16835829 2:59 > 192.168.2.5 5060 192.168.2.39 5060 UDP 17450 10280235 2:58 > 192.168.2.5 5060 192.168.2.35 5060 UDP 16930 9948145 2:59 > 192.168.2.5 5060 192.168.2.42 5060 UDP 12961 7604592 2:54 > 192.168.2.5 5060 192.168.2.37 5060 UDP 3561 2019123 2:57 > 192.168.2.5 5060 192.168.2.36 5060 UDP 3454 1952748 2:53 > 124.171.212.155 50133 172.30.10.2 7123 TCP 222 56430 7199:59 > 192.168.2.22 17500 192.168.2.255 17500 UDP 200 45600 0:55 > 192.168.2.22 17500 255.255.255.255 17500 UDP 100 22800 0:55 > 192.168.2.30 138 192.168.2.255 138 UDP 1 229 0:58 > 172.30.10.2 8272 (10) 8.8.8.8 53 UDP 2 211 0:59 > 172.30.10.2 56406 (2) 113.20.24.94 10051 TCP 2 120 1:11 > 48 Total Firewall States > > After reload: > Source Port (#'s) Destination Port Protocol Packets Bytes TTL > 192.168.2.5 5060 192.168.2.38 5060 UDP 28773 16975982 2:57 > 192.168.2.5 5060 192.168.2.35 5060 UDP 17821 10475864 2:59 > 192.168.2.5 5060 192.168.2.39 5060 UDP 17596 10365993 2:58 > 192.168.2.5 5060 192.168.2.42 5060 UDP 13069 7667552 2:50 > 192.168.2.5 5060 192.168.2.37 5060 UDP 3591 2035954 2:50 > 192.168.2.5 5060 192.168.2.36 5060 UDP 3484 1969553 2:58 > 124.171.212.155 50133 172.30.10.2 7123 TCP 548 132258 7199:59 > 192.168.2.22 17500 192.168.2.255 17500 UDP 214 48792 0:43 > 192.168.2.22 17500 255.255.255.255 17500 UDP 107 24396 0:43 > 172.30.10.2 5060 125.213.162.112 5060 UDP 2 1042 0:50 > 172.30.10.2 31249 (3) 8.8.8.8 53 UDP 2 211 0:59 > 172.30.10.2 56424 (2) 113.20.24.94 10051 TCP 2 120 1:39 > 28 Total Firewall States > > My provider 125.213.162.112 is now there so I assume that the problem is not in the firewall that Astlinux traverses but the Astlinux firewall itself. > I am sending OPTIONS pings every 30 seconds. Why would this not just set up the firewall state again? Maybe its an Asterisk problem? > > Any ideas? What should I check when it happens again? > > Regards > Michael Knill Michael http://www.mksolutions.info ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ 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.... |
|
From: Michael K. <li...@mk...> - 2017-06-08 08:24:40
|
> Am 08.06.2017 um 09:51 schrieb Michael Knill <mic...@ip...>: > > Slightly different but this happened again today. It was a registered trunk but I had to reload before it worked. > > Im beginning to think it's something to do with PPPoE/firewall. I have never had this problem at non PPPoE sites. > > Regards > Michael Knill What I do at PPPoE sites is a cronjob that restarts PPPoE at 03:00, waits an amount of time (20-180 seconds, needs to be tested) and then restarts DNS and reloads Asterisk (whatever you need). Usually the ISPs disconnect the DSL lines every 24 hours (at least here in Germany). > From: Michael Knill <mic...@ip...> > Reply-To: AstLinux List <ast...@li...> > Date: Wednesday, 7 June 2017 at 11:30 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with losing SIP Trunk > > And its happened again at another site. Astlinux rebooted this time which I hope was a power failure. > It just seems like Asterisk doesn't know that its up. Any ideas on how I should test this when it happens again? DNS issue maybe? > I might also try sip qualify peer from the cli to see if this brings it up. > > Regards > Michael Knill > > From: Michael Knill <mic...@ip...> > Reply-To: AstLinux List <ast...@li...> > Date: Monday, 5 June 2017 at 11:26 am > To: AstLinux List <ast...@li...> > Subject: [Astlinux-users] Problems with losing SIP Trunk > > Hi group > > I have actually reported this problem before but it was using a different network connection. > Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via a firewall so it is using NAT but I don't think it should matter. > It appears that when there is a particular event that there is a temporary loss of connectivity, but not a link down event, qualify or SIP OPTIONS pings do not make it to the trunk provider (or back again as I have not been able to test). Performing an Asterisk reload fixes the problem immediately. > > Before reload: > I managed to check the reload before and after firewall states: > Source Port (#'s) Destination Port Protocol Packets Bytes TTL > 192.168.2.5 5060 192.168.2.38 5060 UDP 28535 16835829 2:59 > 192.168.2.5 5060 192.168.2.39 5060 UDP 17450 10280235 2:58 > 192.168.2.5 5060 192.168.2.35 5060 UDP 16930 9948145 2:59 > 192.168.2.5 5060 192.168.2.42 5060 UDP 12961 7604592 2:54 > 192.168.2.5 5060 192.168.2.37 5060 UDP 3561 2019123 2:57 > 192.168.2.5 5060 192.168.2.36 5060 UDP 3454 1952748 2:53 > 124.171.212.155 50133 172.30.10.2 7123 TCP 222 56430 7199:59 > 192.168.2.22 17500 192.168.2.255 17500 UDP 200 45600 0:55 > 192.168.2.22 17500 255.255.255.255 17500 UDP 100 22800 0:55 > 192.168.2.30 138 192.168.2.255 138 UDP 1 229 0:58 > 172.30.10.2 8272 (10) 8.8.8.8 53 UDP 2 211 0:59 > 172.30.10.2 56406 (2) 113.20.24.94 10051 TCP 2 120 1:11 > 48 Total Firewall States > > After reload: > Source Port (#'s) Destination Port Protocol Packets Bytes TTL > 192.168.2.5 5060 192.168.2.38 5060 UDP 28773 16975982 2:57 > 192.168.2.5 5060 192.168.2.35 5060 UDP 17821 10475864 2:59 > 192.168.2.5 5060 192.168.2.39 5060 UDP 17596 10365993 2:58 > 192.168.2.5 5060 192.168.2.42 5060 UDP 13069 7667552 2:50 > 192.168.2.5 5060 192.168.2.37 5060 UDP 3591 2035954 2:50 > 192.168.2.5 5060 192.168.2.36 5060 UDP 3484 1969553 2:58 > 124.171.212.155 50133 172.30.10.2 7123 TCP 548 132258 7199:59 > 192.168.2.22 17500 192.168.2.255 17500 UDP 214 48792 0:43 > 192.168.2.22 17500 255.255.255.255 17500 UDP 107 24396 0:43 > 172.30.10.2 5060 125.213.162.112 5060 UDP 2 1042 0:50 > 172.30.10.2 31249 (3) 8.8.8.8 53 UDP 2 211 0:59 > 172.30.10.2 56424 (2) 113.20.24.94 10051 TCP 2 120 1:39 > 28 Total Firewall States > > My provider 125.213.162.112 is now there so I assume that the problem is not in the firewall that Astlinux traverses but the Astlinux firewall itself. > I am sending OPTIONS pings every 30 seconds. Why would this not just set up the firewall state again? Maybe its an Asterisk problem? > > Any ideas? What should I check when it happens again? > > Regards > Michael Knill Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2017-06-08 08:20:59
|
> Am 08.06.2017 um 09:48 schrieb Michael Knill <mic...@ip...>: > > Hi Michael > So I already have enable-tftp=eth1.100,tun0 and the data interface is eth1. I think this command is for turning ON TFTP when DHCP is turned OFF. > /etc/dnsmasq.conf has the tftp-server option included so I assume that it will still be there. > > Is there any way I can look at the actual config? > I think I might plug a machine in and really see what I am getting. > > Regards > Michael Knill OK, there might be another way around this with tags. E.g.: ---- dhcp-mac=set:yealink,00:15:65:*:*:* dhcp-mac=set:phones,00:15:65:*:*:* dhcp-option=tag:yealink,option:tftp-server,"http://192.168.102.1/phoneprov/yealink/" dhcp-mac=set:snom,00:04:13:*:*:* dhcp-mac=set:phones,00:04:13:*:*:* dhcp-option=tag:snom,option:tftp-server,"http://192.168.102.1/phoneprov/snom/" #dhcp-boot=tag:!phones,thinstation/pxelinux.0,pbx3,192.168.100.3 ---- This way only "non-phones" would get the last "dhcp-boot" option You could of course make other (more useful) tags. Just keep in mind "/etc/dnsmasq.conf" is automatically created and then "/mnt/kd/dnsmasq.static" is included into it. > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Thursday, 8 June 2017 at 5:39 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > >> Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>: >> >> Hi group >> >> What is the best way to provide DHCP on an interface but turn off TFTP? >> I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN! >> >> Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,"" >> >> Has anyone had this issue before? >> >> Regards >> Michael Knill > > Hi Michael, > > from our AstLinux changelog :-) > > -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP. > More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static". > > Michael > > http://www.mksolutions.info Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2017-06-08 07:51:22
|
Slightly different but this happened again today. It was a registered trunk but I had to reload before it worked. Im beginning to think it's something to do with PPPoE/firewall. I have never had this problem at non PPPoE sites. Regards Michael Knill From: Michael Knill <mic...@ip...> Reply-To: AstLinux List <ast...@li...> Date: Wednesday, 7 June 2017 at 11:30 am To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with losing SIP Trunk And its happened again at another site. Astlinux rebooted this time which I hope was a power failure. It just seems like Asterisk doesn't know that its up. Any ideas on how I should test this when it happens again? DNS issue maybe? I might also try sip qualify peer from the cli to see if this brings it up. Regards Michael Knill From: Michael Knill <mic...@ip...> Reply-To: AstLinux List <ast...@li...> Date: Monday, 5 June 2017 at 11:26 am To: AstLinux List <ast...@li...> Subject: [Astlinux-users] Problems with losing SIP Trunk Hi group I have actually reported this problem before but it was using a different network connection. Im on Astlinux 1.2.8 with a SIP Trunk e.g. not registered. This site is via a firewall so it is using NAT but I don't think it should matter. It appears that when there is a particular event that there is a temporary loss of connectivity, but not a link down event, qualify or SIP OPTIONS pings do not make it to the trunk provider (or back again as I have not been able to test). Performing an Asterisk reload fixes the problem immediately. Before reload: I managed to check the reload before and after firewall states: Source Port (#'s) Destination Port Protocol Packets Bytes TTL 192.168.2.5 5060 192.168.2.38 5060 UDP 28535 16835829 2:59 192.168.2.5 5060 192.168.2.39 5060 UDP 17450 10280235 2:58 192.168.2.5 5060 192.168.2.35 5060 UDP 16930 9948145 2:59 192.168.2.5 5060 192.168.2.42 5060 UDP 12961 7604592 2:54 192.168.2.5 5060 192.168.2.37 5060 UDP 3561 2019123 2:57 192.168.2.5 5060 192.168.2.36 5060 UDP 3454 1952748 2:53 124.171.212.155 50133 172.30.10.2 7123 TCP 222 56430 7199:59 192.168.2.22 17500 192.168.2.255 17500 UDP 200 45600 0:55 192.168.2.22 17500 255.255.255.255 17500 UDP 100 22800 0:55 192.168.2.30 138 192.168.2.255 138 UDP 1 229 0:58 172.30.10.2 8272 (10) 8.8.8.8 53 UDP 2 211 0:59 172.30.10.2 56406 (2) 113.20.24.94 10051 TCP 2 120 1:11 48 Total Firewall States After reload: Source Port (#'s) Destination Port Protocol Packets Bytes TTL 192.168.2.5 5060 192.168.2.38 5060 UDP 28773 16975982 2:57 192.168.2.5 5060 192.168.2.35 5060 UDP 17821 10475864 2:59 192.168.2.5 5060 192.168.2.39 5060 UDP 17596 10365993 2:58 192.168.2.5 5060 192.168.2.42 5060 UDP 13069 7667552 2:50 192.168.2.5 5060 192.168.2.37 5060 UDP 3591 2035954 2:50 192.168.2.5 5060 192.168.2.36 5060 UDP 3484 1969553 2:58 124.171.212.155 50133 172.30.10.2 7123 TCP 548 132258 7199:59 192.168.2.22 17500 192.168.2.255 17500 UDP 214 48792 0:43 192.168.2.22 17500 255.255.255.255 17500 UDP 107 24396 0:43 172.30.10.2 5060 125.213.162.112 5060 UDP 2 1042 0:50 172.30.10.2 31249 (3) 8.8.8.8 53 UDP 2 211 0:59 172.30.10.2 56424 (2) 113.20.24.94 10051 TCP 2 120 1:39 28 Total Firewall States My provider 125.213.162.112 is now there so I assume that the problem is not in the firewall that Astlinux traverses but the Astlinux firewall itself. I am sending OPTIONS pings every 30 seconds. Why would this not just set up the firewall state again? Maybe its an Asterisk problem? Any ideas? What should I check when it happens again? Regards Michael Knill |
|
From: Michael K. <mic...@ip...> - 2017-06-08 07:48:47
|
Hi Michael So I already have enable-tftp=eth1.100,tun0 and the data interface is eth1. I think this command is for turning ON TFTP when DHCP is turned OFF. /etc/dnsmasq.conf has the tftp-server option included so I assume that it will still be there. Is there any way I can look at the actual config? I think I might plug a machine in and really see what I am getting. Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Thursday, 8 June 2017 at 5:39 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Dnsmasq, TFTP Option 66 and PXE Boot > Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>: > > Hi group > > What is the best way to provide DHCP on an interface but turn off TFTP? > I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN! > > Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,"" > > Has anyone had this issue before? > > Regards > Michael Knill Hi Michael, from our AstLinux changelog :-) -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP. More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static". Michael http://www.mksolutions.info ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ 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.... |
|
From: Michael K. <li...@mk...> - 2017-06-08 07:39:13
|
> Am 08.06.2017 um 09:29 schrieb Michael Knill <mic...@ip...>: > > Hi group > > What is the best way to provide DHCP on an interface but turn off TFTP? > I have some Intel NUC’s on my data VLAN and I am providing DHCP and I suspect they are having bootup issues because they are trying to do a PXE boot from Option 66 which is being passed to them on the data VLAN! > > Can I set it to NULL e.g. dhcp-option=lan,option:tftp-server,"" > > Has anyone had this issue before? > > Regards > Michael Knill Hi Michael, from our AstLinux changelog :-) -- dnsmasq, version bump to 2.68, new feature allows "enable-tftp=" to define allowed interfaces for TFTP. More Info: View file "/stat/etc/dnsmasq.static" for syntax and make changes to "/mnt/kd/dnsmasq.static". Michael http://www.mksolutions.info |
63 messages has been excluded from this view by a project administrator.
