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: Lonnie A. <li...@lo...> - 2018-01-12 15:42:02
|
Hi Michael,
The easiest way to always make sure a DNS name resolves is to define static IP addresses in:
Network tab -> Network Services: -> DNS Forwarder & DHCP Server: { Configure DNS Hosts }
There you can statically define DNS host names without requiring any changes to your Asterisk configuration. Of course if your SIP provider makes changes you will have to reconfigure the DNS IP's like a bunny.
Another approach, or in tandem, is to not depend on OPTIONS pings (qualify=yes) to keep firewall ports open, instead (qualify=no) use very specific (secure) firewall rules for inbound SIP calls.
To be clear, it is not recommended to do either of the above as a general practice, but you do what you have to do.
Lonnie
On Jan 11, 2018, at 10:50 PM, Michael Knill <mic...@ip...> wrote:
> Hi Group
>
> I have started a new thread although this is a continuation of my intermittent issues with sip trunks not coming back after a network outage.
> After some testing in the lab I have realised that most of these problems are related to DNS resolution.
>
> Basically I am using sip domain names for all my providers so DNS resolution is necessary. What I have found is that if for some reason DNS resolution is not possible (e.g. network is down), if the system is rebooted or Asterisk loses the resolved address, it no longer sends the OPTIONS pings as it cant find the address obviously.
> Yes that makes sense however the problem arises when the network is restored, Asterisk is completely unaware and therefore makes no attempt in resolving the address.
> I believe this is what is causing my intermittent issues which is easily resolved by doing an Asterisk Reload when network connectivity is restored. I have also enabled the Asterisk dnsmgr which does not fix the problem. I suspect that if it couldn't initially resolve it then it gives up totally.
>
> So what is the fix. Here are some of my options:
> • Don't use DNS but just use the IP Address instead. This will most certainly resolve the issue but is it the best way? Something in the Hosts file maybe?
> • Perform sip monitoring using the SIP Monitor script or Monit. If the SIP URL is resolvable but the status is UNKNOWN then issue a module reload of chan_sip
> • Something else
>
> PS the SIP Monitor does not seem to work for me. It only sends me an email when the system is rebooted.
> Thanks all.
>
> Regards
> Michael Knill
> ------------------------------------------------------------------------------
> 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...> - 2018-01-12 04:50:57
|
Hi Group I have started a new thread although this is a continuation of my intermittent issues with sip trunks not coming back after a network outage. After some testing in the lab I have realised that most of these problems are related to DNS resolution. Basically I am using sip domain names for all my providers so DNS resolution is necessary. What I have found is that if for some reason DNS resolution is not possible (e.g. network is down), if the system is rebooted or Asterisk loses the resolved address, it no longer sends the OPTIONS pings as it cant find the address obviously. Yes that makes sense however the problem arises when the network is restored, Asterisk is completely unaware and therefore makes no attempt in resolving the address. I believe this is what is causing my intermittent issues which is easily resolved by doing an Asterisk Reload when network connectivity is restored. I have also enabled the Asterisk dnsmgr which does not fix the problem. I suspect that if it couldn't initially resolve it then it gives up totally. So what is the fix. Here are some of my options: 1. Don't use DNS but just use the IP Address instead. This will most certainly resolve the issue but is it the best way? Something in the Hosts file maybe? 2. Perform sip monitoring using the SIP Monitor script or Monit. If the SIP URL is resolvable but the status is UNKNOWN then issue a module reload of chan_sip 3. Something else PS the SIP Monitor does not seem to work for me. It only sends me an email when the system is rebooted. Thanks all. Regards Michael Knill |
|
From: Michael K. <li...@mk...> - 2018-01-07 23:26:14
|
Sent from a mobile device. Michael Keuter > Am 08.01.2018 um 00:12 schrieb Michael Knill <mic...@ip...>: > > Hi Michael. Yes it certainly would be great to have this working. > It looks like Asternic is OnBox only? Maybe the easiest is to ask Nicolas directly ... > Regards > Michael Knill > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Sunday, 7 January 2018 at 9:59 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] CDR Reporting and Analysis > >> Am 06.01.2018 um 01:57 schrieb Michael Knill <mic...@ip...>: >> >> Hi Group >> >> Im getting a number of requests from my customers for this and Im not quite sure which way to go. >> Here are my current options: >> • Roll my own on Astlinux – Certainly the best option but also the most time consuming and potentially costly >> • Use an external application e.g. CDR Stats – I am concerned about the integration requirements to Astlinux. Is anyone using this? >> • Some other option? >> >> I would love to hear what others are doing in this space. >> >> Regards >> Michael Knill > > Years ago I used the old (Areski) Asterisk-Stat (the predesessor of the current CDR Stats), with a MySQL connector (custom build was needed). > But at that time the GUI was quite barebone and nothing for my customers :-), so I used it only for my own testing. > > I looked at the "new" CDR Stats 3.x a while a ago. But it needs the "CDR Pusher" application which is Go based: > > http://docs.cdr-stats.org/en/latest/installation/configure-asterisk.html > > The good thing is, it is free and it supports more than one Asterisk server. I would be interested as well in CDR Stats (installed on a VM or so). > > Maybe there are other ways to e.g. rsync the CDR SQLite database regularly, to include Go or rewrite the Go script in a language AstLinux supports. > > https://github.com/cdr-stats/cdr-pusher > > BTW: Go 1.9 is already included in BR2 :-). > > Michael > > http://www.mksolutions.info > > PS: There is also another commercial CDR application from Nicolas Gaudino (the FOP2 guy): http://www.asternic.net/cdrreports/ > > > ------------------------------------------------------------------------------ > 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...> - 2018-01-07 23:12:29
|
Hi Michael. Yes it certainly would be great to have this working. It looks like Asternic is OnBox only? Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Sunday, 7 January 2018 at 9:59 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] CDR Reporting and Analysis > Am 06.01.2018 um 01:57 schrieb Michael Knill <mic...@ip...>: > > Hi Group > > Im getting a number of requests from my customers for this and Im not quite sure which way to go. > Here are my current options: > • Roll my own on Astlinux – Certainly the best option but also the most time consuming and potentially costly > • Use an external application e.g. CDR Stats – I am concerned about the integration requirements to Astlinux. Is anyone using this? > • Some other option? > > I would love to hear what others are doing in this space. > > Regards > Michael Knill Years ago I used the old (Areski) Asterisk-Stat (the predesessor of the current CDR Stats), with a MySQL connector (custom build was needed). But at that time the GUI was quite barebone and nothing for my customers :-), so I used it only for my own testing. I looked at the "new" CDR Stats 3.x a while a ago. But it needs the "CDR Pusher" application which is Go based: http://docs.cdr-stats.org/en/latest/installation/configure-asterisk.html The good thing is, it is free and it supports more than one Asterisk server. I would be interested as well in CDR Stats (installed on a VM or so). Maybe there are other ways to e.g. rsync the CDR SQLite database regularly, to include Go or rewrite the Go script in a language AstLinux supports. https://github.com/cdr-stats/cdr-pusher BTW: Go 1.9 is already included in BR2 :-). Michael http://www.mksolutions.info PS: There is also another commercial CDR application from Nicolas Gaudino (the FOP2 guy): http://www.asternic.net/cdrreports/ ------------------------------------------------------------------------------ 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...> - 2018-01-07 11:14:12
|
> Am 07.01.2018 um 11:59 schrieb Michael Keuter <li...@mk...>: > >> >> Am 06.01.2018 um 01:57 schrieb Michael Knill <mic...@ip...>: >> >> Hi Group >> >> Im getting a number of requests from my customers for this and Im not quite sure which way to go. >> Here are my current options: >> • Roll my own on Astlinux – Certainly the best option but also the most time consuming and potentially costly >> • Use an external application e.g. CDR Stats – I am concerned about the integration requirements to Astlinux. Is anyone using this? >> • Some other option? >> >> I would love to hear what others are doing in this space. >> >> Regards >> Michael Knill > > Years ago I used the old (Areski) Asterisk-Stat (the predesessor of the current CDR Stats), with a MySQL connector (custom build was needed). > But at that time the GUI was quite barebone and nothing for my customers :-), so I used it only for my own testing. > > I looked at the "new" CDR Stats 3.x a while a ago. But it needs the "CDR Pusher" application which is Go based: > > http://docs.cdr-stats.org/en/latest/installation/configure-asterisk.html > > The good thing is, it is free and it supports more than one Asterisk server. I would be interested as well in CDR Stats (installed on a VM or so). > > Maybe there are other ways to e.g. rsync the CDR SQLite database regularly, to include Go or rewrite the Go script in a language AstLinux supports. Update: Go is a compiler based language, so the CDR Pusher could be cross-compiled as a binary running on natively on AstLinux. > https://github.com/cdr-stats/cdr-pusher > > BTW: Go 1.9 is already included in BR2 :-). > > Michael > > http://www.mksolutions.info > > PS: There is also another commercial CDR application from Nicolas Gaudino (the FOP2 guy): http://www.asternic.net/cdrreports/ > > > ------------------------------------------------------------------------------ > 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.... Michael http://www.mksolutions.info |
|
From: Michael K. <li...@mk...> - 2018-01-07 10:59:19
|
> Am 06.01.2018 um 01:57 schrieb Michael Knill <mic...@ip...>: > > Hi Group > > Im getting a number of requests from my customers for this and Im not quite sure which way to go. > Here are my current options: > • Roll my own on Astlinux – Certainly the best option but also the most time consuming and potentially costly > • Use an external application e.g. CDR Stats – I am concerned about the integration requirements to Astlinux. Is anyone using this? > • Some other option? > > I would love to hear what others are doing in this space. > > Regards > Michael Knill Years ago I used the old (Areski) Asterisk-Stat (the predesessor of the current CDR Stats), with a MySQL connector (custom build was needed). But at that time the GUI was quite barebone and nothing for my customers :-), so I used it only for my own testing. I looked at the "new" CDR Stats 3.x a while a ago. But it needs the "CDR Pusher" application which is Go based: http://docs.cdr-stats.org/en/latest/installation/configure-asterisk.html The good thing is, it is free and it supports more than one Asterisk server. I would be interested as well in CDR Stats (installed on a VM or so). Maybe there are other ways to e.g. rsync the CDR SQLite database regularly, to include Go or rewrite the Go script in a language AstLinux supports. https://github.com/cdr-stats/cdr-pusher BTW: Go 1.9 is already included in BR2 :-). Michael http://www.mksolutions.info PS: There is also another commercial CDR application from Nicolas Gaudino (the FOP2 guy): http://www.asternic.net/cdrreports/ |
|
From: Michael K. <mic...@ip...> - 2018-01-06 00:57:29
|
Hi Group Im getting a number of requests from my customers for this and Im not quite sure which way to go. Here are my current options: 1. Roll my own on Astlinux – Certainly the best option but also the most time consuming and potentially costly 2. Use an external application e.g. CDR Stats – I am concerned about the integration requirements to Astlinux. Is anyone using this? 3. Some other option? I would love to hear what others are doing in this space. Regards Michael Knill |
|
From: Michael K. <mic...@ip...> - 2017-12-26 14:59:55
|
Thanks Michael ( Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Tuesday, 26 December 2017 at 11:43 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > Am 26.12.2017 um 04:20 schrieb Michael Knill <mic...@ip...>: > > Hi Lonnie > > Sorry for the miscommunication. I have tried both already. > Maybe I have a faulty Ethernet port or driver? > > Regards > Michael Knill I don't think it is driver or hardware related. I had similar issues with all kinds of hardware: Alix 2D13, APU1/2, net5501, Jetway NF9HQL, NF9HG-2930, Proxmox VM (sometimes these boxes were the router, sometimes they were behind an upstream router). Only a reboot worked for me, if it wasn't a provider problem. > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 26 December 2017 at 1:00 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > > Give #2 a try again. > > If still no go, try this: > -- > arno-iptables-firewall stop ; arno-iptables-firewall start > -- > > Lonnie > > > On Dec 25, 2017, at 7:53 PM, Michael Knill <mic...@ip...> wrote: > >> Ok its happened again and I have an opportunity to do some troubleshooting. >> Unfortunately I have not been able to get it reachable after trying the following: >> 1) Add a discrete firewall rule for 5060 from the IP Address Pass Ext -> Local >> 2) Stop Asterisk, wait for 3 minutes and start Asterisk >> 3) Reload config >> >> Sip debug is multiple options pings with no response: >> OPTIONS sip:103.226.10.78 SIP/2.0. >> Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. >> Max-Forwards: 70. >> From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. >> To: <sip:103.226.10.78>. >> Contact: <sip:asterisk@124.148.24.56:5060>. >> Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. >> CSeq: 102 OPTIONS. >> User-Agent: IBCCM. >> Date: Tue, 26 Dec 2017 01:50:49 GMT. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. >> Supported: replaces. >> Content-Length: 0. >> >> U 2017/12/26 12:50:52.309751 124.148.24.56:5060 -> 103.226.10.78:5060 >> >> OPTIONS sip:103.226.10.78 SIP/2.0. >> Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. >> Max-Forwards: 70. >> From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. >> To: <sip:103.226.10.78>. >> Contact: <sip:asterisk@124.148.24.56:5060>. >> Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. >> CSeq: 102 OPTIONS. >> User-Agent: IBCCM. >> Date: Tue, 26 Dec 2017 01:50:49 GMT. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. >> Supported: replaces. >> Content-Length: 0. >> >> U 2017/12/26 12:50:53.309434 124.148.24.56:5060 -> 103.226.10.78:5060 >> >> OPTIONS sip:103.226.10.78 SIP/2.0. >> Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. >> Max-Forwards: 70. >> From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. >> To: <sip:103.226.10.78>. >> Contact: <sip:asterisk@124.148.24.56:5060>. >> Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. >> CSeq: 102 OPTIONS. >> User-Agent: IBCCM. >> Date: Tue, 26 Dec 2017 01:50:49 GMT. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. >> Supported: replaces. >> Content-Length: 0. >> >> U 2017/12/26 12:51:03.309654 124.148.24.56:5060 -> 103.226.10.78:5060 >> >> OPTIONS sip:103.226.10.78 SIP/2.0. >> Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK40f34f93. >> Max-Forwards: 70. >> From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as47f11228. >> To: <sip:103.226.10.78>. >> Contact: <sip:asterisk@124.148.24.56:5060>. >> Call-ID: 670c60845c515149354254b721550d6b@124.148.24.56:5060. >> CSeq: 102 OPTIONS. >> User-Agent: IBCCM. >> Date: Tue, 26 Dec 2017 01:51:03 GMT. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. >> Supported: replaces. >> Content-Length: 0. >> >> Its still broken so any further ideas for testing before I reboot? >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Michael Knill <mic...@ip...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 12:42 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Cool thanks Lonnie >> >> Looks like I will be adding some firewall rules to my default build. >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 12:50 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Michael, >> >> You stated the qualify yes/no tradeoffs perfectly. >> >> Personally I would use "no" if it is not needed, but if you like the latency check give "yes" a shot - the chance of messing-up a firewall state along the way should be low. >> >> Lonnie >> >> >> On Dec 18, 2017, at 7:37 PM, Michael Knill <mic...@ip...> wrote: >> >>> Thanks Lonnie >>> >>> Is there a reason why I would turn off qualify? Its kind of nice knowing whether your ITSP peer is up and it also can highlight potential network issues when you start getting lags and unreachables! >>> >>> But if there is a risk of it messing with the Firewall state then it may be worth doing. >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Tuesday, 19 December 2017 at 11:50 am >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>> >>> Hi Michael, >>> >>> My commercial SIP provider offers exactly the scenario I suggested, using static IPv4 authentication as you are doing. >>> >>> I used the same suggested setup for a dynamic remote trunk for years ... until I switched it to WireGuard a few weeks ago. Though it was a dynamic cable modem, not PPPoE. >>> >>> But, if you are having the same PPPoE issue with a commercial SIP provider, for your clients trying "qualify=no" and opening UDP 5060 from your IPv4 server host would be worth a try. >>> >>> Though going forward, if the server's IP changes you will have more editing to do for each remote client. >>> >>> Lonnie >>> >>> >>> On Dec 18, 2017, at 6:11 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> Hi Lonnie >>>> >>>> In this case it is an Astlinux box at the other end but I also have issues with SIP Trunk providers that I have no administrative control over. >>>> Interestingly I don't think this happens when you lose the PPPoE through network or Layer 1 issues. For this one it was LCP terminated by Peer which may do something differently. >>>> >>>> I was thinking therefore of adding a 5060 firewall rule for all my clients using the SIP Provider address ranges. Do you think that may solve this issue e.g. the firewall rule is static and not dynamic? >>>> Virtually all my systems have a static IP. >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Reply-To: AstLinux List <ast...@li...> >>>> Date: Tuesday, 19 December 2017 at 9:22 am >>>> To: AstLinux List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>> >>>> Hi Michael, >>>> >>>> What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. >>>> >>>> If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . >>>> >>>> Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define >>>> -- >>>> DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" >>>> -- >>>> for every remote dynamic client. >>>> >>>> In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. >>>> >>>> Possibly you can test with one trunk and see if it helps. >>>> >>>> Lonnie >>>> >>>> >>>> >>>> On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>>> Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. >>>>> >>>>> Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? >>>>> I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! >>>>> >>>>> Regards >>>>> Michael Knill >>>>> >>>>> -----Original Message----- >>>>> From: Lonnie Abelbeck <li...@lo...> >>>>> Reply-To: AstLinux List <ast...@li...> >>>>> Date: Tuesday, 19 December 2017 at 1:54 am >>>>> To: AstLinux List <ast...@li...> >>>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>>> >>>>> Hi Michael, >>>>> >>>>>> The terminating SIP server is actually another Astlinux box. >>>>> >>>>> Cool, so this should be solvable. >>>>> >>>>> Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. >>>>> >>>>> I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. >>>>> >>>>> Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. >>>>> >>>>> Lonnie >>>>> >>>>> PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) >>>>> >>>>> >>>>> >>>>> On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>>> Hi Lonnie >>>>>> >>>>>> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >>>>>> It's a static local IP Address (passed by PPPoE) and it did not change. >>>>>> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >>>>>> >>>>>> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >>>>>> >>>>>> I will try that. More testing required! >>>>>> >>>>>> Regards >>>>>> Michael Knill >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lonnie Abelbeck <li...@lo...> >>>>>> Reply-To: AstLinux List <ast...@li...> >>>>>> Date: Monday, 18 December 2017 at 3:39 pm >>>>>> To: AstLinux List <ast...@li...> >>>>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >>>>>> >>>>>> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >>>>>> >>>>>> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >>>>>> >>>>>> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >>>>>> >>>>>> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >>>>>> >>>>>> >>>>>>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>>>>>> Can you think of any good debugging I can do if it happens again? >>>>>> >>>>>> The next time, rather than rebooting, I would try from the CLI ... >>>>>> -- >>>>>> service asterisk stop >>>>>> (wait 3 minutes or more - use your watch) >>>>>> service asterisk init >>>>>> -- >>>>>> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >>>>>> >>>>>> Lonnie >>>>>> >>>>>> >>>>>> >>>>>> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >>>>>> >>>>>>> Hi Group >>>>>>> >>>>>>> I am still having issues with PPPoE and Asterisk connectivity. >>>>>>> >>>>>>> This happened over the weekend with one of my sites: >>>>>>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>>>>>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>>>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>>>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup 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-12-26 13:13:06
|
> Am 26.12.2017 um 04:20 schrieb Michael Knill <mic...@ip...>: > > Hi Lonnie > > Sorry for the miscommunication. I have tried both already. > Maybe I have a faulty Ethernet port or driver? > > Regards > Michael Knill I don't think it is driver or hardware related. I had similar issues with all kinds of hardware: Alix 2D13, APU1/2, net5501, Jetway NF9HQL, NF9HG-2930, Proxmox VM (sometimes these boxes were the router, sometimes they were behind an upstream router). Only a reboot worked for me, if it wasn't a provider problem. > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 26 December 2017 at 1:00 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > > Give #2 a try again. > > If still no go, try this: > -- > arno-iptables-firewall stop ; arno-iptables-firewall start > -- > > Lonnie > > > On Dec 25, 2017, at 7:53 PM, Michael Knill <mic...@ip...> wrote: > >> Ok its happened again and I have an opportunity to do some troubleshooting. >> Unfortunately I have not been able to get it reachable after trying the following: >> 1) Add a discrete firewall rule for 5060 from the IP Address Pass Ext -> Local >> 2) Stop Asterisk, wait for 3 minutes and start Asterisk >> 3) Reload config >> >> Sip debug is multiple options pings with no response: >> OPTIONS sip:103.226.10.78 SIP/2.0. >> Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. >> Max-Forwards: 70. >> From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. >> To: <sip:103.226.10.78>. >> Contact: <sip:asterisk@124.148.24.56:5060>. >> Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. >> CSeq: 102 OPTIONS. >> User-Agent: IBCCM. >> Date: Tue, 26 Dec 2017 01:50:49 GMT. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. >> Supported: replaces. >> Content-Length: 0. >> >> U 2017/12/26 12:50:52.309751 124.148.24.56:5060 -> 103.226.10.78:5060 >> >> OPTIONS sip:103.226.10.78 SIP/2.0. >> Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. >> Max-Forwards: 70. >> From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. >> To: <sip:103.226.10.78>. >> Contact: <sip:asterisk@124.148.24.56:5060>. >> Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. >> CSeq: 102 OPTIONS. >> User-Agent: IBCCM. >> Date: Tue, 26 Dec 2017 01:50:49 GMT. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. >> Supported: replaces. >> Content-Length: 0. >> >> U 2017/12/26 12:50:53.309434 124.148.24.56:5060 -> 103.226.10.78:5060 >> >> OPTIONS sip:103.226.10.78 SIP/2.0. >> Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. >> Max-Forwards: 70. >> From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. >> To: <sip:103.226.10.78>. >> Contact: <sip:asterisk@124.148.24.56:5060>. >> Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. >> CSeq: 102 OPTIONS. >> User-Agent: IBCCM. >> Date: Tue, 26 Dec 2017 01:50:49 GMT. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. >> Supported: replaces. >> Content-Length: 0. >> >> U 2017/12/26 12:51:03.309654 124.148.24.56:5060 -> 103.226.10.78:5060 >> >> OPTIONS sip:103.226.10.78 SIP/2.0. >> Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK40f34f93. >> Max-Forwards: 70. >> From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as47f11228. >> To: <sip:103.226.10.78>. >> Contact: <sip:asterisk@124.148.24.56:5060>. >> Call-ID: 670c60845c515149354254b721550d6b@124.148.24.56:5060. >> CSeq: 102 OPTIONS. >> User-Agent: IBCCM. >> Date: Tue, 26 Dec 2017 01:51:03 GMT. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. >> Supported: replaces. >> Content-Length: 0. >> >> Its still broken so any further ideas for testing before I reboot? >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Michael Knill <mic...@ip...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 12:42 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Cool thanks Lonnie >> >> Looks like I will be adding some firewall rules to my default build. >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 12:50 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Michael, >> >> You stated the qualify yes/no tradeoffs perfectly. >> >> Personally I would use "no" if it is not needed, but if you like the latency check give "yes" a shot - the chance of messing-up a firewall state along the way should be low. >> >> Lonnie >> >> >> On Dec 18, 2017, at 7:37 PM, Michael Knill <mic...@ip...> wrote: >> >>> Thanks Lonnie >>> >>> Is there a reason why I would turn off qualify? Its kind of nice knowing whether your ITSP peer is up and it also can highlight potential network issues when you start getting lags and unreachables! >>> >>> But if there is a risk of it messing with the Firewall state then it may be worth doing. >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Tuesday, 19 December 2017 at 11:50 am >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>> >>> Hi Michael, >>> >>> My commercial SIP provider offers exactly the scenario I suggested, using static IPv4 authentication as you are doing. >>> >>> I used the same suggested setup for a dynamic remote trunk for years ... until I switched it to WireGuard a few weeks ago. Though it was a dynamic cable modem, not PPPoE. >>> >>> But, if you are having the same PPPoE issue with a commercial SIP provider, for your clients trying "qualify=no" and opening UDP 5060 from your IPv4 server host would be worth a try. >>> >>> Though going forward, if the server's IP changes you will have more editing to do for each remote client. >>> >>> Lonnie >>> >>> >>> On Dec 18, 2017, at 6:11 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> Hi Lonnie >>>> >>>> In this case it is an Astlinux box at the other end but I also have issues with SIP Trunk providers that I have no administrative control over. >>>> Interestingly I don't think this happens when you lose the PPPoE through network or Layer 1 issues. For this one it was LCP terminated by Peer which may do something differently. >>>> >>>> I was thinking therefore of adding a 5060 firewall rule for all my clients using the SIP Provider address ranges. Do you think that may solve this issue e.g. the firewall rule is static and not dynamic? >>>> Virtually all my systems have a static IP. >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Reply-To: AstLinux List <ast...@li...> >>>> Date: Tuesday, 19 December 2017 at 9:22 am >>>> To: AstLinux List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>> >>>> Hi Michael, >>>> >>>> What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. >>>> >>>> If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . >>>> >>>> Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define >>>> -- >>>> DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" >>>> -- >>>> for every remote dynamic client. >>>> >>>> In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. >>>> >>>> Possibly you can test with one trunk and see if it helps. >>>> >>>> Lonnie >>>> >>>> >>>> >>>> On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>>> Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. >>>>> >>>>> Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? >>>>> I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! >>>>> >>>>> Regards >>>>> Michael Knill >>>>> >>>>> -----Original Message----- >>>>> From: Lonnie Abelbeck <li...@lo...> >>>>> Reply-To: AstLinux List <ast...@li...> >>>>> Date: Tuesday, 19 December 2017 at 1:54 am >>>>> To: AstLinux List <ast...@li...> >>>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>>> >>>>> Hi Michael, >>>>> >>>>>> The terminating SIP server is actually another Astlinux box. >>>>> >>>>> Cool, so this should be solvable. >>>>> >>>>> Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. >>>>> >>>>> I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. >>>>> >>>>> Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. >>>>> >>>>> Lonnie >>>>> >>>>> PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) >>>>> >>>>> >>>>> >>>>> On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>>> Hi Lonnie >>>>>> >>>>>> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >>>>>> It's a static local IP Address (passed by PPPoE) and it did not change. >>>>>> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >>>>>> >>>>>> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >>>>>> >>>>>> I will try that. More testing required! >>>>>> >>>>>> Regards >>>>>> Michael Knill >>>>>> >>>>>> -----Original Message----- >>>>>> From: Lonnie Abelbeck <li...@lo...> >>>>>> Reply-To: AstLinux List <ast...@li...> >>>>>> Date: Monday, 18 December 2017 at 3:39 pm >>>>>> To: AstLinux List <ast...@li...> >>>>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >>>>>> >>>>>> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >>>>>> >>>>>> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >>>>>> >>>>>> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >>>>>> >>>>>> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >>>>>> >>>>>> >>>>>>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>>>>>> Can you think of any good debugging I can do if it happens again? >>>>>> >>>>>> The next time, rather than rebooting, I would try from the CLI ... >>>>>> -- >>>>>> service asterisk stop >>>>>> (wait 3 minutes or more - use your watch) >>>>>> service asterisk init >>>>>> -- >>>>>> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >>>>>> >>>>>> Lonnie >>>>>> >>>>>> >>>>>> >>>>>> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >>>>>> >>>>>>> Hi Group >>>>>>> >>>>>>> I am still having issues with PPPoE and Asterisk connectivity. >>>>>>> >>>>>>> This happened over the weekend with one of my sites: >>>>>>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>>>>>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>>>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>>>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2017-12-26 03:20:36
|
Hi Lonnie Sorry for the miscommunication. I have tried both already. Maybe I have a faulty Ethernet port or driver? Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux List <ast...@li...> Date: Tuesday, 26 December 2017 at 1:00 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk Hi Michael, Give #2 a try again. If still no go, try this: -- arno-iptables-firewall stop ; arno-iptables-firewall start -- Lonnie On Dec 25, 2017, at 7:53 PM, Michael Knill <mic...@ip...> wrote: > Ok its happened again and I have an opportunity to do some troubleshooting. > Unfortunately I have not been able to get it reachable after trying the following: > 1) Add a discrete firewall rule for 5060 from the IP Address Pass Ext -> Local > 2) Stop Asterisk, wait for 3 minutes and start Asterisk > 3) Reload config > > Sip debug is multiple options pings with no response: > OPTIONS sip:103.226.10.78 SIP/2.0. > Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. > Max-Forwards: 70. > From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. > To: <sip:103.226.10.78>. > Contact: <sip:asterisk@124.148.24.56:5060>. > Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. > CSeq: 102 OPTIONS. > User-Agent: IBCCM. > Date: Tue, 26 Dec 2017 01:50:49 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. > Supported: replaces. > Content-Length: 0. > > U 2017/12/26 12:50:52.309751 124.148.24.56:5060 -> 103.226.10.78:5060 > > OPTIONS sip:103.226.10.78 SIP/2.0. > Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. > Max-Forwards: 70. > From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. > To: <sip:103.226.10.78>. > Contact: <sip:asterisk@124.148.24.56:5060>. > Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. > CSeq: 102 OPTIONS. > User-Agent: IBCCM. > Date: Tue, 26 Dec 2017 01:50:49 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. > Supported: replaces. > Content-Length: 0. > > U 2017/12/26 12:50:53.309434 124.148.24.56:5060 -> 103.226.10.78:5060 > > OPTIONS sip:103.226.10.78 SIP/2.0. > Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. > Max-Forwards: 70. > From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. > To: <sip:103.226.10.78>. > Contact: <sip:asterisk@124.148.24.56:5060>. > Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. > CSeq: 102 OPTIONS. > User-Agent: IBCCM. > Date: Tue, 26 Dec 2017 01:50:49 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. > Supported: replaces. > Content-Length: 0. > > U 2017/12/26 12:51:03.309654 124.148.24.56:5060 -> 103.226.10.78:5060 > > OPTIONS sip:103.226.10.78 SIP/2.0. > Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK40f34f93. > Max-Forwards: 70. > From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as47f11228. > To: <sip:103.226.10.78>. > Contact: <sip:asterisk@124.148.24.56:5060>. > Call-ID: 670c60845c515149354254b721550d6b@124.148.24.56:5060. > CSeq: 102 OPTIONS. > User-Agent: IBCCM. > Date: Tue, 26 Dec 2017 01:51:03 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. > Supported: replaces. > Content-Length: 0. > > Its still broken so any further ideas for testing before I reboot? > > Regards > Michael Knill > > -----Original Message----- > From: Michael Knill <mic...@ip...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 12:42 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Cool thanks Lonnie > > Looks like I will be adding some firewall rules to my default build. > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 12:50 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Michael, > > You stated the qualify yes/no tradeoffs perfectly. > > Personally I would use "no" if it is not needed, but if you like the latency check give "yes" a shot - the chance of messing-up a firewall state along the way should be low. > > Lonnie > > > On Dec 18, 2017, at 7:37 PM, Michael Knill <mic...@ip...> wrote: > >> Thanks Lonnie >> >> Is there a reason why I would turn off qualify? Its kind of nice knowing whether your ITSP peer is up and it also can highlight potential network issues when you start getting lags and unreachables! >> >> But if there is a risk of it messing with the Firewall state then it may be worth doing. >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 11:50 am >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Hi Michael, >> >> My commercial SIP provider offers exactly the scenario I suggested, using static IPv4 authentication as you are doing. >> >> I used the same suggested setup for a dynamic remote trunk for years ... until I switched it to WireGuard a few weeks ago. Though it was a dynamic cable modem, not PPPoE. >> >> But, if you are having the same PPPoE issue with a commercial SIP provider, for your clients trying "qualify=no" and opening UDP 5060 from your IPv4 server host would be worth a try. >> >> Though going forward, if the server's IP changes you will have more editing to do for each remote client. >> >> Lonnie >> >> >> On Dec 18, 2017, at 6:11 PM, Michael Knill <mic...@ip...> wrote: >> >>> Hi Lonnie >>> >>> In this case it is an Astlinux box at the other end but I also have issues with SIP Trunk providers that I have no administrative control over. >>> Interestingly I don't think this happens when you lose the PPPoE through network or Layer 1 issues. For this one it was LCP terminated by Peer which may do something differently. >>> >>> I was thinking therefore of adding a 5060 firewall rule for all my clients using the SIP Provider address ranges. Do you think that may solve this issue e.g. the firewall rule is static and not dynamic? >>> Virtually all my systems have a static IP. >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Tuesday, 19 December 2017 at 9:22 am >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>> >>> Hi Michael, >>> >>> What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. >>> >>> If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . >>> >>> Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define >>> -- >>> DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" >>> -- >>> for every remote dynamic client. >>> >>> In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. >>> >>> Possibly you can test with one trunk and see if it helps. >>> >>> Lonnie >>> >>> >>> >>> On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. >>>> >>>> Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? >>>> I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Reply-To: AstLinux List <ast...@li...> >>>> Date: Tuesday, 19 December 2017 at 1:54 am >>>> To: AstLinux List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>> >>>> Hi Michael, >>>> >>>>> The terminating SIP server is actually another Astlinux box. >>>> >>>> Cool, so this should be solvable. >>>> >>>> Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. >>>> >>>> I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. >>>> >>>> Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. >>>> >>>> Lonnie >>>> >>>> PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) >>>> >>>> >>>> >>>> On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>>> Hi Lonnie >>>>> >>>>> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >>>>> It's a static local IP Address (passed by PPPoE) and it did not change. >>>>> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >>>>> >>>>> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >>>>> >>>>> I will try that. More testing required! >>>>> >>>>> Regards >>>>> Michael Knill >>>>> >>>>> -----Original Message----- >>>>> From: Lonnie Abelbeck <li...@lo...> >>>>> Reply-To: AstLinux List <ast...@li...> >>>>> Date: Monday, 18 December 2017 at 3:39 pm >>>>> To: AstLinux List <ast...@li...> >>>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>>> >>>>> Hi Michael, >>>>> >>>>> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >>>>> >>>>> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >>>>> >>>>> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >>>>> >>>>> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >>>>> >>>>> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >>>>> >>>>> >>>>>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>>>>> Can you think of any good debugging I can do if it happens again? >>>>> >>>>> The next time, rather than rebooting, I would try from the CLI ... >>>>> -- >>>>> service asterisk stop >>>>> (wait 3 minutes or more - use your watch) >>>>> service asterisk init >>>>> -- >>>>> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >>>>> >>>>> Lonnie >>>>> >>>>> >>>>> >>>>> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>>> Hi Group >>>>>> >>>>>> I am still having issues with PPPoE and Asterisk connectivity. >>>>>> >>>>>> This happened over the weekend with one of my sites: >>>>>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>>>>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup >>> >>> >>> ------------------------------------------------------------------------------ >>> 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.... >> >> >> ------------------------------------------------------------------------------ >> 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.... > > > ------------------------------------------------------------------------------ > 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-12-26 02:30:31
|
Hi Michael, Give #2 a try again. If still no go, try this: -- arno-iptables-firewall stop ; arno-iptables-firewall start -- Lonnie On Dec 25, 2017, at 7:53 PM, Michael Knill <mic...@ip...> wrote: > Ok its happened again and I have an opportunity to do some troubleshooting. > Unfortunately I have not been able to get it reachable after trying the following: > 1) Add a discrete firewall rule for 5060 from the IP Address Pass Ext -> Local > 2) Stop Asterisk, wait for 3 minutes and start Asterisk > 3) Reload config > > Sip debug is multiple options pings with no response: > OPTIONS sip:103.226.10.78 SIP/2.0. > Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. > Max-Forwards: 70. > From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. > To: <sip:103.226.10.78>. > Contact: <sip:asterisk@124.148.24.56:5060>. > Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. > CSeq: 102 OPTIONS. > User-Agent: IBCCM. > Date: Tue, 26 Dec 2017 01:50:49 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. > Supported: replaces. > Content-Length: 0. > > U 2017/12/26 12:50:52.309751 124.148.24.56:5060 -> 103.226.10.78:5060 > > OPTIONS sip:103.226.10.78 SIP/2.0. > Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. > Max-Forwards: 70. > From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. > To: <sip:103.226.10.78>. > Contact: <sip:asterisk@124.148.24.56:5060>. > Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. > CSeq: 102 OPTIONS. > User-Agent: IBCCM. > Date: Tue, 26 Dec 2017 01:50:49 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. > Supported: replaces. > Content-Length: 0. > > U 2017/12/26 12:50:53.309434 124.148.24.56:5060 -> 103.226.10.78:5060 > > OPTIONS sip:103.226.10.78 SIP/2.0. > Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. > Max-Forwards: 70. > From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. > To: <sip:103.226.10.78>. > Contact: <sip:asterisk@124.148.24.56:5060>. > Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. > CSeq: 102 OPTIONS. > User-Agent: IBCCM. > Date: Tue, 26 Dec 2017 01:50:49 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. > Supported: replaces. > Content-Length: 0. > > U 2017/12/26 12:51:03.309654 124.148.24.56:5060 -> 103.226.10.78:5060 > > OPTIONS sip:103.226.10.78 SIP/2.0. > Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK40f34f93. > Max-Forwards: 70. > From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as47f11228. > To: <sip:103.226.10.78>. > Contact: <sip:asterisk@124.148.24.56:5060>. > Call-ID: 670c60845c515149354254b721550d6b@124.148.24.56:5060. > CSeq: 102 OPTIONS. > User-Agent: IBCCM. > Date: Tue, 26 Dec 2017 01:51:03 GMT. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. > Supported: replaces. > Content-Length: 0. > > Its still broken so any further ideas for testing before I reboot? > > Regards > Michael Knill > > -----Original Message----- > From: Michael Knill <mic...@ip...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 12:42 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Cool thanks Lonnie > > Looks like I will be adding some firewall rules to my default build. > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 12:50 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Michael, > > You stated the qualify yes/no tradeoffs perfectly. > > Personally I would use "no" if it is not needed, but if you like the latency check give "yes" a shot - the chance of messing-up a firewall state along the way should be low. > > Lonnie > > > On Dec 18, 2017, at 7:37 PM, Michael Knill <mic...@ip...> wrote: > >> Thanks Lonnie >> >> Is there a reason why I would turn off qualify? Its kind of nice knowing whether your ITSP peer is up and it also can highlight potential network issues when you start getting lags and unreachables! >> >> But if there is a risk of it messing with the Firewall state then it may be worth doing. >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 11:50 am >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Hi Michael, >> >> My commercial SIP provider offers exactly the scenario I suggested, using static IPv4 authentication as you are doing. >> >> I used the same suggested setup for a dynamic remote trunk for years ... until I switched it to WireGuard a few weeks ago. Though it was a dynamic cable modem, not PPPoE. >> >> But, if you are having the same PPPoE issue with a commercial SIP provider, for your clients trying "qualify=no" and opening UDP 5060 from your IPv4 server host would be worth a try. >> >> Though going forward, if the server's IP changes you will have more editing to do for each remote client. >> >> Lonnie >> >> >> On Dec 18, 2017, at 6:11 PM, Michael Knill <mic...@ip...> wrote: >> >>> Hi Lonnie >>> >>> In this case it is an Astlinux box at the other end but I also have issues with SIP Trunk providers that I have no administrative control over. >>> Interestingly I don't think this happens when you lose the PPPoE through network or Layer 1 issues. For this one it was LCP terminated by Peer which may do something differently. >>> >>> I was thinking therefore of adding a 5060 firewall rule for all my clients using the SIP Provider address ranges. Do you think that may solve this issue e.g. the firewall rule is static and not dynamic? >>> Virtually all my systems have a static IP. >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Tuesday, 19 December 2017 at 9:22 am >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>> >>> Hi Michael, >>> >>> What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. >>> >>> If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . >>> >>> Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define >>> -- >>> DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" >>> -- >>> for every remote dynamic client. >>> >>> In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. >>> >>> Possibly you can test with one trunk and see if it helps. >>> >>> Lonnie >>> >>> >>> >>> On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. >>>> >>>> Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? >>>> I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Reply-To: AstLinux List <ast...@li...> >>>> Date: Tuesday, 19 December 2017 at 1:54 am >>>> To: AstLinux List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>> >>>> Hi Michael, >>>> >>>>> The terminating SIP server is actually another Astlinux box. >>>> >>>> Cool, so this should be solvable. >>>> >>>> Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. >>>> >>>> I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. >>>> >>>> Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. >>>> >>>> Lonnie >>>> >>>> PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) >>>> >>>> >>>> >>>> On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>>> Hi Lonnie >>>>> >>>>> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >>>>> It's a static local IP Address (passed by PPPoE) and it did not change. >>>>> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >>>>> >>>>> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >>>>> >>>>> I will try that. More testing required! >>>>> >>>>> Regards >>>>> Michael Knill >>>>> >>>>> -----Original Message----- >>>>> From: Lonnie Abelbeck <li...@lo...> >>>>> Reply-To: AstLinux List <ast...@li...> >>>>> Date: Monday, 18 December 2017 at 3:39 pm >>>>> To: AstLinux List <ast...@li...> >>>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>>> >>>>> Hi Michael, >>>>> >>>>> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >>>>> >>>>> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >>>>> >>>>> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >>>>> >>>>> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >>>>> >>>>> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >>>>> >>>>> >>>>>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>>>>> Can you think of any good debugging I can do if it happens again? >>>>> >>>>> The next time, rather than rebooting, I would try from the CLI ... >>>>> -- >>>>> service asterisk stop >>>>> (wait 3 minutes or more - use your watch) >>>>> service asterisk init >>>>> -- >>>>> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >>>>> >>>>> Lonnie >>>>> >>>>> >>>>> >>>>> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >>>>> >>>>>> Hi Group >>>>>> >>>>>> I am still having issues with PPPoE and Asterisk connectivity. >>>>>> >>>>>> This happened over the weekend with one of my sites: >>>>>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>>>>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup >>> >>> >>> ------------------------------------------------------------------------------ >>> 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.... >> >> >> ------------------------------------------------------------------------------ >> 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.... > > > ------------------------------------------------------------------------------ > 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-12-26 01:53:59
|
Ok its happened again and I have an opportunity to do some troubleshooting. Unfortunately I have not been able to get it reachable after trying the following: 1) Add a discrete firewall rule for 5060 from the IP Address Pass Ext -> Local 2) Stop Asterisk, wait for 3 minutes and start Asterisk 3) Reload config Sip debug is multiple options pings with no response: OPTIONS sip:103.226.10.78 SIP/2.0. Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. Max-Forwards: 70. From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. To: <sip:103.226.10.78>. Contact: <sip:asterisk@124.148.24.56:5060>. Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. CSeq: 102 OPTIONS. User-Agent: IBCCM. Date: Tue, 26 Dec 2017 01:50:49 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces. Content-Length: 0. U 2017/12/26 12:50:52.309751 124.148.24.56:5060 -> 103.226.10.78:5060 OPTIONS sip:103.226.10.78 SIP/2.0. Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. Max-Forwards: 70. From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. To: <sip:103.226.10.78>. Contact: <sip:asterisk@124.148.24.56:5060>. Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. CSeq: 102 OPTIONS. User-Agent: IBCCM. Date: Tue, 26 Dec 2017 01:50:49 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces. Content-Length: 0. U 2017/12/26 12:50:53.309434 124.148.24.56:5060 -> 103.226.10.78:5060 OPTIONS sip:103.226.10.78 SIP/2.0. Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK56ffba00. Max-Forwards: 70. From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as1daab990. To: <sip:103.226.10.78>. Contact: <sip:asterisk@124.148.24.56:5060>. Call-ID: 21e8014648d8d5d92f4051c42ff6dda3@124.148.24.56:5060. CSeq: 102 OPTIONS. User-Agent: IBCCM. Date: Tue, 26 Dec 2017 01:50:49 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces. Content-Length: 0. U 2017/12/26 12:51:03.309654 124.148.24.56:5060 -> 103.226.10.78:5060 OPTIONS sip:103.226.10.78 SIP/2.0. Via: SIP/2.0/UDP 124.148.24.56:5060;branch=z9hG4bK40f34f93. Max-Forwards: 70. From: "asterisk" <sip:asterisk@124.148.24.56>;tag=as47f11228. To: <sip:103.226.10.78>. Contact: <sip:asterisk@124.148.24.56:5060>. Call-ID: 670c60845c515149354254b721550d6b@124.148.24.56:5060. CSeq: 102 OPTIONS. User-Agent: IBCCM. Date: Tue, 26 Dec 2017 01:51:03 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces. Content-Length: 0. Its still broken so any further ideas for testing before I reboot? Regards Michael Knill -----Original Message----- From: Michael Knill <mic...@ip...> Reply-To: AstLinux List <ast...@li...> Date: Tuesday, 19 December 2017 at 12:42 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk Cool thanks Lonnie Looks like I will be adding some firewall rules to my default build. Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux List <ast...@li...> Date: Tuesday, 19 December 2017 at 12:50 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk Michael, You stated the qualify yes/no tradeoffs perfectly. Personally I would use "no" if it is not needed, but if you like the latency check give "yes" a shot - the chance of messing-up a firewall state along the way should be low. Lonnie On Dec 18, 2017, at 7:37 PM, Michael Knill <mic...@ip...> wrote: > Thanks Lonnie > > Is there a reason why I would turn off qualify? Its kind of nice knowing whether your ITSP peer is up and it also can highlight potential network issues when you start getting lags and unreachables! > > But if there is a risk of it messing with the Firewall state then it may be worth doing. > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 11:50 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > > My commercial SIP provider offers exactly the scenario I suggested, using static IPv4 authentication as you are doing. > > I used the same suggested setup for a dynamic remote trunk for years ... until I switched it to WireGuard a few weeks ago. Though it was a dynamic cable modem, not PPPoE. > > But, if you are having the same PPPoE issue with a commercial SIP provider, for your clients trying "qualify=no" and opening UDP 5060 from your IPv4 server host would be worth a try. > > Though going forward, if the server's IP changes you will have more editing to do for each remote client. > > Lonnie > > > On Dec 18, 2017, at 6:11 PM, Michael Knill <mic...@ip...> wrote: > >> Hi Lonnie >> >> In this case it is an Astlinux box at the other end but I also have issues with SIP Trunk providers that I have no administrative control over. >> Interestingly I don't think this happens when you lose the PPPoE through network or Layer 1 issues. For this one it was LCP terminated by Peer which may do something differently. >> >> I was thinking therefore of adding a 5060 firewall rule for all my clients using the SIP Provider address ranges. Do you think that may solve this issue e.g. the firewall rule is static and not dynamic? >> Virtually all my systems have a static IP. >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 9:22 am >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Hi Michael, >> >> What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. >> >> If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . >> >> Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define >> -- >> DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" >> -- >> for every remote dynamic client. >> >> In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. >> >> Possibly you can test with one trunk and see if it helps. >> >> Lonnie >> >> >> >> On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: >> >>> Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. >>> >>> Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? >>> I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Tuesday, 19 December 2017 at 1:54 am >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>> >>> Hi Michael, >>> >>>> The terminating SIP server is actually another Astlinux box. >>> >>> Cool, so this should be solvable. >>> >>> Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. >>> >>> I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. >>> >>> Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. >>> >>> Lonnie >>> >>> PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) >>> >>> >>> >>> On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> Hi Lonnie >>>> >>>> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >>>> It's a static local IP Address (passed by PPPoE) and it did not change. >>>> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >>>> >>>> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >>>> >>>> I will try that. More testing required! >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Reply-To: AstLinux List <ast...@li...> >>>> Date: Monday, 18 December 2017 at 3:39 pm >>>> To: AstLinux List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>> >>>> Hi Michael, >>>> >>>> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >>>> >>>> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >>>> >>>> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >>>> >>>> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >>>> >>>> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >>>> >>>> >>>>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>>>> Can you think of any good debugging I can do if it happens again? >>>> >>>> The next time, rather than rebooting, I would try from the CLI ... >>>> -- >>>> service asterisk stop >>>> (wait 3 minutes or more - use your watch) >>>> service asterisk init >>>> -- >>>> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >>>> >>>> Lonnie >>>> >>>> >>>> >>>> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>>> Hi Group >>>>> >>>>> I am still having issues with PPPoE and Asterisk connectivity. >>>>> >>>>> This happened over the weekend with one of my sites: >>>>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>>>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup >> >> >> ------------------------------------------------------------------------------ >> 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.... > > > ------------------------------------------------------------------------------ > 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. <mic...@ip...> - 2017-12-19 02:12:06
|
Cool thanks Lonnie Looks like I will be adding some firewall rules to my default build. Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux List <ast...@li...> Date: Tuesday, 19 December 2017 at 12:50 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk Michael, You stated the qualify yes/no tradeoffs perfectly. Personally I would use "no" if it is not needed, but if you like the latency check give "yes" a shot - the chance of messing-up a firewall state along the way should be low. Lonnie On Dec 18, 2017, at 7:37 PM, Michael Knill <mic...@ip...> wrote: > Thanks Lonnie > > Is there a reason why I would turn off qualify? Its kind of nice knowing whether your ITSP peer is up and it also can highlight potential network issues when you start getting lags and unreachables! > > But if there is a risk of it messing with the Firewall state then it may be worth doing. > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 11:50 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > > My commercial SIP provider offers exactly the scenario I suggested, using static IPv4 authentication as you are doing. > > I used the same suggested setup for a dynamic remote trunk for years ... until I switched it to WireGuard a few weeks ago. Though it was a dynamic cable modem, not PPPoE. > > But, if you are having the same PPPoE issue with a commercial SIP provider, for your clients trying "qualify=no" and opening UDP 5060 from your IPv4 server host would be worth a try. > > Though going forward, if the server's IP changes you will have more editing to do for each remote client. > > Lonnie > > > On Dec 18, 2017, at 6:11 PM, Michael Knill <mic...@ip...> wrote: > >> Hi Lonnie >> >> In this case it is an Astlinux box at the other end but I also have issues with SIP Trunk providers that I have no administrative control over. >> Interestingly I don't think this happens when you lose the PPPoE through network or Layer 1 issues. For this one it was LCP terminated by Peer which may do something differently. >> >> I was thinking therefore of adding a 5060 firewall rule for all my clients using the SIP Provider address ranges. Do you think that may solve this issue e.g. the firewall rule is static and not dynamic? >> Virtually all my systems have a static IP. >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 9:22 am >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Hi Michael, >> >> What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. >> >> If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . >> >> Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define >> -- >> DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" >> -- >> for every remote dynamic client. >> >> In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. >> >> Possibly you can test with one trunk and see if it helps. >> >> Lonnie >> >> >> >> On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: >> >>> Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. >>> >>> Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? >>> I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Tuesday, 19 December 2017 at 1:54 am >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>> >>> Hi Michael, >>> >>>> The terminating SIP server is actually another Astlinux box. >>> >>> Cool, so this should be solvable. >>> >>> Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. >>> >>> I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. >>> >>> Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. >>> >>> Lonnie >>> >>> PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) >>> >>> >>> >>> On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> Hi Lonnie >>>> >>>> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >>>> It's a static local IP Address (passed by PPPoE) and it did not change. >>>> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >>>> >>>> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >>>> >>>> I will try that. More testing required! >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Reply-To: AstLinux List <ast...@li...> >>>> Date: Monday, 18 December 2017 at 3:39 pm >>>> To: AstLinux List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>> >>>> Hi Michael, >>>> >>>> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >>>> >>>> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >>>> >>>> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >>>> >>>> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >>>> >>>> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >>>> >>>> >>>>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>>>> Can you think of any good debugging I can do if it happens again? >>>> >>>> The next time, rather than rebooting, I would try from the CLI ... >>>> -- >>>> service asterisk stop >>>> (wait 3 minutes or more - use your watch) >>>> service asterisk init >>>> -- >>>> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >>>> >>>> Lonnie >>>> >>>> >>>> >>>> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>>> Hi Group >>>>> >>>>> I am still having issues with PPPoE and Asterisk connectivity. >>>>> >>>>> This happened over the weekend with one of my sites: >>>>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>>>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup >> >> >> ------------------------------------------------------------------------------ >> 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.... > > > ------------------------------------------------------------------------------ > 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-12-19 01:50:21
|
Michael, You stated the qualify yes/no tradeoffs perfectly. Personally I would use "no" if it is not needed, but if you like the latency check give "yes" a shot - the chance of messing-up a firewall state along the way should be low. Lonnie On Dec 18, 2017, at 7:37 PM, Michael Knill <mic...@ip...> wrote: > Thanks Lonnie > > Is there a reason why I would turn off qualify? Its kind of nice knowing whether your ITSP peer is up and it also can highlight potential network issues when you start getting lags and unreachables! > > But if there is a risk of it messing with the Firewall state then it may be worth doing. > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 11:50 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > > My commercial SIP provider offers exactly the scenario I suggested, using static IPv4 authentication as you are doing. > > I used the same suggested setup for a dynamic remote trunk for years ... until I switched it to WireGuard a few weeks ago. Though it was a dynamic cable modem, not PPPoE. > > But, if you are having the same PPPoE issue with a commercial SIP provider, for your clients trying "qualify=no" and opening UDP 5060 from your IPv4 server host would be worth a try. > > Though going forward, if the server's IP changes you will have more editing to do for each remote client. > > Lonnie > > > On Dec 18, 2017, at 6:11 PM, Michael Knill <mic...@ip...> wrote: > >> Hi Lonnie >> >> In this case it is an Astlinux box at the other end but I also have issues with SIP Trunk providers that I have no administrative control over. >> Interestingly I don't think this happens when you lose the PPPoE through network or Layer 1 issues. For this one it was LCP terminated by Peer which may do something differently. >> >> I was thinking therefore of adding a 5060 firewall rule for all my clients using the SIP Provider address ranges. Do you think that may solve this issue e.g. the firewall rule is static and not dynamic? >> Virtually all my systems have a static IP. >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 9:22 am >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Hi Michael, >> >> What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. >> >> If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . >> >> Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define >> -- >> DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" >> -- >> for every remote dynamic client. >> >> In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. >> >> Possibly you can test with one trunk and see if it helps. >> >> Lonnie >> >> >> >> On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: >> >>> Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. >>> >>> Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? >>> I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Tuesday, 19 December 2017 at 1:54 am >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>> >>> Hi Michael, >>> >>>> The terminating SIP server is actually another Astlinux box. >>> >>> Cool, so this should be solvable. >>> >>> Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. >>> >>> I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. >>> >>> Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. >>> >>> Lonnie >>> >>> PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) >>> >>> >>> >>> On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> Hi Lonnie >>>> >>>> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >>>> It's a static local IP Address (passed by PPPoE) and it did not change. >>>> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >>>> >>>> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >>>> >>>> I will try that. More testing required! >>>> >>>> Regards >>>> Michael Knill >>>> >>>> -----Original Message----- >>>> From: Lonnie Abelbeck <li...@lo...> >>>> Reply-To: AstLinux List <ast...@li...> >>>> Date: Monday, 18 December 2017 at 3:39 pm >>>> To: AstLinux List <ast...@li...> >>>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>>> >>>> Hi Michael, >>>> >>>> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >>>> >>>> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >>>> >>>> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >>>> >>>> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >>>> >>>> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >>>> >>>> >>>>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>>>> Can you think of any good debugging I can do if it happens again? >>>> >>>> The next time, rather than rebooting, I would try from the CLI ... >>>> -- >>>> service asterisk stop >>>> (wait 3 minutes or more - use your watch) >>>> service asterisk init >>>> -- >>>> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >>>> >>>> Lonnie >>>> >>>> >>>> >>>> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >>>> >>>>> Hi Group >>>>> >>>>> I am still having issues with PPPoE and Asterisk connectivity. >>>>> >>>>> This happened over the weekend with one of my sites: >>>>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>>>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup >> >> >> ------------------------------------------------------------------------------ >> 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.... > > > ------------------------------------------------------------------------------ > 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-12-19 01:37:48
|
Thanks Lonnie Is there a reason why I would turn off qualify? Its kind of nice knowing whether your ITSP peer is up and it also can highlight potential network issues when you start getting lags and unreachables! But if there is a risk of it messing with the Firewall state then it may be worth doing. Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux List <ast...@li...> Date: Tuesday, 19 December 2017 at 11:50 am To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk Hi Michael, My commercial SIP provider offers exactly the scenario I suggested, using static IPv4 authentication as you are doing. I used the same suggested setup for a dynamic remote trunk for years ... until I switched it to WireGuard a few weeks ago. Though it was a dynamic cable modem, not PPPoE. But, if you are having the same PPPoE issue with a commercial SIP provider, for your clients trying "qualify=no" and opening UDP 5060 from your IPv4 server host would be worth a try. Though going forward, if the server's IP changes you will have more editing to do for each remote client. Lonnie On Dec 18, 2017, at 6:11 PM, Michael Knill <mic...@ip...> wrote: > Hi Lonnie > > In this case it is an Astlinux box at the other end but I also have issues with SIP Trunk providers that I have no administrative control over. > Interestingly I don't think this happens when you lose the PPPoE through network or Layer 1 issues. For this one it was LCP terminated by Peer which may do something differently. > > I was thinking therefore of adding a 5060 firewall rule for all my clients using the SIP Provider address ranges. Do you think that may solve this issue e.g. the firewall rule is static and not dynamic? > Virtually all my systems have a static IP. > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 9:22 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > > What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. > > If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . > > Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define > -- > DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" > -- > for every remote dynamic client. > > In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. > > Possibly you can test with one trunk and see if it helps. > > Lonnie > > > > On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: > >> Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. >> >> Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? >> I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 1:54 am >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Hi Michael, >> >>> The terminating SIP server is actually another Astlinux box. >> >> Cool, so this should be solvable. >> >> Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. >> >> I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. >> >> Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. >> >> Lonnie >> >> PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) >> >> >> >> On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >> >>> Hi Lonnie >>> >>> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >>> It's a static local IP Address (passed by PPPoE) and it did not change. >>> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >>> >>> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >>> >>> I will try that. More testing required! >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Monday, 18 December 2017 at 3:39 pm >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>> >>> Hi Michael, >>> >>> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >>> >>> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >>> >>> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >>> >>> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >>> >>> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >>> >>> >>>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>>> Can you think of any good debugging I can do if it happens again? >>> >>> The next time, rather than rebooting, I would try from the CLI ... >>> -- >>> service asterisk stop >>> (wait 3 minutes or more - use your watch) >>> service asterisk init >>> -- >>> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >>> >>> Lonnie >>> >>> >>> >>> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> Hi Group >>>> >>>> I am still having issues with PPPoE and Asterisk connectivity. >>>> >>>> This happened over the weekend with one of my sites: >>>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup > > > ------------------------------------------------------------------------------ > 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-12-19 00:50:28
|
Hi Michael, My commercial SIP provider offers exactly the scenario I suggested, using static IPv4 authentication as you are doing. I used the same suggested setup for a dynamic remote trunk for years ... until I switched it to WireGuard a few weeks ago. Though it was a dynamic cable modem, not PPPoE. But, if you are having the same PPPoE issue with a commercial SIP provider, for your clients trying "qualify=no" and opening UDP 5060 from your IPv4 server host would be worth a try. Though going forward, if the server's IP changes you will have more editing to do for each remote client. Lonnie On Dec 18, 2017, at 6:11 PM, Michael Knill <mic...@ip...> wrote: > Hi Lonnie > > In this case it is an Astlinux box at the other end but I also have issues with SIP Trunk providers that I have no administrative control over. > Interestingly I don't think this happens when you lose the PPPoE through network or Layer 1 issues. For this one it was LCP terminated by Peer which may do something differently. > > I was thinking therefore of adding a 5060 firewall rule for all my clients using the SIP Provider address ranges. Do you think that may solve this issue e.g. the firewall rule is static and not dynamic? > Virtually all my systems have a static IP. > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 9:22 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > > What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. > > If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . > > Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define > -- > DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" > -- > for every remote dynamic client. > > In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. > > Possibly you can test with one trunk and see if it helps. > > Lonnie > > > > On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: > >> Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. >> >> Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? >> I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Tuesday, 19 December 2017 at 1:54 am >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Hi Michael, >> >>> The terminating SIP server is actually another Astlinux box. >> >> Cool, so this should be solvable. >> >> Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. >> >> I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. >> >> Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. >> >> Lonnie >> >> PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) >> >> >> >> On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: >> >>> Hi Lonnie >>> >>> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >>> It's a static local IP Address (passed by PPPoE) and it did not change. >>> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >>> >>> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >>> >>> I will try that. More testing required! >>> >>> Regards >>> Michael Knill >>> >>> -----Original Message----- >>> From: Lonnie Abelbeck <li...@lo...> >>> Reply-To: AstLinux List <ast...@li...> >>> Date: Monday, 18 December 2017 at 3:39 pm >>> To: AstLinux List <ast...@li...> >>> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >>> >>> Hi Michael, >>> >>> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >>> >>> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >>> >>> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >>> >>> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >>> >>> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >>> >>> >>>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>>> Can you think of any good debugging I can do if it happens again? >>> >>> The next time, rather than rebooting, I would try from the CLI ... >>> -- >>> service asterisk stop >>> (wait 3 minutes or more - use your watch) >>> service asterisk init >>> -- >>> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >>> >>> Lonnie >>> >>> >>> >>> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >>> >>>> Hi Group >>>> >>>> I am still having issues with PPPoE and Asterisk connectivity. >>>> >>>> This happened over the weekend with one of my sites: >>>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup > > > ------------------------------------------------------------------------------ > 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-12-19 00:11:43
|
Hi Lonnie In this case it is an Astlinux box at the other end but I also have issues with SIP Trunk providers that I have no administrative control over. Interestingly I don't think this happens when you lose the PPPoE through network or Layer 1 issues. For this one it was LCP terminated by Peer which may do something differently. I was thinking therefore of adding a 5060 firewall rule for all my clients using the SIP Provider address ranges. Do you think that may solve this issue e.g. the firewall rule is static and not dynamic? Virtually all my systems have a static IP. Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux List <ast...@li...> Date: Tuesday, 19 December 2017 at 9:22 am To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk Hi Michael, What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define -- DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" -- for every remote dynamic client. In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. Possibly you can test with one trunk and see if it helps. Lonnie On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: > Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. > > Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? > I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 1:54 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > >> The terminating SIP server is actually another Astlinux box. > > Cool, so this should be solvable. > > Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. > > I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. > > Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. > > Lonnie > > PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) > > > > On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: > >> Hi Lonnie >> >> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >> It's a static local IP Address (passed by PPPoE) and it did not change. >> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >> >> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >> >> I will try that. More testing required! >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Monday, 18 December 2017 at 3:39 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Hi Michael, >> >> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >> >> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >> >> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >> >> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >> >> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >> >> >>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>> Can you think of any good debugging I can do if it happens again? >> >> The next time, rather than rebooting, I would try from the CLI ... >> -- >> service asterisk stop >> (wait 3 minutes or more - use your watch) >> service asterisk init >> -- >> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >> >> Lonnie >> >> >> >> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >> >>> Hi Group >>> >>> I am still having issues with PPPoE and Asterisk connectivity. >>> >>> This happened over the weekend with one of my sites: >>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup ------------------------------------------------------------------------------ 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-12-18 22:22:34
|
Hi Michael, What you are currently doing works *almost* all the time, but there seems to be edge conditions when the PPPoE link cycles. If you don't need the server end "qualify=yes" to monitor the latency and/or immediate "channel not available" (which can also cause issues) ... I would consider "qualify=no" at the server end and add a UDP 5060 firewall rule for each remote static IPv4 SIP client. This also documents the SIP endpoints, easily disable one at the network level, etc. . Additionally, if the remote SIP clients are dynamic (w/ Dynamic DNS Update) and register with asterisk to authenticate, at the server end you can use the AIF dyndns-host-open plugin and define -- DYNDNS_HOST_OPEN_UDP="remote1.sip.tld~5060 remote2.sip.tld~5060" -- for every remote dynamic client. In all cases the remote SIP clients (static or dynamic) are configured with "qualify=yes" at the remote end to open their firewall. Possibly you can test with one trunk and see if it helps. Lonnie On Dec 18, 2017, at 3:23 PM, Michael Knill <mic...@ip...> wrote: > Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. > > Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? > I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Tuesday, 19 December 2017 at 1:54 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > >> The terminating SIP server is actually another Astlinux box. > > Cool, so this should be solvable. > > Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. > > I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. > > Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. > > Lonnie > > PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) > > > > On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: > >> Hi Lonnie >> >> No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. >> It's a static local IP Address (passed by PPPoE) and it did not change. >> The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. >> >> Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? >> >> I will try that. More testing required! >> >> Regards >> Michael Knill >> >> -----Original Message----- >> From: Lonnie Abelbeck <li...@lo...> >> Reply-To: AstLinux List <ast...@li...> >> Date: Monday, 18 December 2017 at 3:39 pm >> To: AstLinux List <ast...@li...> >> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk >> >> Hi Michael, >> >> I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? >> >> Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? >> >> This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. >> >> Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? >> >> Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? >> >> >>> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >>> Can you think of any good debugging I can do if it happens again? >> >> The next time, rather than rebooting, I would try from the CLI ... >> -- >> service asterisk stop >> (wait 3 minutes or more - use your watch) >> service asterisk init >> -- >> If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. >> >> Lonnie >> >> >> >> On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: >> >>> Hi Group >>> >>> I am still having issues with PPPoE and Asterisk connectivity. >>> >>> This happened over the weekend with one of my sites: >>> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >>> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >>> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >>> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup |
|
From: Michael K. <li...@mk...> - 2017-12-18 22:04:30
|
> Am 18.12.2017 um 22:23 schrieb Michael Knill <mic...@ip...>: > > Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. https://raw.githubusercontent.com/astlinux-project/astlinux/master/docs/ChangeLog.txt :-) > Maybe we should have a helpful Astlinux tools page one day. > > Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? > I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! > > Regards > Michael Knill Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2017-12-18 21:23:54
|
Awesome sipgrep! I keep finding new tools all the time that I wished I knew about earlier. Maybe we should have a helpful Astlinux tools page one day. Both ends use qualify (SIP OPTIONS) so the firewall state should always remain open but do you think that adding a static rule in the firewall more reliable? I was thinking of doing this for all my systems for security purposes but it may also remove the reliance on the firewall setting up dynamic states! Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux List <ast...@li...> Date: Tuesday, 19 December 2017 at 1:54 am To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk Hi Michael, > The terminating SIP server is actually another Astlinux box. Cool, so this should be solvable. Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. Lonnie PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: > Hi Lonnie > > No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. > It's a static local IP Address (passed by PPPoE) and it did not change. > The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. > > Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? > > I will try that. More testing required! > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Monday, 18 December 2017 at 3:39 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > > I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? > > Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? > > This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. > > Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? > > Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? > > >> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >> Can you think of any good debugging I can do if it happens again? > > The next time, rather than rebooting, I would try from the CLI ... > -- > service asterisk stop > (wait 3 minutes or more - use your watch) > service asterisk init > -- > If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. > > Lonnie > > > > On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: > >> Hi Group >> >> I am still having issues with PPPoE and Asterisk connectivity. >> >> This happened over the weekend with one of my sites: >> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to103.262.105.78: Network is unreachable >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to103.262.105.78:5060 returned -2: Network is unreachable >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data >> Dec 17 00:31:07 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 34 >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to 103.262.105.78: Network is unreachable >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to103.262.105.78:5060 returned -2: Network is unreachable >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data >> Dec 17 00:31:23 2005-Shaw_BG-CM1 user.info kernel: AIF:Dropped INPUT packet: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:02:60:40:02:01:41:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=146 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=5678 DPT=5678 LEN=126 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: PPP session is 3426 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.warn pppd[336]: Connected to e0:0e:da:4c:55:dd via interface eth0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: Using interface ppp0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connect: ppp0 <--> eth0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: PAP authentication succeeded >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: peer from calling number E0:0E:DA:4C:55:DD authorized >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: local IP address 124.148.24.56 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: remote IP address 150.101.32.171 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: primary DNS address 203.0.178.191 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: secondary DNS address 203.215.29.191 >> >> >> The PPPoE came back fine however the SIP Trunk did not come back. I tried an Asterisk reload an Asterisk restart and a firewall restart to no avail. >> I actually needed to reboot the box before it came back up. This has happened before >> >> Im running Astlinux 1.2.10 with Asterisk 13. >> >> Any ideas? >> >> Regards >> Michael Knill ------------------------------------------------------------------------------ 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-12-18 14:53:39
|
Hi Michael, > The terminating SIP server is actually another Astlinux box. Cool, so this should be solvable. Yes, as you suggested a sip debug on the Asterisk CLI (or use "sipgrep") would help ... if you can VPN into the server also a help during the failure. I would try setting qualify=yes to only the client end SIP trunk, not the server end, this would consistently establish new firewall states from the client to the server endpoint. I'm assuming the client end does not open UDP 5060 and relies on the outbound SIP OPTIONS traffic to establish the firewall state. Additionally, since your SIP trunk is authenticating on the static IPv4 address of the PPPoE endpoint, make sure that IPv4 address is indeed static during any PPPoE hiccups. Lonnie PS, this is a perfect scenario for placing the SIP trunk over a WireGuard VPN, for your future setup down the road :-) On Dec 17, 2017, at 10:56 PM, Michael Knill <mic...@ip...> wrote: > Hi Lonnie > > No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. > It's a static local IP Address (passed by PPPoE) and it did not change. > The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. > > Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? > > I will try that. More testing required! > > Regards > Michael Knill > > -----Original Message----- > From: Lonnie Abelbeck <li...@lo...> > Reply-To: AstLinux List <ast...@li...> > Date: Monday, 18 December 2017 at 3:39 pm > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > Hi Michael, > > I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? > > Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? > > This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. > > Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? > > Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? > > >> Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( >> Can you think of any good debugging I can do if it happens again? > > The next time, rather than rebooting, I would try from the CLI ... > -- > service asterisk stop > (wait 3 minutes or more - use your watch) > service asterisk init > -- > If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. > > Lonnie > > > > On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: > >> Hi Group >> >> I am still having issues with PPPoE and Asterisk connectivity. >> >> This happened over the weekend with one of my sites: >> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to103.262.105.78: Network is unreachable >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to103.262.105.78:5060 returned -2: Network is unreachable >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data >> Dec 17 00:31:07 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 34 >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to 103.262.105.78: Network is unreachable >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to103.262.105.78:5060 returned -2: Network is unreachable >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data >> Dec 17 00:31:23 2005-Shaw_BG-CM1 user.info kernel: AIF:Dropped INPUT packet: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:02:60:40:02:01:41:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=146 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=5678 DPT=5678 LEN=126 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: PPP session is 3426 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.warn pppd[336]: Connected to e0:0e:da:4c:55:dd via interface eth0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: Using interface ppp0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connect: ppp0 <--> eth0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: PAP authentication succeeded >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: peer from calling number E0:0E:DA:4C:55:DD authorized >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: local IP address 124.148.24.56 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: remote IP address 150.101.32.171 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: primary DNS address 203.0.178.191 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: secondary DNS address 203.215.29.191 >> >> >> The PPPoE came back fine however the SIP Trunk did not come back. I tried an Asterisk reload an Asterisk restart and a firewall restart to no avail. >> I actually needed to reboot the box before it came back up. This has happened before >> >> Im running Astlinux 1.2.10 with Asterisk 13. >> >> Any ideas? >> >> Regards >> Michael Knill |
|
From: Michael K. <mic...@ip...> - 2017-12-18 04:56:46
|
Hi Lonnie No it's an IP Address only SIP Trunk so no registration. Only Options Pings. I should have done a sip debug on the Asterisk CLI I think. It's a static local IP Address (passed by PPPoE) and it did not change. The terminating SIP Server has a single Public IP Address so there should be no NAT but I cannot guarantee. The terminating SIP server is actually another Astlinux box. Im just wondering; if no IP Address or Port had changed, shouldn't the firewall state remain the same anyway? I will try that. More testing required! Regards Michael Knill -----Original Message----- From: Lonnie Abelbeck <li...@lo...> Reply-To: AstLinux List <ast...@li...> Date: Monday, 18 December 2017 at 3:39 pm To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk Hi Michael, I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? > Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( > Can you think of any good debugging I can do if it happens again? The next time, rather than rebooting, I would try from the CLI ... -- service asterisk stop (wait 3 minutes or more - use your watch) service asterisk init -- If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. Lonnie On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: > Hi Group > > I am still having issues with PPPoE and Asterisk connectivity. > > This happened over the weekend with one of my sites: > Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 > Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) > Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer > Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. > Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. > Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. > Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup > Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to 103.226.10.78: Network is unreachable > Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to 103.226.10.78:5060 returned -2: Network is unreachable > Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data > Dec 17 00:31:07 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 34 > Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to 103.226.10.78: Network is unreachable > Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to 103.226.10.78:5060 returned -2: Network is unreachable > Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data > Dec 17 00:31:23 2005-Shaw_BG-CM1 user.info kernel: AIF:Dropped INPUT packet: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:02:60:40:02:01:41:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=146 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=5678 DPT=5678 LEN=126 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: PPP session is 3426 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.warn pppd[336]: Connected to e0:0e:da:4c:55:dd via interface eth0 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: Using interface ppp0 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connect: ppp0 <--> eth0 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: PAP authentication succeeded > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: peer from calling number E0:0E:DA:4C:55:DD authorized > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: local IP address 124.148.24.56 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: remote IP address 150.101.32.171 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: primary DNS address 203.0.178.191 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: secondary DNS address 203.215.29.191 > > > The PPPoE came back fine however the SIP Trunk did not come back. I tried an Asterisk reload an Asterisk restart and a firewall restart to no avail. > I actually needed to reboot the box before it came back up. This has happened before > > Im running Astlinux 1.2.10 with Asterisk 13. > > Any ideas? > > Regards > Michael Knill > ------------------------------------------------------------------------------ > 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-12-18 04:38:46
|
Hi Michael, I see your logs stopped after the PPPoE connection was reestablished. Are there a bunch of asterisk register timeouts after that point ? Does your PPPoE "local IP address" typically change every time the connection goes down and back up ? This does sound like a firewall invalid state issue and rebooting allows the invalid state's TTL to expire, BUT the firewall state is probably not in AstLinux but rather upstream. Is it possible there is NAT in the path between your PPPoE "local IP address" and the SIP server ? Does the remote SIP server resolve to a single IPv4 address, or is it a round-robin of IPv4 addresses ? > Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( > Can you think of any good debugging I can do if it happens again? The next time, rather than rebooting, I would try from the CLI ... -- service asterisk stop (wait 3 minutes or more - use your watch) service asterisk init -- If that re-establishes SIP connectivity, that would imply the stuck-firewall-state was upstream. Lonnie On Dec 17, 2017, at 4:43 PM, Michael Knill <mic...@ip...> wrote: > Hi Group > > I am still having issues with PPPoE and Asterisk connectivity. > > This happened over the weekend with one of my sites: > Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 > Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) > Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer > Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. > Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. > Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. > Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup > Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to 103.226.10.78: Network is unreachable > Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to 103.226.10.78:5060 returned -2: Network is unreachable > Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data > Dec 17 00:31:07 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 34 > Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to 103.226.10.78: Network is unreachable > Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to 103.226.10.78:5060 returned -2: Network is unreachable > Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data > Dec 17 00:31:23 2005-Shaw_BG-CM1 user.info kernel: AIF:Dropped INPUT packet: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:02:60:40:02:01:41:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=146 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=5678 DPT=5678 LEN=126 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: PPP session is 3426 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.warn pppd[336]: Connected to e0:0e:da:4c:55:dd via interface eth0 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: Using interface ppp0 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connect: ppp0 <--> eth0 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: PAP authentication succeeded > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: peer from calling number E0:0E:DA:4C:55:DD authorized > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: local IP address 124.148.24.56 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: remote IP address 150.101.32.171 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: primary DNS address 203.0.178.191 > Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: secondary DNS address 203.215.29.191 > > > The PPPoE came back fine however the SIP Trunk did not come back. I tried an Asterisk reload an Asterisk restart and a firewall restart to no avail. > I actually needed to reboot the box before it came back up. This has happened before > > Im running Astlinux 1.2.10 with Asterisk 13. > > Any ideas? > > Regards > Michael Knill > ------------------------------------------------------------------------------ > 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-12-18 02:34:04
|
Yes I agree. I think it's a firewall problem although a Restart Firewall did not fix it ( Can you think of any good debugging I can do if it happens again? Regards Michael Knill -----Original Message----- From: Michael Keuter <li...@mk...> Reply-To: AstLinux List <ast...@li...> Date: Monday, 18 December 2017 at 11:39 am To: AstLinux List <ast...@li...> Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk I don't think it is the PPPoE client, because I have these issues also on boxes where PPPoE is handled by another router in front of AstLinux. It could be a kind of timeout of firewall ports, which are "cleared" in the time when Astlinux reboots (60-80 seconds) ... Or something else ... Sent from a mobile device. Michael Keuter > Am 18.12.2017 um 01:08 schrieb Michael Knill <mic...@ip...>: > > Hmm thanks Michael. > I wonder if it is an Asterisk problem. I don't think so as I restarted Asterisk and it didn't fix it. > Would it be more likely that its the PPPoE client or firewall? > > Regards > Michael Knill > > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Monday, 18 December 2017 at 10:43 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > >> Am 17.12.2017 um 23:43 schrieb Michael Knill <mic...@ip...>: >> >> Hi Group >> >> I am still having issues with PPPoE and Asterisk connectivity. >> >> This happened over the weekend with one of my sites: >> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to 103.226.10.78: Network is unreachable >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to 103.226.10.78:5060 returned -2: Network is unreachable >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data >> Dec 17 00:31:07 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 34 >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to 103.226.10.78: Network is unreachable >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to 103.226.10.78:5060 returned -2: Network is unreachable >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data >> Dec 17 00:31:23 2005-Shaw_BG-CM1 user.info kernel: AIF:Dropped INPUT packet: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:02:60:40:02:01:41:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=146 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=5678 DPT=5678 LEN=126 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: PPP session is 3426 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.warn pppd[336]: Connected to e0:0e:da:4c:55:dd via interface eth0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: Using interface ppp0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connect: ppp0 <--> eth0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: PAP authentication succeeded >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: peer from calling number E0:0E:DA:4C:55:DD authorized >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: local IP address 124.148.24.56 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: remote IP address 150.101.32.171 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: primary DNS address 203.0.178.191 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: secondary DNS address 203.215.29.191 >> >> >> The PPPoE came back fine however the SIP Trunk did not come back. I tried an Asterisk reload an Asterisk restart and a firewall restart to no avail. >> I actually needed to reboot the box before it came back up. This has happened before >> >> Im running Astlinux 1.2.10 with Asterisk 13. >> >> Any ideas? >> >> Regards >> Michael Knill > > I have seen the same behaviour too with Asterisk 11. > > 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-12-18 00:38:42
|
I don't think it is the PPPoE client, because I have these issues also on boxes where PPPoE is handled by another router in front of AstLinux. It could be a kind of timeout of firewall ports, which are "cleared" in the time when Astlinux reboots (60-80 seconds) ... Or something else ... Sent from a mobile device. Michael Keuter > Am 18.12.2017 um 01:08 schrieb Michael Knill <mic...@ip...>: > > Hmm thanks Michael. > I wonder if it is an Asterisk problem. I don't think so as I restarted Asterisk and it didn't fix it. > Would it be more likely that its the PPPoE client or firewall? > > Regards > Michael Knill > > -----Original Message----- > From: Michael Keuter <li...@mk...> > Reply-To: AstLinux List <ast...@li...> > Date: Monday, 18 December 2017 at 10:43 am > To: AstLinux List <ast...@li...> > Subject: Re: [Astlinux-users] Problems with PPPoE and Asterisk > > >> Am 17.12.2017 um 23:43 schrieb Michael Knill <mic...@ip...>: >> >> Hi Group >> >> I am still having issues with PPPoE and Asterisk connectivity. >> >> This happened over the weekend with one of my sites: >> Dec 17 00:30:09 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 33 >> Dec 17 00:30:33 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:24558 in handle_response_peerpoke: Peer 'cts_trunk' is now Reachable. (34ms / 2000ms) >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: LCP terminated by peer >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Connect time 568.6 minutes. >> Dec 17 00:30:52 2005-Shaw_BG-CM1 daemon.info pppd[336]: Sent 1190012 bytes, received 1282467 bytes. >> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connection terminated. >> Dec 17 00:30:55 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Modem hangup >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to 103.226.10.78: Network is unreachable >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to 103.226.10.78:5060 returned -2: Network is unreachable >> Dec 17 00:31:03 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data >> Dec 17 00:31:07 2005-Shaw_BG-CM1 local0.notice asterisk[1266]: NOTICE[1408]: chan_sip.c:30077 in sip_poke_noanswer: Peer 'cts_trunk' is now UNREACHABLE! Last qualify: 34 >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: acl.c:939 in ast_ouraddrfor: Cannot connect to 103.226.10.78: Network is unreachable >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.warn asterisk[1266]: WARNING[1408]: chan_sip.c:3785 in __sip_xmit: sip_xmit of 0x1ef58a0 (len 511) to 103.226.10.78:5060 returned -2: Network is unreachable >> Dec 17 00:31:17 2005-Shaw_BG-CM1 local0.err asterisk[1266]: ERROR[1408]: chan_sip.c:4274 in __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data >> Dec 17 00:31:23 2005-Shaw_BG-CM1 user.info kernel: AIF:Dropped INPUT packet: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:02:60:40:02:01:41:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=146 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=5678 DPT=5678 LEN=126 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: PPP session is 3426 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.warn pppd[336]: Connected to e0:0e:da:4c:55:dd via interface eth0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.info pppd[336]: Using interface ppp0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: Connect: ppp0 <--> eth0 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: PAP authentication succeeded >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: peer from calling number E0:0E:DA:4C:55:DD authorized >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: local IP address 124.148.24.56 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: remote IP address 150.101.32.171 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: primary DNS address 203.0.178.191 >> Dec 17 00:31:25 2005-Shaw_BG-CM1 daemon.notice pppd[336]: secondary DNS address 203.215.29.191 >> >> >> The PPPoE came back fine however the SIP Trunk did not come back. I tried an Asterisk reload an Asterisk restart and a firewall restart to no avail. >> I actually needed to reboot the box before it came back up. This has happened before >> >> Im running Astlinux 1.2.10 with Asterisk 13. >> >> Any ideas? >> >> Regards >> Michael Knill > > I have seen the same behaviour too with Asterisk 11. > > 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.... |
63 messages has been excluded from this view by a project administrator.
