PAP2T and other VOIP adapters having intermittent problems

Home Page Forums Network Management ZeroShell PAP2T and other VOIP adapters having intermittent problems

This topic contains 12 replies, has 0 voices, and was last updated by  DrmCa 11 months, 1 week ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #44891

    DrmCa
    Participant

    Linksys PAP2T works better than others, but every once in a while it looses registration and requires that each line’s port number be changed to any previously unused value. Example: line#1 is 5060, line#2 is 5061, it will not work one day until I change those to 5063 and 5062. Then it will work for another few weeks or months, and lose registration again. I’ll then flip lines back to 5060 and 5061 and so on, so forth.

    The issue only behind ZS. I am not having any of that in another location behind a soap box router. All with the same ISP and VOIP provider.

    Other adapters are having even more problems, but I want to get to the bottom of PAP2T issues first.

    Any ideas?
    Thank you!

    #54607

    iulyb
    Member

    Hi,

    I had this issue and reported it before. Not sure who recommended the fix but conntrack restart fix it for me.


    /usr/local/sbin/conntrack -F
    #54608

    DrmCa
    Participant

    If I understand you correctly, you are probably suggesting restarting conntrack instead of playing with VOIP adapter ports?

    Or are you having a script restart it on a regular basis?

    #54609

    iulyb
    Member

    @drmca wrote:

    If I understand you correctly, you are probably suggesting restarting conntrack instead of playing with VOIP adapter ports?

    Yes, that s correct.

    Or are you having a script restart it on a regular basis?[/quote]

    No need for a script. An entry on crontab will suffice. Also an entry on scritps/cron should be enough.

    First you should see if the conntrack restart fix your issue. My PAP died more that 1 year ago and I replaced with an SPA 3102 and on this device it seems that all I need to do is to add this command on post boot entry on ZS, else will not register with the SIP server

    #54610

    Montikore
    Participant

    you can flush the connexion tracking in the web UI, under the firewall menu, connexion tracking tab. may be easier for testing

    #54611

    DrmCa
    Participant

    Got it, thanks again!

    I prefer setting up something automatic, as no one but myself has access to the router UI and for now users just go to the PAP2T web UI and flip port numbers. I don’t want to give them any access to the router.

    #54612

    DrmCa
    Participant

    @iulyb wrote:

    @drmca wrote:

    No need for a script. An entry on crontab will suffice. Also an entry on scritps/cron should be enough.

    Is there web UI for crontab editing?
    I see in the main page there is Scripts/Cron entry, it loads up a window where Cron is only mentioned as Crontab Shiboleth and it talks about scheduled updates. Is that where I add the command above to flush conntrack?

    #54613

    iulyb
    Member

    @iulyb wrote:

    @drmca wrote:

    No need for a script. An entry on crontab will suffice. Also an entry on scritps/cron should be enough.

    Is there web UI for crontab editing?
    I see in the main page there is Scripts/Cron entry, it loads up a window where Cron is only mentioned as Crontab Shiboleth and it talks about scheduled updates. Is that where I add the command above to flush conntrack?

    UI has an option to add custom jobs..
    On the lower screen there is an “Add job” button, name it PAP and just enter the script command. You will see a new entry named Crontab or Cronjob PAP that will be created having the scheduling available.
    The interface is not very intuitive but will do the job.

    #54614

    DrmCa
    Participant

    Got it, thanks!

    Just wondering why this problem became more frequent with the recent version of ZS. I was only having it every 3-6 months when I was on v.1 and v.2, but now on 3.5 it became a weekly thing. My LAN’s internet traffic did increase, and hardware changed from P4 Celeron to Atom. I also gotten rid of the load balanced 2nd DSL line and only have one now, otherwise this is the same profile as 10 years ago.

    #54615

    iulyb
    Member

    @drmca wrote:

    Got it, thanks!

    Just wondering why this problem became more frequent with the recent version of ZS. I was only having it every 3-6 months when I was on v.1 and v.2, but now on 3.5 it became a weekly thing. My LAN’s internet traffic did increase, and hardware changed from P4 Celeron to Atom. I also gotten rid of the load balanced 2nd DSL line and only have one now, otherwise this is the same profile as 10 years ago.

    Not sure on that, I started with v 2.1 or so on an alix about 7 years ago. At that time I had a PAP, and I don’t think it was any contrack just port forwarding on my side. Contrack is supposed to be better and no need for port forwarding.. well when it works. 🙂
    The version supplied on ZS on my v 2.7 is really really old, 0.9, current version that comes on ubuntu is > 1.4.
    We might need to try to compile a new conntrack version and try it

    #54616

    DrmCa
    Participant

    Ah, so that is why PAP2T did not need any port forwarding!
    Fascinating.
    On the contrary, Grandstream HT702 simply refused to work if I did not forward all ports it requried. And the funnyest part was that when I repaired PAP2T and put it back in service, ports 5060 and 5061 were still being forwarded to the HT702’s IP, but PAP2T still worked on a different IP with those same ports. This device just seems to work no matter what.
    Of course now I removed all port forwarding entries for VOIP from NAT, like it used to be back when I was using PAP2T.

    How did your PAP die? It may be repairable. Mine went into a cyclic reboot after I shut it down for half an hour to test HT702. Ended up re-soldering one of the power transistors and ceramic capacitors on the phone lines side after finding with a oscope that there was no PWM on its inductor. It works fine again.

    #54617

    iulyb
    Member

    My PAP probably died as a result of me but this was a long time ago and now probably has already been recycled :).
    I used by mistake a different power adaptor so I blow the internal power regulator. I figure out that I shorted something and used a different power adaptor so it was working again for 1 or 2 years then it finally died.
    I bought an SPA and set it up to be exactly like the PAP. SPA has an useless cheap router / gateway and only 1 line instead of 2.
    Since then I installed CSIP simple app on my smart phones so I use the app on my cell for outgoing and SPA for incoming on my 2 line landline. This setup works well on port 5060 as long as you don’t have a lot of calls.
    https://play.google.com/store/apps/details?id=com.csipsimple

    #54618

    DrmCa
    Participant

    I initially set the cron entry for once every 24 hours, but looks like that is not frequent enough, as PAP2T still loses registration once about every week.

    For now I set the interval to 1 hour, as running the command manually through the Test button does fix the issue.

    The old versions of ZS did not have this issue for sure.

    #54619

    DrmCa
    Participant

    Looks like setting the job onto 1h schedule fixed the issue.

    Thanks a lot, iulyb!

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.