> Am 26.12.2017 um 04:20 schrieb Michael Knill > <michael.kn...@ipcsolutions.com.au>: > > 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...@lonnie.abelbeck.com> > Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> > Date: Tuesday, 26 December 2017 at 1:00 pm > To: AstLinux List <astlinux-users@lists.sourceforge.net> > 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 > <michael.kn...@ipcsolutions.com.au> 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 <michael.kn...@ipcsolutions.com.au> >> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >> Date: Tuesday, 19 December 2017 at 12:42 pm >> To: AstLinux List <astlinux-users@lists.sourceforge.net> >> 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...@lonnie.abelbeck.com> >> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >> Date: Tuesday, 19 December 2017 at 12:50 pm >> To: AstLinux List <astlinux-users@lists.sourceforge.net> >> 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 >> <michael.kn...@ipcsolutions.com.au> 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...@lonnie.abelbeck.com> >>> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >>> Date: Tuesday, 19 December 2017 at 11:50 am >>> To: AstLinux List <astlinux-users@lists.sourceforge.net> >>> 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 >>> <michael.kn...@ipcsolutions.com.au> 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...@lonnie.abelbeck.com> >>>> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >>>> Date: Tuesday, 19 December 2017 at 9:22 am >>>> To: AstLinux List <astlinux-users@lists.sourceforge.net> >>>> 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 >>>> <michael.kn...@ipcsolutions.com.au> 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...@lonnie.abelbeck.com> >>>>> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >>>>> Date: Tuesday, 19 December 2017 at 1:54 am >>>>> To: AstLinux List <astlinux-users@lists.sourceforge.net> >>>>> 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 >>>>> <michael.kn...@ipcsolutions.com.au> 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...@lonnie.abelbeck.com> >>>>>> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net> >>>>>> Date: Monday, 18 December 2017 at 3:39 pm >>>>>> To: AstLinux List <astlinux-users@lists.sourceforge.net> >>>>>> 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 >>>>>> <michael.kn...@ipcsolutions.com.au> 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 Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org.
